septiembre 2017 – dademuchconnection

UML – Requirements Elicitation

28 septiembre, 201724 septiembre, 2022 carakenio73

The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a requirements specification and serves as a contract between the client and the developers…The requirements specification is structured and formalized during analysis to produce an analysis model…(August 7, 2017).

Actividad

WBS (Overview)

Fuente:

Object-Oriented Software Engineering
1. Requirement Elicitation concepts – Functional requirements
2. Requirement Elicitation activities -Identifying actors – Identifying scenarios – Identifying Use Cases – Identifying relationships between actors and Use Cases – Identifying Initial Analysis Objects -Identifying Non-functional requirements – Documenting Requirements Elicitation- (p 152).

A requirement is a feature that the system must have or a constraint that it must satisfy to be accepted by the client. Requirements engineering aims at defining the requirements of the system under construction. Requirements engineering includes two main activities; Requirements Elicitation, which results in the specification of the system that the client understands, and analysis, which results in an analysis model that the developers can unambiguously interpret. Requirements elicitation is the more challenging of the two because it requires the collaboration of several groups of participants with different backgrounds. On the one hand, the client and the users are experts in their domain and have a general idea of what the system should do, but they often have little experience in software development. On the other hand, the developers have experience in building systems, but often have little knowledge of the everyday environment of the users.

Requirement elicitation

Overview

Scenarios and use cases provide tools for bridging this gap. A scenario describes an example of system use in terms of a series of interactions between the user and the system. A use case is an abstraction that describes a class of scenarios. Both scenarios and use cases are written in natural language, a form that is understandable to the user. In this chapter, we focus on scenario-based requirements elicitation.,,Requirements elicitation is about communication among developers, clients, and users to define a new system…Requirements elicitation methods aim at improving communication among developers, clients, and users…Developers construct a model of the application domain by observing users in their environment. Developers select a representation that is understandable by the clients and users (e.g., scenarios and use cases). Developers validate the application domain model by constructing simple prototypes of the user interface and collecting feedback from potential users…Requirements elicitation focuses on describing the purpose of the system. The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a requirements specification and serves as a contract between the client and the developers…The requirements specification is structured and formalized during analysis to produce an analysis model:

Both requirements specification and analysis model represent the same information. They differ only in the language and notation they use; the requirements specification is written in natural language, whereas the analysis model is usually expressed in a formal or semiformal notation.

Requirements elicitation and analysis focus only on the user’s view of the system. For example, the system functionality, the interaction between the user and the system, the errors that the system can detect and handle, and the environmental conditions in which the system functions are part of the requirements. The system structure, the implementation technology selected to build the system, the system design, the development methodology, and other aspects not directly visible to the user are not part of the requirements.

Requirements elicitation includes the following activities:

Identifying actors
Identifying scenarios
Identifying use cases
Refining use cases
Identifying relationships among use cases
Identifying nonfunctional requirements

Elicitation concepts

Functional requirements describe the interactions between the system and its environment independent of its implementation. The environment includes the user and any other external system with which the system interacts… The functional requirements focus only on the possible interactions between the system and its external world. This description does not focus on any of the implementation details.

Nonfunctional requirements describe aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance. The FURPS+ model2 used by the Unified Process [Jacobson et al., 1999] provides the following categories of nonfunctional requirements:

Elicitation Activities

Identifying Actors: Actors represent external entities that interact with the system. An actor can be human or an external system. In the SatWatch example, the watch owner, the GPS satellites, and the Webify Watch serial device are actors (see Figure 4-4). They all exchange information with the SatWatch.

Figure 4-4 Actors for the SatWatch system. WatchOwner moves the watch (possibly across time zones) and consults it to know what time it is. SatWatch interacts with GPS to compute its position. Webify Watch upgrades the data contained in the watch to reflect changes in time policy.

The first step of requirements elicitation is the identification of actors. This serves both to define the boundaries of the system and to find all the perspectives from which the developers need to consider the system. When the system is deployed into an existing organization (such as a company), most actors usually exist before the system is developed: they correspond to roles in the organization. During the initial stages of actor identification, it is hard to distinguish actors from objects. For example, a database subsystem can at times be an actor, while in other cases it can be part of the system. Note that once the system boundary is defined, there is no trouble distinguishing between actors and such system components as objects or subsystems. Actors are outside of the system boundary; they are external. Subsystems and objects are inside the system boundary; they are internal.

Thus, any external software system using the system to be developed is an actor. When identifying actors, developers can ask the following questions:

Questions for identifying actors:

• Which user groups are supported by the system to perform their work?

• Which user groups execute the system’s main functions?

• Which user groups perform secondary functions, such as maintenance and administration?

• With what external hardware or software system will the system interact?

Identifying Scenarios: A scenario is “a narrative description of what people do and experience as they try to make use of computer systems and applications” [Carroll, 1995]. A scenario is a concrete, focused, informal description of a single feature of the system from the viewpoint of a single actor. Scenarios cannot (and are not intended to) replace use cases, as they focus on specific instances and concrete events (as opposed to complete and general descriptions). However, scenarios enhance requirements elicitation by providing a tool that is understandable to users and clients…

Figure 4-6 is an example of scenario for the FRIEND system, an information system for incident response. In this scenario, a police officer reports a fire and a Dispatcher initiates the incident response.

Scenarios can have many different uses during requirements elicitation and during other activities of the life cycle. Below is a selected number of scenario types taken from [Carroll, 1995]:

As-is scenarios describe a current situation. During reengineering, for example, the current system is understood by observing users and describing their actions as scenarios.

Visionary scenarios describe a future system. Visionary scenarios are used both as a point in the modeling space by developers as they refine their ideas of the future system and as a communication medium to elicit requirements from users.

Evaluation scenarios describe user tasks against which the system is to be evaluated. The collaborative development of evaluation scenarios by users and developers also improves the definition of the functionality tested by these scenarios.

Training scenarios are tutorials used for introducing new users to the system. These are step-by-step instructions designed to hand-hold the user through common tasks.

In requirements elicitation, developers and users write and refine a series of scenarios in order to gain a shared understanding of what the system should be. Initially, each scenario may be high level and incomplete, as the warehouseOnFire scenario is. The following questions can be used for identifying scenarios.

Questions for identifying scenarios

• What are the tasks that the actor wants the system to perform?

• What information does the actor access? Who creates that data? Can it be modified or removed? By

whom?

• Which external changes does the actor need to inform the system about? How often? When?

• Which events does the system need to inform the actor about? With what latency?

Identifying Use Cases: A scenario is an instance of a use case; that is, a use case specifies all possible scenarios for a given piece of functionality. A use case is initiated by an actor. After its initiation, a use case may interact with other actors, as well. A use case represents a complete flow of events through the system in the sense that it describes a series of related interactions that result from its initiation…Figure 4-7 depicts the use case ReportEmergency of which the scenario warehouseOnFire (see Figure 4-6) is an instance

Generalizing scenarios and identifying the high-level use cases that the system must support enables developers to define the scope of the system. Initially, developers name use cases, attach them to the initiating actors, and provide a high-level description of the use case as in Figure 4-7. The name of a use case should be a verb phrase denoting what the actor is trying to accomplish. The verb phrase “Report Emergency” indicates that an actor is attempting to report an emergency to the system (and hence, to the Dispatcher actor). This use case is not called “Record Emergency” because the name should reflect the perspective of the actor, not the system. It is also not called “Attempt to Report an Emergency” because the name should reflect the goal of the use case, not the actual activity

Attaching use cases to initiating actors enables developers to clarify the roles of the different users. Often, by focusing on who initiates each use case, developers identify new actors that have been previously overlooked.

Describing the flow of events of a use case enables developers and clients to discuss the interaction between actors and system. This results in many decisions about the boundary of the system, that is, about deciding which actions are accomplished by the actor and which actions are accomplished by the system.

Identifying relationships between actors and Use Cases: Communication relationships between actors and use cases represent the flow of information during the use case. The actor who initiates the use case should be distinguished from the other actors with whom the use case communicates. By specifying which actor can invoke a specific use case, we also implicitly specify which actors cannot invoke the use case. Similarly, by specifying which actors communicate with a specific use case, we specify which actors can access specific information and which cannot. Thus, by documenting initiation and communication relationships among actors and use cases, we specify access control for the system at a coarse level.

Identifying Initial Analysis Objects: To establish a clear terminology, developers identify the participating objects for each use case. Developers should identify, name, and describe them unambiguously and collate them into a glossary.3 Building this glossary constitutes the first step toward analysis, which we discuss in the next chapter. The glossary is included in the requirements specification and, later, in the user manuals. Developers keep the glossary up to date as the requirements specification evolves. The benefits of the glossary are manyfold: new developers are exposed to a consistent set of definitions, a single term is used for each concept (instead of a developer term and a user term), and each term has a precise and clear official meaning. The identification of participating objects results in the initial analysis object model. The identification of participating objects during requirements elicitation only constitutes a first step toward the complete analysis object model.

During requirements elicitation, participating objects are generated for each use case. If two use cases refer to the same concept, the corresponding object should be the same. If two objects share the same name and do not correspond to the same concept, one or both concepts are renamed to acknowledge and emphasize their difference. This consolidation eliminates any ambiguity in the terminology used.

Identifying Non-functional requirements: Nonfunctional requirements describe aspects of the system that are not directly related to its functional behavior. Nonfunctional requirements span a number of issues, from user interface look and feel to response time requirements to security issues. Nonfunctional requirements are defined at the same time as functional requirements because they have as much impact on the development and cost of the system.

Documenting Requirements Elicitation: The results of the requirements elicitation and the analysis activities are documented in the Requirements Analysis Document (RAD). This document completely describes the system in terms of functional and nonfunctional requirements.Figure 4-16 is an example template for a RAD:

Written by: Larry Francis Obando – Technical Specialist

Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.

Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.

Contact: Caracas, Valladolid, Quito, Guayaquil, Jaén, Villafranca de Ordizia – +34633129287

WhatsApp: +34633129287

email: dademuchconnection@gmail.com

Copywriting, Content Marketing, Tesis, Monografías, Paper Académicos, White Papers (Español – Inglés)

Introduction to differential equation and modeling

21 septiembre, 2017 carakenio73

Fuente: Introduction to Differential Equations

1. Motivation
2. A secret function
3. Cell division
4. Classification of differential equations
5. Homogeneous linear ODE
6. Introduction to modeling
7. Model of a savings account
8. Application: mixing salt water solution
9. Systems and signals
10. Newtonian mechanics
11. 5 step modeling process

Today’s objectives

Identify linear first order differential equations.
Model behavior of certain systems using first order linear differential equations.
Use the input signal and system response paradigm to obtain an ODE for a physical system.
Check reasonableness of models using unit analysis .

Definition 3.2 An initial value problem is a differential equation together with initial conditions.

4. Cell division

Here we will see how the differential equation for our secret function appears when modeling a natural phenomenon – the population growth of a colony of cells…In this example we’ll model the number of yeast cells in a batch of dough. As we work through this example, pay careful attention to the assumptions we make, and how the initial condition plays a role in the resulting differential equation.

For our system, we assume we have a colony of yeast cells in a batch of bread dough. The first step is to identify the variables, the units, and give them names.

y	number of cells
t	time measured in seconds

We also need to set some initial condition, y0, the number of cells that we begin with at t=0. In this system, this might be the number of yeast cells in a yeast packet.

A differential model

If y denotes the number of yeast cells, what can we say about the derivative y˙? The derivative represents the rate at which the number of cells is growing. How should it depend on the number of cells? In nature, cells given plenty of space and food tend to divide through mitosis regularly. If we assume that each cell is dividing independently of all other cells, then doubling the number of cells should double the rate at which new cells are born. In fact, multiplying the number of cells by any scalar factor should do the same to the derivative. So this directly implies that the growth rate of cells is proportional to the number of cells:

y˙∝y.

We can make this into a true equation by simply inserting a proportionality constant a, such that

y˙=ay.

We say that 1/a is a “characteristic” timescale for our problem, setting the rate at which the cells divide. A solution to the above differential equation is

where y0 is the number of yeast cells we started with at t=0. In our case, we assume that y0 is the number of yeast cells in a packet, which is about 180 billion yeast cells.

5. Classification of differential equations

Marcar esta página

There are two kinds:

An ordinary differential equation (ODE) involves derivatives of a function of only one variable.
A partial differential equation (PDE) involves partial derivatives of a multivariable function.

When we consider ODEs, we will often regard the independent variable to be time…The dot notation y˙ should only be used to refer to a time derivative. If for example y is a function of a spacial variable y=y(x), we will only use the notation y′ to denote the derivative with respect to x.

Definition 5.1 The order of a DE is the highest n such that the nth derivative of the function appears…

The order is 5, because the highest derivative that appears is the 5th derivative, y(5).

7. Natural growth and decay equations..We’ve been introduced to a few basic forms of differential equations so far. The first equation we saw was a basic growth equation,

y˙=ay,

which, when a is a positive constant, governs systems like bank accounts and cell populations. If we put a negative sign in front of a we get the decay equation

y˙=−ay,

which can be used to describe things like radioactive decay of materials.

How would you classify the differential equations y˙=ay and y˙=−ay just discussed? Choose all descriptors that apply…
Solution:

These two equations are both first order, linear, homogeneous differential equations. To see that these equations are homogeneous, we can either check that y=0 is a solution (it is), or we can rewrite them in standard linear form:

8. Introduction to modeling

Marcar esta página

There are two kinds of modeling. We’re not going to talk about the kind that involves fancy clothes and photographs. The other kind, mathematical modeling , is converting a real-world problem into mathematical equations.

Guidelines:

Identify relevant quantities, both known and unknown, and give them symbols. Find the units for each.
Identify the independent variable(s). The other quantities will be functions of them, or constants. Often time is the only independent variable.
Write down equations expressing how the functions change in response to small changes in the independent variable(s). Also write down any “laws of nature” relating the variables. As a check, make sure that all summands in an equation have the same units.

Often simplifying assumptions need to be made; the challenge is to simplify the equations so that they can be solved but so that they still describe the real-world system well.

I have a savings account earning interest compounded daily, and I make frequent deposits or withdrawals into the account. Find an ODE with initial condition to model the balance.

Simplifying assumptions:

Daily compounding is almost the same as continuous compounding, so let’s assume that interest is paid continuously instead of at the end of each day.
Similarly, let’s assume that my deposits/withdrawals are frequent enough that they can be approximated by a continuous money flow at a certain rate, the net deposit rate (which is negative when I am withdrawing).

Variables and functions (with units): Define the following:

P	the initial amount that the account starts with (dollars)
t	time from the start (years)
x	balance (dollars)
I	the interest rate (year−1; for example 4%/year=0.04year−1)
q	the net deposit rate (dollars/year).

Here t is the independent variable, P is a constant, and x, I, q are functions of t.

Equations: Now we want to decide how the balance changes as time changes. We’ll estimate the change in the balance Δxas time increases from some time t to a time t+Δt. We can approximate the interest earned per dollar to be:

Note that the units in each of the three terms are dollars/year. Also, there is the initial condition x(0)=P. Thus we have an ODE with initial condition:

Now that the modeling is done, the next step might be to solve this DE, but we won’t do that yet.

Remark 9.2 The notation we chose suggested that the interest rate I depended only on time. However, I could have depended on x as well. This would not change the modeling process. If I does not depend on x, we obtain a linear differential equation. If it does, the equation is nonlinear.

Video: Application: mixing salt water solution

Systems and signals

Let’s get back to the savings account model:

x˙=I(t)x+q(t).

Maybe for financial planning I am interested in testing different saving strategies (different functions q) to see what balances x they result in. To help with this, rewrite the ODE as

In the “systems and signals” language of engineering, q is called the input signal , the bank is the system , and x is the output signal . These terms do not have a mathematical meaning dictated by the DE alone; their interpretation is guided by the system being modeled. But the general picture is this:

The system may be a mechanical system such as an automobile suspension or an electrical circuit, or an economic market. It is impacted by some external signal. We are interested in understanding how the system responds to the external stimulus.

The input signal is the external stimulus. It usually does not appear in as simple a way in the DE as it does in the example above. But it does always determine the right hand side of the DE (when written in standard linear form).
The system response (also called output signal ) is the measurable behavior of the system that we are interested in. It is always the unknown function that we write a differential equation for.
All differential equations have many solutions. The solution of interest is often determined by the state of the system at the beginning. This initial state is given by the initial conditions.

Newtonian mechanics

Let’s try to put this into the input/ system response paradigm we’ve just introduced. The system response is the displacement of the mass. This is what we are interested in.

What is the input signal? You could imagine that there are other forces acting on the mass, like there is a sail on the mass, and wind is blowing on the sail creating an input signal. But we are going to start by considering the case where the input signal is 0. Note that pulling the cart back and releasing it specifies the initial state of the system, that is, it gives the initial conditions.

Now we are ready to write down the differential equation . The equation is governed by Newton’s second law

We need to identify the forces acting on the mass. There is the force due to the spring. For the moment, we assume that air resistance is negligible, and there is no friction on the cart.

What is the spring force? When the displacement is positive, the spring is stretched, the force is negative. When the displacement is negative, the spring is compressed, the force is positive. Thus this force is modeled linearly by Hooke’s law:

which is a function of the displacement x away from the neutral position x=0. Note that this linear model is only valid for relatively small displacements. If we stretch the spring too far, the spring force won’t obey this linear law anymore.

The position at time t=0 is x(0)=x0 for some positive displacement x0>0. From the problem statement, we assume that we release the cart with zero initial velocity, x˙(0)=0.

Putting this all together, we get:

with initial conditions:

The last step is to write this in standard linear form . We obtain the following differential equation:

Now let’s consider the same mass/spring system as above where we’ve add a sail to the mass.

The mass now experiences an additional external force from the wind. How does this change the model?

Solution: The model is exactly the same. The only difference is that the input signal is no longer zero, rather it is now the external force due to the wind on the sail. This external force Fwind(t) depends on time in some complicated way that we will not try to write down. The differential equation for this system is:

5 step modeling process

Marcar esta página

In the example on the previous page, we outlined a 5 step modeling process that we make explicit here.

Draw a diagram of the system.
Identify and give symbols for the parameters and variables of the system.
Decide on the input signal and the system response. Identify any initial conditions.
Write down a differential equation relating the input signal and the system response.
Rewrite the equation in standard linear form with initial conditions.

Written by: Larry Francis Obando – Technical Specialist

Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.

Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.

Contact: Ecuador (Quito, Guayaquil, Cuenca)

WhatsApp: 00593984950376

email: dademuchconnection@gmail.com

Copywriting, Content Marketing, Tesis, Monografías, Paper Académicos, White Papers (Español – Inglés)

Matemática aplicada - Appd Math, Señales y Sistemas

Señales de tiempo continuo – Definición

20 septiembre, 20174 enero, 2021 carakenio73

Una señal x(t) es una función con valor real o escalar de la variable de tiempo t. El término con valor real significa que para cualquier valor fijo de la variable de tiempo t, el valor de la señal en el tiempo t es un número real. Cuando esta variable toma sus valores del conjunto de los números reales, se dice que t es una variable de tiempo continuo, y que la señal x(t) es una señal de tiempo continuo o una señal analógica. Ejemplos comunes de señales de tiempo continuo son el voltaje u ondas de corriente de un circuito eléctrico, las señales de audio como voz u ondas musicales, las posiciones o velocidades de objetos en movimiento, las fuerzas o torcas en un sistema mecánico, las señales bioeléctricas como electrocardiogramas (ECG) o electroencefalogramas (EEG), las velocidades de flujo de líquidos o gases en un proceso químico, etc.

Dada una señal x(t) muy complicada, no siempre es posible determinar una función matemática que sea exactamente igual a x(t). Un ejemplo es una señal de voz, como el segmento de diálogo de 50 milisegundos que aparece en la Figura 1. Este segmento es la transición de la “sh” a “u” de la elocución de la palabra inglesa “should”.

Primero que nada el analista de sistemas debe conocer cómo modelar señales en el dominio del tiempo continuo.

Introducción
Función Escalón
Función Rampa
Función Impulso
Función Pulso Rectangular
Función Pulso Triangular
Función Periódica
Función Exponencial

Función Escalón

Fuente: [3]

Función Rampa

Función Impulso

Función Pulso Rectangular

Función Pulso triangular

Fuente: [2]

Función Periódica

Fuente: [1]

Fuente: [3]

Fuente: [1]

Función Exponencial

Fuente:

Fundamentos_de_Señales_y_Sistemas_usando la Web y Matlab

1.1 Señales en tiempo continuo

SIGUIENTE: Señales de tiempo discreto – Muestreo en matlab.

Written by: Larry Francis Obando – Technical Specialist – Educational Content Creation – Mentoring (Tutoría para estudiantes universitarios)

Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.

Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.

Contact: Caracas, Valladolid, Quito, Guayaquil, Jaén, Villafranca de Ordizia

WhatsApp: +34633129287

email: dademuchconnection@gmail.com

Linear Algebra, Matemática aplicada - Appd Math

Linear Algebra – Foundations

14 septiembre, 2017 carakenio73

Linear Algebra

Start Line:

DLM
1. Appd Mathematics
  1. Linear Algebra…What You Will Learn:
    - Represent quantities that have a magnitude and a direction as vectors.
    - • Read, write, and interpret vector notations.
    - • Visualize vectors in R2.
    - • Perform the vector operations of scaling, addition, dot (inner) product.
    - • Reason and develop arguments about properties of vectors and operations defined on them.
    - • Compute the (Euclidean) length of a vector.
    - • Express the length of a vector in terms of the dot product of that vector with itself.
    - • Evaluate a vector function.
    - • Solve simple problems that can be represented with vectors.
    - • Create code for various vector operations and determine their cost functions in terms of the size of the vectors.
    - • Gain an awareness of how linear algebra software evolved over time and how our programming assignments fit into this
    - (enrichment).
    - • Become aware of overflow and underflow in computer arithmetic (enrichment).
    - Become practical with the use of Matlab to apply all these framework

PAGE_BREAK: PageBreak

Date: August, September 2017. Location: Quito, Pichincha, Ecuador.

Actividad

WBS (Vector Algebra – )

Martes 15, 06:32 am

Martes 29, 04:41 am

Jueves 31, 04:41 am

Lunes 04, 5:37 am

Lunes 11, 5:37 am

Martes 12, 4:46 am

Jueves 14, 5:15 am

I keep attending:

LAFF: Linear Algebra – Foundations to Frontiers
1. Overview of the Course
2. 0.3.3 MATLAB Basics
3. Origins of MATLAB
4. Vectors in Linear Algebra
  1. Notation
  2. Unit Basis Vectors
  3. Simple Vector Operations
  4. Advanced Vector Operations
5. The Science of NFL Football: Vectors

This course is not only designed to teach the standard topics in a typical linear algebra course, but it also investigates how to translate theory into algorithms. Like typical in the algebra courses, we will often start studying operations with small matrices. In practice, however, one often wants to perform operations with large matrices so we generalize the techniques to formulate practical algorithms and their implementations

If you want to learn more about MATLAB, here are some suggestions you may want to investigate:

Matlab Onramp is a free 2-hour interactive online tutorial.
MATLAB Central is a place where people interested in MATLAB can be part of a community. Here, you may want to check out ThingSpeak™, the open loT Platform with MATLAB Analytics that allows you to aggregate, visualize, and analyze live data streams in the cloud.

Definition from Vectors in Linear Algebra

Definition 1.1 We will call a one-dimensional array of n numbers a vector of size n:

denotes the set of all vectors of size n with components in R.

Unit Basis Vectors

Equality, Assignment and Copy

Now we could talk about an algorithm for setting y equal to x. We’re computing y becomes x. We’ve already seen that each of the components of y has to be set to a corresponding component of x. So psi sub i has to become chi sub i. We have to do this for all indices i from 0 to n minus 1. We start indexing at 0, and therefore, if the vectors are of length n, we have to run this until n minus 1. We create an algorithm for this assignment by now writing this as a FOR LOOP.

Vector Addition

Now if we wanted an algorithm for computing the result vector, z, that results from adding x to y, then we can expose the components of z, the components of x and y, and we recognize that the ith of z just equals to the some of the ith components of x and y. And we can then summarise that as a little loop that says for all components of z, for i from 0 to n minus 1, the ith component of z, zeta sub i, should just be computed as chi sub i, added to psi sub i.

Scaling

What if instead we want an algorithm that computes vector y as the stretched vector x stretched by a scaling factor alpha? y becomes alpha times x. We expose the components of y. We need to compute alpha times x, where here we expose the individual components of x. And all we need to do is set the appropriate element of y to the corresponding element of x scaled by alpha. If we do this as an algorithm, then what we need to do to set psi i equal to alpha times chi i.

Subtraction

Let’s review the parallelogram method for vector addition. You lay out your vectors as such. And then, the diagonal becomes x:

You can do the same thing for vector subtraction. You lay out your vectors. And then, the other diagonal becomes the vector x minus y. Obviously, you have to make sure that it points in the right direction.

Now, how do you compute x minus y? Well, you expose the different components of vectors x and y. And you simply subtract each component of y off the corresponding component of x.

In Summary:

Scaled Vector Addition (AXPY)

We’re now going to talk about an operation that is going to be very important as we start looking at more complex operations, and then the algebra later on. It’s hard to picture though. It’s known as the axpy operation, and it takes a vector, scales it, and then adds it to another vector. Given two vectors x and y of size n and a scalar alpha, the axpy operation is given by y is equal to alpha x plus y.

Specifically

These kinds of vector operations have been very important since the 1970s, and back then the language of choice in this area was Fortran 77. Fortran 77 had the limitation that the variables and subroutines had to be identified with at most six letters and numbers. So they had to be somewhat innovative about how to name operations, and subroutines that implemented them. And the axpy here is simply an abbreviation of alpha times x plus y. So it stands for scalar alpha, the a, times x, plus, p, y–axpy.

If we now want to look at an algorithm for performing this operation, notice that the i-th component of y has to be updated by scaling the i-th component of x and adding it to the i-th component of y. So psi i becomes alpha times chi i plus psi i. And as usual, we need to put a loop around that so this is done for all components zero to n minus 1.

About the AXPY operation, it is often emphasized that it is typically used in situations where the output vector overwrites the input vector y.

Linear Combinations of Vectors

If we’re given two vectors of length m, u and v, and two scalars, alpha and beta, then taking the linear combination of u and v with coefficients alpha and beta is given by alpha times u plus beta times v. So that’s the scalar times the vector u, plus the scalar times the vector v. If we expose the components of u and v, then what does this mean? It means that we scale the first vector, that mean scale each of the individual components, by alpha. And we scale the components of vector v by beta. And that gives us, this right here. So taking this linear combination of vectors u and v, using the coefficients alpha and beta, means that we take the same linear combination of each of the components of u and v.

More generally

Well, instead of writing things like this, we could write them like this. What is that? That’s an AXPY. Why? 0 is a vector. And then this is a scalar times a vector, which you add to that vector. Once you’ve computed this vector, you take a scalar times the second vector and add it to that. So now, the first AXPY, we computed this. The second AXPY computes this. And you can imagine that we can do that for all of the vectors until we’re completely done.

This then motivates the following algorithm. You start by setting w equal to 0. And then for j equals 0 to n minus 1, you perform this operation right here where you take a the scalar chi j times v j and at that to w. So for j equals 0, that’s this operation. That then is stored in w. Then this here is what you do for j equals 1 and so forth.

Shortly, this will become really important as we make the connection between linear combinations of vectors, linear transformations, and matrices.

Dot or Inner Product (DOT)

If we’re given vectors x and y of size n, then the dot product is defined as follows.

Now what do we have here? We multiply the first components together, and then we multiply the second components together, and add those to the first components. And then we keep doing that until we get to the last components. We multiply those together, and we add those in as well. We can write this more concisely as I equals 0 to n minus one, of Chi i times Psi i.

Now to motivate an algorithm, let’s look at this slightly differently. Let’s think of this as, take an alpha, and first assigning 0 to it. After that, we multiply the first two components together, and we add that to 0. After that, we multiply the next two components together, and we add that to what already is in alpha, and so forth…This motivates the algorithm given here. You start by setting alpha equal to zero. And then, for i equals zero to n minus 1, you take what is already accumulated in alpha, and you add to it the product of the components Chi i and Psi i.

Now often we will use a slightly different notation to denote the dot product. OK, the dot product is given by this. We will often write this as x transpose y. OK? This T here means transposition. Now what does transposition mean? If we expose the components of x and y, then the transposition means that you take x, which is a column vector, and you make it into a row vector, as such. So the column vector turns into a row vector. Transposition means taking the vector and putting it on its side. And then multiplying the row vector times a column vector means multiplying the first components together, and adding that to the second components multiplied together, and so forth.

Vector Length (NORM2)

If we take that further and we look at a vector of size n, then the length of that vector is given by the square root of the squares of the components,which we can use shorthand to write as the sum of the squares of the components.

There’s a relation between the dot product and the length of a vector.

And therefore, we conclude that the length of vector x is just a square root of the dot products of x with itself. We summarize that right here.

Vector Function

A vector function is a function that takes one or more scalars and/or one or more vectors as inputs and then produces a vector as an output.

Well, let’s look an an example. So here we have an example of f, which is a function of two scalars. How do we know these are scalars? Well, notice that I’m using Greek letters. We agree that the Greek lowercase letters we were going to use for scalars. So it takes two scalars as input, alpha and beta, and then produces a vector of size two as output, where the first component adds the two input scalars and the second component subtracts the second scalar from the first scalar.

If we want to evaluate f of -2, 1, then all we do is we substitute -2 in for alpha. And we substitute 1 in for beta. So this here then would be the vector -2 plus 1, -2, minus 1. And if you do the arithmetic, you get the vector -1, -3. That’s summarized right here.

Let’s do another example. Here we have a function of the scalar and a vector of size three. And the output is that vector, except that each of its components has been changed by adding the scalar to it. So if you want to evaluate this function for a specific input, -2 for the scalar and the vector 1, 2, 3, then again what we need to do is substitute the -2 in for alpha. And we need to substitute 1, 2, and 3 in for the components of the vector that’s the input.

We have seen other examples already. We saw the AXPY operation, which if you think of it as a function, is the function axpy of a scalar alpha and then vectors x and y. And the output is the vector alpha times x plus y. We also saw the DOT function. And notice that in the DOT function, you have two vectors as input, x and y. And the result is the DOT product of the two factors, which is a scalar. Now you might say a scalar is not a vector. But we’re going to think of a scalar often as a vector of size one.

What we will see in the next unit is that we can think of these vector functions as mapping one vector to another vector.

Vector Functions that map a vector to a vector

Now we’re ready to look at functions that map vectors to vectors. Next week, we’ll look at a special case of those kinds of functions called “linear transformations.” We’re going to be looking at our functions that map a vector of size n to a vector of size m.

In the previous units, we looked at a function that took two scalars as input and produced a vector as an output.

We can look at a function g that takes as input a vector with components alpha and beta and then produces the exact same vector as the function f produced.

Here was another example of a function that took as input a scalar and a vector.

We can instead look at a function g, but now stacks scalar on top of the vector creating a vector that is of size four instead of the size three vector that we had before and then evaluates in exactly the same way.

The whole point being that now we have a function that takes as input a vector and as output, produces a vector.

So in summary, this insight allows us to focus on vector functions that simply take one vector as input and produce one vector as output. What we will see next week is that there’s a special class of such functions called “linear transformations” that are of great importance to linear algebra.

Written by: Larry Francis Obando – Technical Specialist

Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.

Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.

Contact: Ecuador (Quito, Guayaquil, Cuenca)

WhatsApp: 00593984950376

email: dademuchconnection@gmail.com

Copywriting, Content Marketing, Tesis, Monografías, Paper Académicos, White Papers (Español – Inglés)

	azzokazz en Representación Fasorial de cor…
	Jose Manuel en Problemas resueltos de circuit…
	Johana en Ejercicio de cálculo de corrie…
	DONAL JUAREZ en Circuitos trifásicos Y-Y. Cone…
	Block Diagram… en Convolución – Problemas…