text:
Modern History/Napoleon Bonaparte

Emperor Napoleon Bonaparte (15 August 1769 – 5 May 1821) was a general of the French Revolution; the ruler of France as First Consul (Premier Consul) of the French Republic from 11 November 1799 to 18 May 1804; then Emperor of the French (Empereur des Français) and King of Italy under the name Napoleon I from 18 May 1804 to 6 April 1814; and briefly restored as Emperor from March 20 to June 22 of 1815.

Although Napoleon himself developed few military innovations, apart from the divisional squares employed in Egypt and the placement of artillery into batteries, he used the best tactics from a variety of sources, and the modernized French army, as reformed under the various revolutionary governments, to score some major victories. His campaigns are studied at military academies all over the world and he is generally regarded as one of the greatest commanders to have ever lived. Over the course of little more than a decade, he fought virtually every European power and acquired control of most of the western and central mainland of Europe by conquest or alliance until his disastrous invasion of Russia in 1812, followed by defeat at the Battle of Leipzig in October 1813, which led to his abdication several months later and his exile to the island of Elba. He staged a comeback known as the Hundred Days (les Cent Jours), but was again defeated decisively at the Battle of Waterloo in present day Belgium on June 18, 1815, followed shortly afterwards by his surrender to the British and his exile to the island of Saint Helena, where he died six years later.

Aside from his military achievements, Napoleon is also remembered for the establishment of the Napoleonic Code. He is considered by some to have been one of the "enlightened despots".

title: Modern History/Napoleon Bonaparte


text:
Authoring Foreign Language Textbooks/Bite-sized language lessons

Bite-Sized Language Lessons: An Idea for Content Improvement
A lot of the existing language course books unfortunately aren't very helpful to learners right now because they aren't very organised: since different people with different ideas contributed, each lesson might differ from the others in its approach, in what prior vocabulary/grammar knowledge it assumes or even what final study goal it pursues. Also there is a didactic problem: often the student is drowned in new things he has to learn in the course of a lesson in order to be able to progress.

Hence my idea for a new type of language courses in Wikibooks, which I already successfully used for German on my private website: courses using a "bite-sized" approach. In short, it means to prepare lessons in such a way that the student will be able to comfortably study one lesson per session and yet to allow him to learn more if he wants to by way of optional modules.

The basic structure of such a lesson:
 * Text or dialogue in the foreign language
 * New words
 * Grammar / word usage explanations
 * Exercise(s)
 * Exercise answers (for auto-correction)
 * Extra vocabulary for optional study

Additionally, the lesson may be interspersed with cultural notes and tips for learning - mnemonics and the like.

The goal of the course shall be proficiency level A1 as defined in the Common European Framework of Reference for Languages. Then more levels can be built with the clear goal of moving from A1 to A2, A2 to B1 and so on, which will allow for better splitting of tasks.

The lesson texts (at least for the first level) will be about common situations that learners may soon find themselves in and they will use standard everyday language. There should be no useless phrases such as "My tailor's son studies dasology"(true example from a commercial textbook!).

A lesson should aim to introduce just 10 new words but in no case should there be more than 15. More vocabulary can be offered in the optional module at the end and the interested student will browse through the optional vocabulary and learn anything he considers important for his personal situation. For example an Algerian person would probably want to learn how to say "Algeria" in the foreign language, but all other students can safely ignore that word until they are at a far more advanced level. In the lesson teaching how to say "I come from ...", "Algeria" and most country names would not be mandatory vocabulary to learn but they would figure on the list of optional vocabulary. The vocabulary taught should be oriented at the most common words in a language and avoid rare ones at all cost.

Similarly, there should not be much grammar in a lesson, not tables upon tables of conjugation to learn for example. Three or four short notes, covering half a screen in total, will be enough. Once a student is familiar enough with the grammar taught in one lesson and would like to learn more, he can move on to the next lesson. That not just ensures that nobody is overwhelmed, it also provides a feeling of success.

Of exercises there can hardly be enough and every lesson needs to include exercises; they are essential to understanding and learning of new grammar or vocabulary. Challenged students will need many opportunities to practise. Unlike in a classroom situation, this won't be a bother for good students because they can always skip some exercises and move on to the next topic.

I have started posting lessons using this approach for German here: BLL German

Help is of course welcome, particularly in wikifying the existing lessons from my website.

I have received nothing but good critiques for this and I really believe that people learning any language in self-study would benefit from such an approach.

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


text:
Modern History/Schrammel accordion

A Schrammel accordion (German: Schrammelharmonika) is an accordion with a melody (right hand) keyboard in the chromatic B-Griff system and a twelve-button diatonic bass keyboard. It is named for a traditional combination of two Violins, Accordion and Contrabass known as Schrammelquartett, the music being performed was called Schrammel music, in the Vienna chamber music tradition.

In most cases, it has two or three sets of reeds tuned in unison configuration. The sound is quite different or special, when compared to modern chromatic button accordions. This is because it is much smaller and lighter than modern CBAs. The handmade reeds used may also contribute to its sound.

title: Modern History/Schrammel accordion


text:
VCE Chemistry

The purpose of this text is to produce a reliable and free textbook, specifically tailored toward the needs of students studying VCE Chemistry in an attempt to gain the Victorian Certificate of Education (VCE). The eventual aim is to provide a practical alternative to standard textbooks, complete with exercises and worked examples.

The Periodic Table
In 1856, Mendeléev, a Russian scientist,was the first to construct a Periodic Table. He pointed out that elements with similar properties kept recurring at regular intervals or periods. He predicted that there were undiscovered elements which could fill these gaps .He even predicted the possible properties of these elements. The modern Periodic Laws states that the properties of the elements are a periodic function of their atomic numbers.
 * /History of The Periodic Table/
 * /Different Views on Matter/
 * /The Current Periodic Table/
 * /Relative Atomic Mass and the Mole/

Materials

 * /Metals/
 * /Ionic Compounds/
 * /Covalent molecules, networks and layers/
 * /Carbon Compounds/
 * /Surfaces, Bonding and Nano-particles/

Water

 * /Solubility/
 * /Precipitation/
 * /Acids and Bases/
 * /Stoichiometry/
 * /Redox Reactions and Corrosion/
 * /Green Chemistry/

The Atmosphere

 * /Atmospheric Make-up/
 * /Environmental Issues/
 * /Gases in the Atmosphere/
 * /Properties of Gases/

Appendices: Unit 1 and Unit 2

 * /Units 1 and 2: Glossary/
 * /Periodic Table/

Chemical Analysis

 * /Analysis via mass/
 * /Volumetric Analysis/
 * /Analysis of acids and bases/
 * /Analysis of oxidants and reductants/
 * /Chromatography/
 * /Spectroscopy/
 * /Combinations of analysis/

Industrial Chemistry

 * /Reaction Speed/
 * /Reaction Yield/
 * /Precipitation/
 * /Equilibria with Acids and Bases/
 * /Benefits and Risks of Industrial Chemistry/
 * /Production of Ammonia/
 * /Production of Nitric Acid/
 * /Production of Sulfuric Acid/
 * /Production of Ethene/

Supplying and Using Chemistry

 * /Fossil Fuels/
 * /Alternative Energy/
 * /Energy in Chemical Reactions; heat and electricity/
 * /Batteries and cells/
 * /Electrolysis/

Appendices: Units 3 and 4

 * /Units 3 and 4: Glossary/

title: VCE Chemistry


text:
WebObjects/Project WONDER/Frameworks/ERJavaMail

Overview
ERJavaMail provides a simple and powerful API for sending component-based emails from a WebObjects application. ERJavaMail does not depend on any other pieces of Project Wonder, and is a good way to get your feet wet using Wonder.

Configuration
Centralize sends all emails to the er.javamail.adminEmail user. Determines whether or not email debugging is displayed. This contains protocol-level debug information. The email address of the admin user to send centralized emails to. This is a required property. The SMTP host name to use. If this isn't set, mail.smtp.host will be checked and ultimately WOHost will be used. The number of messages that the sender queue can hold. Defaults to 50. The number of milliseconds to wait if the sender queue is full. Default is 6000. Sets whether or not Authenticated SMTP is used to send outgoing mail. If set, er.javamail.smtpUser MUST also be set (and preferably er.javamail.smtpPassword). The username to use to login to the authenticated SMTP server. The password to use to login to the authenticated SMTP server. The X-Mailer header to put into all outgoing mail messages. Defaults to nothing. The default character encoding to use for message content. Defaults to ???. A comma-separated list of whitelisted email address patterns. If set, then only addresses that match one of the whitelisted patterns will delivered to. Pattern syntax is the same as EOQualifier's caseInsensitiveLike. A comma-separated list of blacklisted email address patterns. If set, then any email addresses that match a blacklist pattern will not be delivered to. Pattern syntax is the same as EOQualifier's caseInsensitiveLike. The blacklist filter is processed last, so a blacklist pattern beats a whitelist pattern.
 * er.javamail.centralize = true
 * er.javamail.debugEnabled = true
 * er.javamail.adminEmail = user@domain.com
 * er.javamail.smtpHost = smtp.domain.com
 * er.javamail.senderQueue.size = 50
 * er.javamail.milliSecondsWaitIfSenderOverflowed = 6000
 * er.javamail.smtpAuth = true
 * er.javamail.smtpUser = smtpusername
 * er.javamail.smtpPassword = smtppassword
 * er.javamail.XMailerHeader =
 * er.javamail.defaultEncoding = UTF-8
 * er.javamail.WhiteListEmailAddressPatterns =
 * er.javamail.BlackListEmailAddressPatterns =

Example Usage
// Create an instance of an ERMailDelivery subclass ERMailDeliveryHTML mail = new ERMailDeliveryHTML ; // Here ERMailDeliveryHTML needs a WOComponent to  // render the HTML text content. mail.setComponent(mailPage); // Here you create a new instance of the message // You can loop over this fragment of code, not // forgetting to use newMail // before you set the attributes of the message. try { mail.newMail; mail.setFromAddress(emailFrom); mail.setReplyToAddress(emailReplyTo); mail.setSubject(emailSubject); mail.setToAddresses(new NSArray (toEmailAddresses)); // Send the mail. There is an optional sendMail(boolean) that // optionally blocks during the send. mail.sendMail; } catch (Exception e) { // handle the exception ... }

Example of sending Mail with Attachments
The subclasses of ERMailDelivery will not only deliver the mail for you, but also will create the message. So ERMailDelivery is in some way more like a message than a delivery mechanism. For each message you want to sent instantiate a concrete subclass of ERMailDelivery (e.g. ERMailDeliveryPlainText). You can then add attachments to it. Below a simple code snippet sending of a mail with an attachment. The MimeType of the attachment is parsed out of the extension of the filename.

Sending mail is per default asynchronous, you can specify a flag (true == shouldBlock, false == should not block) to influence the behaviour.

byte[] content; // assume this exist, same interface exists for NSData, too // Create an instance of an ERMailDelivery subclass ERMailDeliveryPlainText message = new ERMailDeliveryPlainText; // set the text and subject message.setTextContent("Some Mail text"); message.setSubject("The mail subject"); // add the attachment message.addAttachment(new ERMailDataAttachment("myattachment.zip", null, content)); message.setToAddress("receiver@bitbucket.com"); message.setFromAddress("sender@bitbucket.com"); // send the mail asynchronously message.sendMail;

Gotchas
Be careful of the WOContext that contains the component you are sending. If you use ERMailDeliveryHTML inside of the normal request-response loop with the default WOContext, it is very likely that the next page that is sent to the user will be the emailed component rather than the page you WANTED to send. There are several possible workarounds for this. One is to return a specific component rather than null from your action method. I have had better and more consistent success with the following code:

WOContext context = (WOContext) context.clone; MyComponent component = (MyComponent) WOApplication.application.pageWithName(MyComponent.class.getName, context); ERMailDeliveryHTML mail = new ERMailDeliveryHTML; mail.setComponent(component); ...

This seems to properly isolate the email to a clone of the current context rather than the actual active context. Your mileage may vary.


text:
WebObjects/Web Applications/Development/Sending Emails

Overview
Sending emails is a very common requirement in a web application. There are several methods you can choose from, each with varying levels of complexity and power.

JavaMail
JavaMail is Sun's API definition and open-source reference implementation of various methods of sending and receiving mail. All of the other WO mail-sending techniques are based on JavaMail, but you can choose to use it directly rather than use the higher level API's described below. If you would like to use JavaMail on your own, you will need to download and install the following jars and put them into your WOA's classpath:

 * JavaMail
 * Java Activation Framework

WOMailDelivery
Built into WebObjects is the WOMailDelivery class. It provides a very simple API for sending mails, but lacks the power of Project Wonder's version. To use WOMailDelivery, you will need to set your SMTP server in one of the following ways:

 * Add -DWOSMTPHost=smtp.yourmailserver as a launch parameter
 * Set WOSMTPHost=smtp.yourmailserver.com in your Properties file
 * Hardcode it with WOApplication.application.setSMTPHost("smtp.yourmailserver.com");

Refer to the WOMailDelivery API for more information, but to simply send an email, you can use the following command:

WOMailDelivery.sharedInstance.composePlainTextEmail(   fromAddress,    toAddresses,    bccAddresses,    subject,    body,    WOMailDelivery.SEND_NOW );

By default, WOMailDelivery with use Sun's old SMTP implementation. However, if you install JavaMail (as described above) into your WOA or /Library/WebObjects/Extensions, WOMailDelivery will use it instead.

ERJavaMail
ERJavaMail is part of Project Wonder and provides an API for sending component-based emails. ERJavaMail also uses the JavaMail API's underneath, but it includes the jars inside its framework, so you don't need to manually install JavaMail to use it. Because it does not have any external dependencies on other Project Wonder frameworks, you can use it without bringing in any other Project Wonder frameworks. For more information on ERJavaMail, see the ERJavaMail page.


text:
Control Systems/Nichols Charts

Nichols Charts
This page will talk about the use of Nichols charts to analyze frequency-domain characteristics of control systems.

title: Control Systems/Nichols Charts


text:
Control Systems/State-Space Equations

Time-Domain Approach
The "Classical" method of controls (what we have been studying so far) has been based mostly in the transform domain. When we want to control the system in general, we represent it using the Laplace transform (Z-Transform for digital systems) and when we want to examine the frequency characteristics of a system we use the Fourier Transform. The question arises, why do we do this?

Let's look at a basic second-order Laplace Transform transfer function:

 * $$\frac{Y(s)}{X(s)} = G(s) = \frac{1 + s}{1 + 2s + 5s^2}$$

We can decompose this equation in terms of the system inputs and outputs:

 * $$(1 + 2s + 5 s^2)Y(s) = (1 + s)X(s)$$

Now, when we take the inverse Laplace transform of our equation, we can see that:

 * $$y(t) + 2\frac{d y(t)}{dt} + 5\frac{d^2y(t)}{dt^2} = x(t) + \frac{dx(t)}{dt}$$

The Laplace transform is transforming the fact that we are dealing with second-order differential equations. The Laplace transform moves a system out of the time-domain into the complex frequency domain so we can study and manipulate our systems as algebraic polynomials instead of linear ODEs. Given the complexity of differential equations, why would we ever want to work in the time domain?

It turns out that to decompose our higher-order differential equations into multiple first-order equations, one can find a new method for easily manipulating the system without having to use integral transforms. The solution to this problem is state variables . By taking our multiple first-order differential equations and analyzing them in vector form, we can not only do the same things we were doing in the time domain using simple matrix algebra, but now we can easily account for systems with multiple inputs and outputs without adding much unnecessary complexity. This demonstrates why the "modern" state-space approach to controls has become popular.

State-Space
In a state-space system, the internal state of the system is explicitly accounted for by an equation known as the state equation. The system output is given in terms of a combination of the current system state, and the current system input, through the output equation. These two equations form a system of equations known collectively as state-space equations. The state-space is the vector space that consists of all the possible internal states of the system.

For a system to be modeled using the state-space method, the system must meet this requirement:

 * 1) The system must be "lumped"

"Lumped" in this context, means that we can find a finite-dimensional state-space vector which fully characterises all such internal states of the system.

This text mostly considers linear state-space systems where the state and output equations satisfy the superposition principle. However, the state-space approach is equally valid for nonlinear systems although some specific methods are not applicable to nonlinear systems.

State
Central to the state-space notation is the idea of a state. A state of a system is the current value of internal elements of the system which change separately (but are not completely unrelated) to the output of the system. In essence, the state of a system is an explicit account of the values of the internal system components. Here are some examples:

State Variables
When modeling a system using a state-space equation, we first need to define three vectors:

 * Input variables: A SISO (Single-Input Single-Output) system will only have one input value, but a MIMO (Multiple-Input Multiple-Output) system may have multiple inputs. We need to define all the inputs to the system and arrange them into a vector.
 * Output variables: This is the system output value, and in the case of MIMO systems we may have several. Output variables should be independent of one another, and only dependent on a linear combination of the input vector and the state vector.
 * State Variables: The state variables represent values from inside the system that can change over time. In an electric circuit for instance, the node voltages or the mesh currents can be state variables. In a mechanical system, the forces applied by springs, gravity, and dashpots can be state variables.

We denote the input variables with u, the output variables with y, and the state variables with x. In essence, we have the following relationship:

 * $$y = f(x, u)$$

Where f(x, u) is our system. Also, the state variables can change with respect to the current state and the system input:

 * $$x' = g(x, u)$$

Where x'  is the rate of change of the state variables. We will define f(u, x) and g(u, x) in the next chapter.

Multi-Input, Multi-Output
In the Laplace domain, if we want to account for systems with multiple inputs and multiple outputs, we are going to need to rely on the principle of superposition to create a system of simultaneous Laplace equations for each input and output. For such systems, the classical approach not only doesn't simplify the situation, but because the systems of equations need to be transformed into the frequency domain first, manipulated, and then transformed back into the time domain, they can actually be more difficult to work with. However, the Laplace domain technique can be combined with the State-Space techniques discussed in the next few chapters to bring out the best features of both techniques. We will discuss MIMO systems in the MIMO Systems Chapter.

State-Space Equations
In a state-space system representation, we have a system of two equations: an equation for determining the state of the system, and another equation for determining the output of the system. We will use the variable y(t) as the output of the system, x(t) as the state of the system, and u(t) as the input of the system. We use the notation x'(t) (note the prime) for the first derivative of the state vector of the system, as dependent on the current state of the system and the current input. Symbolically, we say that there are transforms g and h, that display this relationship:

 * $$x'(t) = g[t_0, t, x(t), x(0), u(t)]$$
 * $$y(t) = h[t, x(t), u(t)]$$

The first equation shows that the system state change is dependent on the previous system state, the initial state of the system, the time, and the system inputs. The second equation shows that the system output is dependent on the current system state, the system input, and the current time.

If the system state change x'(t) and the system output y(t) are linear combinations of the system state and input vectors, then we can say the systems are linear systems, and we can rewrite them in matrix form:

 * $$x'(t) = A(t)x(t) + B(t)u(t)$$

 * $$y(t) = C(t)x(t) + D(t)u(t)$$

If the systems themselves are time-invariant, we can re-write this as follows:

 * $$x'(t) = Ax(t) + Bu(t)$$
 * $$y(t) = Cx(t) + Du(t)$$

The State Equation shows the relationship between the system's current state and its input, and the future state of the system. The Output Equation shows the relationship between the system state and its input, and the output. These equations show that in a given system, the current output is dependent on the current input and the current state. The future state is also dependent on the current state and the current input.

It is important to note at this point that the state space equations of a particular system are not unique, and there are an infinite number of ways to represent these equations by manipulating the A, B, C and D matrices using row operations. There are a number of "standard forms" for these matrices, however, that make certain computations easier. Converting between these forms will require knowledge of linear algebra.

Matrices: A B C D
Our system has the form:

 * $$\mathbf{x}'(t) = \mathbf{g}[t_0, t, \mathbf{x}(t), x(0), \mathbf{u}(t)]$$
 * $$\mathbf{y}(t) = \mathbf{h}[t, \mathbf{x}(t), \mathbf{u}(t)]$$

We've bolded several quantities to try and reinforce the fact that they can be vectors, not just scalar quantities. If these systems are time-invariant, we can simplify them by removing the time variables:

 * $$\mathbf{x}'(t) = \mathbf{g}[\mathbf{x}(t), x(0), \mathbf{u}(t)]$$
 * $$\mathbf{y}(t) = \mathbf{h}[\mathbf{x}(t), \mathbf{u}(t)]$$

Now, if we take the partial derivatives of these functions with respect to the input and the state vector at time t0, we get our system matrices:

 * $$A = \mathbf{g}_x[x(0), x(0), u(0)]$$
 * $$B = \mathbf{g}_u[x(0), x(0), u(0)]$$
 * $$C = \mathbf{h}_x[x(0), u(0)]$$
 * $$D = \mathbf{h}_u[x(0), u(0)]$$

In our time-invariant state space equations, we write these matrices and their relationships as:

 * $$x'(t) = Ax(t) + Bu(t)$$
 * $$y(t) = Cx(t) + Du(t)$$

We have four constant matrices: A, B, C, and D. We will explain these matrices below:
 * Matrix A:Matrix A is the system matrix, and relates how the current state affects the state change x' . If the state change is not dependent on the current state, A will be the zero matrix. The exponential of the state matrix, eAt is called the state transition matrix, and is an important function that we will describe below.
 * Matrix B:Matrix B is the control matrix, and determines how the system input affects the state change. If the state change is not dependent on the system input, then B will be the zero matrix.
 * Matrix C:Matrix C is the output matrix, and determines the relationship between the system state and the system output.
 * Matrix D:Matrix D is the feed-forward matrix, and allows for the system input to affect the system output directly. A basic feedback system like those we have previously considered do not have a feed-forward element, and therefore for most of the systems we have already considered, the D matrix is the zero matrix.

Matrix Dimensions
Because we are adding and multiplying multiple matrices and vectors together, we need to be absolutely certain that the matrices have compatible dimensions, or else the equations will be undefined. For integer values p, q, and r, the dimensions of the system matrices and vectors are defined as follows:

 * {| class="wikitable"

!Vectors || Matrices
 * $$x: p \times 1$$
 * $$x': p\times 1$$
 * $$u: q \times 1$$
 * $$y: r \times 1$$
 * $$A: p \times p$$
 * $$B: p \times q$$
 * $$C: r \times p$$
 * $$D: r \times q$$
 * }
 * $$C: r \times p$$
 * $$D: r \times q$$
 * }

If the matrix and vector dimensions do not agree with one another, the equations are invalid and the results will be meaningless. Matrices and vectors must have compatible dimensions or they cannot be combined using matrix operations.

For the rest of the book, we will be using the small template on the right as a reminder about the matrix dimensions, so that we can keep a constant notation throughout the book.

Notational Shorthand
The state equations and the output equations of systems can be expressed in terms of matrices A, B, C, and D. Because the form of these equations is always the same, we can use an ordered quadruplet to denote a system. We can use the shorthand (A, B, C, D) to denote a complete state-space representation. Also, because the state equation is very important for our later analysis, we can write an ordered pair (A, B) to refer to the state equation:

 * $$(A, B) \to x' = Ax + Bu$$
 * $$(A, B, C, D) \to \left\{\begin{matrix}x' = Ax + Bu \\ y = Cx + Du \end{matrix}\right.$$

Obtaining the State-Space Equations
The beauty of state equations, is that they can be used to transparently describe systems that are both continuous and discrete in nature. Some texts will differentiate notation between discrete and continuous cases, but this text will not make such a distinction. Instead we will opt to use the generic coefficient matrices A, B, C and D for both continuous and discrete systems. Occasionally this book may employ the subscript C to denote a continuous-time version of the matrix, and the subscript D to denote the discrete-time version of the same matrix. Other texts may use the letters F, H, and G for continuous systems and Γ, and Θ for use in discrete systems. However, if we keep track of our time-domain system, we don't need to worry about such notations.

From Transfer Functions
The method of obtaining the state-space equations from the Laplace domain transfer functions are very similar to the method of obtaining them from the time-domain differential equations. We call the process of converting a system description from the Laplace domain to the state-space domain realization. We will discuss realization in more detail in a later chapter. In general, let's say that we have a transfer function of the form:

 * $$T(s) = \frac{s^m+a_{m-1}s^{m-1} +\cdots+a_0}{s^n+b_{n-1}s^{n-1}+\cdots+b_0}$$

We can write our A, B, C, and D matrices as follows:

 * {|class="wikitable"

0 & 0 & 1 & \cdots & 0 \\ \vdots &\vdots &\vdots & \ddots & \vdots \\ 0 & 0 & 0 & \cdots & 1 \\ -b_0 & -b_1 & -b_2 & \cdots & -b_{n-1} \end{bmatrix}$$
 * $$A = \begin{bmatrix}0 & 1 & 0 & \cdots & 0 \\
 * $$A = \begin{bmatrix}0 & 1 & 0 & \cdots & 0 \\
 * $$B = \begin{bmatrix}0 \\ 0 \\ \vdots \\1\end{bmatrix}$$
 * $$C = \begin{bmatrix}a_0 & a_1 & \cdots & a_{m-1}\end{bmatrix}$$
 * $$D = 0$$
 * }
 * $$D = 0$$
 * }
 * }

This form of the equations is known as the controllable canonical form of the system matrices, and we will discuss this later.

Notice that to perform this method, the denominator and numerator polynomials must be monic, the coefficients of the highest-order term must be 1. If the coefficient of the highest order term is not 1, you must divide your equation by that coefficient to make it 1.

State-Space Representation
As an important note, remember that the state variables x are user-defined and therefore are arbitrary. There are any number of ways to define x for a particular problem, each of which are going to lead to different state space equations.

Consider the previous continuous-time example. We can rewrite the equation in the form

 * $$ \frac{d}{dt}\left[\frac{d^2y(t)}{dt^2} + a_2\frac{dy(t)}{dt} + a_1y(t)\right] + a_0y(t)=u(t) $$.

We now define the state variables

 * $$ x_1 = y(t) $$

 * $$ x_2 = \frac{dy(t)}{dt} $$

 * $$ x_3 = \frac{d^2y(t)}{dt^2} + a_2\frac{dy(t)}{dt} + a_1y(t) $$

with first-order derivatives

 * $$ x_1' = \frac{dy(t)}{dt} = x_2 $$

 * $$ x_2' = \frac{d^2y(t)}{dt^2} = - a_1x_1 - a_2x_2 + x_3 $$ (suspected error here. Fails to account that :$$\frac{d}{dt}\left[\right] $$. encapsulates :$$ \frac{d^2y(t)}{dt^2} + a_2\frac{dy(t)}{dt} + a_1y(t)$$ five lines earlier.)

 * $$ x_3' = -a_0y(t) + u(t) $$

The state-space equations for the system will then be given by

 * $$ x' = \begin{bmatrix}

0 & 1 & 0 \\              -a_1 & -a_2 & 1 \\ -a_0 & 0 & 0 \end{bmatrix} x(t) + \begin{bmatrix} 0 \\ 0 \\ 1            \end{bmatrix} u(t) $$

 * $$ y(t) = \begin{bmatrix}

1 & 0 & 0              \end{bmatrix} x(t) $$

x may also be used in any number of variable transformations, as a matter of mathematical convenience. However, the variables y and u correspond to physical signals, and may not be arbitrarily selected, redefined, or transformed as x can be.

Discretization
If we have a system (A, B, C, D) that is defined in continuous time, we can discretize the system so that an equivalent process can be performed using a digital computer. We can use the definition of the derivative, as such:

 * $$x'(t) = \lim_{T\to 0} \frac{x(t + T) - x(t)}{T}$$

And substituting this into the state equation with some approximation (and ignoring the limit for now) gives us:

 * $$\lim_{T\to 0} \frac{x(t + T) - x(t)}{T} = Ax(t) + Bu(t)$$

 * $$x(t + T) = x(t) + Ax(t)T + Bu(t)T$$

 * $$x(t + T) = (1 + AT)x(t) + (BT)u(t)$$

We are able to remove that limit because in a discrete system, the time interval between samples is positive and non-negligible. By definition, a discrete system is only defined at certain time points, and not at all time points as the limit would have indicated. In a discrete system, we are interested only in the value of the system at discrete points. If those points are evenly spaced by every T seconds (the sampling time), then the samples of the system occur at t = kT, where k is an integer. Substituting kT for t into our equation above gives us:

 * $$x(kT + T) = (1 + AT)x(kT) + TBu(kT)$$

Or, using the square-bracket shorthand that we've developed earlier, we can write:

 * $$x[k+1] = (1 + AT)x[k] + TBu[k]$$

In this form, the state-space system can be implemented quite easily into a digital computer system using software, not complicated analog hardware. We will discuss this relationship and digital systems more specifically in a later chapter.

We will write out the discrete-time state-space equations as:

 * $$x[n+1] = A_dx[n] + B_du[n]$$
 * $$y[n] = C_dx[n] + D_du[n]$$

Note on Notations
The variable T is a common variable in control systems, especially when talking about the beginning and end points of a continuous-time system, or when discussing the sampling time of a digital system. However, another common use of the letter T is to signify the transpose operation on a matrix. To alleviate this ambiguity, we will denote the transpose of a matrix with a prime:

 * $$A^T \to A'$$

Where A'  is the transpose of matrix A.

The prime notation is also frequently used to denote the time-derivative. Most of the matrices that we will be talking about are time-invariant; there is no ambiguity because we will never take the time derivative of a time-invariant matrix. However, for a time-variant matrix we will use the following notations to distinguish between the time-derivative and the transpose:

 * $$A(t)'$$ the transpose.

 * $$A'(t)$$ the time-derivative.

Note that certain variables which are time-variant are not written with the (t) postscript, such as the variables x, y, and u. For these variables, the default behavior of the prime is the time-derivative, such as in the state equation. If the transpose needs to be taken of one of these vectors, the (t)'  postfix will be added explicitly to correspond to our notation above.

For instances where we need to use the Hermitian transpose, we will use the notation:

 * $$A^H$$

This notation is common in other literature, and raises no obvious ambiguities here.

MATLAB Representation
State-space systems can be represented in MATLAB using the 4 system matrices, A, B, C, and D. We can create a system data structure using the ss function:

sys = ss(A, B, C, D);

Systems created in this way can be manipulated in the same way that the transfer function descriptions (described earlier) can be manipulated. To convert a transfer function to a state-space representation, we can use the tf2ss function:

[A, B, C, D] = tf2ss(num, den);

And to perform the opposite operation, we can use the ss2tf function:

[num, den] = ss2tf(A, B, C, D);

תורת הבקרה/משתני מצב

title: Control Systems/State-Space Equations


text:
User:Westsarchery/About the author

 The material for this chapter was provided by Mark West, owner and operator of West's Archery which was established in 1937 by his grandfather. Mark's father, Bill was a National Champion and 2-time World Champion. Mark has been an archer since 1969 and an instructor since 1973. He competed in the Olympics in 1972 and was the U.S. National Champion and 3-time California State Champion. He has travelled the world teaching archery skills and performing in programs with his "Gospel Archery" sharpshooting team. In 2004 at the Faith on Fire Camporee in Oshkosh, Wisconsin, Mark not only set a Guinness World Record by shooting a single arrow through eleven "handheld" balloons, but he and the West family also taught the Archery honor to over 1000 Pathfinders.

title: User:Westsarchery/About the author


text:
Talk:Digital Signal Processing/Discrete Fourier Transform

MickLinux 04:53, 6 December 2005 (UTC)MickLinux (Michael Rudmin)

Untitled
Todo: Add math behind the DFT, conversion of calculus FT->DFT, 2-d and 3-d cases.


text:
Wikijunior:Big Book of Fun Science Experiments/Baking powder and lemon squash

If you use the summer fruits squash, which is pink, the frothy bubbles will be pink!!
 * 1) Take out a clean shiny glass.
 * 2) Add lemon, orange, or summer fruits squash and pour it in.
 * 3) Take a pinch of baking powder.

Watch your amazing experiment bubble!


text:
Wikijunior:Big Book of Fun Science Experiments/Floating compass

Stroke a needle with a magnet about 50 times. Stroke in the same direction each time to make the needle magnetic, then tape the needle to a piece of cork in a bowl of water. You will see after a while that the needle settles and always points in one direction. This direction is North.

Principle
The Principle here is something called magnetism. Magnetism is a basic fundamental force, similar to gravity. The earth has something called a magnetic field, which, very weakly, affects all magnets on earth.

Every metal has little groups of metal atoms called domains. Each domain has a north, and a south side. In a normal pin this domains are all jumbled up and facing every which way. However, after stroking it with a magnet in the same direction, the domains all align, or face, in the same direction. After this happens, your pin is effected by the earth's magnetic field. If you were to go back and forth across the magnet, the domains would become jumbled up and confused.


text:
Windows Programming/GDI and Drawing

This page will talk about graphics and drawing using the windows GDI libraries.

GDI was the original graphics API for Windows. However, the DirectX Graphics Infrastructure is now recommended for its improved use of GPU functions, alpha blending, and anti-aliasing.

Device Contexts
What's in? And their defaults: To be continued ...

Brush object
Windows uses brushes to paint colors and fill areas with predefined patterns. Brushes have a minimum size of 8X8 pixels and like pens, have three basic characteristic: size, pattern and color. With their 8X8 pixel minimum size,brushes are said to have a pattern, not a style as pens do. The pattern may be a solid color, hatched, diagonal or any other user definable combination, even a bitmap pattern.

case WM_PAINT: {    /* This will paint a red rectangle */ HDC holdBrush; HDC hdc = BeginPaint(hwnd, &ps); HBRUSH hBrush = CreateSolidBrush(RGB(255,0,0)); holdBrush = SelectObject(hdc, hBrush); Rectangle(hdc, 10, 10, 100, 100);

DeleteObject(hBrush); /* Memory management has been omitted for brevity */ EndPaint(hwnd, &ps); break; }

What's behind the brush object?

Note that a bitmap pattern brush behaves differently from a hatched brush, even when the bitmap looks like the hatch. Hatched brushes are transparent, whereas bitmap brushes are opaque. If a black-and-white bitmap is used, black is replaced by the Device Context's text color, and white is replaced by the background color. (This is exactly the BitBlt behaviour.) SetBkMode won't work. However, DC's ROP2 applies.

Pen object
Pens are used to create borders around shapes you have drawn.

Lines which result in widths larger than 1 device pixel (not logical units) are drawn as polygons with winding rule. Line colors are never dithered, except ExtCreatePen with a solid brush is used.

Font object
Fonts are for displaying text and symbols in various styles and sizes. Internal large differences exist for font management between Windows 2 (very basic), 3.1 (introducing TrueType), and 4+ (Unicode; world-transform rotation and mirroring; escapement can differ from rotation).

See LOGFONT structure for visible fields.

Hidden fields include
 * Referencing device context
 * Device-dependent bitmap font representation

Therefore, selecting a font into a Device Context (SelectObject) can be time-consuming, especially for large Asian fonts and large font sizes, to “paint” all the glyphs out of the TrueType template into the bitmap. Furthermore, as for all GDI objects, it's not a good idea to select one object from one to another context, because invalidating the hidden files can be a time-consuming process. Note that any GDI object cannot be selected into more that one DC.

Basic Drawing
In Windows, drawing is typically handled by the WM_PAINT message. The following is an example of how to draw a red square: case WM_PAINT: { 	PAINTSTRUCT ps; BeginPaint(hwnd, &ps); // RECT defines the upper-left and lower-right corners of a rectangle RECT rectangle = {50, 50, 250, 250}; HBRUSH hbr = CreateSolidBrush(RGB(125, 0, 0)); FillRect(ps.hdc, &rectangle, hbr); DeleteObject(hbr); EndPaint(hwnd, &ps); } break; Firstly, we create the PAINTSTRUCT variable ps. This is a data structure containing information about the painting operation. The next line calls BeginPaint. This initializes ps, then fills it with relevant information. For this example, we only need the hdc member of ps. This is a handle to our window's Device Context. Next, we create a rectangle. This holds the upper-left and lower-right coordinates we're going to paint this rectangle at. The coordinates are relative to the upper-left corner of the window's client area. We also have to create a brush, otherwise Windows won't know what color to paint the rectangle. Finally, we call FillRect, and pass the parameters ps.hdc, a pointer to rectangle, and hbr, our brush. This paints the rectangle directly to our window's device context, and from there it is painted on the screen. After every painting operation, it is necessary to clean up any GDI objects we use, in this case hbr and ps.

Advanced hint
Because Windows should respond to WM_PAINT and WM_PRINTCLIENT, a more general rule for writing a WM_PAINT handler is this: case WM_PRINTCLIENT: OnPaint((HDC)wParam, NULL); break;

case WM_PAINT: { PAINTSTRUCT ps; BeginPaint(hwnd, &ps); OnPaint(ps.hdc, &ps.rcPaint);	// It's a good idea to manage the update area. Other PAINTSTRUCT fields are of less usefulness. EndPaint(hwnd, &ps); }break;

// Somewhere else void OnPaint(HDC dc, RECT* rcUpdate) { ... }

Next Chapter

 * Dialog Boxes

title: Windows Programming/GDI and Drawing


text:
Talk:Umbraco/Templating/Templates

Maybe some images/screenshots here anyone? Darrenferguson 15:08, 10 May 2006 (UTC)

title: Talk:Umbraco/Templating/Templates


text:
Windows Programming/Registry API

The Registry
The registry is a system-defined hierarchical central database in x86, x64 and Mobile versions of Microsoft Windows System. The Windows Registry API provides methods for an application to save and query data stored in the registry. Although the registry was present even in 3.x Windows, it was used to store much less data.

The registry stores configuration settings for software, information about operating system configuration, current hardware profile, drivers' settings etc. It was also designed to replace the old-fashioned way of storing application data in .ini files. On 16-bits Windows systems applications used to store data in configuration files with .ini extensions.

Values are grouped and stored in keys. The registry stores keys in tree format, with keys containing values and sub-keys.

Applications should only modify keys created by itself, and changing or deleting other application's keys and values is not recommended. Also, an application shouldn't modify keys containing important system settings. We should keep these two tips in mind when editing registry (of course there are situations when we want to change some system settings but this is very rare).

Opening a Key
Keys must be opened before they can be used. To do this, we use either of
 * RegOpenKeyEx : To open any key.
 * RegCreateKeyEx : To create a key or open it if it exists already.

Values
The value of a key can be obtained by calling RegQueryValueEx.

The RegSetValueEx function is used to associate a value with a key.

Next Chapter

 * Security API

title: Windows Programming/Registry API


text:
Windows Programming/Security API

This page will talk about the Windows security API.

Security Overview
API I live pickles

Next Chapter

 * Winsock

title: Windows Programming/Security API


text:
Futurology/Time

Time has long been a major subject of philosophy, art, poetry, and science. There are widely divergent views about its meaning, hence it is difficult to provide an uncontroversial definition of time. Many fields use an operational definition in which the units of time are defined. Scholars disagree on whether time itself can be measured or is itself part of the measuring system.

The Oxford English Dictionary defines time as "the indefinite continued progress of existence and events in the past, present, and future, regarded as a whole." Another standard dictionary definition is "a nonspatial linear continuum wherein events occur in an apparently irreversible order." The Latin word for time, tempus came from Greek temnein meaning "to cut" (same root for atomos άτομον meaning "indivisible"; thus signifying a division of the flowing duration.

The measurement of time has also occupied scientists and technologists, and was a prime motivation in astronomy. Time is also a matter of significant social importance, having economic value ("time is money") as well as personal value, due to an awareness of the limited time in each day and in our lives. Units of time have been agreed upon to quantify the duration of events and the intervals between them. Regularly recurring events and objects with apparent periodic motion have long served as standards for units of time. Examples are the apparent motion of the sun across the sky, the phases of the moon, and the swing of a pendulum.

title: Futurology/Time


text:
Futurology/Election 2008

According to the Constitution of the United States (Article II, Sec. I), every four years a presidential candidate is picked by his party and runs for office. The one to score a majority or 270 Electoral votes becomes the new president. It is unlikely that a third party candidate or an independent will become president.

Historically speaking there have been five ways to become President:

 * Be a military general who wins a critical campaign that affects the very survival of the United States (aka Washington, Jackson, Grant, Eisenhower)
 * Be the Secretary of State.
 * Be a senator from a very large and critical state, especially from a "swing state" that might be critical to winning electorial votes.
 * Be a governor or former governor of a state.
 * Be the Vice-president of the United States.

Of these, being vice-president seems to have the most influence, but being governor is also quite useful. Notable governors of even smallish states like Bill Clinton (Arkansas) and Jimmy Carter (Georgia) have been able to get elected.

As for being a general, World War II was the last major war for this to have worked out in this way, although it certainly is a very good item on the resume for Colin Powell to have "won" the Gulf War in 1991, and it should be of note that no current general involved with the Iraq War is certainly commanding national attention or a likely candidate as President of the United States any time in the future.

While being senator certainly seems to be useful to getting the party nomination, there has not been a senator to become President of the United States since John F. Kennedy. Nor other than JFK anybody other than a governor or vice-president since Herbert Hoover (he was Secretary of Commerce as the highest office he held prior to being president).

Announced Candidates

 * Senator Joe Biden of Delaware
 * Former Senator Mike Gravel of Alaska
 * Senator Hillary Clinton of New York
 * Senator Barack Obama of Illinois
 * Former Senator John Edwards of North Carolina

Likely potential candidates

 * Senator Evan Bayh of Indiana
 * Retired General Wesley Clark of Arkansas
 * Former Senator Tom Daschle of South Dakota
 * Senator Russ Feingold of Wisconsin
 * Senator John Kerry of Massachusetts
 * Governor Bill Richardson of New Mexico
 * Governor Tom Vilsack of Iowa
 * Former Governor Mark Warner of Virginia

Other potential candidates

 * Senator Barbara Boxer of California
 * Governor Phil Bredesen of Tennessee
 * Former Governor Howard Dean of Vermont
 * Senator Christopher Dodd of Connecticut
 * Governor Mike Easley of North Carolina
 * Former Vice President Al Gore of Tennessee
 * Representative Dennis Kucinich of Ohio
 * Representative John Lewis of Georgia
 * Former Gov. Gary Locke of Washington
 * Governor Joe Manchin of West Virginia
 * Self-help guru Tony Robbins of California
 * Governor Brian Schweitzer of Montana
 * Reverend Al Sharpton of New York

Announced Candidate

 * Congressman Ron Paul M.D. of Texas
 * John H. Cox of Illinois
 * Former New York City Mayor Rudy Giuliani
 * Governor Mitt Romney of Massachusetts
 * Senator John McCain of Arizona

Likely potential candidates

 * Senator George Allen of Virginia
 * Senator Sam Brownback of Kansas
 * Senator Bill Frist of Tennessee
 * Former House Speaker Newt Gingrich of Georgia
 * Senator Chuck Hagel of Nebraska
 * Governor Mike Huckabee of Arkansas
 * Governor George Pataki of New York
 * Representative Tom Tancredo of Colorado

Other potential candidates

 * Senator Elizabeth Dole of North Carolina
 * Senator Lindsey Graham of South Carolina
 * Former Ambassador Alan Keyes of Maryland
 * Former Chief Justice of the Alabama Supreme Court Roy Moore
 * Governor Bill Owens of Colorado
 * Governor Tim Pawlenty of Minnesota
 * Representative Mike Pence of Indiana
 * Secretary of State Condoleezza Rice of California
 * Governor Mark Sanford of South Carolina
 * Former Governor Tommy Thompson of Wisconsin

Link

 * http://www.cox2008.com/

title: Futurology/Election 2008


text:
Wikijunior:Languages/Klingon

What writing system(s) does this language use?
Klingon is a constructed language invented by American linguist Marc Okrand, who was hired to create it for the Star Trek movies and television series. In descriptions of the Klingon language, it is written using letters from the same alphabet that English uses (the Latin alphabet) — while there is also an invented alphabet that is used when Klingon writing is shown in the movies and series.

What is the history of this language?
Unlike Esperanto, which was invented to help people understand each other, or Quenya, which was invented as a work of art, Klingon was invented as background for a story world that had already been created. An American profession linguist, Marc Okrand, was hired to create Klingon for the third Star Trek movie.

What are some basic words in this language that I can learn?
Well done! ... Majoa'

Where is the bathroom? ... Nugdag 'oh puchpa' 'e'

Yes ... Hislah

No ... Ghobe'

Happy Birthday ... Qoslij dativjaj

title: Wikijunior:Languages/Klingon


text:
Bourne Shell Scripting/Debugging and signal handling

In the previous sections we've told you all about the Bourne Shell and how to write scripts using the shell's language. We've been careful to include all the details we could think of so you will be able to write the best scripts you can. But no matter how carefully you've paid attention and no matter how carefully you write your scripts, the time will come to pass when something you've written simply will not work — no matter how sure you are it should. So how do you proceed from here?

In this module we cover the tools the Bourne Shell provides to deal with the unexpected. Unexpected behavior of your script (for which you must debug the script) and unexpected behavior around your script (caused by signals being delivered to your script by the operating system).

Debugging Flags
So here you are, in the middle of the night having just finished a long and complicated shell script, just poured your heart and soul into it for three days straight while living on nothing but coffee, cola and pizza... and it just won't work. Somewhere in there is a bug that is just eluding you. Something is going wrong, some unexpected behavior has popped up or something else is driving you crazy. So how are you going to debug this script? Sure, you can pump it full of 'echo' commands and debug that way, but isn't there an easier way?

Generally speaking the most insightful way to debug any program is to follow the execution of the program along statement by statement to see what the program is doing exactly. The most advanced form of this (offered by modern IDEs) allows you to trace into a program by stopping the execution at a certain point and examining its internal state. The Bourne Shell is, unfortunately, not that advanced. But it does offer the next best thing: command tracing. The shell can print each and every command as it is being executed.

The tracing functionality (there are two of them) is activated using either the 'set' command or by passing parameters directly to the shell executable when it is called. In either case you can use the -x parameter, the -v parameter or both.

 * -v:Turns on verbose mode; each command is printed by the shell as it is read.
 * -x:This turns on command tracing; every command is printed by the shell as it is executed.

Debugging
Let's consider the following script:

divider.sh: Script with a potential error

Let's execute this script and not pass in a command-line argument (so we use the default value 0 for the DIVISOR variable):

Running the script

Of course it's not too hard to figure out what went wrong in this case, but let's take a closer look anyway. Let's see what the shell executed, using the -x parameter:

Running the script with tracing on

So indeed, clearly the shell tried to have a division by zero evaluated. Just in case we're confused about where the zero came from, let's see which commands the shell actually read:

Running the script in verbose mode

So obviously, the script read a command with a variable substitution that didn't work out very well. If we combine these two parameters the resulting output tells the whole, sad story:

Running the script with maximum debugging

There is another parameter that you can use to debug your script, the -n parameter. This causes the shell to read the commands but not execute them. You can use this parameter to do a syntax checking run of your script.

Places to put your parameters
As you saw in the previous section, we used the shell parameters by passing them in as command-line parameters to the shell executable. But couldn't we have put the parameters inside the script itself? After all, there is an interpreter hint in there... And surely enough, we can do exactly that. Let's modify the script a little and try it.

The same script, but now with parameters to the interpreter hint

Running the script

So there's no problem there. But there is a little gotcha. Let's try running the script again:

Running the script again

So what happened to the debugging that time? Well, you have remember that the interpreter hint is used when you try to execute the script as an executable in its own right. But in the last example, we weren't doing that. In the last example we called the shell ourselves and passed it the script as a parameter. So the shell executed without any debugging activated. It would have worked if we'd done a "sh -xv divider.sh" though.

What about sourcing the script (i.e. using the dot notation)?

Running the script again

This time the script was executed by the same shell process that is running the interactive shell for us. And the same principle applies: no debugging there either. Because the interactive shell was not started with debugging flags. But we can fix that as well; this is where the 'set' command comes in:

Running the script again

And now we have debugging active in the interactive shell and we get a full trace of the script. In fact, we even get a trace of the interactive shell calling the script! But now what happens if we start a new shell process with debugging on in the interactive shell? Does it carry over?

Running the script again

Well, we certainly get a trace of the script being called, but no trace of the script itself. The moral of the story is: when debugging, make sure you know which shell you're activating the trace in.

By the way, to turn tracing in the interactive shell off again you can either do a 'set +xv' or simply a 'set -'.

Breaking out of a script
When writing or debugging a shell script it is sometimes useful to exit out (to stop the execution of the script) at certain points. You use the 'exit' built-in command to do this. The command looks simply like this:

If you leave off the optional exit status, the exit status of the script will be the exit status of the last command that executed before the call to 'exit'.

For example:

Exiting from a script

If you run this script and then test the output status, you will see (using the "$?" built-in variable):

Checking the exit status

There's one thing to look out for when using 'exit': 'exit' actually terminates the executing process. So if you're executing an executable script with an interpreter hint or have called the shell explicitly and passed in your script as an argument that is fine. But if you've sourced the script (used the dot-notation), then your script is being run by the process running your interactive shell. So you may inadvertently terminate your shell session and log yourself out by using the 'exit' command!

There's a variation on 'exit' meant specifically for blocks of code that are not processes of their own. This is the 'return' command, which is very similar to the 'exit' command:

Return has exactly the same semantics as 'exit', but is primarily intended for use in shell functions (it makes a function return without terminating the script). Here's an example:

exit_and_return.sh: A script with a function and an explicit return

If we run this script, we see the following:

Running the script

The function returned with a testable exit status of 2. The overall exit status of the script is zero though, since the last command executed by the script ('echo Goodbye!!') exited without errors.

You can also use a 'return' statement to exit a shell script that you executed by sourcing it (the script will be run by the process that runs the interactive shell, so that's not a subprocess). But it's usually not a good idea, since this will limit your script to being sourced: if you try to run it any other way, the fact that you used a 'return' statement alone will cause an error.

Signal trapping
A syntax, command error or call to 'exit' is not the only thing that can stop your script from executing. The process that runs your script might also suddenly receive a signal from the operating system. Signals are a simple form of event notification: think of a signal as a little light suddenly popping on in your room, to let you know that somebody outside the room wants your attention. Only it's not just one light. The Unix system usually allows for lots of different signals so it's more like having a wall full of little lamps, each of which could suddenly start blinking.

On a single-process operating system like MS-DOS, life was simple. The environment was single-process, meaning your code (once running) had complete machine control. Any signal arriving was always a hardware interrupt (e.g. the computer signalling that the floppy disk was ready to read) and you could safely ignore all those signals if you didn't need external hardware; either it was some device event you weren't interested in, or something was really wrong — in which case the computer was crashing anyway and there was nothing you could do.

On a Unix system, life is not so easy. On Unix, signals can come from all over the place (including other programs). And you never have complete control of the system either. A signal may be a hardware interrupt, or another program signalling, or the user who got fed up with waiting, logged in to a second shell session and is now ordering your process to die. On the bright side, life is still not too complicated. Most Unix systems (and certainly the Bourne Shell) come with default handling for most signals. Usually you can still safely ignore signals and let the shell or the OS deal with them. In fact, if the signal in question is number 9 (loosely translated: KILL!! KILL!! DIE!! DIE, RIGHT NOW!!), you probably should ignore it and let the OS kill your process.

But sometimes you just have to do your own signal handling. That might be because you've been working with files and want to do some cleanup before your process dies. Or because the signal is part of your multi-process program design (e.g. listening for signal 16, which is "user-defined signal 1"). Which is why the Bourne Shell gives us the 'trap' command.

Trap
The trap command is actually quite simple (especially if you've ever done event-driven programming of any kind). Essentially the trap command says "if one of the following signals is received by this process, do this". It looks like this:

For example, to trap user-defined signal 1 (commonly referred to as SIGUSR1) and print "Hello World" whenever it comes along, you would do this:

Trapping SIGUSR1

Most Unix systems also allow you to use symbolic names (we'll get back to these a little later). So you can probably also do this:

Trapping SIGUSR1 (little easier)

And if you can do that, you can usually also do this:

Trapping SIGUSR1 (even easier)

The command string passed to 'trap' is a string that contains a command list. It's not treated as a command list though; it's just a string and it isn't interpreted until a signal is caught. The command string can be any of the following:

 * A string:A string containing a command list. Any and all commands are allowed and you can use multiple commands separated by semicolons as well (i.e. a command list).
 * ' ':The empty string. Actually this is the same as the previous case, since this is the empty command string. This causes the shell to execute nothing when a signal is trapped — in other words, to ignore the signal.
 * :Nothing, the null string. This resets the signal handling to the default signal action (which is usually "kill process").

Following the command list you can list as many signals as you want to be associated with that command list. The traps that you set up in this manner are valid for every command that follows the 'trap' command.

Right about now it's probably a good idea to look at an example to clear things up a bit. You can use 'trap' anywhere (as usual) including the interactive shell. But most of the time you will want to introduce traps into a script rather than into your interactive shell process. Let's create a simple script that uses the 'trap' command:

A simple signal trap

This script in and of itself is an endless loop, which prints "Running..." and then sleeps for five seconds. But we've added a 'trap' command (before the loop, otherwise the trap would never be executed and it wouldn't affect the loop) that prints "Hello World" whenever the process receives the SIGUSR1 signal. So let's start the process by running the script:

Infinite loop...

To spring the trap, we must send the running process a signal. To do that, log into a new shell session and use a process tool (like 'ps') to find the correct process id (PID):

Finding the process ID

Now, to send a signal to that process, we use the 'kill' command which is built into the Bourne Shell:

As the name suggests, 'kill' was actually intended to kill processes (this fits with the default signal being SIGTERM and the default signal handler being terminate). But in fact what it does is nothing more than send a signal to a process. So for example, we can send a SIGUSR1 to our process like this:

Let's trip the trap...

You might notice that there's a short pause before "Hello World!" appears; it won't happen until the running 'sleep' command is done. But after that, there it is. But you might be a little surprised: the signal didn't kill the process. That's because 'trap' completely replaces the signal handler with the commands you set up. And an 'echo Hello World' alone won't kill a process... The lesson here is a simple one: if you want your signal trap to terminate your process, make sure you include an 'exit' command.

Between having multiple commands in your command list and potentially trapping lots of signals, you might be worried that a 'trap' statement can become messy. Fortunately, you can also use shell functions as commands in a 'trap'. The following example illustrates that and the difference between an exiting event handler and a non-exiting event handler:

A trap with a shell function as a handler

System signals
Here's the official definition of a signal from the POSIX-1003 2001 edition standard:

A mechanism by which a process or thread may be notified of, or affected by, an event occurring in the system. Examples of such events include hardware exceptions and specific actions by processes.

The term signal is also used to refer to the event itself.

In other words, a signal is some sort of short message that is sent from one process (possible a system process) to another. But what does that mean exactly? What does a signal look like? The definition given above is kind of vague...

If you have any feel for what happens in computing when you give a vague definition, you already know the answer to the questions above: every Unix flavor that was developed came up with its own definition of "signal". They pretty much all settled on a message that consists of an integer (because that's simple), but not exactly the same list everywhere. Then there was some standardization and Unix systems organized themselves into the System V and BSD flavors and at last everybody agreed on the following definition:

The system signals are the signals listed in /usr/include/sys/signal.h.

God, that's helpful...

Since then a lot has happened, including the definition of the POSIX-1003 standard. This standard, which standardizes most of the Unix interfaces (including the shell in part 1 (1003.1)) finally came up with a standard list of symbolic signal names and default handlers. So usually, nowadays, you can make use of that list and expect your script to work on most systems. Just be aware that it's not completely fool-proof...

POSIX-1003 defines the signals listed in the table below. The values given are the typical numeric values, but they aren't mandatory and you shouldn't rely on them (but then again, you use symbolic values in order not to use actual values).

Earlier on we talked about job control and suspending and resuming jobs. Job suspension and resuming is actually completely based on sending signals to processes, so you can in fact control job stopping and starting completely using 'kill' and the signal list. To suspend a process, send it the SIGSTOP signal. To resume, send it the SIGCONT signal.

Err... ERR?
If you go online and read about 'trap', you might come across another kind of "signal" which is called ERR. It's used with 'trap' the same way regular signals are, but it isn't really a signal at all. It's used to trap command errors (i.e. non-zero exit statuses), like this:

Error trapping

So why didn we cover this "signal" earlier, when we were discussing 'trap'? Well, we saved it until the discussion on system and non-system signals for a reason: ERR isn't standard at all. It was added by the Korn Shell to make life easier, but not adopted by the POSIX standard and it certainly isn't part of the original Bourne Shell. So if you use it, remember that your script may not be portable anymore.


text:
Talk:Bourne Shell Scripting/Debugging and signal handling

This needs some re-formatting....couldn't figure out how to get the '' tags working for some reason....


text:
Talk:Authoring Foreign Language Textbooks/Bite-sized language lessons

Please put any comments and questions here.

Good advice
All this is very true. IMHO the page ought to be placed somewhere nobody making language courses could miss it. David 22:00, 4 June 2006 (UTC)

 * Thank you for your feedback. I have tried to make other language course creators aware of it, but it's not easy since most don't even read the Wikibook on creating a language course on Wikibooks before starting to work. Junesun 09:11, 6 June 2006 (UTC)

Great advice. I've taken some action: --Singkong2005 04:57, 14 August 2006 (UTC)
 * I've moved this to "Help" space.
 * Help:Languages links to all the help pages on languages (that I could find).
 * We could make a small box for all language talk pages which links to a common space for language books discussion, and also links to Help:Languages. (See Staff lounge for my suggestion) - comments welcome.

 * This page is about teaching languages and deserves a wikibook in its own right. This way it will also be easier to find since it will appear on Subject:Languages. --Martin Kraus (talk) 12:06, 18 January 2009 (UTC)


text:
User:Whiteknight/Images

This page is going to serve as a repository for the images that I have created and uploaded. See also my images page at commons: commons:User:Whiteknight/My Images. Content here may change without warning. Unauthorized edits can and will be removed.

SVG Images
These images were created by me in Inkscape or Dia. All these images prior to 29 October 2007 are released under the GFDL. All images uploaded after that date will be cross-licensed under the GFDL and CC-BY-SA-1.0,2.0,2.5,3.0. I may eventually update all the licenses of the older images. Eventually, all these images will be moved to commons.

Waveforms
These images are waveforms, and are used in books such as, , , or. Authors of related books may find these images useful as well.

Electric Circuits
These images are diagrams of electric circuits or electric circuit components. These images are useful in the, or  books.

Computer Components
These images are of computer or microprocessor components. They are most useful in books such as or.

Computer Software
These images are diagrams of computer software. They are useful in the and  books.

Controllable Systems
These images depict physical systems, and are typically for use in the book.

Block Diagrams
These images depict block diagrams, and are useful in the, , , or  books. Other engineering books may also make good use of them.

Mathematical Images
These images depict mathematical concepts, and are useful in the book, and for explanations in other engineering or mathematics books.

Orbital Images
These are diagrams of orbits and space objects. They are for use in the book, but may be applied to other books such as, , and others.

Neural Network Images
These are diagrams of neural networks, or related topics. They will be used in the book, among others.

Cover Images
These images are all 8.5 × 11 images for use as book covers.

Other Images
These images are not SVG images. Some of them are low quality and need to be redone as SVG in the future. Some of them are screenshots. Some of them are put together by myself in MS Paint or Adobe Photoshop.

Photoshop Images
These images have been created by myself in Adobe Photoshop or GIMP. They are cross-licensed under the GFDL and CC-BY-SA-3.0, 2.5, 2.0, and 1.0.

Inkscape PNG Images
These images were created by me in Inkscape, JFLAP, or other free graphics programs. All these images are released under the GFDL. Images that are not SVG will be updated eventually to be SVG. When these images are sufficiently improved and polished, I will upload them to commons.

JFLAP Images
These images were produced in JFLAP, and are released under the GFDL.

Rough Images
These are rough images, drawn by myself in MS paint. All of these images are released into the public domain. I will attempt to reproduce many of these images in a better format such as SVG. When I do reproduce these images, they will no longer be public domain.

Screenshots
These images are screenshots of copyrighted programs and are released under a fair use license.

Screenshots of Wikibooks
These screenshots are taken of the wikibooks interface. They are all released under the GFDL.

PDF Versions
These PDF versions were created by me using either Adobe Acrobat, or OpenOffice. These PDF versions are all released under the GFDL.

Image:Control Systems.pdf

Personal Images
These are images that I use for my personal namespace. The ones that are not drawn in MS paint are likely taken with a digital camera. I release these images into the public domain.

Useful Image Storage
This is where I will list useful images that I have found that i can reproduce, move to commons, or use in my books.

 * http://en.wikipedia.org/wiki/User:Cburnett/GFDL_images
 * Diagrams

title: User:Whiteknight/Images


text:
Programmable Logic/Hardware Design Languages

This page is going to discuss the history and development of HDL methods, and the 3 HDL languages that we are going to study in this book: Verilog, VHDL, and SystemC.

History of HDL
Hardware Description Languages (HDL) are programming languages that are designed to program FPGAs and CPLDs. HDL compilers will often create a "gate map" instead of a computer executable file. This gate map can be downloaded onto the programmable device, and run.

There are three common HDLs: Verilog, VHDL, and SystemC. Of these, SystemC is the newest and least popular, although its use has been rising in the industry.

History of Verilog
Verilog HDL originated at Automated Integrated Design Systems (later renamed as Gateway Design Automation) in 1985. The company was privately held at that time by Dr. Prabhu Goel, the inventor of the PODEM test generation algorithm. Verilog HDL was designed by Phil Moorby, who was later to become the Chief Designer for Verilog-XL and the first Corporate Fellow at Cadence Design Systems. Gateway Design Automation grew rapidly with the success of Verilog-XL and was finally acquired by Cadence Design Systems, San Jose, CA in 1989.

Verilog was invented as simulation language. Use of Verilog for synthesis was a complete afterthought. Rumors abound that there were merger discussions between Gateway and Synopsys in the early days, where neither gave the other much chance of success..

In the late 1980's it seemed evident that designers were going to be moving away from proprietary languages like n dot, HiLo and Verilog towards the US Depatment of Defense standard H.D.L., known as the VHSIC Hardware Description Language. VHSIC itself stands for "Very High Speed Integrated Circuit").

Perhaps due to such market pressure, Cadence Design Systems decided to open the Verilog language to the public in 1990, and thus OVI (Open Verilog International) was born. Until that time, Verilog HDL was a proprietary language, being the property of Cadence Design Systems. When OVI was formed in 1991, a number of small companies began working on Verilog simulators, including Chronologic Simulation, Frontline Design Automation, and others. The first of these came to market in 1992, and now there are mature Verilog simulators available from many sources.

As a result, the Verilog market has grown substantially. The market for Verilog related tools in 1994 was well over $75,000,000, making it the most commercially significant hardware description language on the market.

An IEEE working group was established in 1993 under the Design Automation Sub-Committee to produce the IEEE Verilog standard 1364. Verilog became IEEE Standard 1364 in 1995.

As an international standard, the Verilog market continued to grow. In 1998 the market for Verilog simulators alone was well over $150,000,000; continuing its dominance.

The IEEE working group released a revised standard in March of 2002, known as IEEE 1364-2001. Significant publication errors marred this release, and a revised version was released in 2003, known as IEEE 1364-2001 Revision C.

Subsequently, a new working group was formed, IEEE P1800, to build on the IEEE 1364 language along with additional contributions from Accellera. In mid 2004 the IEEE 1364 committee was disbanded, and maintenance on the standard was taken up by the IEEE 1800 working group.

History of VHDL
VHDL stands for "Very High Speed Integrated Circuit (VHSIC) Hardware Description Language", and is a common HDL for use in programmable gate arrays and application specific integrated circuits (ASIC). VHDL is very similar in form to Ada. VHDL is a language for describing digital electronic systems. It arose out of the United States Government’s Very High Speed Integrated Circuits (VHSIC) program, initiated in 1980. In the course of this program, it became clear that there was a need for a standard language for describing the structure and function of integrated circuits (ICs). Hence the VHSIC Hardware Description Language (VHDL) was developed.

The first publicly available version of VHDL, version 7.2, was released in 1985. In 1986, the Institute of Electrical and Electronics Engineers, Inc. (IEEE) was presented with a proposal to standardize the language, which it did in 1987 after substantial enhancements and modifications were made by a team of commercial, government and academic representatives. The resulting standard, IEEE 1076-1987, is the basis for virtually every simulation and synthesis product sold today. An enhanced and updated version of the language, IEEE 1076-1993, was released in 1994, and VHDL tool vendors have been responding by adding these new language features to their products. Though IEEE Standard 1076 defines the complete VHDL language, there are aspects of the language that made it difficult to write completely portable design descriptions across different vendor tools. The problem stemmed from the fact that basic VHDL supported many abstract data types, but it did not address the simple problem of characterizing different signal strengths or commonly used simulation conditions such as unknowns and high-impedance. Simulator companies began enhancing VHDL with new, non-standard types to allow their customers to accurately simulate complex electronic circuits. This caused problems because design descriptions entered into one simulator were often incompatible with other simulation environments. VHDL was quickly becoming a nonstandard. To get around the problem of nonstandard data types, another standard was developed by an IEEE committee. This standard, numbered 1164, defines a standard package (a VHDL feature that allows commonly used declarations to be collected into an external library) containing definitions for a standard nine-valued data type. This standard data type is called std_logic, and the IEEE 1164 package is often referred to as the Standard Logic package. The IEEE 1076-1987 and IEEE 1164 standards together form the complete VHDL standard in widest use today. IEEE 1076-1993 is slowly working its way into the VHDL mainstream, but it does not add significant new features for synthesis users. Standard 1076.3 (often called the Numeric Standard or Synthesis Standard) defines standard packages and interpretations for VHDL data types as they relate to actual hardware. This standard, which was released at the end of 1995, is intended to replace the many custom (nonstandard) packages that vendors of synthesis tools have created and distributed with their products. IEEE Standard 1076.3 does for synthesis users what IEEE 1164 did for simulation users i.e. increase the power of Standard 1076, while at the same time ensuring compatibility between different vendors’ tools. The 1076.3 standard includes, among other things the annotation of timing information to a simulation model is an important aspect of accurate digital simulation. The VHDL 1076 standard describes a variety of language features that can be used for timing annotation. However, it does not describe a standard method for expressing timing data outside of the timing model itself.


text:
Programmable Logic/Verilog Module Structure

Verilog Modules
Modules are the fundamental descriptive units in Verilog HDL. Verilog modules, like functions in other programming languages, are pieces of code that can be used and reused within a single program. Verilog modules are declared using the module keyword, and are ended with the endmodule keyword.

Module Format
Basic Modules are laid out as follows:

module MyModule ([parameters]); inputs ...     outputs ...      internal variables ...      ...      Module Code ... endmodule

The module is declared with a module name (in this case, "MyModule"), followed by a list of parameters. Parameters in this case are a list of input and output signals (also called the 'port list') that the module can interact with. If we synthesize our Verilog code, the parameters will signify the physical wire connections that connect our module to the rest of the microchip. Note that in the parameter list, we do not need to specify what the type of the connection is, or whether it is an input or an output. We do that in the next few lines. Here is an example module declaration with some parameters:

module MyModule(a, b, c, clock);

Inputs and Outputs
In Verilog, all inputs and outputs are passed through the parameter list. A module requires this list of input and output ports to interact with the environment.

Modules do not return a value in the same way that a C function or a Java function can return a value. Therefore, we use the input and output keywords to specify which parameters are going which direction:

module MyModule(a, b, c, clock); input a, b, clock; output c;   ... endmodule

output connections are generally not initialized, so it is bad practice to attempt to read from a connection specified as an output.

Instance Identifiers
When calling a Verilog module from a higher-level module, we need to include an instance identifier. This is done because when we synthesize our code onto a physical chip, functions that need to be called multiple times in parallel are actually created multiple times! This means that if we want the same module to execute with itself in parallel, we need to instruct the synthesizer program to create multiple physical copies of the module. Furthermore, using instance identifiers allows oneself to "wire" multiple modules together (i.e. if we wanted the output of one module to be the input of another module). For the first definition exemplified, let's say we have a module AND that's defined as such:

module AND(a, b, c); input a, b;   output c;    assign c = a & b; endmodule

If we want to use AND in another module, we need to call it as follows:

wire w, x, y, z; ... AND A1(w, x, y); AND A2(w, y, z); AND A3(z, x, w);

Notice how we place an identifier in between the module name "AND" and the parameter list? This is an instance identifier. Note that we are defining 3 separate instances of the module AND.

An identifier can be composed of Alphanumeric characters and underscore(_), and it cannot begin with a number.


text:
Programmable Logic/Verilog Data Types

Data Values
Verilog has four values any signal can take:

In practice, x and z values are difficult to use in synthesis, and should typically be avoided, unless there is a very specific reason for using them.

Wire
Wires, specified with the wire keyword represent physical wires that carry electrical signals from one module to the next. Wires do not store any data, and they must be constantly supplied with a value or they will not contain a value. Wires may not be the target of a blocking or sequential assignment.

Wires come in one of three varieties:

Wires can be assigned a value using the assign keyword. All assign declarations are considered to be running concurrently and continuously.

In the following case, the value of a is dependent on the values of b and c. Any change in either b or c will result in an automatic and instantaneous change in the value of a.

wire a, b, c; assign a = b & c;

Circular assignments cannot be made using the assign keyword, as this produces a continuous loop. In the following example, the value of a is undefined, because it depends on itself passed through combinational (i.e. asynchronous, continuously operating) logic.

wire a, b; assign a = a | b;

For the wand and wor data types, all assignments to that wire are considered to be ports to logic gates. For instance, the following code:

wire a, b, c; wor x; assign x = a; assign x = b; assign x = c;

Is equivalent to this code:

wire a, b, c, x assign x = (a | b | c);

While it may seem like more work to use wor or wand, they can greatly simplify some complicated logic operations, and they can help to improve the readability of the code.

Reg
check syntax

A register, denoted with the keyword reg is a memory storage location. Registers store values without needing constant assignment, but they must be manually updated with a blocking or sequential assignment. Register values are all treated as being unsigned values, and any extension of a value into a larger register will not result in logical sign extension.

Registers can be used with the "=" and "<tt><=</tt>" b <= y + z;

Assignments with the "=" operator are blocking assignments, and they will be performed sequentially. Assignments with the "<=" operator are non-blocking. All non-blocking assignments in a particular code block will begin at the same time. The block will not terminate until all the non-blocking assignments have completed.

Vector
a vector is collection of a variables denoted with same name but with different subscripts example: [2:0]i; assign y=i[2]^i[1]; assign y=i[1]^i[0]; endmodule

Integer
Integer values, specified with the integer keyword are similar in function to registers, except that they are treated implicitly as signed numbers. Integer values will be logically sign-extended on assignment.

Real
A real number can be specified in one of the following two forms. 23_5.1e2  23510.0 (underscores are ignored) 3.6e2     360.0 (e and E are the same) 5E-4      0.0005
 * 1) decimal notation:examples of numbers in this form are: 2.0, 5.678, 1154.76, 0.1
 * 2) scientific notation: examples of numbers in this form are:

Parameter
A parameter is similar to predefined identifiers in C. It is used to declare a global constant example: parameter u=8; local parameter is used to declare single digit

Buses
Register and wire types can be specified as multi-bit buses. This assignment is made in the variable declaration using the <tt>[]</tt> operator. As an example:

wire [5:0] a;

This declares wire a to be a bus of 6 wires, with bit 5 (a[5]) being the MSB, and bit 0 (a[0]) being the LSB. The bit number of the LSB must be lower than the bit number for the MSB, but it needs not be zero.

Bit Selection
The individual wires or registers in a bus can be interfaced with directly, and subsets of the bus can be manipulated. Given the following declaration:

wire [15:0] a;

The following code will set a value to bit 14 of the bus:

assign a[14] = 1'b1;

And the following code will assign a value to the lower 8 bits of the bus:

assign a[7:0] = 8'b01101101;

Likewise, we can read from only part of a bus. The following code assigns the 8-bit bus b to be the upper 8 bits of the 16-bit bus a:

wire [15:0] a; wire [7:0] b; assign b[7:0] = a[15:8];

Part-select operators let the compiler calculate the range based on a starting point and a data-width size;

wire [15:0] a; wire [7:0] b; assign b[7:0] = a[15:8]; assign b[7:0] = a[8+:8]; // equivalent assign b[7:0] = a[15-:8]; // equivalent

title: Programmable Logic/Verilog Data Types