text:
The Sway Reference Manual/More about Functions

We have already seen some examples of functions, some user-defined and some built-in. For example, we have used the built-in functions, such as *. In reality, * is not a function but a variable that is bound to the function that multiplies two numbers together, but it is tedious to say 'the function bound to *' so we say the more concise (but technically incorrect) phrase 'the * function'.

Predefined Functions
Sway has many predefined functions. You can see the list of built-in functions by executing the command

sway -p

at the system prompt (don't confuse the system prompt with the Sway interpreter prompt). More detail on the built-in functions is given in the last chapter. No one, however, can anticipate all possible tasks that someone might want to perform, so most programming languages allow the user to define new functions. Sway is no exception and provides for the creation of new and novel functions. Of course, to be useful, these functions should be able to call built-in functions as well as other programmer created functions.

For example, a function that determines whether a given number is odd or even is not built into Sway but can be quite useful in certain situations. Here is a definition of a function named even? which returns true if the given number is even, false otherwise:

sway> function even?(x) { return x % 2 == 0; } FUNCTION:  sway> even?; FUNCTION:  sway> even?(4); SYMBOL: :true sway> even?(5); SYMBOL: :false sway> even?(4 + 5); SYMBOL: :false

We could talk for days about what's going on in these interactions with the interpreter. First, let's talk about the syntax of a function definition. Later, we'll talk about the purpose of a function definition. Finally, will talk about the mechanics of a function definition and a function call.

Function syntax
Recall that the words of a programming language include its primitives, keywords and variables. A function definition corresponds to a sentence in the language in that it is built up from the words of the language. And like human languages, the sentences must follow a certain form. This specification of the form of a sentence is known as its syntax. Computer Scientists often use a special way of describing syntax of a programming language called the Backus-Naur form (or BNF). Here is a high-level description of the syntax of a Sway function definition using BNF:

functionDefinition : 'function' variable '(' optionalParameterList ')' block optionalParameterList : $$\Epsilon$$ | parameterList parameterList : variable | variable ',' parameterList block: '{' definitionSequence statementSequence '}'

The first BNF rule says that a function definition begins with the keyword function (parts of the rule that appear verbatim appear within single quotes), followed by a variable, followed by an open parenthesis, followed by something called an optionalParameterList, followed by a close parenthesis, followed by something called a block. By reading the remaining rules, we see that one defines a function by entering the keyword function followed by the name of the function, followed by a parenthesized list of formal parameters (possibly empty, as indicated by $$\Epsilon$$), followed by the body of the function. The body is a brace-enclosed list of definitions, then statements (the block that follows the parameter list is often called the function body).

The parameter list is composed of zero or more variable names, separated by commas. Parameters are local variables that will be bound to the values given in the call to the function. In the particular case of even?, the variable x will be bound to the number whose eveness is to be determined. It is customary to call x a formal parameter of the function even?. In function calls, the values to be bound to the formal parameters are called arguments.

Function Objects
Let's look at the body of even?. The % operator is bound to the remainder or modulus function. The == operator is bound to the equality function and determines whether the value of the left operand expression is equal to the value of the right operand expression, yielding true or false as appropriate. The value produced by == is then immediately returned as the value of the function.

When given a function definition like that above, Sway performs a couple of tasks. The first is to create the internal form of the function, known as a function object, which holds the function's name, parameter list, and body, plus the current environment. The second task is to add the function name and the function object to the current environment as a variable-value binding. Thus the name of the function is simply a variable that happens to be bound to a function object. As noted before, we often say 'the function even?' even though we really mean 'the function bound to the variable even?'.

The value of a function definition is the function object, which has type FUNCTION (indicating a user of Sway has defined the function) and a printable value of , where definitionName is the name of the function when created and formalParameters is the parenthesized list of parameters. Although the print value of the function object only lists the original name and the parameters, the actual object contains the body and context in which it was created (known as the defining environment) as well.

We can see the actual components of a function object by passing the function object to the built-in ppObject function. The pp in ppObject stands for pretty printing which means to display in a pleasing format.

sway> ppObject(even?); : context:  prior: :null filter: :null parameters: (x) code: { return x % 2 == 0; } name: even? FUNCTION:

In addition to some other fields we will learn about later, we see that the parameters, code, and name fields look as expected. The only unexpected item is that the code contains a return where it did not before. You will learn more about returns in a later chapter. For now, we'll just say that returns allow you to return a value from somewhere other than the last expression in the function body.

While we are on the subject of prettying printing, we can also look at even? with the pp function:

sway> pp(even?) function even?(x) {       return x % 2 == 0; }   FUNCTION:

Calling Functions
Once a function is created, it is used by calling the function with arguments. A function is called by supplying the name of the function followed by a parenthesized, comma separated, list of expressions. The arguments are the values of those expressions and are to be bound to the formal parameters. In general, if there are n formal parameters, there should be n arguments. Furthermore, the value of the first argument is bound to the first formal parameter, the second argument is bound to the second formal parameter, and so on. Moreover, the arguments are usually evaluated before being bound to the parameters.

Once the evaluated arguments are bound to the parameters, then the body of the function is evaluated. Most times, the expressions in the body of the function will reference the parameters. If so, how does the interpreter find the values of those parameters? That question is answered in the next section.

Scope
The formal parameters of a function can be thought of as variable definitions that are only in effect when the body of the function is being evaluated. That is, those variables are only visible in the body and no where else. For that reason, parameters are considered to be local variable definitions, since they only have local effect (the function body). Any direct reference to those particular variables outside the body of the function is not allowed. Consider the following interaction with the interpreter:

sway> function square(a) { return a * a; } FUNCTION:  sway> square(4); INTEGER: 16 sway> a;   EVALUATION ERROR: :undefinedVariable variable a is undefined stdin,line 3: a;

Scope refers to where a variable is visible.

In the above example, the scope of variable a is restricted to the body of the function square. Any reference to a other than in the context of square is invalid. Now consider a slightly different interaction with the interpreter:

sway> var a = 10; INTEGER: 10 sway> var b = 1; INTEGER: 1 sway> function almostSquare(a) { return a * a + b; } FUNCTION: <function almostSquare(a)> sway> almostSquare(4); INTEGER: 17

In this dialog, two variable definitions, a and b, precede the definition of almostSquare. In addition, the variable serving as the formal parameter of almostSquare has the same name as the first variable defined in the dialog. Moreover, the body of almostSquare refers to both variables a and b. Variable a is defined twice (once as a regular variable and once as a formal parameter) while variable b is referenced but is not a formal parameter. Although it seems confusing at first, the Sway interpreter has no difficulty in figuring out what's what. From the responses of the interpreter, the b in the body must refer to the variable that was defined with an initial value of 1 (since there it is the only b). The a in the function body must refer to the formal parameter whose value was set to 4 by the call to the function (given the output of the interpreter).

When a formal parameter (or any definition local to a function) has the same name as another variable that is also in scope, the formal parameter is said to shadow the other. The term shadowed refers to the fact that the other variable is in the shadow of the formal parameter and cannot be seen. A variable is said to be in scope if it is bound in the current environment or in the environment bound to the context variable in the current environment. We can see this clearly in Sway by looking at bindings. Consider this dialog:

sway> var a = 10; INTEGER: 10 sway> var b = 1; INTEGER: 1 sway> function almostSquare(a) { pp(this); a * a + b; } FUNCTION: <function almostSquare(a)>

Note that in the body of this version of almostSquare, we pretty print the current environment. sway> almostSquare(4); <OBJECT 2569>: context: <OBJECT 749> dynamicContext: <OBJECT 749> callDepth: 1 constructor: <function almostSquare(a)> this: <OBJECT 2569> a: 4 INTEGER: 17

It is in this current environment that the value of a is retrieved in calculating the return value. We see that, indeed, a has a value of 4. But where is the value of b found?

When the value of a variable is needed, Sway looks in the current environment (this). If the variable is not found there, Sway looks in context. If the variable is not in context, it looks in the context of context, and so on. Let's modify almostSquare to illustrate:

sway> function almostSquare(a) { pp(this); pp(context); a * a + b; } FUNCTION: <function almostSquare(a)>

This latest version pretty prints both its current environment and its context:

sway> almostSquare(4); <OBJECT 2603>: context: <OBJECT 749> dynamicContext: <OBJECT 749> callDepth: 1 constructor: <function almostSquare(a)> this: <OBJECT 2603> a: 4 <OBJECT 749>: context: <OBJECT 18> dynamicContext: :null callDepth: 0 constructor: :null this: <OBJECT 749> almostSquare: <function almostSquare(a)> b: 1 a: 10 SwayEnv: ["SSH_AGENT_PID=5076","SHELL=/bin/bash","TERM=x...       SwayArgs: :null    INTEGER: 17

Here we see the bindings of a, b, and almostSquare, as expected.

This shows two things:

 * 1) that within the function body, formal parameters are found in the current environment
 * 2) that the context of the environment active in a function call is bound to the defining environment of the function.

When a reference to a is made, a search is made of the current environment. Within the function body, the value of 4 is immediately found. When the value of b is required, it is not found in the current environment. The interpreter then searches the current environment's context (in this case <OBJECT 1616>). This object does has a binding for b.

Since a has a value of 4 and b has a value of 1, the value of 17 is returned by the function. Finally, the last interaction with the interpreter illustrates the fact that the initial binding of a was unaffected by the function call.

In general, a variable found in the current environment is considered local. A variable that is in scope but is not in the current environment is considered non-local. Alternatively, local variables are considered to reside in the local scope while non-local variables are said to reside in the non-local scope. Local and non-local scope are sometimes referred to as inner and outer scope, respectively. If a non-local variable resides in the outermost scope, it is considered a global variable and the environment holding the bindings of global variables is called the global environment. In Sway, the initial environment is the global environment. Contrary to the definition above, Sway's global environment does have has an outer scope; this outer scope holds the bindings of the built-in functions. The built-in environment cannot be modified so perhaps a better definition of the global environment is the outermost environment which can be modified by the programmer.

How did the environment <OBJECT 1845>, the environment under which the function body was executed, come into being? The evaluation of the expression almostSquare(4) triggers a number of actions. The first is the creation of a new environment that will hold the formal parameters of the function to be called (in this case, the single parameter a) bound to the values of the corresponding arguments in the call (in this case, the single argument has a value of 4). This new environment has its context variable bound to context variable found in the function object associated with the function being called (this new environment is also populated with other pre-defined variables such as constructor). The body of the function being called is then executed under this new environment. The process of creating a new environment and linking its context to another environment via its context variable is called extending an environment. To summarize, when a function call is performed, the following actions are performed:

 * the arguments to the function call are evaluated under the current environment
 * the function object associated with the function to be called is retrieved from the current environment
 * the formal parameters are retrieved from the function object
 * the defining environment is retrieved from the function object
 * a new environment is extended from the defining environment
 * the new environment is populated by binding the formal parameters to the evaluated arguments
 * the function body is retrieved from the function object
 * the function body is evaluated under the newly extended environment
 * the result of this evaluation is returned as the result of the function call

There are two important concepts about function calls: the static chain and the dynamic chain. The static chain we have already seen, the current environment, the context of the current environment, the context of the context, and so on. It is this chain that is searched for the value of a referenced variable. The dynamic chain, on the other hand, is the current environment, the environment of the calling function, the environment of the caller of the calling function, and so on. Unlike most languages, the dynamic chain is available for programmers to search and manipulate. For the moment, that kind of manipulation is beyond us, so we will postpone that topic to a later date.

Returning from functions
The return value of a function is the value of the last expression evaluated when executing the function body. The return function is used to make an expression anywhere in the function be the last expression evaluated.

function test(x,y) {       if (y == 0) {           return(0); }       println("good value for y!"); return (x / y); }

In the example, if y is zero, then there is an immediate return from the function and no other expressions in the function body are evaluated. If not, a message is printed and the a quotient is returned. The final return is not really needed; just having <tt>x / y</tt> as the final expression would work as well.

To make Sway, which is a functional language, look like C and Java, a call to the return function has an alternate syntax, the parentheses enclosing the single argument can be omitted:

function test(x,y) {       if (y == 0) { return 0; } println("good value for y!"); x / y;       }


text:
MIRC Scripting/Info/TODO

Pages To Be Deleted
None as of yet.

Pages The Author Needs Help With
MIRC_Scripting/Basics/Become_Familiar_with_mIRC PiemanXC (talk) 00:14, 16 March 2008 (UTC)

Other Things To Do
Long term, make a PDF/Printable Book. PiemanXC (talk) 00:14, 16 March 2008 (UTC)

Move devstages in the TOC to the left of the items. 14:41, 14 April 2008 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: MIRC Scripting/Info/TODO


text:
The Sway Reference Manual/Lazy Evaluation

Many functional languages feature delayed (or lazy) evaluation of function arguments, Unlike applicative order evaluation (used by C and Java), where function arguments are evaluated before they are bound to formal parameters, lazy evaluation delays evaluation until the actual values are needed. This is accomplished by passing the argument as a thunk, which is a data structure containing the actual expression forming the argument and the environment in which the argument would have been evaluated under applicative order.

Sway allows the programmer to decide whether or not lazy evaluation should be used. To signify lazy evaluation, the formal parameter is named starting with a dollar sign ($). When the actual value of the argument is needed, the force function is used to evaluate the argument expression in the thunk. Here is an example:

When this code is executed, we get the output:

Contrast this with the output of the following code, where the formal parameter is named normally:

When this new code is executed, we get the output:

This is because the println must be evaluated before its result is bound to the formal parameter x.


text:
Fundamentals of Transportation

Table of contents

{|width="100%" cellspacing="0" cellpadding="15"
 * valign="top" width="33%"|
 * valign="top" width="33%"|

Introductory Material

 * /About/
 * /Introduction/

/Planning/

 * /Decision Making/
 * /Evaluation/

Planning Models

 * /Modeling/
 * /Data/
 * /Networks/
 * /Modes/

Modeling Methods

 * /Agent-based Modeling/
 * /Choice Modeling/

Traditional Travel Demand Forecasting

 * /Land Use Forecasting/
 * /Trip Generation/
 * /Destination Choice/
 * /Modal Split/
 * /Route Choice/

 * valign="top" width="33%"|

/Transit/

 * /Transit Demand/
 * /Transit Operations and Capacity/
 * /Network Design and Frequency/
 * /Timetabling and Scheduling/
 * /Traveler Information for Transit/

/Traffic/

 * /Queueing/
 * /Traffic Flow/
 * /Queueing and Traffic Flow/
 * /Shockwaves/
 * /Traffic Signals/
 * /Traffic Control Devices/
 * /Metering/
 * /Analogs/

 * valign="top" width="33%"|

Geometric Design

 * /Sight Distance/
 * /Grade/
 * /Earthwork/
 * /Horizontal Curves/
 * /Vertical Curves/

Conclusions

 * /Conclusions/
 * }

Related Wikibooks

 * Transportation Economics
 * Introduction
 * Pricing
 * Transportation Geography and Network Science

Useful Off-site Resources

 * NSF STREET: Simulating Transportation for Realistic Engineering Education and Training
 * Transportation Engineering Lab Manual
 * Pavement Interactive
 * Georgia Tech Traffic Lab (simulations)

title: Fundamentals of Transportation


text:
MIRC Scripting/Info/Authors

List of Authors
These people contributed a lot to the writing of the Wikibook and have their contributions listed here.

Special Thanks
These people didn't make major edits to the book, but still made valuable contributions to the writing process.
 * Mike.lifeguard was a huge help to me as far as wiki markup, espeially Templates and categories, how to do things, and overall support.
 * Darklama helped me out with my templates.

title: MIRC Scripting/Info/Authors


text:
Fundamentals of Transportation/Introduction

Transport is the movement of humans,animals and goods from one location to another.Transportation moves people and goods from one place to another using a variety of vehicles across different infrastructure systems. It does this using not only technology (namely vehicles, energy, and infrastructure), but also people’s time and eﬀort; producing not only the desired outputs of passenger trips and freight shipments, but also adverse outcomes such as air pollution, noise, congestion, crashes, injuries, and fatalities.If agriculture and industries are supposed to be the body of country,transport may be said to be the nerves and veins of the economy.

Figure 1 illustrates the inputs, outputs, and outcomes of transportation. In the upper left are traditional inputs (infrastructure including pavements, bridges, etc.), labor required to produce transportation, land consumed by infrastructure, energy inputs, and vehicles). Infrastructure is the traditional preserve of civil engineering, while vehicles are anchored in mechanical engineering. Energy, to the extent it is powering existing vehicles is a mechanical engineering question, but the design of systems to reduce or minimize energy consumption require thinking beyond traditional disciplinary boundaries.

On the top of the ﬁgure are Information, Operations, and Management, and Travelers’ Time and Eﬀort. Transportation systems serve people, and are created by people, both the system owners and operators, who run, manage, and maintain the system and travelers who use it. Travelers’ time depends both on freeﬂow time, which is a product of the infrastructure design and on delay due to congestion, which is an interaction of system capacity and its use. On the upper right side of the ﬁgure are the adverse outcomes of transportation, in particular its negative externalities:
 * by polluting, systems consume health and increase morbidity and mortality;
 * by being dangerous, they consume safety and produce injuries and fatalities;
 * by being loud they consume quiet and produce noise (decreasing quality of life and property values); and
 * by emitting carbon and other pollutants, they harm the environment.

All of these factors are increasingly being recognized as costs of transportation, but the most notable are the environmental eﬀects, particularly with concerns about global climate change. The bottom of the ﬁgure shows the outputs of transportation. Transportation is central to economic activity and to people’s lives, it enables them to engage in work, attend school, shop for food and other goods, and participate in all of the activities that comprise human existence. More transportation, by increasing accessibility to more destinations, enables people to better meet their personal objectives, but entails higher costs both individually and socially. While the “transportation problem” is often posed in terms of congestion, that delay is but one cost of a system that has many costs and even more benefits. Further, by changing accessibility, transportation gives shape to the development of land.

Modalism and Intermodalism
Transportation is often divided into infrastructure modes: e.g. highway, rail, water, pipeline and air. These can be further divided. Highways include different vehicle types: cars, buses, trucks, motorcycles, bicycles, and pedestrians. Transportation can be further separated into freight and passenger, and urban and inter-city. Passenger transportation is divided in public (or mass) transit (bus, rail, commercial air) and private transportation (car, taxi, general aviation).

These modes of course intersect and interconnect. At-grade crossings of railroads and highways, inter-modal transfer facilities (ports, airports, terminals, stations).

Different combinations of modes are often used on the same trip. I may walk to my car, drive to a parking lot, walk to a shuttle bus, ride the shuttle bus to a stop near my building, and walk into the building where I take an elevator.

Transportation is usually considered to be between buildings (or from one address to another), although many of the same concepts apply within buildings. The operations of an elevator and bus have a lot in common, as do a forklift in a warehouse and a crane at a port.

Motivation
Transportation engineering is usually taken by undergraduate Civil Engineering students. Not all aim to become transportation professionals, though some do. Loosely, students in this course may consider themselves in one of two categories: Students who intend to specialize in transportation (or are considering it), and students who don't. The remainder of civil engineering often divides into two groups: "Wet" and "Dry". Wets include those studying water resources, hydrology, and environmental engineering, Drys are those involved in structures and geotechnical engineering.

Transportation students
Transportation students have an obvious motivation in the course above and beyond the fact that it is required for graduation. Transportation Engineering is a pre-requisite to further study of Highway Design, Traffic Engineering, Transportation Policy and Planning, and Transportation Materials. It is our hope, that by the end of the semester, many of you will consider yourselves Transportation Students. However not all will.

"Wet Students"
I am studying Environmental Engineering or Water Resources, why should I care about Transportation Engineering?

Transportation systems have major environmental impacts (air, land, water), both in their construction and utilization. By understanding how transportation systems are designed and operate, those impacts can be measured, managed, and mitigated.

"Dry Students"
I am studying Structures or Geomechanics, why should I care about Transportation Engineering?

Transportation systems are huge structures of themselves, with very specialized needs and constraints. Only by understanding the systems can the structures (bridges, footings, pavements) be properly designed. Vehicle traffic is the dynamic structural load on these structures.

Citizens and Taxpayers
Everyone participates in society and uses transportation systems. Almost everyone complains about transportation systems. In developed countries you seldom hear similar levels of complaints about water quality or bridges falling down. Why do transportation systems engender such complaints, why do they fail on a daily basis? Are transportation engineers just incompetent? Or is something more fundamental going on?

By understanding the systems as citizens, you can work toward their improvement. Or at least you can entertain your friends at parties.

Goal
It is often said that the goal of Transportation Engineering is "The Safe and Efficient Movement of People and Goods."

But that goal (safe and efficient movement of people and goods) doesn’t answer:

Who, What, When, Where, How, Why?

Overview
This wikibook is broken into 4 major units
 * Transportation Planning: Forecasting, determining needs and standards.
 * Transit: Transit demand, service planning, and operations.
 * Traffic Engineering (Operations): Queueing, Traffic Flow Highway Capacity and Level of Service (LOS)
 * Highway Engineering (Design): Vehicle Performance/Human Factors, Geometric Design

Thought Questions

 * What constraints keeps us from achieving the goal of transportation systems?
 * What is the "Transportation Problem"?

Sample Problem

 * Identify a transportation problem (local, regional, national, or global) and consider solutions. Research the efficacy of various solutions. Write a one-page memo documenting the problem and solutions, documenting your references.

Abbreviations

 * LOS - Level of Service
 * ITE - Institute of Transportation Engineers
 * TRB - Transportation Research Board
 * TLA - Three letter abbreviation

Key Terms

 * Hierarchy of Roads
 * Functional Classification
 * Modes
 * Vehicles
 * Freight, Passenger
 * Urban, Intercity
 * Public, Private


text:
User:DavidLevinson

Projects Linked with | STREET: Simulating Transportation for Realistic Engineering Education and Training project, funded by NSF.
 * Fundamentals of Transportation - Introductory transportation text derived from class notes etc. (Featured book)
 * Transportation Economics - Introductory text in transportation economics.
 * Transportation Geography and Network Science - Introductory text in transportation geography and network science. (In progress)
 * Transportation Planning Casebook - Casebook of Transportation Planning Case Studies
 * Transportation Deployment Casebook - Casebook of Transportation Technology Deployment Case Studies

Real-life

 * - Nexus website (my research group)

title: User:DavidLevinson


text:
Fundamentals of Transportation/Modeling

All forecasts are wrong; some forecasts are more wrong than others. - anonymous

Modeling is a means for representing reality in an abstracted way. Your mental models are your world view: your outlook on life, and the world. The world view is your internal model of how the world works; it is employed every time you make a prediction: what do you expect, what is a surprise. The expression “Where you stand depends on where you sit” epitomizes this idea. Your world view is shaped by your experience and your position.

When modeling, the issue of Point of View should be considered. It must be clear who (and what) the results are for. If you are modeling for personal pleasure, it will naturally reflect your own worldview, but if you are working for an employer or client, their point of view must also be considered, if the inputs or results deviate significantly from their worldview, they may adapt their worldview, but more likely will dismiss the model.

Modeling can be conducted both for subjective advocacy and for objective analysis. The same methods may be employed in either, and the ethical modeler will produce the same results in either case, but they may be used differently.

Why Model?
There are a variety of reasons to model. Modeling helps
 * gain insight into complex situations by understanding simpler situations resembling them
 * optimize the use of resources in building or maintaining systems
 * operate system, particularly by testing alternative operational scenarios
 * educate and provide experience for model-builders
 * provide a platform for testing contending ideas and use in negotiations.

Particular applications in transportation include:
 * Forecasting traffic
 * Testing scenarios (alternative land uses, networks, policies)
 * Planning projects/corridor studies
 * Regulating land use: Growth management/public facility adequacy
 * Managing complexity, when eyeballs are insufficient, (different people have different intuitions)
 * Understanding travel behavior
 * Influencing decisions
 * Estimating traffic in the absence of data

Developing Models
As an engineer, economist, or planner you may be given a model to use. But that model was not spontaneously generated, it came from other engineers, economists, or planners who undertook a series of steps to translate raw data into a tool that could be used to generate useful information.

The first step, specification, tells us what depends on what (the number of trips leaving a zone may depend on the number of households). The estimation step tells us how strong these relationships mathematically are, (each household generates two trips in the peak hour). Implementation takes those relationships and puts them into a computer program. Calibration looks at the output of the computer program and compares it to other data, if they don't match exactly, adjustments to the models may be made. Validation compares the results to data at another point in time. Finally the model is applied to look at a project (e.g. how much traffic will use Granary Road after Washington Avenue is closed to traffic).

 * Specification:
 * $$y=f(X)\,\!$$
 * Estimation:
 * $$y=mX+b\,\!$$; m=1, b=2
 * Implementation
 * If Z > W, Then $$y=mX+b\,\!$$
 * Calibration
 * $$y_{predicted}+k=y_{observed}\,\!$$
 * Validation
 * $$y_{predicted1990}+k=y_{observed1990}\,\!$$
 * Application

Specification
When building a model system, numerous decisions must be made. These are discussed below:

Types of Models
There are numerous types of models, a short list is below. Each has different applicability, multiple methods may be used in pursuit of the same question, sometimes they are complementary, and sometimes competitive techniques.

 * Network analysis
 * Linear Programming
 * Nonlinear Programming
 * Simulation
 * Deterministic queuing
 * Probabilistic queuing
 * Regression
 * Neural Nets
 * Genetic Algorithm
 * Cost/ Benefit Analysis
 * Life-cycle costing
 * System Dynamics
 * Control Theory
 * Difference Equations
 * Differential Equations
 * Probabilistic Risk Assessment
 * Supply/Demand Equilibrium
 * Game Theory
 * Statistical Decision Theory
 * Markov Models
 * Cellular Automata
 * Etc.

Model Trade-offs
Building a model requires trading-off time and resource constraints. One could always be more detailed, more accurate, or more comprehensive if resources were not constrained. However, the following must also be considered.
 * Money,
 * Data,
 * Computation,
 * Labor,
 * Ease of Use,
 * Convincing (e.g. Graphic Displays),
 * Extendable,
 * Evidence of Model Benefits,
 * Measuring Model Success

Organization of Model System

 * Hierarchy of Models
 * Centralized vs. Decentralized (Optimization (Global) vs. Agent, Local Optimization)

Time

 * Time Frame
 * Static vs. Dynamic
 * Real Time vs. Offline
 * Short Term vs. Long Term (Partial vs. General Equilibrium)
 * Proactive vs. Reactive (Predictive vs. Responsive)

Space

 * Scale/Detail
 * Spatial Extent
 * Boundaries (Boundary Effects)
 * Macroscopic vs. Microscopic (Zones, Flows vs. Individuals, Vehicles)

Process

 * Stochastic vs. Deterministic
 * Linear vs. Nonlinear
 * Continuous vs. Discrete
 * Numerical Simulation vs. Closed Form Solution
 * Equilibrium vs. Disequilibrium

Type

 * Behavioral vs. Aggregate Model
 * Physical vs. Mathematical Models

Solution Techniques
When solving the model, the system as a whole must be understood. Several questions arise:

 * Does the solution exist?
 * Is the solution unique?
 * Is the solution feasible?

Solution techniques often trade-off accuracy vs. speed. Some solution techniques may only guarantee a local optima, while others (such as brute force techniques) can guarantee a global optimum, but may be much slower.

“Four-Step” Urban Transportation Planning Models
We want to answer a number of related questions (who, what, where, when, why, and how):
 * Who is traveling or what is being shipped?
 * Where are the origin and destination of those trips, shipments?
 * When do those trips begin and end (how long do they take, how far away are the trip ends)?
 * Why are the trips being made, what is their purpose?
 * How are the trips getting there, what routes or modes are they taking?

If we know the answers to those questions, we want to know what are the answers to those questions a function of?
 * Cost: Money, Time spent on the trip,
 * Cost: Money and Time of alternatives.
 * Benefit (utility) of trip (e.g. the activity at the destination)
 * Benefit of alternatives

The reason for this is to understand what will happen under various circumstances:
 * How much “induced demand” will be generated if a roadway is expanded?
 * How many passengers will be lost if bus services are cut back?
 * How many people will be “priced off” if tolls are implemented?
 * How much traffic will a new development generate?
 * How much demand will I lose if I raise shipping costs to my customers?

In short, for urban passenger travel, we are trying to predict the number of trips by:
 * Origin Activity,
 * Destination Activity,
 * Origin Zone,
 * Destination Zone,
 * Mode,
 * Time of Day, and
 * Route.

This is clearly a multidimensional problem.

In practice, the mechanism to do this is to employ a "four-step" urban transportation planning model, each step will be detailed in subsequent modules. These steps are executed in turn, though there may be feedback between steps:

 * Trip Generation - How many trips $$T_{i}$$ or $$T_{j}$$ are entering or leaving zone $$i$$ or $$j$$
 * Trip Distribution or Destination Choice - How many trips $$T_{ij}$$are going from zone $$i$$ to zone $$j$$
 * Mode Choice - How many trips $$T_{ijm}$$ from $$i$$ to $$j$$ are using mode $$m$$
 * Route Choice - Which links are trips $$T_{ijmr}$$ from $$i$$ to $$j$$ by mode $$m$$ using route $$r$$

Thought Questions

 * Is past behavior reflective of future behavior?
 * Can the future be predicted?
 * Is the future independent of decisions, or are prophecies self-fulfilling?
 * How do we know if forecasts were successful?
 * Against what standard are they to be judged?
 * What values are embedded in the planning process?
 * What happens when values change?

Additional Problems

 * Homework
 * Additional Problems

Key Terms

 * Rational Planning
 * Transportation planning model
 * Matrix, Full Matrix, Vector Matrix, Scalar Matrix
 * Trip table
 * Travel time matrix
 * Origin, Destination
 * Purpose
 * Network
 * Zone (Traffic Analysis Zone or Transportation Analysis Zone, or TAZ)
 * External station or external zone
 * Centroid
 * Node
 * Link
 * Turn
 * Route
 * Path
 * Mode

Video

 * Models

title: Fundamentals of Transportation/Modeling


text:
Fundamentals of Transportation/Design

In order to have a fully functional transportation system, the links that connect the various origins and destinations need to be designed to a level of quality that allows the safe and efficient movement of all vehicles that use them. This level of quality is reflective to the accurate installment of a geometric design. Such a design needs to take various elements into consideration, including number of lanes, lane width, median type, length of acceleration and deceleration lanes, curve radii, and many more. The detailed work of design has made lifelong careers for many engineers in the past. Today, despite advances in computer software, the basic fundamental understanding of building a highway still needs to be understood to guarantee that intuitive roads continue to be built in the future.

Highway design itself is made up of a spectrum of considerations. Some of the main points are discussed below. Details can be found in their respective sections.

Sight Distance
Sight Distance is the distance a driver can see from his or her vehicle. This becomes important when determining design speed, as it would be unsafe to allow a driver to drive faster and not be able to stop in time for a potential, unforeseen hazard. Sight distance is applied to two main categories:

 * Stopping Sight Distance (SSD)
 * Passing Sight Distance (PSD)

Grade
Grade is the slope, either upward or downward, of a road. This is especially critical because the terrain on which a road is built is seldom flat, thus requiring inherent "hills" to be present on the road to keep costs down from digging canyons or tunnels. However, too steep of a grade would make it difficult for vehicles to travel along that route. Since a road is built to provide a service to travelers, it is undesirable to have an impassable road.

An appropriate grade is dependent on the engine power in the vehicles that are expected to use the road. This breaks down into a force balance equation, where engine power is countered by various resistances. These include:

 * Aerodynamic Resistance
 * Rolling Resistance
 * Grade Resistance

Horizontal Curves
Horizontal Curves are semicircular curves designed on the horizontal plane to allow roads to weave around obstacles, such as towns, mountains, or lakes. They allow a smooth transition to occur between two nonparallel roads instead of a sharp, pointed turn. When designing horizontal curves, designers must consider the intended design speed, as centripetal force is required to ensure that vehicles can successfully negotiate the curve. Such elements to consider for design include:

 * Curve Radius
 * Superelevation

Vertical Curves
Vertical Curves are placed to allow the road to follow the terrain, whether it be hills or valleys. Vertical curves are primarily designed as parabolas, using the general form of the parabolic equation with coefficients corresponding to known elements for the road in question. Designers can design a road by adjusting these elements and minimizing costs. These elements include:

 * Inbound and Outbound Grades
 * Curve Length
 * Rate of curvature

Cross Sections
Roadway cross sections are important in design primarily for drainage. If roads were flat and level, water would congregate on the surface, reduce the coefficient of friction, and become a safety concern. Therefore, designers implement a "crown" cross section, which has a high elevation along the road's centerline and then tapers off as it leads to the shoulders. This slope is generally very small and unnoticeable by drivers, but succeeds in allowing the water to run into the ditches or storm sewers.

Earthwork
Earthwork plays into highway design as primarily a budgetary concern. The movement of earth, regardless if it is to a site, away from a site, or around a site, is an expensive venture. Designers often make roadway designs with a minimal amount of necessary earthwork to keep project costs down. However, knowing how to minimize dirt movement requires an understanding of the process.

Pavement Design
Pavement design generally is not considered part of geometric design, but is still an important part of the design process. In order to facilitate efficient traffic flow, the road beneath the vehicles' tires needs to sturdy, stable, and smooth. Pavement engineers are responsible for determining appropriate pavement depths necessary to allow traffic to pass on a certain road. Inadequate engineering would result in cracking, formation of potholes, and total degradation of the roadway surface.

External Exercises
The calculation and design process of roadway geometry design are often cumbersome and time consuming. The University of Minnesota has an online roadway geometry design tool that was created to assist transportation students in this process. This tool, titled Roadway Online Application for Design (ROAD), allows students to design a roadway on a computer screen using a contour map in the background as reference. This tool makes the design process more efficient and effective over the traditional paper and pencil method. It can be found on the link listed below, is free to use, and covers the topics discussed in the Design section. It can be found at the STREET website.

Additional Questions

 * Additional Questions

title: Fundamentals of Transportation/Design


text:
Fundamentals of Transportation/Traffic

Almost anybody can build a road. Its safety and durability would likely come into question if done by an amateur, but roads are not a difficult thing to deploy. Management of these roads, however, is something that is far from simple. Safety, efficiency, and sensibility are all elements that come into play when managing a road. It is seldom possible to find a managing strategy that satisfies all three of these categories, but often a "good" strategy can be found by balancing tradeoffs. This section introduces the fundamentals of traffic management and operation, discussing everything from queueing theory to traffic signals. The discussions here cover the fundamentals for traffic operations. To this day, research is still being conducted to perfect these elements.

Queueing
Queueing is the study of traffic behavior near a certain section where demand exceeds available capacity. Queues can be seen in a variety of situations and transportation systems. Its presence is one of the causes of driver delay.

Traffic Flow
Traffic Flow is the study of the movement of individual drivers and vehicles between two points and the interactions they make with one another. While traffic flow cannot be predicted with one-hundred percent certainty due to unpredictable driver behavior, drivers tend to behave within a reasonable range that can be represented mathematically. Relationships have been established between the three main traffic flow characteristics:
 * Flow
 * Density
 * Velocity

Queueing and Traffic Flow
Queueing and Traffic Flow is the study of traffic flow behaviors surrounding queueing events. They merge concepts learned in the prior two sections and apply them to bottlenecks.

Shockwaves
Shockwaves are the byproducts of traffic congestion and queueing. They are defined as transition zones between two traffic states that are dynamic, meaning they generally have the ability to move. Most drivers can identify shockwaves as the propagation of brake lights stemming from a given incident.

Traffic Signals
Traffic Signals are one of the more familiar types of traffic control. Using either a fixed or adaptive schedule, traffic signals allow certain parts of the intersection to move while forcing other parts to wait, delivering instructions to drivers through a set of colored lights. While many benefits come with traffic signals, they also come with a series of costs, such as increasing delay during the off-peak. But, traffic signals are generally a well-accepted form of traffic control for busy intersections and continue to be deployed.

Level of Service
One of the basic assessments of roadway performance is by determining its Level of Service (LOS). These Levels of Service, typically ranging between A and F (A being good performance, F being poor performance), are assessed by certain predetermined thresholds for any of the three characteristics of traffic flow (flow, density, and/or velocity). Finding the correct LOS often requires reference to a table.

When computing a value of flow to determine LOS, the following formula is used:

$$v_p^{} = \frac{V}\,\!$$

Where:
 * $$v_p$$ = Actual Volume per Lane
 * $$V$$ = Hourly Volume
 * $$PHF$$ = Peak Hour Factor
 * $$N$$ = Number of Lanes
 * $$f_{HV}$$ = Heavy Vehicle Factor
 * $$f_p$$ = Driver Familiarity Factor (generally, a value of 1 for commuters, less for out-of-town drivers)

Peak Hour Factor is found to be:

$$PHF = V/(4V_{15}) \,\!$$

Where:
 * $$V$$ = Hourly Volume
 * $$V_{15}$$ = Peak 15-Minute Flow

The Heavy Vehicle Factor is found to be:

$$f_{HV} = \frac{1}\,\!$$

Where:
 * $$P_T$$ = Percentage of Trucks, in decimal
 * $$E_T$$ = Passenger Car Equivalent of Trucks (found through table)
 * $$P_R$$ = Percentage of Recreational Vehicles, in decimal
 * $$E_R$$ = Passenger car Equivalent of Recreational Vehicles (found through table)

Similarly, LOS can be analyzed the anticipated speed of the corridor. The equation below produces the estimated free-flow speed for a strip of rural road, given certain characteristics about it:

$$FFS = BFFS - f_{LW} - f_{LC} - f_N - f_{ID}\,\!$$

Where:
 * $$FFS$$ = Estimated Free Flow Speed
 * $$BFFS$$ = Base Free Flow Speed
 * $$f_{LW}$$ = Adjustment for Lane Width (found in tables)
 * $$f_{LC}$$ = Adjustment for Lateral Clearance (found in tables)
 * $$f_N$$ = Adjustment for Number of Lanes (found in tables)
 * $$f_{ID}$$ = Adjustment for Interchange Density (found in tables)

For multilane urban highways, free-flow speed is computed with a similar equation:

$$FFS = BFFS - f_{LW} - f_{LC} - f_M - f_A\,\!$$

Where:
 * $$FFS$$ = Estimated Free Flow Speed
 * $$BFFS$$ = Base Free Flow Speed
 * $$f_{LW}$$ = Adjustment for Lane Width (found in tables)
 * $$f_{LC}$$ = Adjustment for Lateral Clearance (found in tables)
 * $$f_M$$ = Adjustment for Median Type (found in tables)
 * $$f_{A}$$ = Adjustment for Access Points (found in tables)

Lateral Clearance is computed:

$$TLC = LC_R + LC_L\,\!$$

Where:
 * $$TLC$$ = Total Lateral Clearance
 * $$LC_R$$ = Lateral Clearance on the Right Side of the Travel Lanes to Obstructions
 * $$LC_L$$ = Lateral Clearance on the Left Side of the Travel Lanes to Obstructions

Once TLC is computed, a table can provide the value for the Lateral Clearance Adjustment.

Estimating Gaps
One area of transportation operations that is still being considered is the estimation of gaps between vehicles. This is applicable in a variety of situations, primarily dealing with arrivals of vehicles at a given intersection. Gaps can only be predicted through a probability, based on several known characteristics occurring at a given time or location.

One of the more popular models used for predicting arrivals is the Poisson Model. This model is shown here:

$$P(x) = \fracfor\quad x = 0,1,2,\infty \,\!$$

Where:
 * $$P(x)$$ = Probability of having x vehicles arrive in time t
 * $$\lambda$$ = Average vehicle flow or arrival rate
 * $$t$$ = Duration of the time interval over which vehicles are counted
 * $$x$$ = Number of vehicles to arrive in time t

Additional Questions

 * Homework
 * Additional Questions

Variables

 * $$v_p$$ - Actual Volume per Lane
 * $$V$$ - Hourly Volume
 * $$PHF$$ - Peak Hour Factor
 * $$N$$ - Number of Lanes
 * $$f_{HV}$$ - Heavy Vehicle Factor
 * $$f_p$$ - Driver Familiarity Factor (generally, a value of 1 for commuters, less for out-of-town drivers)
 * $$V_{15}$$ - Peak 15-Minute Flow
 * $$P_T$$ - Percentage of Trucks, in decimal
 * $$E_T$$ - Passenger Car Equivalent of Trucks (found through table)
 * $$P_R$$ - Percentage of Recreational Vehicles, in decimal
 * $$E_R$$ - Passenger car Equivalent of Recreational Vehicles (found through table)
 * $$FFS$$ - Estimated Free Flow Speed
 * $$BFFS$$ - Base Free Flow Speed
 * $$f_{LW}$$ - Adjustment for Lane Width (found in tables)
 * $$f_{LC}$$ - Adjustment for Lateral Clearance (found in tables)
 * $$f_N$$ - Adjustment for Number of Lanes (found in tables)
 * $$f_{ID}$$ - Adjustment for Interchange Density (found in tables)
 * $$f_M$$ - Adjustment for Median Type (found in tables)
 * $$f_{A}$$ - Adjustment for Access Points (found in tables)
 * $$TLC$$ - Total Lateral Clearance
 * $$LC_R$$ - Lateral Clearance on the Right Side of the Travel Lanes to Obstructions
 * $$LC_L$$ - Lateral Clearance on the Left Side of the Travel Lanes to Obstructions
 * $$P(x)$$ - Probability of having x vehicles arrive in time t
 * $$\lambda$$ - Average vehicle flow or arrival rate
 * $$t$$ - Duration of the time interval over which vehicles are counted
 * $$x$$ - Number of vehicles to arrive in time t

title: Fundamentals of Transportation/Traffic


text:
MIRC Scripting/Info/Manual of Style

This manual of style will be undergoing major work as the wikibook is belongs to is being constructed.

Basic Wikibook Style

 * The main format of the page hierarchy this book looks like this:
 * Title Page
 * Section
 * Chapter
 * Subpage (If any)

 * Every chapter/subpage should contain sections. The main idea of a section should be a first-level header. A sub-topic should be a second-level header. An offshoot of the sub-topic should be a third-level. There should be no need to go beyond a third-level.
 * Every content page MUST use the template with the proper parameters and it must be the first item on the page. A content page is a page listed in, you guessed it, THE TABLE OF CONTENTS! This means do not use the header template on Images, Templates, pages in the section /Info/, or any other page that ISN'T a chapter of the book.
 * To make sure you don't break Firefox browsers, use : in place of * when there's multiple bullets. e.g. Instead of **** use :::*, instead of ** use :*, and so on.
 * For code examples, use a table, like so:

 * For code in the middle of a sentence or commands for a user to type, use <tt>
 * For continuity's sake, most images should go on the right, because most of them are already over there, and it looks better.
 * Consult the main author BEFORE making massive changes, or any changes to a template/image

Development Stages Style

 * Please don't forget |devstage= in the template. Also, make sure that the dev stage on the bookshelf, total progress for the book header, and each ToC entry is up to date.

Page Style

 * All pages not images or templates should have on them.

Image Style

 * All images need on their page.

Template Style

 * All templates need a usage section. It should be inside <pre> tags and should explain the syntax and usage of the template.
 * All templates also need on them.

Author Page Style

 * Nothing on the list of authors should be changed other than adding templates. The only other data besides an Author template should be the special thanks.
 * If a field does not apply to you, leave it alone.

To-Do Page Style

 * Please sign things to do with the four tildes (~).

Use Common Sense
Even if something might go against the Manual of Style, this is not written in stone, and not everything is covered in here. As long as it looks alright and is helpful the book it will most likely be fine.

title: MIRC Scripting/Info/Manual of Style


text:
MIRC Scripting/Basics/Basics

You've got the foundation to use mIRC and the Scripts Editor. Now we can start with learning how to script. Read this chapter section by section and follow along with the examples. You will need to understand the skills in this chapter to move on and make any sort of script whatsoever. This is a very long chapter, especially for beginners, so take your time reading this.

Types of Scripts
There are three types of scripts in mIRC.; aliases, popups, and remotes. Each one is comprised of different parts and has its own tab in the scripts editor.

Aliases
Aliases are user-defined commands that stand for a set of one or more commands. Aliases are usually used to simplify everyday IRC tasks, such as identifying your nickname. The syntax of an alias is:

An example of an alias placed in the aliases tab of your script editor would look something like this:

The first part of the alias is hello. This is the alias' name. You would type the command /hello in the command line. The say Hi, I'm $me and I am an mIRC user. part is the command that is executed when you type /hello. Typing /hello and pressing Enter would result in the line showing up in the current window saying "Hi, I'm mynickname and I am an mIRC user."

One important thing to take note of is that I didn't use a / before the alias name or the command. This is unnecessary in the scripts editor. mIRC prefixes every command in a script with a //, which runs every command and evaluates any variables or identifiers in the command automatically. So, mIRC would treat both of these the exact same way:

Multi-line Aliases
mIRC requires anything spanning multiple lines to be enclosed in brackets ({ and }). For example, the alias hello that we had above could use /say twice. This could be accomplished using this code:

WARNING: Another method of doing multi-command blocks of code in mIRC Scripting is called piping, where a pipe character (|) is stuck in between the two commands, such as /echo hi! | /echo goodbye! This makes hard to read code, takes mIRC longer to process, and in general is bad coding practice. Use it sparingly.

Function Key Aliases
Function keys can also be given functions using aliases. Enter the following script in your script editor under Aliases.

Now push F1 on your keyboard. You should see a little dialog box pop up asking for your nickname and password. Enter a nickname, and a password for NickServ if you have one, and hit enter. The script should try and change your nick and identify you to NickServ. Note that depending on your network, you may not have a Nickname Service.

If 12 Fkeys aren't enough for you, well, you can assign up to 36 commands to Fkeys. Use c or s behind an fkey to make the alias work for the key combinations "shift + FX" or "Ctrl + FX."

See the s before the F1? It's the only thing that changed since the last example. However, instead of pressing F1 to activate it, hold shift and press F1. The same thing should happen as last time.

One more notable thing about function key aliases: you can can use them on the command line by typing the name of the alias, like any old alias name. For the alias we made, you would simply type /sF1.

Aliases in Remote Scripts
Aliases also serve a much more important purpose than simply doing a set of commands. Aliases in remote scripts can be used to shorten code and reuse a certain set of commands over and over, which makes writing code a lot easier. Aliases change their syntax a bit when in remote scripts.

To do an alias in a remote section, it must have the <tt>alias</tt> prefix. For example, the command I just made above would now look like

The alias prefix is the only thing that changes. Running the alias still works the same; type <tt>/hello</tt> to see the lines of text on the screen.

The real advantage of putting an alias inside a remote script is being able to use it repeatedly. For example, maybe you have an alias that increases a number three times. Technically, you can use the <tt>/inc</tt> command to do this, but for the sake of the example, we'll make our own alias.

See how I used the <tt>incnum</tt> alias three times? If this was a longer script, I could have saved myself a lot of time and typing by using aliases multiple times. People familiar to other programming/scripting languages will notice that aliases, in this respect, are similar to functions or subroutines that can be recycled.

Local Aliases
If you only want a command to be able to run in one script, or it would overwrite a command built-in to mIRC or another script, you can do <tt>alias -l</tt> in front of the alias name. The <tt>-l</tt> is a switch that tells the alias ONLY to work when called from a script inside that remote file. Let's take our previous example and add a local alias.

Now you cannot use <tt>/incnum</tt> from the command line or from other scripts, but the alias <tt>/incnum3</tt> CAN call it.

Recursive Aliases
mIRC cannot call an alias from inside itself. For example, this code would not work:

You cannot use <tt>/echomyname</tt> recursively inside itself. You CAN call it from another alias, however.

That would work, although it would loop forever, and most likely crash mIRC. Crashing programs is generally a bad idea. And it's quite embarrassing for you when your own program locks up in an infinite loop. So don't do it.

Now, there is one caveat to this recursive alias business. Say you wanted to write over an alias with a custom one of your own. When you call an alias from inside itself, and it has a built-in mIRC version, the alias will call mIRC's version. Take a look at this example:

Let's say you wanted to overwrite the kick alias to say how many kicks you've done. You could do <tt>/k</tt> from now on. Or, using the knowledge that mIRC can't recurse aliases, you could do this:

This will increase your kick count and kick the user you want from the channel, WITH the Total Kicks message. This comes in very useful in more advanced scripting, especially when making themes for full scripts.

Popups
Popups are user-defined context menus that show up at certain places in mIRC when you right-click. There are five popups you can customize; one on the Menu Bar, one in the status window, one on the nicklist, one in channels, and one in private messages.

Making Menus
Open your scripts editor to the Popup tab. I'll be using the Channel tab for the purposes of this book. To define a simple menu item, the syntax is:

So, to make a simple menu item that would change your nickname to "mIRCUser" you could do this:

Submenus
Now right click in any channel. You should see an option saying "Change Nick →" appear. Click it. Your nick, provided it isn't in use, should change to mIRCUser. But what if you have more than one nickname you like to use. Maybe you have the nicknames mIRCUser, Cakeman, and Blackknight. You can add a submenu to this existing menu.

Now, right-click in the channel again. You should see a menu looking something like "Change Nick To →". If you hover over the menu, you get three choices; mIRCUser, Cakeman, and Blacknight, all three of your nicks. You can even make submenus inside your menus.

Multi-Line Menus
But what if your server has a Nickname Service and you identify with your nicks, like in the fkey alias example? Well, popup menu definitions can have multi-line sections just like other parts of scripts using { and }.

Nicklist Menus
Making menus in a nicklist is relatively similar to making regular menus, except you need to specify which nicklist nick is being affected. This is specified by the identifier <tt>$1</tt>. Take note that these menus go under the Nicklist view in the Popups tab.

The identifier <tt>$$1</tt> in this case means the same thing as <tt>$1</tt>. It is the nickname selected on the nicklist (if there is one and you are in a channel). When you click on an option (kick, ban, or kickban), it will do that option to whatever nickname is in <tt>$$1</tt>. For example, the kick option kicks <tt>$$1</tt> from <tt>$$chan</tt> with the message, <tt>"You got kicked by mynick!"</tt>

Now, allow me to use this example to explain the double $$ prefix. When used with an identifier, this will stop a command from executing if the identifier returns <tt>$null</tt>. For instance, if you did not select a nick on the nicklist, <tt>$$1</tt> returns nothing and halts the command. As an added aesthetic bonus, if a double-prefixed identifier returns nothing in a menu item, the menu item will not show up. In this example, the entire menu would be hidden from view if you did not select a nick on the nicklist.

Nicklist menus also support everything regular menus support. You can use multi-line commands, submenus, etc. They work exactly the same. The only real caveat to using pop up menus that target a user in the nicklist is to remember to use <tt>$1</tt> or <tt>$$1</tt>.

Menu Bar Menus
Menu Bar menus work like the rest of the popup menus, except they appear in the menu bar at the top of the mIRC Windows under the "Commands" menu. You can also change the name of the Commands menu, if you'd like. On the first line of a popup file under the menu bar section, put the word <tt>Pie</tt>. Save the file and look at your menu bar. The menu should now be labeled <tt>"Pie."</tt>

Identifiers and Variables In Menu Items
Variables and identifiers in menu items are evaluated each time a menu is opened. As seen in the previous example, a nicklist menu like this:

Would have <tt>$$1</tt> evaluated each time you open then menu.

If you have variables set called <tt>%mytext</tt> and <tt>%mycmd</tt> then the menu item will appear clickable. If you only have <tt>%mytext</tt> set, the item will appear, but grayed out and disabled. If you only have <tt>%mycmd%</tt> set, The menu item will evaluate to <tt>$null</tt> and not appear at all in the menu.

The advantage of using identifiers and variables in popup menus is to make them more dynamic, as seen in the kick/ban menu example above.

Popups in Remote Files
Much like aliases, popups can be defined in remote files, in almost the same way. You simply use the <tt>menu [menuname]</tt> prefix, and then enclose the menu commands in brackets. <tt>Menuname</tt> is the location of the popup; either channel, status, query, menubar, or nicklist. Unlike the Popups tab, a menu under the Remote tab does not know where to open it the menu, so you must say it after the menu prefix.

This is roughly the same as the default menu in mIRC under the Popups/Channel tab, however, it is in a remote file now, with the menu prefix attached.

Menus in remote files can also have multiple menu names of where the menu should pop up. This one will pop up in a channel window OR a query window.

Popup Menu Styles
Menu Styles are used to change the look of your menu items. You can make a menu item appear checked off or disabled using menu styles. There are three menu styles you can use, using the <tt>$style</tt> identifier.

This is an example of a menu that uses styles to disable items if you are not connected to a server.

If mIRC is not connected to a server, both commands will be disabled. If you ARE connected, both of them will be enabled and have check marks (√) next to them.

$submenu
<tt>$submenu</tt> is a fairly advanced identifier that makes a dynamic submenu for a popup menu. It calls a custom identifier with the parameter <tt>$1</tt>, where 1 is a number that increases each time it runs through the identifier, until it stops. Sound confusing? Perhaps this code example will help.

The main thing to pay attention to here is how <tt>$submenu</tt> is used. <tt>$submenu</tt> Inserts the value 1 into <tt>$1</tt>, then increases that each time it goes through until it ends. So for <tt>$chan($1)</tt> in the custom identifier <tt>$_infochan</tt> will return the first channel you are on, then the second one, and so on, until you run out of channels.

Let's assume you are on #mIRC, #Windows, and #Scripting, and ChanServ is on your network. If you right-click in your status window, you will see a menu saying "Get Channel Info →" and three menu items in that menu's submen; #mIRC, #Windows, and #Scripting. Clicking on one of those will do a <tt>/msg chanserv info</tt> on the channel. This command returns information about a registered channel, if it is registered. The output would look something like this:

Menu Separators
To separate menu items, you can use a single '-' (hyphen) in between items.

Remote Scripts
Remote scripts make up the majority of what you will script in mIRC. They are a combination of aliases, popup menus, and event-driven blocks of commands. Unlike aliases and popups, you can have multiple remotes loaded at the same time. Each remote file usually contains one script. An individual script is a remote file (a file ending in .mrc or .ini) with related events, aliases, and popup definitions. An example of a script could be a script that makes you join a channel when you connect to a server, or manage a list of quotes people have said on IRC. The basic syntax of a remote event looks like this:

Remote Events
The <tt>*</tt> is what user level the event will trigger on. User levels are defined later in this section. Typically, events will usually have a user level of <tt>*</tt> or <tt>1</tt>. <tt>*</tt> means the event will trigger on any level, and the <tt>1</tt> means it will trigger by anyone with a user level of 1 or higher (1 is the default level in mIRC, unless you change it, so this will also usually mean anyone). The <tt>event</tt> is the name of the event you are defining. Examples of events are Text, Action, Ban, Join, and Part. You should only have one type of each event in a script for them to work right. The <tt>parameters</tt> part of the event can be anything. It's usually match text, where the event takes place, both, or neither of them. Inside this event block are all the commands you want the script to do.

This is an example of one of the more popular remote events, and one of the easiest to understand. It triggers whenever someone says text that matches the matchtext. The matchtext in this case is <tt>*</tt>, the wild card symbol. This means it will match anything. The if-then-else statement in the event's body determines what text it matches. This is a better idea in practice when using events. Instead of using multiple events that match different things, using one event that uses if-then-else statements will ensure that everything is processed in the right order. In this case, the script checks to see if the word <tt>"hello"</tt> is in the text said, but only in channels. The <tt>#</tt> after the <tt>*</tt> is what determines where the event triggers. You can also specify a <tt>?</tt> for private messages only, and <tt>*</tt> to make it trigger in both channels and PMs.

This is another example of a remote event. This one has no parameters. The event simply triggers when you load the script it is in. When you load this script, it will display the line on your screen, <tt>"Thank you for loading my script!"</tt>.

One important thing to know about remote event scripts is that most of them do not work when you trigger them yourself. Some events do, like On Kick or On Ban, while others like On Text will not work when you say something in a channel with the script loaded. mIRC will generally say in the help file when you can or can't trigger it yourself. Otherwise, it's trial and error.

CTCP Events
CTCP Events are events that trigger when you get a CTCP (client-to-client protocol) from another client. A CTCP event can be used to override a default mIRC action for a CTCP event (with the exception of VERSION), but can also be used to make your own CTCP replies.

A CTCP event looks very similar to a regular remote event. However, instead of the <tt>On</tt> prefix, CTCP events start with <tt>CTCP</tt>. The <tt>*</tt> is still the same; the access level required to trigger the event. <tt>Ctcpname</tt> is the name of the ctcp the event should trigger on. This could be anything from a built-in CTCP event such as <tt>TIME</tt> or <tt>VERSION</tt> or a made-up event such as <tt>BLAH</tt> or <tt>HELLO</tt>. The location parameter, again, is the same as a regular event. <tt>#</tt> is a channel, <tt>?</tt> is a PM, and <tt>*</tt> is both.

This event will respond any time someone CTCPs you with the text <tt>"secretword."</tt> It will check and see if the word they gave matches the secret word. If it matches, the script will PM them saying so.

Using a variable (<tt>%secretword</tt>) as the matchtext for the CTCP event, you can change the secret word any time and shorten the code. Now, the script will only respond when they CTCP you with the correct word.

While you can't hide the original mIRC version reply itself, you can add your own reply to the standard one. This one will send a CTCP reply back using <tt>/ctcpreply</tt> to the person who CTCP'd you with your custom version reply, after the mIRC one.

By enclosing the matchtext in wildcards, this script will trigger any time anyone says the word <tt>help</tt> anywhere in the CTCP query, and msg them back.

Raw Events
Raw events are advanced events that trigger when you receive a raw numeric from a server. This happens when you send a query to a server using a command such as <tt>/whois</tt> and you get a reply back.

Unlike remotes and CTCPs, Raw events ONLY trigger in your client, when you receive raw numerics from the IRC server. This happens when you get a reply after sending a query to a server; for example, using <tt>/whois</tt> or <tt>/away</tt>.

This event replaces mIRC's default reply for Raw 431, the message you get when you fail to specify a target for a command like <tt>/whois</tt> or <tt>/nick</tt>. It silences the default reply using /haltdef.

You may know how to use remote events now, but they are only a small fraction of making remote scripts. Making the events themselves is simple, but there is a huge amount commands to put inside the events. This is the real challenge of mIRC scripting, and what the remaining bulk of this book will cover.

Variables
Variables are dynamic values that evaluate each time the script is run to a certain value. Variables are assigned a certain value and always return their current value when called upon. In mIRC Scripting, variables are untyped. This means that a variable can store any type of data; text, numbers, or any combination of the two. A variable starts with a <tt>%</tt> prefix. There are two kinds of variables; local and global.

Local Variables
Local variables are created during scripts, and do not overwrite other local variables or global variables of the same name. Local variables are destroyed after the calling script executes.

If you type <tt>/saysomething</tt> and hit enter, a box will come up asking, <tt>"What should I say?"</tt>. Enter some text and hit okay. That text will get put into <tt>%text</tt>, and then whatever is in <tt>%text</tt> will be echoed to the screen. <tt>%text</tt> will not exist after the script ends. Try typing <tt>//echo -a %text</tt> into the command line. You should get a <tt>* /echo: insufficient parameters</tt> error. This is because variables evaluate to <tt>$null</tt> if they do not exist.

Global Variables
Global variables stay around once they are set, until they are unset, unlike local variables.

When you connect to a server, the server will ask you what you want your nickname to be if the variable <tt>%connnick</tt> doesn't exist. Either way, it will change your nickname to whatever is in <tt>%connnick</tt>. Now, open your script editor and open the Variables tab. You should see a variable called <tt>%connnick</tt> with a value of whatever nickname you chose. You may also see other variables, if you have run other scripts. These variables are all global, and will stick around under the Variables tab and return a value, until you use the <tt>/unset</tt> command.

Notice the difference in this script? The variable <tt>%connnick</tt>, in a sense, will act like a global variable in this script because of the <tt>-u0</tt> flag in the <tt>/set</tt> command. <tt>-uN</tt> make the global variable unset after N seconds. However, if you specify 0 for N, the variable will unset when the script finishes executing. It is not completely like a local variable; other global variables can overwrite it, and vice-versa. However, it is still a way to make sure the script cleans up all its global variables when it finishes.

Mathematical Equations With Variables
There are two ways to perform mathematical operations on variables; the commands <tt>/inc</tt> and <tt>/dec</tt>, and the <tt>=</tt> (assignment operator).

This alias will take any number you give it, assign it to a variable, and increases it twice using <tt>/inc</tt>. For example, if you did <tt>/incnum2 7</tt> you would get the message <tt>"Your number was increased by two! You got 9!"</tt>

Now the <tt>/inc</tt> commands have changed to <tt>/dec</tt> commands. This will decrease your number by two. The same <tt>/incnum2 7</tt> changed to <tt>/decnum2 7</tt> would give you the number <tt>5</tt>.

This code snippet uses the assignment operator to perform math on the variable. The first thing this code does is check to see if you gave it three parameters. It makes sure <tt>$1</tt> is a number, <tt>$2</tt> is a mathematical operator (+, -, *, or /), and <tt>$3</tt> is a number. If they are all correct, the script then puts the two numbers into variables <tt>%num1</tt> and <tt>%num2</tt>. <tt>%num1</tt> and <tt>%num2</tt> have an operation done to them (whatever you put into <tt>$2</tt>) and reports the result. Doing the command <tt>/math 3 * 2</tt> would output <tt>6</tt>.

A simpler alias than the last one, this command simply takes the first number you give it and multiplies it by itself. <tt>/square 3</tt> will give you <tt>9</tt>.

Identifiers
Identifiers are similar to variables. They are dynamic values in scripts that evaluate when they are parsed in the script. However, unlike variables, they do not always return a static value that is the same every time. Like variables, they can evaluate to <tt>$null</tt>.

For example, one identifier we have used a lot so far is <tt>$1</tt>. <tt>$1</tt> evaluates to the first parameter, if any, passed to a command when it is run. However, this is not always in the same. In the example above, we could use the command <tt>/square 3</tt>. <tt>$1</tt> in this case is <tt>3</tt>. Let's change that <tt>3</tt> to a <tt>4</tt>. Now <tt>$1</tt> is <tt>4</tt>. Pass nothing to it, and <tt>$1</tt> will evaluate to <tt>$null</tt>.

Another popular identifier used is <tt>$chan</tt>. <tt>$chan</tt> returns whatever channel a script or command triggers in. Make sure you have two channels open. Go to one of them, and type <tt>//echo $chan $chan</tt>.The effect of this action is to print in the current channel(the first occurrence of "$chan")right the name of current channel(evalutate by the second "$chan"). Now go to a different channel and do the same command. Notice you still get the channel name. This is because <tt>$chan</tt> re-evaluates every time is occurs in a script.

Built-In Identifiers
Built-In identifiers are identifiers coded into mIRC. There are dozens of built-in identifiers, but some of the most used are <tt>$nick</tt>, <tt>$chan</tt>, <tt>$me</tt>, <tt>$1</tt>, and <tt>$+</tt>. Identifiers built-in to mIRC have priority over custom ones and cannot be changed or re-coded, unlike built-in commands.

Custom Identifiers
A custom identifier is an alias that can return a value. Custom identifiers take the form of a regular alias, but are used differently. They are called with the same <tt>$</tt> prefix as regular identifiers instead of the <tt>/</tt> prefix used when calling an alias as a command.

The script first starts off by again, checking to make sure the two parameters are valid numbers. Then, it returns the value of the two numbers added together. The proper way to use this is <tt>//echo -a $addnum(n1,n2)</tt>. If you type this as a command, nothing will happen. <tt>/addnum 1 2</tt> will return a value of <tt>3</tt>, but nothing will show up because it returns a value, instead of echoing it. You can change this, however, using the identifier <tt>$isid</tt>.

<tt>$isid</tt> returns <tt>$true</tt> if the alias was called as <tt>$addnum</tt> and <tt>$false</tt> if it was called as the alias <tt>/addnum</tt>. Combined with another identifier, <tt>$iif</tt>, we can determine if <tt>$isid</tt> returns <tt>$true</tt> or <tt>$false</tt> and take an action based on what the result is. If <tt>$isid</tt> is true, that means <tt>addnum</tt> was called as an identifier, and will return a value. If <tt>$isid</tt> is false, then <tt>addnum</tt> was called as an alias, and will echo a value to the screen. Try the command both ways now with <tt>1</tt> and <tt>2</tt>. Both times, you should get <tt>3</tt>

Custom Properties
You may notice that some identifiers have properties. For example, if you type <tt>//echo -a $chan(1).topic</tt>, the topic of the first channel you are on will display on your screen. <tt>.topic</tt> is the property of the identifier. You can add properties to your identifiers, too.

Again, using <tt>$iif</tt>, we can check the property of the identifier. If you use the command <tt>//echo -a $addnum(1,2).neg</tt>, instead of returning <tt>3</tt> you will get <tt>-3</tt>. This because the property <tt>.neg</tt> was used with <tt>$addnum</tt>.

'' Note: Built in identifiers to mIRC will take precedence over custom ones with the same name. You cannot re-script <tt>$chan</tt> to return <tt>42</tt>. mIRC will still return the name of the channel you are on.''

Comments
Comments are a very important part of coding when your scripts start to get very large and complex. You will hopefully remember tomorrow what your code did last night, but can you say you will remember what a line of code should do six months from now? Comments are lines of code that are ignored by mIRC's interpreter and can be used to remind you what a certain part of a script does. This is what the last example could look like if we commented it.

Single Line Comments
All the comments in this code were one line comments. One line comments start with either <tt>;</tt> or <tt>//</tt> and a blank space, then the comment. We could just as easily have used <tt>//</tt> for comments in that script instead of <tt>;</tt>. All one line comments end at the end of the line they start on.

Multi Line Comments
Multi line comments span multiple lines. They start wherever a <tt>/*</tt> is placed in the code and ends wherever there is a <tt>*/</tt> in the code.

Using multi-line comments, we achieved the same effect as the one line comments, but in one multi line comment.

Command Prefixes
There are three types of prefixes that are placed in front of commands, and one prefix placed before identifiers, variables, and operators.

Control Codes
Control codes are special characters that are placed in text to modify the look of text.

If you've made it this far, congratulations for making it through this long chapter! You can now make some basic mIRC scripts, and you should understand a few of the concepts required to script. If you're ready, you can go on to the next chapter.

Back To Top

title: MIRC Scripting/Basics/Basics


text: User talk:69.62.164.230

title: User talk:69.62.164.230


text:
Talk:Blender 3D: Noob to Pro/Platformer: Physics Fixes

Lokiclock, I don't understand why you created a new plane for the touch sensor. Why not just add a property to the existing floor and use that?

Also, what sort of problems are you having with jumping? The tutorial isn't very clear beyond the part about jumping in mid-air. There are non-pythonic solutions to some problems posed by the game engine (although not many!)... this might be one of them.

-> (Non-Python) Possible solution to jumping:

1) Give all ground objects an identical property (say "ground")

2) Create a cube under the player (about the size/location of the jumping limits) and parent it to said player--the cube must not be touching the player. Bad things happen with constant ghost collision, namely slowing the game down a lot.

3) Make cube ghost

4) Give cube a collision sensor for property ground

5) Connect cube collision sensor to jump controller (make it an "AND" controller)

-Note: You should probably make the jump-cube an inverted pyramid (longer on the z axis) depending on how you want jumping to be restricted. This would make it so you couldn't jump off walls unless they were directly below you, or very close to you (thus the up-side down pyramid).

Malaz

 * The problem arises later on that you can jump infinitely in mid-air. So you have to link it to a collision with some ground object. If you just link it to the cubes, you end up being able to jump while touching any side of the cube, not just the top. You can still kind of jump while being almost on the collision platforms and not having to necessarily be on top of them, which is the problem I could not solve within the engine. I am not sure your jump-cube pyramid would to the trick. I suppose it's worth a shot. You'd have to make the cube send a message that the player requires as a jump condition, because I don't think you could have the jump cube's collision connect directly to the player's jump business. Loki Clock (talk) 09:02, 11 March 2008 (UTC)

 * Actually, you can just directly link the collision sensor (of the jump-pyramid) to the jumping controller. You just have to select both the pyramid and the player, then you can link between objects. --Malaz (talk) 00:40, 12 March 2008 (UTC)

 * A much simpler way is to simply use a -Z ray sensor, rather than the whole pyramid-collision thing. It works just as well with a bit of tweaking, and is probably faster.--207.81.49.53 (talk) 19:04, 25 March 2008 (UTC)


text:
Geometry/Circles/Sectors

Sector of a circle
A sector of a circle can be thought of as a pie piece. In the picture below, a sector of the circle is shaded yellow.

To find the area of a sector, find the area of the whole circle and then multiply by the angle of the sector over 360 degrees.

$$A = \pi r^2 \cdot \frac{\theta}{360}$$

A more intuitive approach can be used when the sector is half the circle. In this case the area of the sector would just be the area of the circle divided by 2.

title: Geometry/Circles/Sectors


text:
User talk:Lizransey

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 01:13, 3 March 2008 (UTC)

title: User talk:Lizransey


text:
User talk:DavidLevinson

Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. – Mike.lifeguard  | talk 01:21, 3 March 2008 (UTC)

Equations
There are some errors in the math syntax at Fundamentals of Transportation/Operations. TeX markup may be helpful. – Mike.lifeguard  | talk 01:21, 3 March 2008 (UTC)
 * also Fundamentals of Transportation/Design. – Mike.lifeguard  | talk 01:22, 3 March 2008 (UTC)

Fundamentals of Transportation and Computer Networks
I have been skimming your work and even if I don't know the particular application to traffic, something do have some parallel in computer network traffic and optimization. Costs, route optimization, queueing and many other aspects, this is something that even if a bit far from the book topic would probably merit some reference, perhaps on the introduction. I will take a look on the math on the work to see how portable it is, great work, thx for your contributions... --Panic (talk) 01:27, 12 March 2008 (UTC)

Commons category Transport Economics
Hello- I noticed you have several files at commons categorized as "Transport Economics" rather than "Transportation Economics". Is that intentional? TDang (talk) 16:57, 8 September 2009 (UTC)
 * Nope, just me lapsing into UK English instead of US English. Feel free to fix. dml (talk) 18:29, 10 September 2009 (UTC)

Citation bibtex test
@article{levinson1998accessibility, title=, author={Levinson, D.M.}, journal={Journal of Transport Geography}, volume={6}, number={1}, pages={11--21}, year={1998}, publisher={Elsevier} }

WCI 2011 : Accelerating Wikibooks : Would like to discuss!
Hello!

I will be delivering a Talk at the Wikimedia Conference India 2011 on the topic of "Accelerating Wikibooks".

Over the next few days, I aim to make the proposal more and more wholesome and relevant. I'd like to discuss with you about the proposal and hope you can recommend me a few names on Wikibooks with whom I can discuss this.

I'd be very happy if you could discuss the proposal at User:Thewinster/Accelerating_Wikibooks

--Thewinster (discuss • contribs) 08:20, 26 September 2011 (UTC)

Summary of the proposal
This is not a summary of the final talk, only a tentative guideline.

 * Create Roadmaps for a book
 * Define Learning Outcomes
 * Annotate and Discuss new content available from around the web.
 * Minor tweaks and fixes which concentrate on crowdsourcing.
 * Identifying Small Contribution that advance a book and designing good UIs and triggers according to B.J. Fogg's Behavior Change Model, 8 Step Design Process. The paper can be found here at Persuasive Design : Eight Step Process by B. J. Fogg

Reversion
I reverted your edit on Transportation Deployment Casebook/Growth of the Modern U.S. Highway System, Post 1960. I took you page blanking and comment in consideration and have initiated a copyvio discussion. Read the post on the talk page for more information or to put forward information on the infringed material. --Panic (discuss • contribs) 19:37, 8 November 2011 (UTC)

Transportation Deployment Casebook
Are you the one overseeing the 2021 version of that book? Leaderboard (discuss • contribs) 11:15, 25 March 2021 (UTC)

 * Yes, should be mostly done with student submissions now. dml (discuss • contribs) 20:57, 28 March 2021 (UTC)

title: User talk:DavidLevinson


text: User talk:208.100.205.28

title: User talk:208.100.205.28


text: User talk:203.106.67.247

title: User talk:203.106.67.247


text:
User:Remi/Notes

Negative effects of real estate flipping
Many experts blame the US real estate bubble in 2004 and 2005 on investor speculation and "irrational" flipping. Very low interest rates were a root cause, but speculation and flipping compounded the bubble. Although the practice of flipping existed long before the real estate bubble, it became more rampant and widespread in those years. Flipping was so popular nationally that some DIY television programs detailed the process. Flipping trends have historically ended in disaster, such as during the Florida Real Estate Crash of the 1920s. In 2006 we see, reported by USNEWS on Wed June 14 2006, that the "Housing bubble correction could be severe."

Flipping can play a role in the gentrification of older communities. As flipping occurs more and more in a community, the total cost of living there can rise substantially, essentially forcing the local people, specifically the younger generations, to relocate. During the real estate bubble, flipping and gentrification both have been linked to the mass migration of Californians to the (once much) less expensive areas of the surrounding states such as Arizona, Nevada, Texas, Oregon and Washington. This migration of Californians caused further gentrification in the areas that they had moved to en masse. Areas such as Phoenix, AZ and Las Vegas, NV which were once very inexpensive to live in prior to the real estate bubble are now quite expensive. The chain reaction continued (continues?), as the gentrified people of these cities had to find somewhere cheaper to live to maintain their standard of living, where they undoubtedly caused gentrification of their own.

The other significant adverse financial aspect of the mentality of "flipping" is when interest rates increase. The resulting lack of sales, and major price depreciations (often far below) their previous increases, results in a flood of properties on the market at one time, not selling due to lack of buyers, causing a meltdown of a local market and potentially the economy as a whole.

Positive effects of real estate flipping
Although most arguments surrounding flipping tend to be negative, it is also possible to identify some benefits from the practice as well.

For example, "rational" flipping can encourage a rejuvenation and restoration of a previously decrepit neighborhood. (Under the broken windows theory, an unkept house/area attracts a criminal element, which drives out those making a responsible living, which allows for more criminal element, and so on in a vicious downward cycle.) The restoration creates jobs, particularly in construction, for locals and generates more sales (and sales taxes) to local vendors (initially those involved in selling construction materials). The newly remodelled homes will then attract new populations and businesses to a region, encouraging more economic development, plus the remodelled homes' higher assessed values brings more property tax revenues to local governments, allowing for more improvements to the area and driving out the criminal element.

Even on a single home basis, flipping can have positive impacts (the house itself will be in better condition and last longer, and can be sold at a higher price, thus increasing its property tax assessed value, plus increased sales for goods and services related to property improvement and the related increase in sales taxes).

Source

 * http://en.wikipedia.org/w/index.php?title=Flipping&oldid=193184834

Contributors

 * http://en.wikipedia.org/w/index.php?title=Flipping&action=history

http://en.wikipedia.org/wiki/US_real_estate_bubble

title: User:Remi/Notes


text: Category:Book:SuperCard Programming

title: Category:Book:SuperCard Programming


text:
User talk:Johnnyvancouver~enwikibooks

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 02:50, 3 March 2008 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Johnnyvancouver. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Johnnyvancouver~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:20, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:05, 19 April 2015 (UTC)

title: User talk:Johnnyvancouver~enwikibooks


text:
User talk:Cassiopeia sweet

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 02:50, 3 March 2008 (UTC)

title: User talk:Cassiopeia sweet


text:
User talk:Æ~enwikibooks

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 02:50, 3 March 2008 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Æ. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Æ~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:55, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:40, 19 April 2015 (UTC)

title: User talk:Æ~enwikibooks


text:
User talk:Ƕ

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 02:50, 3 March 2008 (UTC)

title: User talk:Ƕ


text:
User talk:Swebb~enwikibooks

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 02:51, 3 March 2008 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Swebb. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Swebb~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:44, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 05:34, 19 April 2015 (UTC)

title: User talk:Swebb~enwikibooks


text:
User talk:Webb21

Welcome!
Welcome, !

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.-- – Mike.lifeguard  | talk 02:51, 3 March 2008 (UTC)

title: User talk:Webb21


text: User talk:69.126.117.98

title: User talk:69.126.117.98