text:
Git/Branching & merging

Branching is supported in most VCSes. For example, Subversion makes a virtue of “cheap copying”—namely, that creating a new branch does not mean making a copy of the whole source tree, so it is fast. Git’s branching is just as fast. However, where Git really comes into its own is in merging between branches, in particular, reducing the pain of dealing with merge conflicts. This is what makes it so powerful in enabling collaborative software development.

Why Branch?
There are many reasons for creating multiple branches in a Git repo.
 * You may have branches representing “stable” releases, which continue to get incremental bug fixes but no (major) new features. At the same time, you may have multiple “unstable” branches representing various new features being proposed for the next major release, and being worked on in parallel, perhaps by different groups. Those features which are accepted will need to be merged into the branch for the next stable release.
 * You can create your own private branches for personal experiments. Later, if the code becomes sufficiently interesting to tell others about, you may make those branches public. Or you could send patches to the maintainer of the upstream public branch, and if they get accepted, you can pull them back down into your own copy of the public branch, and then you can retire or delete your private branch.

You may, in fact, want to add updates to different branches at different times. Switching between branches is easy.

View your branches
Use  with nothing else to see what branches your repository has: $ * master The branch called "master" is the default main line of development. You can rename it if you want, but it is customary to use the default. When you commit some changes, those changes are added to the branch you have checked out - in this case, master.

Create new branches
Let's create a new branch we can use for development - call it "dev": $ $    dev * master This only creates the new branch, it leaves your current HEAD where you remain. You can see from the * that the master branch is still what you have checked out. You can now use  to switch to the new branch.

Alternatively, you can create a new branch and check it out all at once with $

Delete a branch
To delete the current branch, again use git-branch, but this time send the  argument. $

If the branch hasn't been merged into master, then this will fail: $ error: The branch 'foo' is not a strict subset of your current HEAD. If you are sure you want to delete it, run 'git branch -D foo'.

Git's complaint saves you from possibly losing your work in the branch. If you are still sure you want to delete the branch, use  instead.

Sometimes there are a lot of local branches which have been merged on the server, so have become useless. To avoid deleting them one by one, just use:

git branch -D `git branch --merged | grep -v \* | xargs`

Pushing a branch to a remote repository
When you create a local branch, it won't automatically be kept in sync with the server. Unlike branches obtained by pulling from the server, simply calling git push isn't enough to get your branch pushed to the server. Instead, you have to explicitly tell git to push the branch, and which server to push it to:

$

Deleting a branch from the remote repository
To delete a branch that has been pushed to a remote server, use the following command:

$

This syntax isn't intuitive, but what's going on here is you're issuing a command of the form:

$

and giving an empty branch in the  position, meaning to overwrite the branch with nothing.

Merging
Branching is a core concept of a DVCS, but without good merging support, branches would be of little use.

This command merges the given branch into the current branch. If the current branch is a direct ancestor of the given branch, a fast-forward merge occurs, and the current branch head is redirected to point at the new branch. In other cases, a merge commit is recorded that has both the previous commit and the given branch tip as parents. If there are any conflicts during the merge, it will be necessary to resolve them by hand before the merge commit is recorded.

Handling a Merge Conflict
Sooner or later, if you’re doing regular merges, you will hit a situation where the branches being merged will include conflicting changes to the same source lines. How you resolve this situation will be a matter of judgement (and some hand-editing), but Git provides tools you can use to try to get an insight into the nature of the conflict(s), and how best to resolve them.

Real-world examples of merge conflicts tend to be nontrivial. Here we will try to create a very simple, albeit artificial, example, to try to give you some flavour of what is involved.

Let us start with a repo containing a single Python source file, called test.py. Its initial contents are as follows:

 * 1) !/usr/bin/python3
 * 2) This code doesn't really do anything at all.
 * 1) This code doesn't really do anything at all.

def func_common pass
 * 1) end func_common

def child1 func_common
 * 1) end child1

def child2 func_common
 * 1) end child2

def some_other_func pass
 * 1) end some_other_func

Commit this file to the repo, with a commit message saying something like “first version”.

Now create a new branch and switch to it, using the command

(This second branch is to simulate work being done on the same project by another programmer.) Edit the file test.py, and simply swap the definitions of the functions child1 and child2 around, equivalent to applying the following patch:

diff --git a/test.py b/test.py index 863611b..c9375b3 100644 --- a/test.py +++ b/test.py @@ -7,14 +7,14 @@ def func_common pass -def child1 -   func_common -#end child1 - def child2 func_common +def child1 +   func_common +#end child1 + def some_other_func pass
 * 1) end func_common
 * 1) end child2
 * 1) end some_other_func

Commit the update to the branch side-branch with a message like “swap a pair of functions around”.

Now switch back to the master</TT> branch:

This will also put you back to the previous version of <TT>test.py</TT>, since that was the last (in fact only) version committed to that branch.

On this branch, we now rename the function <TT>func_common</TT> to <TT>common</TT>, equivalent to the following patch:

diff --git a/test.py b/test.py index 863611b..088c125 100644 --- a/test.py +++ b/test.py @@ -3,16 +3,16 @@ #- -def func_common +def common pass -#end func_common +#end common def child1 -   func_common +   common def child2 -   func_common +   common def some_other_func
 * 1) This code doesn't really do anything at all.
 * 1) end child1
 * 1) end child2

Commit this change to the <TT>master</TT> branch, with a message like “rename func_common to common”.

Now, try to merge in the change you made on <TT>side-branch</TT>:

This should immediately fail, with a message like Auto-merging test.py CONFLICT (content): Merge conflict in test.py Automatic merge failed; fix conflicts and then commit the result.

Just to check what reports:

On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add ..." to mark resolution) both modified:     test.py no changes added to commit (use "git add" and/or "git commit -a")

If we look at <TT>test.py</TT> now, it should look like

 * 1) !/usr/bin/python3
 * 2) This code doesn't really do anything at all.
 * 1) This code doesn't really do anything at all.

def common pass
 * 1) end common

<<<<<<< HEAD def child1 common
 * 1) end child1

=
>>>>>>> side-branch def child2 common
 * 1) end child2

def child1 func_common
 * 1) end child1

def some_other_func pass
 * 1) end some_other_func

Note those sections marked “<<<<<<< HEAD” ... “=======” ... “>>>>>>> src-branch”: the part between the first two markers comes from the HEAD branch, the one we are merging onto (<TT>master</TT>, in this case), while the part between the last two markers comes from the branch named src-branch, which we are merging from (<TT>side-branch</TT>, in this case).

Assuming we know exactly what the code does, we can carefully fix up all the conflicting/duplicated parts, remove the markers, and continue the merge. But perhaps this is a large project, and no single person, not even the project leader, fully understands every corner of the code. In this case, it is helpful to at least narrow down the set of commits that lead directly to the conflict, in order to get a handle on what is going on. There is a command that you can use,, which is designed specifically to be used during a merge conflict, for just this purpose. In this example, I get output something like this:

$ commit 9df4b11586b45a30bd1e090706e3ff09692fcfa7 Author: Lawrence D'Oliveiro <ldo@geek-central.gen.nz> Date:  Thu Apr 17 10:44:15 2014 +0000 rename func_common to common commit 4e98aa4dbd74543d7035ea781313c1cfa5517804 Author: Lawrence D'Oliveiro <ldo@geek-central.gen.nz> Date:  Thu Apr 17 10:43:48 2014 +0000 swap a pair of functions around $

Now, as project leader, I can look further at just those two commits, and figure out that nature of the conflict is really quite simple: one branch has swapped the order of two functions, while the other has changed the name of another function being referenced within the rearranged code.

Another useful command is, which shows a 3-way diff between the state of the source file in the staging area, and the versions from the parent branches:

$ diff --cc test.py index c9375b3,863611b..088c125 --- a/test.py +++ b/test.py @@@ -3,18 -3,18 +3,18 @@@ # This code doesn't really do anything at all. #- --def func_common ++def common pass --#end func_common - - def child2 -    func_common - #end child2 ++#end common def child1 --   func_common ++   common #end child1 + def child2 -   func_common ++   common + #end child2 +   def some_other_func pass #end some_other_func $

Here you see, in the first two columns of each line, “+” and “-” characters indicating lines added/removed with respect to the two branches, or a space indicating no change.

Armed with this information, I can approach the problem of fixing up the conflicted file with a bit more confidence, creating the following merged version of <TT>test.py</TT>:

 * 1) !/usr/bin/python3
 * 2) This code doesn't really do anything at all.
 * 1) This code doesn't really do anything at all.

def common pass
 * 1) end common

def child2 common
 * 1) end child2

def child1 common
 * 1) end child1

def some_other_func pass
 * 1) end some_other_func

Just to recheck, after doing  on the above fixed version, but before committing, do another , which should produce output like:

diff --cc test.py index c9375b3,863611b..088c125 --- a/test.py +++ b/test.py @@@ -3,18 -3,18 +3,18 @@@ # This code doesn't really do anything at all. #- --def func_common ++def common pass --#end func_common - - def child2 -    func_common - #end child2 ++#end common def child1 --   func_common ++   common #end child1 + def child2 -   func_common ++   common + #end child2 +  def some_other_func pass #end some_other_func

And what does  say?

On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified:  test.py

Now when you do like it says and enter, Git automatically finishes the merge.

“The Stupid Content Tracker”
The git(1) man page summarizes Git as “the stupid content tracker”. It is important to understand what “stupid” means in this case: it means that Git does not use elaborate algorithms to try to automatically handle merge conflicts, instead it concentrates on displaying just the relevant information to help human intelligence to resolve the conflict. Linus Torvalds has famously said that he wouldn’t trust his code to such elaborate merge conflict-resolution systems, which is why he deliberately designed Git to be “stupid”, and therefore, reliable.

Git/Branch

title: Git/Branching & merging


text:
Git/Introduction

Here, we will introduce the simplest git commands: creating a new repository, adding and committing files, removing files, reverting bad commits, throwing away uncommitted changes, and viewing a file as of a certain commit.

Creating a git repository
Creating a new git repository is simple. There are two commands that cover this functionality:, and. Cloning a pre-existing repository will be covered later. For now, let's create a new repository in a new directory: $ Initialized empty Git repository in:
 * 1) /home/username/myrepo/.git/ on Linux.
 * C:/Users/username/myrepo/.git/ on Windows.

If you already have a directory you want to turn into a git repository: $ $

Taking the first example, let's look what happened: $ $  .git

The totality of your repository will be contained within the  directory. Conversely, some SCMs leave files all over your working directory (eg,,  ,  , etc.). Git refrains, and puts all things in a subdirectory of the repository root aptly named.

Remark: to set the default directory where Git will point at each opening, under Windows right click on the shortcut, and change the path of the field called "start in".

Checking Your Status
To check the status of your repo, use the command. For example, a newly-created repo with no commits in it as yet should show this:

$ On branch master Initial commit nothing to commit (create/copy files and use "git add" to track)

Get into the habit of frequent use of, to be sure that you’re doing what you think you’re doing. :)

Adding and committing files
Unlike most other VCSs, git doesn't assume you want to commit every modified file. Instead, the user adds the files they wish to commit to the staging area (also known as the index or cache, depending on which part of the documentation you read). Whatever is in the staging area is what gets committed. You can check what will be committed with or.

To stage files for the next commit, use the command. $ hack hack hack... $ # # # nothing added to commit but untracked files present (use "git add" to track)
 * 1) On branch master
 * 1) Initial commit
 * 1) Untracked files:
 * 2)   (use "git add ..." to include in what will be committed)
 * 1) 	file.txt

This shows us that we're using the branch called "master" and that there is a file which git is not tracking (does not already have a commit history). Git helpfully notes that the file can be included in our next commit by doing : $ $  # # # #
 * 1) On branch master
 * 1) Initial commit
 * 1) Changes to be committed:
 * 2)   (use "git rm --cached ..." to unstage)
 * 1) 	new file:  file.txt

After adding the file, it is shown as ready to be committed. Let's do that now: $ [master (root-commit) be8bf6d] My first commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 file.txt

In most cases, you will not want to use the  form - instead, leave it off to have   opened so you can write a proper commit message. We will describe that next, but in examples, the  form will be used so the reader can easily see what is going on.

You can use  to automatically stage all changed and untracked files for inclusion in the next commit. Once a file is being tracked,  will stage it if it has changed.

reset
If you change your mind about staging a file, and you haven’t committed yet, you can unstage it with the simplest form of the command: $ to unstage just the one file, or $ to remove everything in the staging area.

has many more functions than this, for example:
 * To cancel the two latest commits without touching the files:.
 * To cancel the two latest commits and their modifications into the files:.
 * To cancel the two last operations on the branch:  (which uses  ). This can be used to cancel an undesired reset.

To exclude certain untracked files from being seen by, read on...

restore
comes back to a version of the file specified in parameter.

Excluding files from Git
Often there are files in your workspace that you don't want to add to the repository. For example, emacs will write a backup copy of any file you edit with a tilde suffix, like filename~. Even though you can manually avoid adding them to the commit (which means never using ), they clutter up the status list.

In order to tell Git to ignore certain files, you can create an ignore file, each line of which represents a specification (with wildcards) of the files to be ignored. Comments can be added to the file by starting the line with a blank or a # character.

For example:

 * 1) Ignore emacs backup files:

app/cache
 * 1) Ignore everything in the cache directory:

Git looks for an ignore file under two names:
 * .git/info/exclude — this is specific to your own personal copy of the repository, not a public part of the repository.
 * .gitignore — since this is outside the .git directory, it will normally be tracked by Git just like any other file in the repository.

What you put in either (or both) of these files depends on your needs. .gitignore is a good place to mention things that everybody working on copies of this repository is likely to want to be ignored, like build products. If you are doing your own personal experiments that are not likely to concern other code contributors, then you can put the relevant ignore lines into .git/info/exclude.

Note that ignore file entries are only relevant to the  and   (add all new and changed files) commands. Any files you explicitly add with  will always be added to the repository, regardless of whether their names match ignore entries or not. And once they are added to the repository, changes to them will henceforth be automatically tracked by.

Good commit messages
Tim Pope writes about what makes a model Git commit message:

Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the present tense: "Fix bug" and not "Fixed bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a  single space, with blank lines in between, but conventions vary here - Use a hanging indent Let’s start with a few of the reasons why wrapping your commit messages to 72 columns is a good thing.
 * Git log doesn’t do any special wrapping of the commit messages. With the default pager of, this means your paragraphs flow far off the edge of the screen, making them difficult to read. On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns.
 * converts a series of commits to a series of emails, using the messages for the message body. Good email netiquette dictates we wrap our plain text emails such that there’s room for a few levels of nested reply indicators without overflow in an 80 column terminal.

Vim users can meet this requirement by installing my vim-git runtime files, or by simply setting the following option in your git commit message file: :set textwidth=72

For Textmate, you can adjust the “Wrap Column” option under the view menu, then use ^Q to rewrap paragraphs (be sure there’s a blank line afterwards to avoid mixing in the comments). Here’s a shell command to add 72 to the menu so you don’t have to drag to select each time: $ defaults write com.macromates.textmate OakWrapColumns '( 40, 72, 78 )'

More important than the mechanics of formatting the body is the practice of having a subject line. As the example indicates, you should shoot for about 50 characters (though this isn’t a hard maximum) and always, always follow it with a blank line. This first line should be a concise summary of the changes introduced by the commit; if there are any technical details that cannot be expressed in these strict size constraints, put them in the body instead. The subject line is used all over Git, oftentimes in truncated form if too long of a message was used. The following are just a handful of examples of where it ends up:

 * shows a terse history mapping containing the commit id and the summary
 * provides the summary for each commit in the editor it invokes
 * If the config option <tt>merge.summary</tt> is set, the summaries from all merged commits will make their way into the merge commit message
 * uses summary lines in the changelog-like output it produces
 * ,, and related tools use it as the subject for emails
 * , a local history accessible intended to help you recover from mistakes, get a copy of the summary
 * , a graphical interface which has a column for the summary
 * Gitweb and other web interfaces like GitHub use the summary in various places in their user interface.

The subject/body distinction may seem unimportant but it’s one of many subtle factors that makes Git history so much more pleasant to work with than Subversion.

Removing files
Let's continue with some more commits, to show you how to remove files: $ $  # # no changes added to commit (use "git add" and/or "git commit -a")
 * 1) On branch master
 * 2) Changed but not updated:
 * 3)   (use "git add ..." to update what will be committed)
 * 4)   (use "git checkout -- ..." to discard changes in working directory)
 * 1) 	modified:  file.txt

Although git doesn't force the user to commit all modified files, this is a common scenario. As noted in the last line of, use   to commit all modified files without reading them first: $ [master e633787] My second commit 1 files changed, 1 insertions(+), 0 deletions(-)

See the string of random characters in git's output after committing (bolded in the above example)? This is the abbreviation of the identifier git uses to track objects (in this case, a commit object). Each object is hashed using SHA-1, and is referred to by that string. In this case, the full string is <tt>e6337879cbb42a2ddfc1a1602ee785b4bfbde518</tt>, but you usually only need the first 8 characters or so to uniquely identify the object, so that's all git shows. We'll need to use these identifiers later to refer to specific commits.

To remove files, use the "rm" subcommand of git: $ rm 'file.txt' $ # # $  .  ..  .git
 * 1) On branch master
 * 2) Changes to be committed:
 * 3)   (use "git reset HEAD ..." to unstage)
 * 1) 	deleted:   file.txt

Note that this deletes the file from your disk. If you only want to remove the file from the git repository but want to leave the file in your working directory, use.

$ [master b7deafa] Removed file.txt 1 files changed, 0 insertions(+), 2 deletions(-) delete mode 100644 file.txt

Reverting a commit
To revert a commit with another, use : $ Finished one revert. [master 47e3b6c] Revert "My second commit" 1 files changed, 0 insertions(+), 1 deletions(-) $ .  ..  file.txt  .git

You can specify any commit instead of HEAD. For example:
 * The commit before HEAD:
 * The commit five back:
 * The commit identified by a given hash:

Resetting a commit
provides the same options as, but instead of creating a revert commit, it just cancels the commit(s) and lets the file(s) uncommitted.

To cancel a reset, use:.

Throwing away local, uncommitted changes
To throw away your changes and get back to the most recently-committed state: $

As above, you can specify any other commit: $

If you only want to reset one file (where you have made some stupid mistake since the last commit), you can use $ This will delete all changes made to that file since the last commit, but leave the other files untouched.

Get a specific version of a file
To get a specific version of a file that was committed, you'll need the hash for that commit. You can find it with : $ commit 47e3b6cb6427f8ce0818f5d3a4b2e762b72dbd89 Author: Mike.lifeguard <myemail@example.com> Date:  Sat Mar 6 22:24:00 2010 -0400 Revert "My second commit" This reverts commit e6337879cbb42a2ddfc1a1602ee785b4bfbde518. commit e6337879cbb42a2ddfc1a1602ee785b4bfbde518 Author: Mike.lifeguard <myemail@example.com> Date:  Sat Mar 6 22:17:20 2010 -0400 My second commit commit be8bf6da4db2ea32c10c74c7d6f366be114d18f0 Author: Mike.lifeguard <myemail@example.com> Date:  Sat Mar 6 22:11:57 2010 -0400 My first commit

Then, you can use : $ hack hack hack... more stuff

Git Checkout Is Not Subversion Checkout
If you are coming to Git after having used the Subversion centralized version-control system, you may assume that the checkout operation in Git is similar to that in Subversion. It is not. While both Git and Subversion let you check out older versions of the source tree from the repository, only Subversion keeps track of which revision you have checked out. Git does not. will only show you that the source tree does not correspond to the current branch HEAD; it will not check whether it corresponds to some prior commit in the history.

<TT>diff</TT> and <TT>patch</TT>: The Currency of Open-Source Collaboration
It is important to understand early on the use of the <TT>diff(1)</TT> and <TT>patch(1)</TT> utilities. <TT>diff</TT> is a tool for showing line-by-line differences between two text files. In particular, a unified diff shows added/deleted/changed lines next to each other, surrounded by context lines which are the same in both versions. Assume that the contents of <TT>file1.txt</TT> are this: this is the first line. this is the same line. this is the last line.

while <TT>file2.txt</TT> contains this: this is the first line. this line has changed. this is the last line.

Then a unified diff looks like this: $ --- file1.txt   2014-04-18 11:56:35.307111991 +1200 +++ file2.txt  2014-04-18 11:56:51.611010079 +1200 @@ -1,3 +1,3 @@ this is the first line. -this is the same line. +this line has changed. this is the last line. $

Notice the extra column at the start of each line, containing a “-” for each line that is in the first file but not in the second, a “+” for each line that is in the second file but not the first, or a space for an unchanged line. There are extra lines, in a special format, identifying the files being compared and the numbers of the lines where the differences were found; all this can be understood by the <TT>patch</TT> utility, in order to change a copy of <TT>file1.txt</TT> to become exactly like <TT>file2.txt</TT>:

$ $  patching file file1.txt $ $

Notice how the second <TT>diff</TT> command no longer produces any output: the files are now identical!

This is how collaborative software development got started: instead of exchanging entire source files, people would distribute just their changes, as a unified <TT>diff</TT> or in <TT>patch</TT> format (same thing). Others could simply apply the patches to their copies. And provided there were no overlaps in the changes, you could even apply a patch to a file that had already been patched with another <TT>diff</TT> from someone else! And so this way changes from multiple sources could be merged into a common version with all the new features and bug fixes contributed by the community.

Even today, with version-control systems in regular use, such diffs/patches are still the basis for distributing changes. and both produce output which is compatible with , and can be correspondingly understood by <TT>patch</TT>. So even if the recipient of your patches isn’t using Git, they can still accept your patches. Or you might receive a patch from someone who isn’t using Git, and so didn't use <TT>git-format-patch</TT>, so you can’t feed it to to automatically apply it and save the commit; but that’s OK, you can use, or even <TT>patch</TT> itself on your source tree, and then make a commit on their behalf.

Conclusion
You now know how to create a new repository, or turn your source tree into a git repository. You can add and commit files, and you can revert bad commits. You can remove files, view the state of a file in a certain commit, and you can throw away your uncommitted changes.

Next, we will look at the history of a git project on the command line and with some GUI tools, and learn about git's powerful branching model.

Git/Premiers pas Git/Przypadki

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

title: Git/Introduction


text:
Talk:Guitar/Blanks

One problem with the tablature: Make sure the spaces always are a multiple of 4, since the most commmon time signature is 4/4. --MetalGeoff

title: Talk:Guitar/Blanks


text:
Basic Book Design/Straight Quotes vs. Curly Quotes

Keep out of Trouble Rules

 * 1) Use prime marks for measurements (single prime for feet, double prime for inches).
 * 2) Use curly quotes for quotations
 * 3) Use a curly apostrophe (backwards C shape) for contractions, regardless of where in the word the missing letters fall.
 * 4) Use curly single quotes (open and closed apostrophes) for quotes within quotes.
 * 5) In American English, virtually all punctuation marks fall within the quotation marks; in British English, the only punctuation marks that fall within quotation marks are those that occur in the original material being quoted. The American standard seems gradually to be giving way to the more rational British one.


text: User talk:67.170.50.151

title: User talk:67.170.50.151


text:
User talk:Jbate015

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.– Mike.lifeguard  | talk 04:45, 20 October 2007 (UTC)

title: User talk:Jbate015


text:
User talk:Jarms016

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally.– Mike.lifeguard  | talk 04:46, 20 October 2007 (UTC)

title: User talk:Jarms016


text:
Category talk:Subject:Computer science

Merge
Category:Computer Science & Category:Computer science

we have a category of "Computer science" which also seems to be a sub-category of "Computer Science".

This seems redundant; if there is some reason for having both, then i'm willing to accept that, but if it's only a matter of the difference in capitalization, can't we fix that with a re-direct or something? It leaves a lot of opportunities for confusion & makes searching for, or adding, articles more complicated; you can miss something easily if it's not listed in both sections.

If they are merged, i'd suggest keeping "Computer Science" as the heading looks better with both letters capitalized & as that page seems to be more developed. —The preceding unsigned comment was added by User:Dr. know

 * In fact the merge will have to happen the other way around. Category name should not capitalize the second word (that's how english works I guess :-)) I understand that this standard is not applied very well in wikibooks but wikipedia is pretty clear about that so we shall use their default. Regards -- Jacques (talk) (email) 17:10, 21 December 2007 (UTC)

 * Done. --Panic (talk) 07:23, 17 December 2008 (UTC)

title: Category talk:Subject:Computer science


text:
User:DonkeyKong64

See my main profile on Wikipedia:

Wikipedia:User:DonkeyKong64

title: User:DonkeyKong64


text:
Git/Internal structure

Understanding something of the internal structure of Git is crucial to understanding how Git works.

Naked Git Structure
The following is a freshly initialized git v1.9.0 repository.

. └── .git/ ├── HEAD ├── branches/ ├── config ├── description ├── hooks/ │  ├── applypatch-msg.sample │  ├── commit-msg.sample │  ├── post-update.sample │  ├── pre-applypatch.sample │  ├── pre-commit.sample │  ├── prepare-commit-msg.sample │  ├── pre-push.sample │  ├── pre-rebase.sample │  └── update.sample ├── info/ │  └── exclude ├── objects/ │  ├── info/ │  └── pack/ └── refs/ ├── heads/ └── tags/ Additional files and folders may appear as activity happens on the repository.

COMMIT_EDITMSG
The message for a commit being made is saved here by a text editor.

FETCH_HEAD
Information is saved here from the last operation, for use by a later.

HEAD
HEAD indicates the currently checked out code. This will usually point to the branch you're currently working on.

You can also enter what git calls a "detached HEAD" state, where you are not on a local branch. In this state the HEAD points directly to a commit rather than a branch.

config
The configuration file for this git repository. It can contain settings for how to manage and store data in the local repository, remote repositories it knows about, information about the local user and other configuration data for git itself.

You can edit this file with a text editor, or you can manage it with the command.

description
Used by repository browser tools - contains a description of what this project is. Not normally changed in non-shared repositories.

index
This is the staging area. It contains, in a compact form, all changes to files that have been staged for the next commit.

info/exclude
This is your own personal exclude file for your copy of the repo.

info/refs
If this file exists, it contains definitions, one to a line, of branches (both local and remote) and tags defined for the repository, in addition to ones that may be defined in individual files in refs/heads and refs/tags. This file seems to be used for large repositories with lots of branches or tags.

ORIG_HEAD
Operations that change commit history on the current branch save the previous value of HEAD here, to allow recovery from mistakes.

branches
Never seems to be used.

hooks
Contains scripts to be run when particular events happen within the git repository. Git gives you a set of initial example scripts, with .sample on the ends of their names (see the tree listing above); if you take off the .sample suffix, Git will run the script at the appropriate time.

Hooks would be used, for example, to run tests before creating each commit, filter uploaded content, and implement other such custom requirements.

logs
The reflogs are kept here.

objects
This is where all the files, directory listings, commits and such are stored.

There are both unpacked objects in numbered directories under this, and "packs" containing many compressed objects within a pack directory. The uncompressed objects will be periodically collected together into packs by automatic "git gc" runs.

refs/heads
Can contain one file defining the head commit for each local branch (but see info/refs above).

refs/remotes
Can contain one subdirectory for each remote repository you have defined. Within each subdirectory, there is a file defining the tip commit for each branch on that remote.

refs/tags
Can contain one file defining the commit corresponding to each tag (but see info/refs above).

svn
This directory will appear if you use to communicate with a Subversion server.

Object Types
A Git repository is made up of these object types:
 * A blob holds the entire contents of a single file. It doesn’t hold any information about the name of the file or any other metadata, just the contents.
 * A tree represents the state of a directory tree. It contains the pathnames of all the component files and their modes, along with the IDs of the blobs holding their contents. Note that there is no representation for a directory on its own, so a Git repository cannot record the fact that subdirectories were created or deleted, only the files in them.
 * A commit points to a tree representing the state of the source tree as of immediately after that commit. It also records the date/time of the commit, the author/committer information, and pointers to any parent(s) of that commit, representing the immediately-prior state of the source tree.
 * A tag is a name pointing to a commit. These are useful, for example, to mark release milestones. Tags can optionally be digitally signed, to guarantee the authenticity of the commit.
 * A branch is a name pointing to a commit. The difference between a branch and a tag is that, when a branch is the currently-checked-out branch, then adding a new commit will automatically update the branch pointer to point to the new commit.

Blobs, trees and commits all have IDs which are computed from SHA-1 hashes of their contents. These IDs allow different Git processes on different machines to tell whether they have identical copies of things, without having to transfer their entire contents over. Because SHA-1 is a cryptographically strong hash algorithm, it is practically impossible to make a change to the contents of any of these objects without changing its ID. Git doesn’t prevent you from rewriting history, but you cannot hide the fact that you have done so.

A commit may have 0, 1 or more parents. Typically there is only one commit with no parents—a root commit—and that is the first commit to the repository. A commit which makes some change to one branch will have a single parent, the previous commit on that branch. A commit which is a merge from two or more branches will have two or more parent commits.

Note that a branch points to a single commit; the chain of commits is implicit in the parent(s) of that commit, and their parents, and so on.

Topology Of Commits
The commit history in Git is arranged as a directed acyclic graph (DAG). To understand what this means, let’s take the terms step by step.

 * In mathematical terms, a graph is a bunch of points (nodes) connected by lines (edges).

 * A directed graph is one where each edge has a direction, represented here by an arrowhead. Note that the arrow points from the child to the parent, not the other way round; it is the child that records who its parent(s) are, the parent does not record who its children are, because the set of children can change at any time, but the parent cannot change without invalidating its SHA-1 hash.

 * Acyclic means that, if you start from any point and traverse edges in the direction of the arrows, you can never get back to your starting point, no matter what choice you make at any branch. No child can ever be a (direct or indirect) parent of itself!

In Git terms, each node represents a commit, and the lines and arrows represent parent-child relationships. Banning cycles simply means that a commit cannot be a (direct or indirect) parent or a child of itself!

The Reflog
The reflogs record changes that are not saved as part of the commit history—things like rebases, fast-forward merges, resets and the like. There is one reflog per branch. The reflog is not a public part of the repository, it is strictly specific to your local copy, and information is only kept in it for a limited time (2 weeks by default). It provides a safety net, allowing you to recover from mistakes like deleting or overwriting things you didn’t mean to.

Reachability And Garbage Collection
A commit is reachable if it is pointed to by a branch, tag or reflog entry, or is a parent of a commit which is reachable. A tree is correspondingly reachable if it is pointed to by a reachable commit, and a blob is reachable if it is pointed to by a reachable tree. Other commit/tree/blob objects are unreachable, and are not really serving any purpose beyond taking up space.

It is quite normal for your repositories to accumulate unreachable objects over time, perhaps as a result of aborted commits, deletion of unwanted branches, that kind of thing. Such objects will be deleted from the repository by a  command. This is also done automatically every now and then by some other commands, so it is rarely necessary to invoke  explicitly.

.gitkeep
Placed in a directory, it guarantees that it will be committed, even if empty.

.gitignore
Contains the files and folders to exclude from versioning. Ex: /var/ /vendor/ /.env.*.local

.gitattributes
Contains somes attributes. For example, to ignore .gitattributes and .gitignore in the "git archive" exports: .gitattributes export-ignore .gitignore export-ignore

title: Git/Internal structure


text:
Talk:Ordinary Differential Equations/Substitution 1

Include an example of where substitution doesn't work?
Under "Other Methods", it says "Remember that between v and v' you must eliminate the y in the equation."

Maybe it would be a good idea to include an example where this doesn't work? In particular, a good example whould be where a substitution v = v(x,y) eliminates y from the right-hand-side of the DE, but it's not possible to eliminate y from the dy/dx term.

It's a common misunderstanding with, for example, integration by substitution, that if you can get rid of all of the xs from the integrand, then you should be able to solve it (they forget about the dx). A similar misunderstanding can happen with this kind of substitution, where people forget they need to eliminate the y from dy/dx.

That's why I think an example (or rather a counter-example) would be helpful. DonkeyKong64 06:42, 20 October 2007 (UTC)


text:
Programming with Moose

Moose is a distribution (set of modules), that constitute a new framework for Perl 5. It addresses many of the criticisms about Perl's object orientation (OO) implementation, and brings new light to crufty old perl syntax.

Moose was created by Stevan Little, the author of countless modules both useful and useless hosted on CPAN.

Table of Contents

 * 1) /Preface/
 * 2) /Obtaining Moose/
 * 3) /Ideology/
 * 4) /Problems solved/
 * 5) Accessors
 * 6) Type-system
 * 7) Scalar::Defer
 * 8) /Evolution of the Moose/
 * 9) Roles and Plugins
 * 10) /Type system/
 * 11) Syntax Reference

Difficulties Identified?

 * 1) Moose-w-Moose

title: Programming with Moose


text:
Programming with Moose/Preface

The first goal of a book should be to convince the reader it's worth reading in the first five minutes. It shouldn't take you five minutes to read this.

Should I even be reading this?
This book is free, and in being free I can willfully tell people how to save time up front: If the following applies to you do not waste your time and go away:

 * You don't use the OOP paradigm and you don't care to know what you're missing.
 * You won't entertain the idea of making your perl programs dependent on a module that does not exist in the CORE distribution.
 * You think all syntax that looks foreign to perl is bad.
 * You're the benchmark-before-completion type of programmer, or you won't compromise on execution speed.
 * You don't like radical change.

Tell me what you're 'twerkin with
Let me start out with the problem: perl5 is old and crusty.

The OOP paradigm of Perl5 is in severe need of a face lift. Not only does it lack functionality that other programming languages have, the functionality it does have it does poorly. Moose will scrape off this crust and abstract away these shortfalls. All hail the shiny newer Moose-powered perl.

Moose is an awkward gem, and telling you what it's about is more of a boring practice of pedantry - one we will tackle at a later point. Moose does a lot, and it has ambitious goals, but aside from what it wants to accomplish, you'll find it delivers on the following:

 * 1) It will eliminate the need for the variety of modules that help compensate for that aforementioned old and crustyness.
 * 2) It will make programming more fun and less tedious. To further assist the hype-catalyst, it will make the fun more fun, and the tedious more fun, and the tedious less existent and.. or something...
 * 3) It will provide a versatile framework for which you can quickly prototype, and meld real-world problems.
 * 4) It will give you real world practice with another up and coming paradigm: AOP.

Be prepared to leave behind all of your old perl-OOP practices. Moose doesn't play well with them: it single-handedly replaces them! No more need for, or writing manual checks using   inside of your app. Gone are the days of using Conway's cursed, or violating blackbox rules to get the job done. Tokens, Models, and Events are all that you should be thinking of. Moose will think of the rest for you in a totally impersonal pre-thought-out fashion of course.

One more thing, this book goes about teaching Moose by comparing the "(old) perl way", with the "(new) Moose way." If this analogy bothers you, you can find the non-entertaining Moose docs on CPAN.

There is in addition a set of syntax docs in this book, which are surely more neutral.

title: Programming with Moose/Preface


text:
Programming with Moose/Problems solved/Accessors

Perl has two aggregate (non-scalar) data types: arrays and hashes (i.e., associative arrays) which are commonly used as the base data structure for objects. A more serious problem is that neither of these data types is an object. For instance, native array and hash support doesn't allow you to receive an event trigger when you write a new key-value pair to a hash, or when you push a new element onto an array. It's possible to use Perl's tie mechanism to get this, but tie comes with a serious performance penalty. Perl does enhance the C-style array of fixed size - a simple contiguous block of memory, addressed via indexing - to allow it to grow or shrink as needed, but chose for reasons of efficiency to implement only basic operations.

One of the two might be better for one task, and not applicable for another, but that doesn't matter. With Moose, your program isn't directly tied to a Perl data structure.

The old way
Traditionally,, has done the most for arena, we'll see that soon. The problem it solved was a big and simple one, and it didn't overachieve one bit: if you've got a hash and you don't want a  to be inserted, how do you go about it? You simply  the hash into an object and say what accessors should be generated. Now this "hash" acts as watered down model that your module can wrap to achieve the goals of the program. When an unrelated function is called perl realizes it can't resolve the method to a matching sub and errors.

An Example
Examine the terseness of this code.

Here we create an object, essentially a hash that permits only three keys. The getters and setters for this hash directly correlate to the keys in the underlying perl hash. Remember, that a Perl object is very simple. complexities are left as an exercise to the programmer.

Invoking the Moose
Truth be told, Moose is more than a replacement for. So, off the shelf, it won't compete with the simplicity of. In this section however, we will see Moose's analog.

An Example
Pretty simple. No syntax thus far really needs explaining -- but in the next section we will anyway.

New Syntax
For clarity and those who just can't learn by example:

has
has is one of few Moose keywords, it begins a Moose expression that declares a statement.

isa
isa in the context of has refers to the TypeConstraint of the object. Moose has a built in type system, and this keyword, which will be explained further in the next chapter specifies what values this attribute is to accept.

is
is in the context of has refers to the type of accessors to be created. A value of rw will instruct Moose to forge a setter and getter, while a value of ro will only yield a get'er.


text:
Programming with Moose/Problems solved/Type-system

Perl lacks and Moose doesn't. At least, not nearly as much. Back to the issues of Perl, more specifically another feature not covered by the Object System but delivered as a blessed benediction of Moose. So in this example, you're writing a program and like a good programmer, *all* of your URLs are handled by  objects, and all of your methods operate on   objects - or at least they think they do. Having methods dependent on  objects is a good thing. Trust me, it is, the alternative is heaven-1. Unfortunately, when you publish the module to a world of intellectually inferior blokes you have no streamlined method of making sure they send only URIs.

Again this is where Perl is lacking. All urls are stored as  objects, but you can't easily make sure they're only   objects.

Roots in pre-object fanaticsm
Ponder for a bit the utility of sigils. One of the side effects of sigils is a function knows at compile time whether or not the input sent to it is in the right ballpark. Perl's sigils are a little more voodoolicious because sometimes they can change the value by acting as an operator. Let's look at how perl deals with validating input.

In the following example, the class HashOperations expects a HashObject:

So the issue here, is that the procedural non-referenced form will be caught in compile time, and all other object variants will not.

The old way
The old stock-Perl way to tackle this problem was really a joke on the users. Rather than adding specific functionality to the CORE, or radically modifying it, the core-team would rather bother the programmer with modular language add-ons that productivity is totally dependent on. We can speculate on the reasoning for the lack of TypeConstraint functionality.

 * There weren't any examples of interpreted languages for Perl to model itself after, never mind interpreted languages with base-object types.
 * Perl's references came before its objects.
 * A hash is a Hash (of Scalars), an array is an Array (of Scalars). A good portion of this can be determined on compile time by the use of perl's sigils. This is not so with Objects which occur wholly at runtime, and aren't granted a unique sigil.

An Example
In this set of examples we will show how Class::Accessor is automagically inferior to Moose at making accessors, because of Moose's ability to specify valid types.

Here we create a custom datatype, ie. NonMooseObject:

This is what you want your user to do:

This is what you don't want your user to do. In this example we show how easily a NonMooseObject can be abused. There is one important thing that is difficult to show in an example: the death might or might not occur on the call to. Hopefully, for the user and programmer, it dies on the call to new; but, let's assume you run for 42 days, and then something internally calls  on   when   does not contain a URI object. The result is then a bug that could be much harder to troubleshoot.

The pre-Moose days
We told ourselves this functionality, is more advanced and niche, isn't needed everywhere. To accomplish this functionally you much first decouple your module and. So not just is this solution ugly, but now you're back at having to write accessors. Baby Jesus cried around this point in time.

Invoking the Moose
Dredging up the past is boring and disturbing, so let's now look forward now, towards the light.

An Example
No more examples needed. You now either send in a  object to the constructor, or you die with an accompanying stack trace and Moose's default message telling you what you need to do.


text:
Programming with Moose/Problems solved

Perl (prior to version 5.10) has an illogical Method Resolution Order (MRO), this becomes apparent when using multiple inheritance dispatching. A fix for MI-dispatching was first popularized with Dameon's, which turned out to be a buggy hack that failed horribly in many cases. was unfortunately inducted into the CORE distro with Perl v5.7.3 and remains in the CORE even today. Moose uses the newer jazzier C optimized  which is the new non-default standard for proper method-dispatch in all Perl's greater than Perl 5.95.

Before  and , you had   which predates   by approximately six months and thankfully never made CORE. was goofy and mostly useless because if foo and bar were siblings and subclasses of baz you could not re-dispatch in foo to a method in bar.

Essentially  supported Method Dispatch only for linear patterns. supported them in a fashion that was quirky and made little sense. Without learning the quirks there is a high probability the new  does precisely what the programmer wants - it is intuitive. uses the C3 MRO algorithm which is also employed by Python.

The old way
The differences between  and   are outside of the range of this book; but, because vanilla Perl doesn't even permit method resolution, and dispatch in the sense of the OO paradigm we will show   in its stead.

title: Programming with Moose/Problems solved


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...Bd7/7. Qe2

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ Bd7

Statistics
Estimated next move likelihood Be7 67%, Bd6 30%, Bxb5 3%


text:
Programming with Moose/Obtaining Moose

There are numerous way you can obtain the latest version of Moose. Some of the more popular methods are listed below.

CPAN
Using the CPAN module:

Using the interactive shell, in non-interactive mode:

To use the shell in interactive mode simply:

Tarball
Download from http://search.cpan.org/dist/Moose/.

Debian (and Debian-derived systems)
If you're running Debian, or a Debian-based system, your package manager can install Moose. Using this method has advantages and disadvantages. The disadvantage is that you will not always be running the bleeding edge of Moose, and not all Moose extensions are packaged for Debian. The advantages are that you get quality control, security tracking, and ease of installation with Debian's APT.

To install Moose on a Debian system;

title: Programming with Moose/Obtaining Moose


text:
Famous Theorems of Mathematics/Logic

Gödel's completeness theorem
In the following, we state two equivalent forms of the theorem, and show their equivalence.

Later, we prove the theorem. This is done in the following steps:

 * 1) Reducing the theorem to sentences (formulas with no free variables) in prenex form, i.e. with all quantifiers ($$\forall$$ and $$\exists$$) at the beginning. Furthermore, we reduce it to formulas whose first quantifier is $$\forall$$. This is possible because for every sentence, there is an equivalent one in prenex form whose first quantifier is $$\forall$$.
 * 2) Reducing the theorem to sentences of the form $$\forall x_1 \forall x_2 ... \forall x_k \exists y_1 \exists y_2... \exists y_m \phi(x_1...x_k, y_1...y_m)$$. While we cannot do this by simply rearranging the quantifiers, we show that it is yet enough to prove the theorem for sentences of that form.
 * 3) Finally we prove the theorem for sentences of that form.
 * 4) * This is done by first noting that a sentence such as $$B = \exists x_1 \exists x_2 ... \exists x_k \exists y_1 \exists y_2... \exists y_m \phi(x_1...x_k, y_1...y_m)$$ is either refutable or has some model in which it holds; this model is simply assigning truth values to the subpropositions from which B is built of. The reason for that is the completeness of propositional logic, with the existential quantifiers playing no role.
 * 5) * We extend this result to more and more complex and lengthy sentences, Dn (n=1,2...), built out from B, so that either any of them is refutable and therefore so is φ, or all of them are not refutable and therefore each holds in some model.
 * 6) * We finally use the models in which the Dn hold (in case all are not refutable) in order to build a model in which φ holds.

Theorem 1. Every formula valid in all structures is provable.

This is the most basic form of the completeness theorem. We immediately restate it in a form more convenient for our purposes:

Theorem 2. Every formula φ is either refutable or satisfiable in some structure.

"φ is refutable" means by definition "¬φ is provable".

Equivalence of both theorems
To see the equivalence, note first that if Theorem 1 holds, and φ is not satisfiable in any structure, then ¬φ is valid in all structures and therefore provable, thus φ is refutable and Theorem 2 holds. If on the other hand Theorem 2 holds and φ is valid in all structures, then ¬φ is not satisfiable in any structure and therefore refutable; then ¬¬φ is provable and then so is φ, thus Theorem 1 holds.

Proof of theorem 2: first step
We approach the proof of Theorem 2 by successively restricting the class of all formulas φ for which we need to prove "φ is either refutable or satisfiable". At the beginning we need to prove this for all possible formulas φ in our language. However, suppose that for every formula φ there is some formula ψ taken from a more restricted class of formulas C, such that "ψ is either refutable or satisfiable" → "φ is either refutable or satisfiable". Then, once this claim (expressed in the previous sentence) is proved, it will suffice to prove "φ is either refutable or satisfiable" only for φ's belonging to the class C. Note also that if φ is provably equivalent to ψ (i.e., (φ≡ψ) is provable), then it is indeed the case that "ψ is either refutable or satisfiable" → "φ is either refutable or satisfiable" (the soundness theorem is needed to show this).

There are standard techniques for rewriting an arbitrary formula into one which does not use function or constant symbols, at the cost of introducing additional quantifiers; we will therefore assume that all formulas are free of such symbols. In Gödel's paper, he uses a version of first-order predicate calculus which has no function or constant symbols to begin with.

Next we consider a generic formula φ (which no longer uses function or constant symbols) and apply the prenex form theorem to find a formula ψ in normal form such that φ≡ψ (ψ being in normal form means that all the quantifiers in ψ, if there are any, are found at the very beginning of ψ). It follows now that we need only prove Theorem 2 for formulas φ in normal form.

Next, we eliminate all free variables from φ by quantifying them existentially: if, say, x1...xn are free in φ, we form $$\psi=\exists x_1 ... \exists x_n \phi$$. If ψ is satisfiable in a structure M, then certainly so is φ and if ψ is refutable, then $$\neg \psi = \forall x_1 ... \forall x_n \neg \phi$$ is provable, and then so is ¬φ, thus φ is refutable. We see that we can restrict φ to be a sentence, that is, a formula with no free variables.

Finally, we would like, for reasons of technical convenience, that the prefix of φ (that is, the string of quantifiers at the beginning of φ, which is in normal form) begin with a universal quantifier and end with an existential quantifier. To achieve this for a generic φ (subject to restrictions we have already proved), we take some one-place relation symbol F unused in φ, and two new variables y and z.. If φ = (P)Φ, where (P) stands for the prefix of φ and Φ for the matrix (the remaining, quantifier-free part of φ) we form $$\psi = \forall y (P) \exists z ( \Phi \wedge [ F(y) \vee \neg F(z) ] )$$. Since $$\forall y \exists z ( F(y) \vee \neg F(z) )$$ is clearly provable, it is easy to see that $$\phi=\psi$$ is provable.

Reducing the theorem to formulas of degree 1
Our generic formula φ now is a sentence, in normal form, and its prefix starts with a universal quantifier and ends with an existential quantifier. Let us call the class of all such formulas R. We are faced with proving that every formula in R is either refutable or satisfiable. Given our formula φ, we group strings of quantifiers of one kind together in blocks:

 * $$\phi = (\forall x_1 ... \forall x_{k_1})(\exists x_{k_1+1} ... \exists x_{k_2}).......(\forall x_{k_{n-2}+1} ... \forall x_{k_{n-1}})(\exists x_{k_{n-1}+1} ... \exists x_{k_n}) (\Phi)$$

We define the degree of $$\phi$$ to be the number of universal quantifier blocks, separated by existential quantifier blocks as shown above, in the matrix of $$\phi$$. The following lemma, which Gödel adapted from Skolem's proof of the Löwenheim-Skolem theorem, lets us sharply reduce the complexity of the generic formula $$\phi$$ for which we need to prove the theorem:

Lemma. Let k>=1. If every formula in R of degree k is either refutable or satisfiable, then so is every formula in R of degree k+1.

 * Comment: Take a formula φ of degree k+1 of the form $$\phi = (\forall x)(\exists y)(\forall u)(\exist v) (P) \psi$$, where $$(P)\psi$$ is the remainder of $$\phi$$ (it is thus of degree k-1). φ states that for every x there is a y such that... (something). It would have been nice to have a predicate Q'  so that for every x, Q'(x,y) would be true if and only if y is the required one to make (something) true. Then we could have written a formula of degree k which is equivalent to φ, namely $$(\forall x')(\forall x)(\forall y)(\forall u)(\exist v)(\exist y') (P) Q'(x',y') \wedge (Q'(x,y) \rightarrow \psi)$$. This formula is indeed equivalent to φ because it states that for every x, if there is a y which satisfies Q'(x,y), then (something) holds, and furthermore, we know that there is such a y, because for every x', there is a y' which satisfies Q'(x',y'). Therefore φ follows from this formula. It is also easy to show that if the formula is false, then so is φ. Unfortunately, in general there is no such predicate Q'. However, this idea can be understood as a basis for the following proof of the Lemma.

Proof. Let φ be a formula of degree k+1; then we can write it as

 * $$\phi = (\forall x)(\exists y)(\forall u)(\exist v) (P) \psi$$

where (P) is the remainder of the prefix of $$\phi$$ (it is thus of degree k-1) and $$\psi$$ is the quantifier-free matrix of $$\phi$$. x, y, u and v denote here tuples of variables rather than single variables; e.g. $$(\forall x)$$ really stands for $$\forall x_1 \forall x_2 ... \forall x_n$$ where $$x_1 ... x_n$$ are some distinct variables.

Let now x' and y' be tuples of previously unused variables of the same length as x and y respectively, and let Q be a previously unused relation symbol which takes as many arguments as the sum of lengths of x and y; we consider the formula

 * $$\Phi = (\forall x')(\exists y') Q(x',y') \wedge (\forall x)(\forall y)( Q(x,y) \rightarrow (\forall u)(\exist v)(P)\psi )$$

Clearly, $$\Phi \rightarrow \phi$$ is provable.

Now since the string of quantifiers $$(\forall u)(\exists v)(P)$$ does not contain variables from x or y, the following equivalence is easily provable with the help of whatever formalism we're using:

 * $$( Q(x,y) \rightarrow (\forall u )(\exists v)(P) \psi) \equiv (\forall u)(\exists v)(P) ( Q(x,y) \rightarrow \psi )$$

And since these two formulas are equivalent, if we replace the first with the second inside Φ, we obtain the formula Φ' such that Φ≡Φ':

 * $$\Phi' = (\forall x')(\exist y') Q(x',y') \wedge (\forall x)(\forall y) (\forall u)(\exists v)(P) ( Q(x,y) \rightarrow \psi )$$

Now Φ' has the form $$(S)\rho \wedge (S')\rho'$$, where (S) and (S') are some quantifier strings, ρ and ρ' are quantifier-free, and, furthermore, no variable of (S) occurs in ρ' and no variable of (S') occurs in ρ. Under such conditions every formula of the form $$(T)(\rho \wedge \rho')$$, where (T) is a string of quantifiers containing all quantifiers in (S) and (S') interleaved among themselves in any fashion, but maintaining the relative order inside (S) and (S'), will be equivalent to the original formula Φ'(this is yet another basic result in first-order predicate calculus that we rely on). To wit, we form Ψ as follows:
 * $$\Psi = (\forall x')(\forall x)(\forall y) (\forall u)(\exists y')(\exists v)(P)Q(x',y') \wedge (Q(x,y) \rightarrow \psi )$$

and we have $$\Phi' \equiv \Psi$$.

Now $$\Psi$$ is a formula of degree k and therefore by assumption either refutable or satisfiable. If $$\Psi$$ is satisfiable in a structure M, then, considering $$\Psi \equiv \Phi' \equiv \Phi \wedge \Phi \rightarrow \phi$$, we see that $$\phi$$ is satisfiable as well. If $$\Psi$$ is refutable, then so is $$\Phi$$ which is equivalent to it; thus $$\neg \Phi$$ is provable. Now we can replace all occurrences of Q inside the provable formula $$\neg \Phi$$ by some other formula dependent on the same variables, and we will still get a provable formula. (This is yet another basic result of first-order predicate calculus. Depending on the particular formalism adopted for the calculus, it may be seen as a simple application of a "functional substitution" rule of inference, as in Gödel's paper, or it may be proved by considering the formal proof of $$\neg \Phi$$, replacing in it all occurrences of Q by some other formula with the same free variables, and noting that all logical axioms in the formal proof remain logical axioms after the substitution, and all rules of inference still apply in the same way.)

In this particular case, we replace Q(x',y') in $$\neg \Phi$$ with the formula $$(\forall u)(\exists v)(P)\psi(x,y|x',y')$$. Here (x,y|x',y') means that instead of ψ we are writing a different formula, in which x and y are replaced with x' and y'. Note that Q(x,y) is simply replaced by $$(\forall u)(\exists v)(P)\psi$$.

$$\neg \Phi$$ then becomes

 * $$\neg ( (\forall x')(\exists y') (\forall u)(\exists v)(P)\psi(x,y|x',y') \wedge (\forall x)(\forall y) ( (\forall u)(\exists v)(P)\psi \rightarrow (\forall u)(\exists v)(P) \psi ) )$$

and this formula is provable; since the part under negation and after the $$\wedge$$ sign is obviously provable, and the part under negation and before the $$\wedge$$ sign is obviously φ, just with x and y replaced by x' and y', we see that $$\neg \phi$$ is provable, and φ is refutable. We have proved that φ is either satisfiable or refutable, and this concludes the proof of the Lemma.

Notice that we could not have used $$(\forall u)(\exists v)(P)\psi(x,y|x',y')$$ instead of Q(x',y') from the beginning, because $$\Psi$$ would not have been a well-formed formula in that case. This is why we cannot naively use the argument appearing at the comment which precedes the proof.

Proving the theorem for formulas of degree 1
As shown by the Lemma above, we only need to prove our theorem for formulas φ in R of degree 1. φ cannot be of degree 0, since formulas in R have no free variables and don't use constant symbols. So the formula φ has the general form:

 * $$ (\forall x_1...x_k)(\exists y_1...y_m) \phi(x_1...x_k, y_1...y_m) $$

Now we define an ordering of the k-tuples of natural numbers as follows: $$ (x_1...x_k) < (y_1...y_k) $$ should hold if either $$ \Sigma_k (x_1...x_k) < \Sigma_k (y_1...y_k) $$, or $$ \Sigma_k (x_1...x_k) = \Sigma_k (y_1...y_k) $$, and $$ (x_1...x_k) $$ precedes $$ (y_1...y_k) $$ in lexicographic order. [Here $$ \Sigma_k (x_1...x_k) $$ denotes the sum of the terms of the tuple.] Denote the nth tuple in this order by $$ (a^n_1...a^n_k) $$.

Set the formula $$ B_n $$ as $$ \phi(z_{a^n_1}...z_{a^n_k}, z_{(n-1)m+2}, z_{(n-1)m+3}...z_{nm+1}) $$. Then put $$D_n$$ as
 * $$ (\exists z_1...z_{nm+1}) (B_1 \wedge B_2 ... \wedge B_n) $$

Lemma: For every n, $$ \phi \rightarrow D_n$$.

Proof: By induction on n; we have $$ D_k \equiv D_{k-1} \wedge (\exists z_1...z_{nm+1}) B_n \equiv D_{k-1} \wedge (\exists z_{a^n_1}...z_{a^n_k})(\exists y_1...y_m) \phi(z_{a^n_1}...z_{a^n_k}, y_1...y_m) $$, where the latter equivalence holds by variable substitution, since the ordering of the tuples is such that $$(\forall k)({a^n_1}...{a^n_k}) < (n-1)m + 2$$. Each conjunct here obviously follows from φ.

For the base case, $$ D_1 \equiv (\exists z_1...z_{m+1}) \phi(z_{a^1_1}...z_{a^1_k}, z_2, z_3...z_{m+1}) \equiv (\exists z_1...z_{m+1}) \phi(z_1...z_1, z_2, z_3...z_{m+1}) $$ is obviously a corollary of φ as well. So the Lemma is proven.

Now if $$ D_n $$ is refutable for some n, it follows that φ is refutable. On the other hand, suppose that $$ D_n $$ is not refutable for any n. Then for each n there is some way of assigning truth values to the distinct subpropositions $$E_h$$ (ordered by their first appearance in $$D_n$$; "distinct" here means either distinct predicates, or distinct bound variables) in $$ B_k $$, such that $$ B_k $$ will be true when each proposition is evaluated in this fashion. This follows from the completeness of the underlying propositional logic.

We will now show that there is such an assignment of truth values to $$E_h$$, so that all $$D_n$$ will be true: The $$E_h$$ appear in the same order in every $$ D_n $$; we will inductively define a general assignment to them by a sort of "majority vote": Since there are infinitely many assignments affecting $$E_1$$, either infinitely many make $$E_1$$ true, or infinitely many make it false and only finitely many make it true. In the former case, we choose $$E_1$$ to be true in general; in the latter we take it to be false in general. Then from the infinitely many n for which $$E_1 through E_{h-1}$$ are assigned the same truth value as in the general assignment, we pick a general assignment to $$E_h$$ in the same fashion.

This general assignment must lead to every one of the $$B_k$$ and $$D_k$$ being true, since if one of the $$B_k$$ were false under the general assignment, $$D_n$$ would also be false for every n > k. But this contradicts the fact that for the finite collection of general $$E_h$$ assignments appearing in $$D_k$$, there are infinitely many n where the assignment making $$D_n$$ true matches the general assignment.

Now from this general assignment which makes all of the $$D_k$$ true, we construct an interpretation of the language's predicates which makes φ true. The universe of the model will be the natural numbers. Each i-ary predicate $$\Psi$$ should be true of the naturals $$(u_1...u_i)$$ precisely when the proposition $$\Psi(z_{u_1}...z_{u_i})$$ is either true in the general assignment, or not assigned by it (because it never appears in any of the $$D_k$$).

In this model, each of the formulas $$ (\exists y_1...y_m) \phi(a^n_1...a^n_k, y_1...y_m) $$, is true by construction. But this implies that φ itself is true in the model, since the $$a^n$$ range over all possible k-tuples of natural numbers. So φ is satisfiable, and we are done.

Intuitive explanation
We may write each Bi as Φ(x1...xk,y1...ym) for some x-s which we may call "first arguments" and y-s which we may call "last arguments".

Take B1 for example. Its "last arguments" are z2,z3...zm+1, and for every possible combination of k of these variables there is some j so that they appear as "first arguments" in Bj. Thus for large enough n1, Dn 1 has the property that the "last arguments" of B1 appear, in every possible combinations of k of them, as "first arguments" in other Bj-s within Dn. For every Bi there is a Dn i with the corresponding property.

Therefore in a model which satisfies all the Dn-s, there are objects corresponding to z1, z2... and each combination of k of these appear as "first arguments" in some Bj, meaning that for every k of these objects zp 1 ...zp k there are zq 1 ...zq m which makes Φ(zp 1 ...zp k ,zq 1 ...zq m ) satisfied. By taking a submodel which contains only these z1, z2... objects, we have a model satisfying φ.

Gödel's incompleteness theorems
First Theorem: For any consistent formal, computably enumerable theory that proves basic arithmetical truths, an arithmetical statement that is true, but not provable in the theory, can be constructed. That is, any effectively generated theory capable of expressing elementary arithmetic cannot be both consistent and complete.

Second Theorem: For any formal recursively enumerable (i.e. effectively generated) theory T including basic arithmetical truths and also certain truths about formal provability, T includes a statement of its own consistency if and only if T is inconsistent.

Modern Proof
Assuming that a computer exists, and that formal logic can be represented as a computer program, it is easy to prove Gödel's incompleteness theorem from basic lemmas in computer science.

1. The Quine lemma—any computer program can include a subroutine that prints out the entire program's code. This allows any program to write itself into a string variable, or a large enough bigint.
 * proof: Let the printing subroutine be a standard quine, with additional data that contains all the rest of the code.

2. The Halting lemma: There does not exist a computer program PREDICT(P) which takes the code to program P and predicts whether P eventually halts.
 * proof: Write program SPITE, which prints itself into variable R, then calculates PREDICT(R). If the answer is R halts, Spite goes into an infinite loop. If the answer is R does not halt, SPITE halts. Since R is really SPITE in disguise, no matter what PREDICT says, the answer is wrong.

The incompleteness theorem: Suppose that an axiom system describes integers (or any other discrete structure), and that it has enough operations (addition and multiplication are sufficient) to describe the working of a computer. Then this system is either inconsistent or incomplete.

 * proof: Write DEDUCE to deduce all consequences of the axiom system. Let DEDUCE print its own code into the variable R, and search for the theorem R never halts, in the embedding of a computer inside the system. Only if DEDUCE finds this theorem does it halt.

 * If the axiom system proves that DEDUCE doesn't halt, it is inconsistent. If the system is consistent, DEDUCE doesn't halt and the axioms cannot prove it.

 * This argument doesn't explicitly demonstrate the incompleteness, because a consistent axiom system could still prove the $\omega$-inconsistent theorem that DEDUCE halts (even though it doesn't) without contradiction.

 * So write ROSSER: ROSSER prints its code into R, and searches deductions for either 1. R prints something out or 2. R never prints anything out. If it finds 1, it halts without printing anything. If it finds 2, It prints "Hello World!" to the screen and halts.

 * If the axiom system is consistent, it cannot prove either ROSSER eventually prints something nor the negation ROSSER does not print anything. So whatever its conclusions about DEDUCE, the axiom system is incomplete.

To prove the second incompleteness theorem, note that the consistency of the axioms proves that DEDUCE does not halt, so the axiom system cannot prove its own consistency.

title: Famous Theorems of Mathematics/Logic


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nh3/9...g5

= Two Knights Defence:Steinitz Variation =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nh3 g5

Statistics
Estimated next move likelihood d3 73%, Nc3 21%, c3 11%, g4 5%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Bd6

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Bd6

Statistics
Estimated next move likelihood d4 75%, f4 23%, Ng4 2%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Qd4

= Two Knights Defence = 10...Qd4

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Qd4

Estimated next move likelihood
f4 67%, Ng4 33%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Qc7

= Two Knights Defence = 10. Qc7

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Qc7

Estimated next move likelihood
d4 70%, f4 30%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Bd6/11. f4

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Bd6

Statistics
Estimated next move likelihood exf3 67%, Qc7 16%, O-O 16%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Bd6/11. d4

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Bd6

Statistics
Estimated next move likelihood exd3 78%, O-O 12% Qc7 10%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Bd6/11. d4/11...exd3

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Bd6 11 d4 exd3

Statistics
Estimated next move likelihood Nxd3 100%


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Bd6/11. d4/11...exd3/12. Nxd3

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Bd6 11 d4 exd3

Statistics
Estimated next move likelihood Qc7 84%, O-O 16%


text:
Talk:Sociological Theory/Conflict Theory

sociological theory


text:
Chess Opening Theory/1. e4/1...e5/2. Nf3/2...Nc6/3. Bc4/3...Nf6/4. Ng5/4...d5/5. exd5/5...Na5/6. Bb5/6...c6/7. dxc6/7...bxc6/8. Be2/8...h6/9. Nf3/9...e4/10. Ne5/10...Bd6/11. d4/11...exd3/12. Nxd3/12...Qc7

= Two Knights Defence =

Theory table
.
 * 1.e4 e5 2.Nf3 Nc6 3.Bc4 Nf6 4.Ng5 d5 5.exd5 Na5 6.Bb5+ c6 7. dxc6 bxc6 8. Be2 h6 9. Nf3 e4 10. Ne5 Bd6 11. d4 exd3 12. Nxd3

Statistics
Estimated next move likelihood b3 66%, h3 24%, f4 7%, O-O 3%


text:
User:WikiWizard~enwikibooks/monobook.js

// Install InstaView document.write(' '); InstaView.conf.user.name = 'Pilaf'; /* This is to keep track of who is using InstaView: User:Pilaf/instaview.js */ /************ OLD STUFF ************* // Live Preview customization, // edit this to your own liking. wpUserName  = 'WikiWizard';   // User name to display in signatures wpShowImages = true;     // Enable downloading and displaying of images // Include Live Preview... document.write(' '); // Now set everything up window.onload = Main; function Main { LivePreviewInstall; // You may include here other "extensions" }

title: User:WikiWizard~enwikibooks/monobook.js


text:
IB Mathematics SL/Calculus

Introduction
Calculus is considered by many as being one the harder chapters of the IB SL Maths curriculum.

General Equations
Average Rate of Change (AROC) between x=a and x=b in f(X)

Average Rate of Change = $$ \frac{f(a) - f(b)}{a-b}$$

Instantaneous Rate of Change (IROC) at x=a is the slope of the line tangent at x=a:

Instantaneous rate of Change =$$ \lim_{x \to a} \frac{f(x) - f(a)}{x-a}$$

Definition of the derivative f'(x) of a function f(x) (First principles of calculus):

$$f'(x) = \lim_{h \to 0} \frac{f(x+h) - f(x)}{h}$$

Basic Differentiation
The following formulas are shortcuts for finding the derivative

Derivative of a power function

$$f(x) = ax^n \,\!$$, $$f'(x) = anx^{n-1}\,\!$$

Derivative of exponential function

$$f(x) = e^x \,\!$$, $$f'(x) = e^{x}\,\!$$

Derivative of logarithmic function

$$f(x) = \ln x \,\!$$, $$f'(x) = \frac{1}{x} \,\!$$

Derivative of trigonometric functions

$$f(x) = \sin x \,\!$$, $$f'(x) = \cos x \,\!$$

$$f(x) = \cos x \,\!$$, $$f'(x) = -\sin x \,\!$$

$$f(x) = \tan x \,\!$$, $$f'(x) = \frac{1}{\cos^2 x} = \sec^2 x \,\!$$

Derivatives of sum of two functions

$$f(x) = g(x) + h(x)\,\!$$, $$f'(x) = g'(x) + h'(x)\,\!$$

Chain Rule

$$f(x) = g(h(x))\,\!$$, $$f'(x) = g'(h(x)) \cdot h'(x)\,\!$$

Product Rule

$$f(x) = uv \,\!$$, $$f'(x) = uv' + vu'\,\!$$

Quotient Rule

$$f(x) = \frac{u}{v} \,\!$$, $$f'(x) = \frac{vu'-uv'}{v^2}\,\!$$

Applications to the derivative
The derivative is the slope at one point in a function. The slope is the rate of change. Ergo, with the derivative you can determine the rate of change at a given point. Given a displacement graph, where time is represented by x and position is represented by y, the derivative of any point on any function graphed will say the rate of change at that position; this is known as the velocity. The derivative of a velocity graph shows the acceleration.

Introduction to Integrals
Integrals find the area under the curve and are also known as the anti-derivative. This means that if the integral of the derivative is found, the original equation will be given but with an arbitrary constant c. A documented method of integration is the use of u-substitution.

Basic Integration
Integration (from the Latin integer, meaning whole or entire) generally means combining parts so that they work together or form a whole. In information technology, there are several common usages:

1) Integration during product development is a process in which separately produced components or subsystems are combined and problems in their interactions are addressed.

2) Integration is an activity by companies that specialize in bringing different manufacturers' products together into a smoothly working system.

3) In marketing usage, products or components said to be integrated appear to meet one or more of the following conditions:

A) They share a common purpose or set of objectives. (This is the loosest form of integration.)

B) They all observe the same standard or set of standard protocol or they share a mediating capability, such the Object Request Broker (ORB) in the Common Object Request Broker Architecture (CORBA).

C) They were all designed together at the same time with a unifying purpose and/or architecture. (They may be sold as piece-parts but they were designed with the same larger objectives and/or architecture.)

D) They share some of the same programming code.

E) They share some special knowledge of code (such as a lower-level program interface) that may or may not be publicly available. (If not publicly available, companies have been known to sue to make it available in order to make competition fair.)

Rules of Integration
Integration of logarithmic functions

Integration of Exponential functions

Integration of Trigonometric functions

Area under a curve
Integration is primarily used to find the area under a curve.

Example

 * Let $$ f(x) = 2x^2 + 3 $$

 * Find the area under the curve from $$ x = 3 $$ to $$ x = 7 $$.

Solution:

 * $$ f(x) = 2x^2 + 3 $$

 * $$ A = \int_3^7 f(x) dx $$

 * $$ A = \int_3^7 (2x^2 + 3) dx $$

 * $$ A = \left [ \frac {2(7)^3} {3} \right] - \left [ \frac {2(3)^3} {3} \right ] $$

 * $$ A = \left [ \frac {686} {3} \right] - \left [ \frac {54} {3} \right ] $$

 * $$ A = \frac {632} {3} $$

Total Distance traveled

 * Distance traveled on a velocity over time function can be found by evaluating the definite integral from the initial time to the final time.

Example:

 * Let $$ v(t)= t^2 $$ units per second be the velocity over time function for motion of a particle.
 * Find the distance traveled by the particle from $$ t=2 $$ seconds to $$ t=5 $$  seconds.
 * Solution:
 * Solution:

 * $$ v(t) = t^2 $$ units

 * $$ t_{initial} = 2 $$ seconds

 * $$ t_{final} = 5 $$ seconds

 * $$ d = \int_2^5 v(t) dt $$ units

 * $$ d = \int_2^5 t^2 dt $$ units

 * $$ d = \left [ \frac {(5)^3} {3} \right ] - \left [ \frac {(2)^3} {3} \right ] $$ units

 * $$ d = \frac {125} {3} - \frac {8} {3} $$ units

 * $$ d = 39 $$ units

 * The particle traveled 39 units from 2 seconds to 5 seconds.

Solids of revolution

Picture a function, $$ f(x) $$. Now rotate it about an axis to make a solid. Integration can be used to find the volume of this solid.

The formula used is:

 * $$ V = \pi \int_a^b f(x) dx $$ where a is the left limit and b is the right limit.

Example
Let $$ f(x) = \frac {1} {x} $$. Find the volume of its solid of revolution from x = 2 to x = 4.

Solution

 * $$ f(x) = \frac {1} {x} $$

 * $$ a = 2 $$

 * $$ b = 4 $$

 * $$ V = \pi \int_a^b f(x) dx $$ cubic units

 * $$ V = \pi \int_2^4 \frac {1} {x} dx $$ cubic units

 * $$ V = \pi \left ( \left [ \ln 4 \right ] - \left [ \ln 2 \right ] \right ) $$ cubic units

 * $$ V = \pi \left ( \ln 4 - \ln 2 \right ) $$ cubic units

 * $$ V = \pi \left (0.69314718056 \right ) $$ cubic units

 * $$ V = 2.1775860903 $$ cubic units

 * $$ V = 2.178 $$ cubic units (The IB instructs candidates to round calculated answers to three decimal points)

title: IB Mathematics SL/Calculus


text: Template:Style/IPA

title: Template:Style/IPA


text:
Template:Style/yid

noinclude
     commons:template:style/yid ·

ar:قالب:Style/yid de:Vorlage:Style/yid eo:Ŝablono:Style/yid fr:Modèle:Style/yid he:תבנית:Style/yid is:Snið:Style/yid pl:Szablon:Style/yid ro:Format:Style/yid

title: Template:Style/yid


text:
User talk:Sammyt1122

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. Urbane  (Talk)   (Contributions)  15:37, 20 October 2007 (UTC)

title: User talk:Sammyt1122


text:
User talk:Strevellion

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. Urbane  (Talk)   (Contributions)  15:37, 20 October 2007 (UTC)

title: User talk:Strevellion


text:
User talk:DonkeyKong64

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. Urbane  (Talk)   (Contributions)  15:37, 20 October 2007 (UTC)

title: User talk:DonkeyKong64


text:
User talk:Teiluj98~enwikibooks

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. Urbane  (Talk)   (Contributions)  15:37, 20 October 2007 (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 Teiluj98. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Teiluj98~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:49, 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:35, 19 April 2015 (UTC)

title: User talk:Teiluj98~enwikibooks


text:
User talk:Srwalter

Come introduce yourself at the new users page. If you have any questions, you can ask there or contact me personally. Urbane  (Talk)   (Contributions)  15:37, 20 October 2007 (UTC)

title: User talk:Srwalter


text:
User talk:74.12.26.170

Your changes to the Muggles' Guide have been removed. Chazz (talk) 15:42, 20 October 2007 (UTC)
 * Revision: In light of JKR's recent interview. this is no longer considered vandalism; however, the changes have been left reverted. This is a children's book, comments regarding character's sexuality will be left in the "greater picture" section only. Chazz (talk) 18:12, 22 October 2007 (UTC)

title: User talk:74.12.26.170


text:
User talk:121.1.16.130

– Mike.lifeguard  | talk 15:59, 20 October 2007 (UTC)

title: User talk:121.1.16.130


text:
User talk:24.253.147.12

– Mike.lifeguard  | talk 16:00, 20 October 2007 (UTC)

title: User talk:24.253.147.12


text:
Programming with Moose/Syntax

A big problem with the CPAN docs thus far is they utilize (abuse) the fact that Moose is an application of. is Meta Object Protocol building framework - and that is usually about where the cryptic confusion sets in.. There is a very blurry distinction between  and Moose, because Moose is the only known application of.

Essentially what we have in  is an archive of hacks that allow Moose to be terse and non-pearlish. Moose makes a few of these hacks available with out much sugar but generally speaking candy coats them to a comfortable level.

In this syntax compendium of Moose we promise to never mention  again.

Table of Contents
Keywords exported with :
 * 1) has
 * 2) before, after, around
 * 3) blessed
 * 4) override
 * 5) augment
 * 6) extends
 * 7) with
 * 8) meta
 * 9) Other functions - Non-polluting fully-qualified syntax

title: Programming with Moose/Syntax