text:
Orthopaedic Surgery/Note To Authors

First of all, a warm welcome to Orthopaedic Surgery!

You can become one of the authors of this book simply by contributing useful content on Orthopaedic Surgery.

We are in the process of posting advice for authors in this page. Please feel free to add your own, if any.

Before you jump onto the bandwagon, there are a few places you could go visiting. To become an author of this module it is neither necessary nor essential to read through all the articles. But it is certainly recommended to do so in order to develop a proper perspective of the environment in which you are going to work and contribute.

The Wiki Process

 * Learn what a Wiki is.
 * What is Collaborative writing?
 * Read about Wikipedia and Wikibooks and visit Wikipedia and Wikibooks.
 * Who writes Wikipedia?
 * A little about GFDL.
 * Content in Wikibooks is free in both Free as in beer and Free as in speech ways. It is Open content
 * Before you rush in, read also about some criticism that the projects have faced.

The Starting Point
You have decided to be an author but do not know where to start off. Visit the Sandbox and experiment to your heartful. Learn about how to edit and how to start a new page. Visit the Community Portal and Reading room to interact with other contributors.

Basic Principles
Our advice over would be very simple. We borrow our principles from the foundation on which Wikipedia was based upon. The simplified ruleset of wikipedia is listed for those of you who are interested.

Read Jimbo Wales' principles to be clear about who is the last authority on all matters!!
 * BE BOLD! in editing and contributing.[[Image:be bold ortho.png|200px|right]]
 * Be civil to other users at all times. It is the hallmark of a successful collaborative process.
 * Neutral point of view (NPOV). This will help us in producing a book that is applicable and acceptable to most of us.
 * Verifiability. Articles that cite a reputable source are encouraged and should be the order of the day for a medical textbook.
 * Assume good faith. Consider other contributors to be thinking rational beings who are trying to contribute positively to building this book.
 * Respect copyright. No Plagiarism is permitted. If your contribution violates copyright then it will be mercilessly edited and possibly removed. In addition you must be comfortable with GFDL.
 * Decent edit summaries are essential for collaborating. If one has to respect the edit of another contributor, a logical reason for the edit makes things easy to understand.
 * No personal attacks are allowed on these pages. Instead explain in clear terms what someone did wrong. Avoid labelling people.
 * Be graceful: Be liberal in what you accept, be conservative in what you do. Be polite, solid and straightforward.
 * No original research, please.
 * Signing. It helps others to associate a name with a contribution.
 * Use the preview button; to prevent edit conflicts.
 * Discuss potential issues in the talk pages.
 * Ignore all rules. If rules are a hindrance, forget about them!!

Last but not the least, this must be foremost in the mind of any author or reader of this textbook. WIKIBOOKS DOES NOT GIVE MEDICAL ADVICE Also go through the General disclaimer

Our Principles
There are few issues to consider before you move ahead. Lets not call them rules ...but guidelines, so that even if we are not moving together, we are at least making progress in the same direction and towards one destination.

Goals

 * 1) To develop a Textbook of Orthopaedic Surgery.
 * 2) To continuously improvise on the contents and structure of this textbook.
 * 3) To make it readable and presentable to the intended audience.

Guidelines

 * 1) To start with all pages, new or old, must follow the new Naming policy of wikibooks. They must be in the format - Orthopaedic Surgery/New Page. Please avoid using The format Orthopaedic Surgery/Chapter Name/Page Name for two reasons. One it makes the Page name long and the other is because we have common topics in Orthopaedic Surgery. The former naming format allows us to list the same topic under numerous headings without any repeatations.
 * 2) Find a topic to write on. There is already a chapter layout and many topics listed. See if your topic fits into one of them. Don't worry if it does not! You can always create a new page and add it to the appropriate chapter.
 * 3) As far as possible cite references for your article. That will make it more authentic. Don't worry if you can't. Someone in the community will do it for you.
 * 4) Do not copy articles verbatim from elsewhere. Derive material from them if necessary. Explain issues in your own words. Don't worry if it doesn't sound too good. We will help you in improvising on the article.
 * 5) The top of every page carries two navigation headings. One carries links to the chapters and the other maintains the continuity between the pages on the book. Please do not remove them. If you create a new page please add them to the top by typing and note that you have to replace Chapter Name with the name of the chapter to which the page belongs:
 * 1) Add images, figures and tables as necessary. We want a colorful book not a dull and dry book. Please make sure that the images you add to the book are released or available under the GFDL licence.

title: Orthopaedic Surgery/Note To Authors


text:
Cookbook:Tabbouleh I

This tabbouleh is great as a salad, or as a meal in itself. Eat it with lots of falafel!

Ingredients

 * 1 cup (240 ml) bulgur wheat (medium grind)
 * ½ cup (120 ml) olive oil
 * ½ cup (120 ml) lemon juice
 * 1 tbsp salt
 * Ground black pepper
 * 1 bunch parsley (Italian or curly)
 * ½ green bell pepper (optional)
 * ½ red bell pepper (optional)
 * Sliced ripe olives (optional)
 * 1 dash of ground nutmeg (optional)
 * 2–3 ripe tomatoes (optionally peeled)

Procedure

 * 1) Cover the wheat in boiling water and let stand for 5 minutes; drain.
 * 2) Stir in lemon juice, oil, salt, and pepper to wheat. Refrigerate while the rest of the vegetables are being chopped.
 * 3) Core and finely chop the bell peppers.
 * 4) Remove the larger stems from the parsley and finely chop.
 * 5) Drop the tomatoes in boiling water for 20 seconds, then run under cold water, and the skins peel off easily.
 * 6) Quarter the tomatoes and discard seeds. Chop finely.
 * 7) Mix all vegetables along with olives and nutmeg into the wheat.
 * 8) Refrigerate at least 4 hours.

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

title: Cookbook:Tabbouleh I


text:
Orthopaedic Surgery/Upper Arm and Elbow

Fractures of the humerus are discussed in four groups, diaphyseal, proximal, distal and combined. All can be challenging to treat. Best results occur by means which achieve early motion while maintaining satisfactory alignment so that union can be reasonably expected while preserving functional motion at the shoulder and elbow. Tolerance for angular malalignment of the diaphyseal component of the fracture is more liberal than in the lower extremity for the obvious reason that malangulation in the lower extremity interferes with gait. Secondly the multiplanar range of motion of the shoulder and the elbow/forearm articulations affords ample opportunity for functional compensation for diaphyseal malangulations of as much as 30 degrees.

Beginning with the diaphyseal fracture, a parusal of abstracts over the last decade can easily yield a broad range of treatment options. As Osman puts it; "The indications for treatment should be eclectic"(Osman 1998). http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&dopt=Citation&list_uids=10855286

In this abstract the displacement of a diaphyseal fracture is sufficient indication for operative treatment. The choice between rod, flexible rod, and plate fixation is guided by the pattern and degree of comminution. Could this perhaps reflect a different tradition in Europe vs North America? Seemingly even within Europe there is wide latitude taken as to indications for surgery. Contrast this with the experience in Brug 1994. "Closed fractures without concomitant injuries can generally be managed conservatively." This seems closer to the North American standard if one could be said to exist, though there is no specific mention as to the criteria for an acceptable alignment. Furthermore the presence of a complete radial nerve palsy is taken as an indication to explore and internally fix the fracture, not generally taken as an indication for operative intervention in the US, with the caveat that some fracture patterns and perhaps, with disproportionate pain, or if the nerve goes out during splinting there is an indication to explore the radial nerve when it's function cannot be demonstrated. http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&dopt=Citation&list_uids=7855608

Consensus it seems is lacking with regard to the optimal treatment for diaphyseal humerus fractures. It appears that a given patient and surgeon will in many cases opt for operative treatment where previously the patient would be managed with a coaptation splint and an off-the-shelf abduction pillow brace followed within a week or so with a functional orthosis, and continued use of the abduction pillow as needed to control varus alignment. Operative intervention would be reserved for non-unions or special circumstances, including open fractures, polytrauma, floating elbow.

We can speculate as to the reasons for the wide variation in treatment decisions for an otherwise uncomplicated diaphyseal humerus fracture. The traditional assumption is that closed treatment should be used when there is a reasonable expectation of a successful outcome, so why then do we opt for surgery instead?

It is not that the results from the more conservative regimen have been found lacking, in any long term sense. Unions are generally achieved with satisfactory alignment and with preservation of motion at the shoulder and elbow. Indeed no bridge is really burned in the effort though the overall treatment course might arguably be prolonged if surgery is later required due to nonunion or inability to maintain a satisfactory reduction.

On the other hand, it does not necessarily reflect favorably on the quality of the care provided when the initial closed treatment pursued does not work out, especially when 6 weeks of gainful employment is lost and the patient has endured weeks of discomfort and lack of sleep as the fracture became a non-union. Increasingly it seems surgeons must consider this a negative reflection on their care.

title: Orthopaedic Surgery/Upper Arm and Elbow


text:
Cookbook:Cheese Puffs (Pão de Queijo)

| Brazilian Cuisine

Pães de queijo are Brazilian cheese puffs made of tapioca. They are similar to gougères and are typically served at breakfast or as a snack.

Ingredients

 * ⅔ cup (160 ml) milk
 * ⅓ cup (80 ml) neutral oil (e.g. vegetable oil)
 * 2 cups (450 g) fine cassava flour or tapioca flour
 * 6 ounces (170 g) grated hard cheese (a mix of cheddar and parmesan is good)
 * 2 eggs
 * Salt to taste
 * Pepper to taste

Procedure

 * 1) Mix the milk and oil together in a saucepan, and boil until a white foam appears.
 * 2) Gradually add flour to this hot mixture; mix well to form a firm dough with no lumps.
 * 3) Let the dough rest for 15 minutes.
 * 4) Preheat the oven to 375°F (190°C).
 * 5) Mix the eggs, cheese, salt, and pepper into the dough. The dough will become sticky and wet. If the dough is too wet, add more flour and cheese in order to make firmer balls (instead of cookies).
 * 6) Grease your hands, and form small balls 1–2 inches in diameter.
 * 7) Place the balls on a greased baking tray. Bake for 15–20 minutes, until the top begins to brown.
 * 8) Cool slightly.

Notes, tips, and variations

 * Ensure you use a fine flour, and not the coarser grain type of flour used to make farofa. This recipe should produce small cheesy bread rolls, so a finer flour consistency is required.
 * An egg substitute like Egg Beaters is fine.

title: Cookbook:Cheese Puffs (Pão de Queijo)


text:
User talk:Flaran

Gospel 101
This was the opening message to the other student, who eventually dropped out, but you got the system down right, and the same requirements would apply just for the record... Welcome to Gospel 101. We would hope for 6 students, so limit yourself to 10 verses at first on Verses for the week and see if something meaningful happens. That page is something of a misnomer, should be Verses for etenity. The test is, if something meaningful happens, rather subjective to say the least, but two students is better than one. The translation so far is based on literary word play in some ways, but I don't play with the WORD itself. Maybe, there should be prerequisites, your question should you wish to take it − What did Jesus call the well prepared scribe, this Greek term in English is now used by the IRS. - Athrash | T a l k 04:49, 15 February 2006 (UTC)

title: User talk:Flaran


text:
C Sharp Programming/Keywords/true

The keyword is a Boolean constant value. Therefore

would create an infinite loop.

/Keywords

title: C Sharp Programming/Keywords/true


text:
Java Programming/Keywords/final

is a keyword. Beware! It has distinct meanings depending whether it is used for a class, a method, or for a variable. It must be placed before the variable type or the method return type. It is recommended to place it after the access modifier and after the keyword.

For a variable
The  keyword only allows a single assignment for the variable. That is to say, once the variable has been assigned, its value is in read-only. If the variable is a primitive type, its value will no longer change. If it is an object, only its reference will no longer change. Keep in mind that its value can still be changed.

A final variable is often used for universal constants, such as pi:

The  keyword can also be used for method parameters:

It is useful for methods that use side effects to update some objects. Such methods modify the content of an object passed in parameter. The method caller will receive the object update. This will fail if the object parameter has been reassigned in the method. Another object will be updated instead. Final method parameter can also be used to keep the code clean.

The  keyword is similar to   in other languages and the   keyword in C#. A final variable cannot be.

For a class
The  keyword forbids the creation of a subclass. It is the case of the  or   class.

A final class cannot be. The  keyword is similar to   keyword in C#.

For a method
The  keyword forbids to overwrite the method in a subclass. It is useless if the class is already final and a private method is implicitly. A final method cannot be.

Interest
The  keyword is mostly used to guarantee a good usage of the code. For instance (non- ) methods, this allows the compiler to expand the method (similar to an inline function) if the method is small enough. Sometimes it is required to use it. For instance, a nested class can only access the members of the top-level class if they are final.
 * See also Access Modifiers.

title: Java Programming/Keywords/final


text:
Java Programming/Keywords/static

is a Java keyword. It can be applied to a field, a method or an inner class. A static field, method or class has a single instance for the whole class that defines it, even if there is no instance of this class in the program. For instance, a Java entry point has to be static. A static method cannot be. It must be placed before the variable type or the method return type. It is recommended to place it after the access modifier and before the keyword:

The static items can be called on an instantiated object or directly on the class:

Static methods cannot call nonstatic methods. The current object reference is also not available in static methods.

Interest

 * Static variables can be used as data sharing amongst objects of the same class. For example to implement a counter that stores the number of objects created at a given time can be defined as so:

The  variable is incremented each time an object is created.

Public static variable should not be used, as these become global variables that can be accessed from everywhere in the program. Global constants can be used, however. See below:

 * Static methods can be used for utility functions or for functions that do not belong to any particular object. For example:

 * See also Static methods

title: Java Programming/Keywords/static


text:
MATLAB Programming/Graphics

Plot
The plot command renders a 2D line in Cartesian coordinates.

Example:

Matlab also lets the user specify the line style. The following example generates the same graph as in the previous example, but plots the function with a specific line style: a black line with circle markers on each node:

To plot two or more graphs in one figure, simply append the second (x,y) pair to the first: The following example will plot y1 and y2 on the same x-axis in the output.

Polar Plot
Plots a function using θ and r(θ)

plot3
The "plot3" command is very helpful and makes it easy to see three-dimensional images. It follows the same syntax as the "plot" command. If you search the MATLAB help (not at the command prompt. Go to the HELP tab at the top of the main bar and then type plot3 in the search), you will find all the instruction you need.

Example:

This example plots a line in 3D. I created this code in an M-file. If you do the same, change the values and hit the run button in the menu bar to see the effect.

Mesh
Creates a 3D plot using vectors x and y, and a matrix z. If x is n elements long, and y is m elements long, z must be an m by n matrix.

Example:

Contour
Creates a 2D plot of a 3D projection, using vectors x and y, and a matrix z. If x is n elements long, and y is m elements long, z must be an m by n matrix.

Example:

Contourf
Same as contour, but fills color between contour lines

Surface
Basically the same as mesh

title: MATLAB Programming/Graphics


text:
Template:CC-self

pl:Szablon:CC-self

title: Template:CC-self


text:
MATLAB Programming/Control Flow

IF statement
An IF statement can be used to execute code when the logical test (expression) returns a true value (anything but 0). An "else" statement following an "if" statement is executed if the same expression is false (0).

Syntax: if expression statements elseif expression2 statements end

SWITCH statement
Switch statements are used to perform one of several possible sets of operations, depending on the value of a single variable. They are intended to replace nested "if" statements depending on the same variable, which can become very cumbersome. The syntax is as follows:

switch variable case value1 statements(1) case value2 statements(2) ...    otherwise statements end

The end is only necessary after the entire switch block, not after each case. If you terminate the switch statement and follow it with a "case" statement you will get an error saying the use of the "case" keyword is invalid. If this happens it is probably because you deleted a loop or an "if" statement but forgot to delete the "end" that went with it, thus leaving you with surplus "end"s. Thus MATLAB thinks you ended the switch statement before you intended to.

The otherwise keyword executes a certain block of code (often an error message) for any value of variable other than those specified by the "case" statements.

Programmers who are used to C style languages, often put break statements after each case. In C, C++, and Java, not putting a break statement allows the code to fall through in the code above, if value1 is true, then statements(1), statements(2), etc., will execute in C-style languages. However, in MATLAB only statements(1) will execute.

TRY/CATCH statement
The TRY/CATCH statement executes a certain block of code in the "try" block. If it fails with an error or a warning, the execution of this code is terminated, and the code in the "catch" block is executed rather than simply reporting an error to the screen and terminating the entire program. This is useful for debugging and also for filtering out erroneous calculations, like if you accidentally try to find the inverse of a singular matrix, when you don't wish to end the program entirely.

Syntax: try statements catch statements end

Note that unlike the other control flow statements, the TRY/CATCH block does not rely on any conditions. Therefore the code in the TRY block will always be at least partially executed. Not all of the TRY block code will always be executed, since execution of the TRY ends when an error occurs. In addition, the statements in the CATCH block will never be executed if the TRY block does not fail.

FOR statement
The FOR statement executes code a specified number of times using an iterator. Syntax: for iterator = startvalue:increment:endvalue statements end The iterator variable is initialized to startvalue and is increased by the amount in increment every time it goes through the loop, until it reaches the value endvalue. If increment is omitted, it is assumed to be 1, as in the following code:

for ii = 1:3 statements end

This would execute statements three times.

WHILE statement
The while statement executes code until a certain condition evaluates to false or zero. Example: while condition statements end

Forgetting to change the condition within a while loop is a common cause of infinite loops.

BREAK, CONTINUE, and RETURN
MATLAB includes the "break" and "continue" keywords to allow tighter loop control. The "break" keyword will cause the program to leave the loop it is currently in and continue from the next line after the loop ends, regardless of the loop's controlling conditions. If the code is in a nested loop it only breaks from the loop it's in, not all of them. The syntax is simply to write the word "break" within the loop where you desire it to break.

In contrast to "break", "continue" causes the program to return to the beginning of the loop it is presently in, and to recheck the condition to see if it should continue executing loop code or not. The code in the loop after the "continue" statement is not executed in the same pass.

If you want to exit a function entirely (as opposed to just a loop) before the last line of code, it is possible to do so using the "return" keyword. The value of any output variables is immediately returned to the calling function. As an example of how this works, consider the following function:

function output = controlTest(doWhat) switch doWhat case 1 output = -1; return; case 2 output = 3; end output = output + 4; end

Calling

>> output = controlTest(1)

would return output = -1, because output is defined to -1 and the return statement tells MATLAB to immediately take the current value of output and pass it back to the calling function. However, calling

>> output = controlTest(2)

would return output = 7, because output is initially defined as 3 and then 4 is added to it. Since the return statement is only executed in the case that doWhat=1, it is not called and the rest of the function executes.

Beware that if the output variables are not defined before calling the return statement, you will get an error, so use this with some degree of caution.

title: MATLAB Programming/Control Flow


text:
User talk:Nashife

Image:The Disturbed Tree by Bakenius.jpg
You haven't set license for this image. You should know that we don't accept "only for Wikibooks" or "only for educational purpose" permissions. You can find list of legitimate licenses at WB:ICT. --Derbeth talk 09:42, 15 February 2006 (UTC)

title: User talk:Nashife


text: Template:GPL

title: Template:GPL


text:
Talk:False Friends of the Slavist/Ukrainian

Proofreading Center
Some things still have to be done by speakers of Ukrainian. Please leave a note about what you are doing or have done in the following list of tasks.

Monolingual page
The monolingual page has to be proof-read by someone who knows Ukrainian well; please correct the mistakes you find and make a list of your corrections here, so that other people can use your list to correct the bilingual pages. While doing this, look if someone else has already listed mistakes they spotted on this talk page.
 * Starting to check the monolingual page. Eritain 05:34, 2 March 2006 (UTC)

Bilingual pages
The bilingual pages should be proof-read after the monolingual page is corrected, so that the mistakes spotted there can already be used. Please have a look at the talk pages of the bilingual pages, too, to see if someone else has already made comments about mistakes there.

 * Ukrainian-Russian (proof-read, see talk page)
 * Ukrainian-Belarusian (proof-read, see talk page)
 * Ukrainian-Polish (proof-read, see talk page)
 * Ukrainian-Kashubian (proof-read, see talk page)
 * Ukrainian-Upper Sorbian (proof-read, see talk page)
 * Ukrainian-Czech (proof-read, see talk page)
 * Ukrainian-Slovak (proof-read, see talk page)
 * Ukrainian-Slovenian (proof-read, see talk page)
 * Ukrainian-Croatian (proof-read, see talk page)
 * Ukrainian-Bosnian (proof-read, see talk page)
 * Ukrainian-Serbian (proof-read, see talk page)
 * Ukrainian-Macedonian (proof-read, see talk page)
 * Ukrainian-Bulgarian (proof-read, see talk page)

Maps
Someone should look through the semasiological maps of those words where there have been mistakes in the monolingual page and adapt them.

igorsova: It would be great if you could include word krajina (kraina, краjина, країна) not only word kraj.

Translations needed

 * The bilingual pages should have headings in the respective languages, in separate lines (i.e. with an empty line between them in the edit window) below the main heading. So we need the following Ukrainian translations:
 * " Ukrainian-Belarusian false friends " below (above the Belarusian heading, if it exists) at the head of the Ukrainian-Belarusian page.
 * " Ukrainian-Kashubian false friends " above (under the Kashubian heading, if it exists) at the head of the Ukrainian-Kashubian page.
 * " Ukrainian-Upper Sorbian false friends " above (under the Upper Sorbian heading, if it exists) at the head of the Ukrainian-Upper Sorbian page.
 * " Ukrainian-Czech false friends " above (under the Czech heading, if it exists) at the head of the Ukrainian-Czech page.
 * " Ukrainian-Slovak false friends " above (under the Slovak heading, if it exists) at the head of the Ukrainian-Slovak page.
 * " Ukrainian-Slovenian false friends " above (under the Slovenian heading, if it exists) at the head of the Ukrainian-Slovenian page.
 * " Ukrainian-Macedonian false friends " above (under the Macedonian heading, if it exists) at the head of the Ukrainian-Macedonian page.
 * " Ukrainian-Bulgarian false friends " above (under the Bulgarian heading, if it exists) at the head of the Ukrainian-Bulgarian page.

Багатир
I believe this word shares its meaning with the Russian word богатырь - at least I found багатирський as athletic in but I'm not sure about the other meaning. -Iopq 12:51, 19 June 2006 (UTC)
 * No, in Ukrainian it is about the man, who is very "багатий", that is "rich" --Pavlo Shevelo 18:32, 29 September 2006 (UTC)

Жінка
Чому тут слово "жінка" повторюється двічі?--94.178.191.135 (discuss) 15:14, 30 March 2011 (UTC)


text:
Haskell/Understanding arrows

Arrows, like monads, express computations that happen within a context. However, they are a more general abstraction than monads, and thus allow for contexts beyond what the  class makes possible. The essential difference between the abstractions can be summed up thus:

"Just as we think of a monadic type as representing a 'computation delivering an  '; so we think of an arrow type, (that is, the application of the parameterised type   to the two parameters   and  ) as representing 'a computation with input of type   delivering a  '; arrows make the dependence on input explicit."

- John Hughes

This chapter has two main parts. Firstly, we will consider the main ways in which arrow computations differ from those expressed by the functor classes we are used to, and also briefly present some of the core arrow-related type classes. Secondly, we will study the parser example used by John Hughes in the original presentation of arrows.

Arrows look a lot like functions
The first step towards understanding arrows is realising how similar they are to functions. Like, the type constructor of an   instance has kind  , that is, it takes two type arguments − unlike, say, a  , which takes only one. Crucially,  has   as a superclass. is, to put it very roughly, the class for things that can be composed like functions:

Functions have an instance of  − in fact, they are  s as well.

A practical consequence of this similarity is that you have to think in point-free terms when looking at expressions full of  operators, such as this example from the tutorial:

Otherwise you will quickly get lost looking for the values to apply things on. In any case, it is easy to get lost even if you look at such expressions in the right way. That's what  notation is all about: adding extra variable names and whitespace while making some operators implicit, so that   code gets easier to follow.

Before continuing, we should mention that also defines   and , which is very commonly used to compose arrows from left to right.

glides between and
In spite of the warning we gave just above, arrows can be compared to applicative functors and monads. The trick is making the functors look more like arrows, and not the opposite. That is, you should not compare  with   or  , but rather with:

 * , the type of static morphisms i.e. the values to the left of ; and
 * , the type of Kleisli morphisms i.e. the functions to the right of.

Morphisms are the sort of things that can have  instances, and indeed we could write instances of   for both static and Kleisli morphisms. This modest twisting is enough for a sensible comparison.

If this argument reminds you of the sliding scale of power discussion, in which we compared,   and  , that is a sign you are paying attention, as we are following exactly the same route. Back then, we remarked how the types of the morphisms limit how they can, or cannot, create effects. Monadic binds can induce near-arbitrary changes to the effects of a computation depending on the  values given to the Kleisli morphism, while the isolation between the functorial wrapper and the function arrow in static morphisms mean the effects in an applicative computation do not depend at all on the values within the functor.

What sets arrows apart from this point of view is that in  there is no such connection between the context   and a function arrow to determine so rigidly the range of possibilities. Both static and Kleisli morphisms can be made into s, and conversely an instance of   can be made as limited as an   one or as powerful as a   one. More interestingly, we can use  to take a third option and have both applicative-like static effects and monad-like dynamic effects in a single context, but kept separate from each other. Arrows make it possible to fine tune how effects are to be combined. That is the main thrust of the classic example of the arrow-based parser, which we will have a look at near the end of this chapter.

An can multitask
These are the  methods:

With these methods, we can carry out multiple computations at each step of what seems to be a linear chain of composed arrows. That is done by keeping values used in separate computations as elements of pairs in a (possibly nested) pair, and then using the pair-handling functions to reach each value when desired. That allows, for instance, saving intermediate values for later or using functions with multiple arguments conveniently.

Visualising may help understanding the data flow in an arrow computation. Here are illustrations of  and the five   methods:

It is worth mentioning that defines   as a do-nothing arrow. One of the arrow laws says  must be equivalent to the   from the   instance.

An can be resolute
If  makes multitasking possible,   forces a decision on what task to do.

provides a way to tag the values, so that different arrows can handle them depending on whether they are tagged with  or. Note that these methods involving  are entirely analogous to those involving pairs offered by.

An is just boring
As the name suggests,  makes it possible to apply arrows to values directly midway through an arrow computation. Ordinary s do not allow that − we can just compose them on and on and on. Application only happens right at the end, once a run-arrow function of some sort is used to get a plain function from the arrow.

(For instance,  for functions is   .)

, however, comes at a steep price. Building an arrow as a value within an arrow computation and then eliminating it through application implies allowing the values within the computation to affect the context. That sounds a lot like what monadic binds do. It turns out that an  is exactly equivalent to some   as long as the   laws are followed. The ultimate consequence is that  arrows cannot realise any of the interesting possibilities   allows but   doesn't, such as having a partly static context.

"The real flexibility with arrows comes with the ones that aren't monads, otherwise it's just a clunkier syntax."

- Philippa Cowderoy

Arrow combinators crop up in unexpected places
Functions are the trivial example of arrows, and so all of the  functions shown above can be used with them. For that reason, it is quite common to see arrow combinators being used in code that otherwise has nothing to do with arrows. Here is a summary of what they do with plain functions, alongside with combinators in other modules that can be used in the same way (in case you prefer the alternative names, or just prefer using simple modules for simple tasks).

The  module provides the   class, of which pairs and   are instances. A  is very much like a , except that there are two independent ways of mapping functions over it, corresponding to the   and   methods.

Avoiding leaks
Arrows were originally motivated by an efficient parser design found by Swierstra and Duponcheel. In order to have a reference point for discussing the benefits of their design, let's begin with a very quick look at how monadic parsers work.

Here is a really bare-bones illustration of a monadic parser type:

A  is a function that takes a stream of input (here, a list of type  ), and, depending on what it finds in the input, returns either a result (of type  ) and a stream (often, the input stream minus some of the input that is consumed by the parser), or. When we say a parser succeeded or failed, we refer to whether it produced a result. While real world parser types, such as  from Parsec, can be a lot more complex in order to provide various other features (notably, informative error messages upon failure), this simple   is good enough for our current purposes.

For instance, this is a parser for a single character in a string:

If the first character in the input string is,   succeeds, consuming the first character and giving   as a result; otherwise, it fails:

A second look at the  type shows it is essentially   over. As such, it is not surprising we can make it an instance of,  ,  , and so forth (you might want to give it a try). That gives us a very flexible set of combinators for building more complex parsers out of simpler ones. Parsers can be run in sequence...

... have their results combined...

... or be tried as alternatives to each other:

Through this last example, we can indicate which issue Swierstra and Duponcheel were trying to tackle. When  is run on the string , we can't detect the parser will fail until all of the three alternatives have failed. If we had more complex parsers in which one of the alternatives might fail only after attempting to consume a lot of the input stream, we would have to descend down the chain of parsers in the very same way. All of the input that can possibly be consumed by later parsers must be retained in memory in case one of them happens to be able to consume it. That can lead to much more space usage than you would naively expect − a situation often called a space leak.

Can it be done better?
Swierstra and Duponcheel (1996) noticed that, when dealing with some kinds of parsing tasks, a smarter parser could immediately fail upon seeing the very first character. For example, in the  parser above, the choice of first letter parsers was limited to letters ,   and  , for  ,   and   respectively. This smarter parser would also be able to garbage collect input sooner because it could look ahead to see if any other parsers might be able to consume the input, and drop input that could not be consumed. This new parser is a lot like the monadic parsers with the major difference that it exports static information. It's like a monad, but it also tells you what it can parse.

There's one major problem. This doesn't fit into the  interface. Monadic composition works with  functions, and functions alone. There's no way to attach static information. You have only one choice, throw in some input, and see if it passes or fails.

Back when this issue first arose, the monadic interface was being touted as a completely general purpose tool in the functional programming community, so finding that there was some particularly useful code that just couldn't fit into that interface was something of a setback. This is where arrows come in. John Hughes's Generalising monads to arrows proposed the arrows abstraction as new, more flexible tool.

Static and dynamic parsers
Let us examine Swierstra and Duponcheel's parser in greater detail, from the perspective of arrows as presented by Hughes. The parser has two components: a fast, static parser which tells us if the input is worth trying to parse; and a slow, dynamic parser which does the actual parsing work.

The static parser consists of a flag, which tells us if the parser can accept the empty input, and a list of possible starting characters. For example, the static parser for a single character would be as follows:

It does not accept the empty string and the list of possible starting characters consists only of.

The dynamic parser needs a little more dissecting. What we see is a function that goes from  to. It is useful to think in terms of sequencing two parsers: each parser consumes the result of the previous parser, along with the remaining bits of input stream , it does something with  to produce its own result  , consumes a bit of string and returns that. So, as an example of this in action, consider a dynamic parser, where the   represents a count of the characters parsed so far. The table below shows what would happen if we sequence a few of them together and set them loose on the string "cake" :

So the point here is that a dynamic parser has two jobs : it does something to the output of the previous parser (informally, ), and it consumes a bit of the input string, (informally,  ), hence the type. Now, in the case of a dynamic parser for a single character (type ), the first job is trivial. We ignore the output of the previous parser, return the character we have parsed and consume one character off the stream:

This might lead you to ask a few questions. For instance, what's the point of accepting the output of the previous parser if we're just going to ignore it? And shouldn't the dynamic parser be making sure that the current character off the stream matches the character to be parsed by testing ? The answer to the second question is no − and in fact, this is part of the point: the work is not necessary because the check would already have been performed by the static parser. Naturally, things are only so simple because we are testing just one character. If we were writing a parser for several characters in sequence we would need dynamic parsers that actually tested the second and further characters; and if we wanted to build an output string by chaining several parsers of characters then we would need the output of previous parsers.

Time to put both parsers together. Here is our S+D style parser for a single character:

In order to actually use the parser, we need a  function that runs the static tests and applies the dynamic parser to the input:

Note how  gives out a function with type   function, which is essentially the same as the monadic parser we demonstrated earlier on. Now we can use  much in the same way we used   back then. (The main difference is the  which we pass as a dummy argument. That makes sense here because   doesn't actually use the initial value of type  . With other parsers, though, that need not be the case.)

Bringing the arrow combinators in
With the preliminary bit of exposition done, we are now going to implement the Arrow class for, and by doing so, give you a glimpse of what makes arrows useful. So let's get started:

should convert an arbitrary function into a parsing arrow. In this case, we have to use "parse" in a very loose sense: the resulting arrow accepts the empty string, and only the empty string (its set of first characters is ). Its sole job is to take the output of the previous parsing arrow and do something with it. That being so, it does not consume any input.

Likewise, the  combinator is relatively straightforward. Given a parser, we want to produce a new parser that accepts a pair of inputs. The first component of the input, is what we actually want to parse. The second part passes through untouched:

We also have to supply the  instance. is entirely obvious, as  must hold:

On the other hand, the implementation of  requires a little more thought. We want to take two parsers, and return a combined parser incorporating the static and dynamic parsers of both arguments:

Combining the dynamic parsers is easy enough; we just do function composition. Putting the static parsers together requires a little bit of thought. First of all, the combined parser can only accept the empty string if both parsers do. Fair enough, now how about the starting symbols? Well, the parsers are supposed to be in a sequence, so the starting symbols of the second parser shouldn't really matter. If life were simple, the starting symbols of the combined parser would only be. Alas, life is not simple, because parsers could very well accept the empty input. If the first parser accepts the empty input, then we have to account for this possibility by accepting the starting symbols from both the first and the second parsers

So what do arrows buy us?
If you look back at our  type and blank out the static parser section, you might notice that this looks a lot like the arrow instances for functions.

There's the odd  variable out for the ride, which makes the definitions look a little strange, but the outline of e.g. the simple   functions is there. Actually, what you see here is roughly the arrow instance for the  monad/Kleisli morphism (let ,   and   actually be  ).

That's fine, but we could have easily done that with bind in classic monadic style, with  becoming just an odd helper function that could be easily written with a bit of pattern matching. But remember, our Parser type is not just the dynamic parser − it also contains the static parser.

This is not at all a function, it's just pushing around some data types, and it cannot be expressed in a monadic way. But the  interface can deal with just as well. And when we combine the two types, we get a two-for-one deal: the static parser data structure goes along for the ride along with the dynamic parser. The Arrow interface lets us transparently compose and manipulate the two parsers, static and dynamic, as a unit, which we can then run as a traditional, unified function.

Arrows in practice
Some examples of libraries using arrows:

 * Opaleye (library documentation), a library for SQL generation.
 * The Haskell XML Toolbox (project page and library documentation) uses arrows for processing XML. There is a Wiki page in the Haskell Wiki with a somewhat Gentle Introduction to HXT.
 * Netwire (library documentation) is a library for functional reactive programming (FRP). FRP is a functional paradigm for handling events and time-varying values, with use cases including user interfaces, simulations and games. Netwire has an arrow interface as well as an applicative one.
 * Yampa (Haskell Wiki page library documentation) is another arrow-based FRP library, and a predecessor to Netwire.
 * Hughes' arrow-style parsers were first described in his 2000 paper, but a usable implementation wasn't available until May 2005, when Einar Karttunen released PArrows.

Acknowledgements
This module uses text from An Introduction to Arrows by Shae Erisson, originally written for The Monad.Reader 4

title: Haskell/Understanding arrows


text:
Talk:Haskell/Understanding arrows

Ross Paterson
Ross Paterson has kindly given us permission to use material from the Haskell arrows page, as well as the parts of the GHC User's guide on arrows. But be careful! His Arrows and computation book chapter belongs to his publisher, so we'd better not use that. -- Kowey 11:40, 15 February 2006 (UTC)

Shae Erisson
In #haskell, Shae Erisson has helpfully given us permission to use material from the TMRWiki introduction to arrows. Thanks again, shapr! -- Kowey 14:50, 20 February 2006 (UTC)

 * The link is now dead. I only managed to find the original text with the Wayback Machine.--Duplode (discuss • contribs) 06:54, 15 July 2015 (UTC)

Parser nitpicking - is buggy
About the definition of  for arrow parsers: if  's dynamic component doesn't check whether the first character of input is correct, relying on that having been done by the static component, then, in case of , who's going to invoke the static component of the second character parser? The definition of  shown in the section certainly doesn't do it, which results in   accepting   followed by any character.

Either the contract for a parser should require that its dynamic component rejects all invalid input (i.e. is a validating parser), or  should invoke the static component of its right operand. --Alexey Feldgendler (talk) 15:53, 15 March 2009 (UTC)

 * You're probably right. In any case, the exact details are in the D&P paper.
 * -- apfeλmus 09:16, 16 March 2009 (UTC)

 * If I'm right, then the code in this article needs to be fixed. :-) --X-Man (talk) 19:22, 19 March 2009 (UTC)

 * Certainly. :-) I'd like to make sure, though. I'm not familiar with the details myself, could you have a look at the Swierstra and Duponchel's paper for a correct implementation?
 * -- apfeλmus 07:47, 21 March 2009 (UTC)

 * Looked at the paper (BTW, shouldn't it be referenced from the article?) and found the same problem in D&P's definition of  . In their notation,   will accept   followed by any character. I'm confused now. It's probably something obvious that I'm overlooking, but to me it looks like the paper contains the same glaring bug. --X-Man (talk) 04:53, 22 March 2009 (UTC)

 * I've had a look at the paper but it doesn't mention arrows at all, does it? IIRC, there was a successor paper that does, though. Could you dig it up and have a look?
 * In any case, the irony is that the parser combinators presented in the paper you mentioned are an instance of Haskell/Applicative Functors.
 * -- apfeλmus 20:53, 23 March 2009 (UTC)

 * Using arrows for parsers was John Hughes' idea. Duponcheel writes in his blog: One of John Hughes motivations for introducing the Arrow model in Haskell was a class of error correcting parsers (developed by Doaitse Swierstra and Luc Duponcheel) that could be modelled using Arrows, but not using Monads (cfr. afp-arrows). However, if there was a mistake in the original parser paper that didn't mention arrows, it could just as well have been carried over to later papers. To me it seems like the parsers in have a bug, even though they aren't expressed as arrows. What do you think about it? /me is in terrible need of one more sensible person to confirm I'm not delusional. --X-Man (talk) 10:49, 28 March 2009 (UTC)

 * I've had a closer look now. The main definition  for sequencing the dynamic parsers is on page 11 and it indeed does not check for errors. This can be used to produce a bug as you showed. In fact,   alone will never fail which would be a bug already. However, the choice combinator   does check for errors.
 * But note that the goal of the paper is to include automatic error correction and accepting any input would be the right behavior in this case. So, the important and different question is whether there is a bug in the final version of the parsers on page 16.
 * In other words, the point is that the definition of the dynamic parsers in the paper is quite different from the one in the wikibook. Even the version from page 11 includes an extra  argument which the wikibook version doesn't have. So, the two aren't really comparable.
 * But what to do for the wikibook? (See below)
 * -- apfeλmus 09:36, 2 April 2009 (UTC)

 * What to do?
 * The full D&P stuff is probably too complicated to be included here. Also, parsers are best viewed as applicative functors anyway. But describing one of the main motivation for arrows would be nice, so a dumbed-down version similar to the present one would be great to have. So, it would be best if someone could turn it into something that actually works.
 * -- apfeλmus 09:36, 2 April 2009 (UTC)

 * I believe there might be no bug. I'm revising the texts using Hughes' paper (Generalising Monads to Arrows) as a reference - the simplified parser used here actually comes from there. It boils down to:
 * If you have, and feed it  ,   is the second character, and so the static test of   is not supposed to be invoked.
 * The static tests are only actually carried out by the alternative/ combinators, and so even though there is no static test for characters beyond the first there would still be noticeable gains (i.e. potentially skipping a lot of alternatives).
 * Finally, and this is the part I'm not 100% sure of, it seems to be implied by both Hughes and S&D that the symbol parsers are really just meant to parse a single character. If you want to write a word parser you'd use a different char parser for any characters beyond the first − a parser with a dynamic part that actually does something.
 * So, what is to be done? Preliminarily, I don't think the exercises are helpful in their current form, so I am removing them. Also, the justification for why the dynamic parser must be changed into something more meaningful. I will try to certify that I'm actually making sense with this interpretation.
 * Duplode (discuss • contribs) 21:57, 15 July 2015 (UTC)

2015-07-15 reorganisation
The reorganisation of this chapter has finally begun. Last revision before it and the corresponding solutions page  .--Duplode (discuss • contribs) 01:48, 15 July 2015 (UTC)

First half (pocket guide)
The first half of the chapter was just rewritten - only the pretty pictures and part of the exercises remain. The old version had two issues: it relied on the problematic factory metaphor (a holdout from an old version of Understanding monads) and it focused too much on the machinery, offering very little insight on what is the point of. I tried to go in the opposite direction: a bird's eye overview, focusing on the key concepts. The pace faster than the usual for me, and that is intentional: operationally, arrows are different enough from monads etc. that you could easily write a dozen pages of introduction - and it wouldn't help readers at all. The obvious consequence is that Haskell/Arrow tutorial is even more important now. I will update the lead text of the tutorial to reflect that. There are still several missing things in the first half alone:

 * The lead of the deprecated Haskell/Arrows says "[arrows] allow notions of computation that may be partially static (independent of the input) or may take multiple inputs", paraphrasing a passage in Patterson's Arrows and Computations. While the discussion in the "Arrow glides" section covers the "partially static" part well enough, the text does not mention the "may take multiple inputs" bit. It might be good to squeeze that into the text in a meaningful way. (However, perhaps there is nothing mysterious about those "multiple inputs". Though I only read the relevant passages in Patterson's very quickly while writing this, the reference is to "map transformers" and data parallelism through arrow computations, and the instance given for it is quite ziplist-like).

 * It would be great to pick a concrete use case in an actual arrowised library and mention it en passant. (By the way, the examples section at the end also needs some cleanup.)

 * More exercises are desirable - ideally, some that tie in with the tutorial.

 * In "An Arrow can multitask", when talking about the tricks with pairs I wanted to draw parallels with currying/uncurrying/partial application, and also with the relation between the applicative and monoidal presentations of . I couldn't figure out how to do that without it being horribly confusing though.

 * More images would be good. I will try to make a diagram for that snippet of non-proc arrow code in the tutorial. Pretty pictures for the ArrowChoice combinators would be cool, though I guess they won't be in the same style of the existing ones.

 * Speaking of proc-notation, I have removed the section on it as it is covered well enough by the tutorial. Only a very complete and systematic presentation might be worth the trouble, and even then probably not.

I am now going to review the second part. It has a few problems of its own, but I don't think it needs a full rewrite. --Duplode (discuss • contribs) 04:16, 15 July 2015 (UTC)

Second half (S+D/Hughes parser)
Second part review done. I believe this chapter is now roughly on par with the rest of the book up to this point in terms of readability and consistency. Further improvements for the future include:

 * I didn't bother very much with copyediting and phrasing improvements in the second part.

 * We do not show the static parsers actually being used, except for a limp footnote after the implementation of  that I added as an afterthought. That will (hopefully) be solved soon: the issue is that showing that implies showing the   implementation, which implies having introduced   in the first part of the chapter, and I don't want to do that while there is not a discussion of   somewhere else. I plan to return here to fix that once the   issue is dealt with.

 * It would be good to have an exercise asking for a working parser for a range of characters, or even a word. That, however, would only become a sensible addition once  is covered (see item above). Also, the exercise would have to account the "possible bug" discussed a few threads above, which I worked around through the only reasonable guess I could think of (see the thread above for details).

 * We could also discuss the  example from the tutorial from a more conceptual point of view. For background reading,   is very close to the automaton example in Patterson's Arrows and computation.

--Duplode (discuss • contribs) 23:45, 15 July 2015 (UTC)

title: Talk:Haskell/Understanding arrows


text:
Talk:Programming:Haskell arrows/Kowey

I'm using the same pattern for monad transformers of using the talk page to jot down my notes as I attempt to understand arrows, digesting it and then regurgitating it on the module page. So the following shall be a mess. -- Kowey 12:58, 15 February 2006 (UTC)

So what?
What are they good for? What can they do easily that monads can't?

 * Ok, so from the JH paper, you can use it to avoid certain space and time leaks. The basic idea is to make certain decisions early on rather than waiting until the very end when you've done a bunch of useless work.
 * Parallel computation...

Parallelism idea
I was thinking maybe one angle of attack would be to present arrows as a means of representing computation that is done in parallel. I mean, when you've got a piece of monadic code like this x <- thingOne y <- thingTwo return $ x + y

...what's not so nice is that x and y are calculated in a sequence, which is not neccesarily what you really wanted to say. It seems from my hazy understanding of arrows so far is that what they buy you is further seperation of the sequence-plumbing so that you can write stuff which does not introduce any sequence contraints that you didn't really intend. But actually, I still don't have the slightest clue what I'm saying.

Stream processors ideas
Huh... maybe stream processors is the way to go. It seems easier to understand than the parsing stuff, and lends itself much more readily to pretty pictures. What I'm thinking is that each machine has two conveyor belts, an input belt and an output belt. Arrows give you a handy way to link machines together and do all sorts of routing stuff. Of course, I might be completely wrong here, but if I'm not, woohoo! Almost ready to write the tutorial! -- Kowey 20:02, 21 February 2006 (UTC)

 * Conveyor belts idea implemented. Now I need to understand some more arrow stuff before I can move on. -- Kowey 11:54, 22 February 2006 (UTC)

title: Talk:Programming:Haskell arrows/Kowey


text:
User:Jdoe000001

Hello Jdoe000001. just as an FYI: before undertaking massive deletions like the one you did here (http://en.wikibooks.org/wiki/EverQuest) please ask on the relevant discussion page. Else it's more like vandalism --Kajolus 13:05, 15 February 2006 (UTC)

title: User:Jdoe000001


text:
Water Resources Directory/USA/Culture

History

 * Development of Federal Water Supply Policy, in: Water Supply Handbook, U.S. Army Corps of Engineers, December 1998, page 1-1.

 * Water Resources Update, journal of the Universities Council on Water Resources, special millenium issue, 2000.

 * Historian's Office, Institute for Water Resources, U.S. Army Corps of Engineers.

Photography

 * U.S. Army Corps of Engineers - online photo library

title: Water Resources Directory/USA/Culture


text:
Arabic/Professions

 * An engineer
 * مُهَندِس/مُهَندِسَة mu-han-dis/a
 * A teacher
 * مُدَرِّس/مُدَرِّسة mu-dar-ris/a (مُعَلِّم/مُعَلِّمة mu'-al-lim/a)
 * A doctor (physician)
 * طَبيب/طَبيبة Ta-beeb/a
 * A writer
 * كاتِب/كاتِبة ka-tib/a
 * A lawyer
 * مُحامي/مُحامية mu-Haa-mee/a
 * An actor/actress
 * مُمَثِّل/مُمَثِّلة mu-math-thel/a
 * A minister
 * وَِزير/وَزيرة wa-zeer/a

title: Arabic/Professions


text:
Arabic/Directions

 * to the right
 * إلى اليَمين ila al-ya-meen

 * to the left
 * إلى اليَسار ila al-ya-saar

 * on the front
 * في المُقَدِّمَة fee al-mu-qad-di-ma

 * on the back
 * في المُؤَخِرَة fee al-mu'a-khi-ra

 * the north
 * الشَّمال   ash-sha-maal

 * the south
 * الجَنوب    al-ja-nuub

 * the east
 * الشَّرق    ash-sharq

 * the west
 * الغَرب    al-gharb

 * go! (imperative)
 * إذهب      ez-hab

 * turn! (imperative)
 * لف              leef

 * at
 * عند            a'and

 * before
 * قبل          qabal

 * after
 * بعد         ba'ad

 * next to
 * بجانب        bejanib

 * in front of
 * أمام       amam

 * between
 * بين         bain

 * meter
 * متر        meeter

title: Arabic/Directions


text:
Emergency Medicine/Acetaminophen

Drug  Acetamenophen  /  paracetamol

Potential complications of overdose   Liver failure, renal Failure

Metabolism of Paracetamol   Paracetamol is mainly metabolized in the liver by canjugation to either sulfate or glucuronide, and thereafter excreted by the kidneys. A small amount is oxidized in the CYP450-system, forming a toxic metabolite (N-acetyl-p-benzo-quinone imine (NAPQI)) which then is conjugated with glutathione and -no longer toxic- excreted by the kidneys.

Mechanism of poisoning Increased paracetamol metabolism depletes sulfate and glucuronide, so a larger amount of paracetamol is shunted to the cytochrome p450 system. There is not sufficient glutathione to take care of all of the formed NAPQI, which binds to liver cells and causes necrosis.

Management Blood paracetamol 4 hours post ingestion.Levels above 200 mg/litre need treatment in a normal person.In patients with altered liver function levels above 100 mg/litre need treatment.

Treatment N acetyl cysteine infusion or oral methionine. Acetyl cysteine will release glutathione which lowers the amount of free NAPQI in the liver.

title: Emergency Medicine/Acetaminophen


text:
Emergency Medicine/Troponin

Troponin Troponin is a muscle protein present in cardiac and skeletal muscle. Troponin is a complex of three proteins, troponin C, troponin T and troponin I. The complex is located on the thin filament of the sarcomere and is involved in the regulation of muscle contraction.  Cardiac troponins Cardiac isoforms exist of troponin T and troponin I. Antibodies have been raised against these cardiac isoforms. The presence of a rised cardiac troponin in serum or plasma indicates cardiac cellular damage.

title: Emergency Medicine/Troponin


text:
Cryptography/Database protection

Cryptographic protection of databases, mailinglists, memberslists.

There are many cryptographic techniques associated with databases:

 * anonymizing / aggregating / depersonalizing data, so people can get summary statistics of data without associating particular items with any one person
 * column-level encryption, with a different encryption key for each column
 * Format-preserving encryption
 * data comparison

 * transparent data encryption
 * etc.

Often databases are protected by ../full-disk encryption/, which is described in a different chapter of this book.

The shadow password file could be considered a "database" of password hash digests. Password handling is discussed in detail in another chapter of this book, ../Secure Passwords/.

data comparison
Often we want to tell someone *not* to use some piece of data. But we would rather not tell people the specific details.

For example, We often want to implement "password reset", so if someone forgets the password associated with their account on our website, they can request a password reset and then click a "password reset" link sent to their email address. We want to only allow that person to reset their own password; we certainly don't want some other person (using some other email address) to reset the password for that account. But some people say GDPR frowns on us storing everyone's email address in plaintext (in case the server backup files are stolen). One proposed approach is to store a salted and hashed email (HEM), so that when a user hits the "forgot password" button, the user can punch in an email address (which the system never stores to disk), which the system compares to the stored HEM, and only if they are the same does the system send the password reset link to that email address.

For example, we want people to know if their particular password has been revealed in a public data breach, but we don't want to make it easy for malicious people to harvest those passwords.

For example, we want to tell email marketers not to send any email to anyone on the "do not email" registry, but we don't want to make it even easier for spammers to send spam email to everyone on the "do not email" registry. One proposed approach is to avoid ever storing such email addresses directly or even in encrypted form, but instead using a one-way-hash on each submitted email address and storing only the output hash values in the database.

A variety of data masking policies have been proposed for email addresses.

Gravatar uses hashed email addresses.

Simply hashing an email address by itself generates the same hash value every time. Some people propose adding "salt" or "pepper" or both to email addresses before hashing them, so that hashed addresses in one database cannot be matched to hashed addresses (using a different salt or a different pepper or both) in some other database.

Row-level encryption
A straightforward protection scheme: One-way hash function with symmetric encryption.

1. Use a one-way hash function on the (plaintext of) the index field to create the encryption key for one row.

2. Use the encryption key for one row from step 1 as the cipher key to encrypt every data field in that row. All fields are stored encrypted, even the index field.

Symmetric encryption algorithim — the same cipher key is used to encrypt and decrypt data

Searching the database
Look for the hashed value in the index field of the database and for each matching entry decrypt the data fields using the index field as the cipher key.

Example in php code
Some very easy php pseudocode to protect your data by encrypting your databases with a one-way hash and blowfish symmetric encryption.

Using a one-way hash and blowfish symmetric encryption. 1. Insert a record of John Doe in an encrypted database. 2. Get the encrypted record of user John Doe and decrypt the data.

Insert a record of John Doe in an encrypted database.
setKey( $cipher_key );

// crypt_blowfish symmetric encryption to encrypt the data $aRecord['email']      = $bf->encrypt( $aRecord['email'] ); $aRecord['name']       = $bf->encrypt( $aRecord['name'] ); $aRecord['creditnr']   = $bf->encrypt( $aRecord['creditnr'] );

$result = sqlInsert( $aRecord ) ; ?>

Get the encrypted record of user John Doe and decrypt the data.
setKey( $cipher_key );

// crypt_blowfish symmetric encryption to ecrypt the primary key for a sql select $select_key = $bf->encrypt( $primary_key ) ;

$aRecord = sqlSelectWithPKEY( $select_key );

// crypt_blowfish symmetric encryption to decrypt the data $aRecord['email']      = $bf->decrypt( $aRecord['email'] ); $aRecord['name']       = $bf->decrypt( $aRecord['name'] ); $aRecord['creditnr']   = $bf->decrypt( $aRecord['creditnr'] ); ?>

title: Cryptography/Database protection


text:
Greek Mythology

Greek Mythology is among the most famous and well known of the Ancient Mythologies. It stretches back millennia and has intrigued man with its fantastical stories and unusual beasts. This book will serve as a detailed reference to all things in Greek Mythology, including a bestiary of Greek mythological creatures such as the centaur and nymph and a collection of Greek stories.

Introduction

 * /Introduction/
 * /A Brief History/
 * /Sources/
 * /Theoretical Issues/
 * /How And When To Contribute/
 * /Contributors/
 * /Requests/

Gods and goddesses

 * Family Tree of the Gods

The Olympians

 * Aphrodite
 * Apollo
 * Ares
 * Artemis
 * Athena
 * Demeter
 * Dionysus
 * Hephæstus
 * Hera
 * Hermes
 * Poseidon
 * Zeus

The Titans

 * Kronos
 * Oceanus
 * Hyperion
 * Iapetus
 * Crius
 * Coeus
 * Tethys
 * Mnemosyne
 * Themis
 * Rhea
 * Phoebe
 * Theia

Descendants of the Titans

 * Prometheus
 * Epimetheus
 * Enceladus
 * Atlas
 * The Seasons
 * Metis
 * Muses
 * Eos
 * Helios
 * Selene
 * Leto

Protogenoi (First Born Gods)

 * Gaia
 * Ourea
 * Pontus
 * Thalassa
 * Uranus

Major Gods

 * Helios

Minor Gods

 * Erinyes
 * Moirae (Fates)
 * Charites (Graces)
 * Muses

Theoi Ouranioi (Sky & Weather Gods)

 * Anemoi (Wind Gods)

Theoi Halioi (Sea Gods)

 * Nureus
 * Palaemon
 * Triton

Primeval Gods

 * Phorcys

Chthonian Gods

 * Hades
 * Hecate
 * Hypnos
 * Persephone

Theoi Nomioi (Countryside Gods)

 * Pan

Theoi Georgikoi (Agricultural Gods)

 * Horae

Regular Beasts

 * Cerberus
 * Charybdis
 * Chimaera
 * Cyclops
 * Brontes
 * Steropes
 * Arges
 * Polyphemus
 * Giants
 * Graeae
 * Gorgons
 * Medusa
 * Hesperides
 * Hydra
 * Minotaur
 * Pegasus
 * Phœnix
 * Scylla
 * Sphinx (Greek Σφινξ)

Primeval Beasts

 * Ceto
 * Typhon

Heroes

 * Perseus (Greek: Περσεύς)
 * Theseus (Greek Θησεύς)
 * Heracles
 * Bellerophon
 * Oedipus
 * Jason (Greek: Ιάσων)
 * Achilles
 * Odysseus

Myths and Legends

 * The Creation
 * Labours Of Heracles
 * The Minotaur
 * The Sphinx
 * Perseus and Medusa
 * Voyage of the Argo
 * Calydonian Boar Hunt
 * Seven against Thebes
 * Trojan War
 * The Titanomachy

Mitologi Yunani

Griekse mythologie

title: Greek Mythology


text:
Greek Mythology/Beasts/Gorgons

The Gorgons (singular Gorgon) were three devilish sisters with snakes instead of hair. Their names were Euryale, loosely translated as far-goer, Sthenno, literally translated as forceful and the most famous, Medusa, which translates solidly as female ruler. They were all immortal except for the latter (Medusa), who was killed by Perseus with a sickle.

Origin
The Gorgons were the daughters of Phorcys, a primitive Greek sea god, and Ceto, a hideous monster of the oceans. They (Gorgons) and their siblings were known collectively as the Phorcydes, along with the Graeae, the Hespirides, the Scylla and Charybdis. They were originally normal women, until Medusa was raped by Poseidon in a temple of Athena, who then turned her and her sisters into the repugnant beings they came to be.

Appearance
The popular depiction of the Gorgons is with green skin, sometimes scaly, green eyes and their hair as aforementioned consists of live snakes and their hands made of a shiny metal such as brass. They are also sometimes shown as having beards and tusks, like that of swine. Gorgons are usually drawn with a protruding tongue and wings. They have snakes for hair and long talons, with slit eyes. They have long tails and sharp teeth wet with blood from their enemies

Abilities
Gorgons are best known for their ability to turn anyone who looks them in the eye into stone,and putting their statues in front of their cave as a warning

Fate
Although Eurydale and Sthenno were immortal, Medusa was not, and she was killed by Perseus(She was immortal but though immortal things according to Greek mythology were able to get pain when she saw her own reflection her immortality went away by her fear and Perseus was able to kill her in that time being) who used a shield to stop her from turning him into stone. Once she was dead, from her mane sprang Pegasus and Chrysaor

title: Greek Mythology/Beasts/Gorgons


text:
Greek Mythology/Contributors

Please add your name here if you wish to become a main contributor in the following template. Also please try and link to your contributions.

*Signature/Stamp + Your contributions* so par exemplar

--Kyriakos 21:10, 15 February 2006 (UTC) + Started the book, contents, Gorgons, Cyclops.

Sign below:

 * Lnhammer 20:55, 23 February 2006 (UTC) + Muses
 * Trooper209 22:08, 23 February 2006 (PST) + Zeus, Artemis, Athena
 * Hedwig0407 03 August 2003 + None at the moment but I will starting make contributions.
 * Webjunkie 13:53, 6 August 2006 (UTC) Odysseus - didn't add it, but, started it.
 * MKnock 10:34, 8 April 2007 (EST) + Aphrodite, Prometheus, Atlas, Graeae, Scylla, Charybdis, Pegasus, Medusa
 * Nymah 15:37, 7 December 2007 Minotaur
 * Vampirism44 (talk) 00:16, 26 March 2009 (UTC) + Phorcys, Ceto, Improved The Creation Story, created the pages The Sphinx, Giants

title: Greek Mythology/Contributors


text:
Greek Mythology/How And When To Contribute

Requests
Anything in bold in this Wikibook means an article is requested. Rather than clutter up the contents too much, they are requested under their appropriate sections. Once they have been at least started, please add them to the appropriate section in the contents. If there is no fitting section, create one, but keep it very broad. To request an article, add it in the Requests section.


text:
User talk:68.58.162.139

Please stop adding nonsense to Wikibooks. It is considered vandalism. If you would like to experiment, use the sandbox. Thank you.

title: User talk:68.58.162.139


text:
Educational Technology Innovation and Impact

Contents

 * /Why use Technology in Education/
 * /Multimedia Courseware/
 * /Classroom Technology/
 * /Virtual Learning Environments/ (VLEs)
 * /Blogs, Wikis and Online Interaction/
 * /Assistive Technologies/
 * /Computer Assisted Assessment/
 * /Mobile Learning/
 * /Simulation/
 * /Edutainment/


text:
User:AtionSong

 * Wikipedia

title: User:AtionSong


text:
Improvisational Acting

Improvisational Acting is acting spontaneously without a script, either for fun or out of necessity. It is often used for comic effect in theater. It can also be used to cover for missing/forgotten lines or just to add more creativity (if the director and the situation permit). It is a good way to extend and deepen the interpretation of a character and is generally useful for any acting situation, even for stand-up comics as a way to engage the public.

Beginning Improv

 * The Rules of Improv
 * Improv Games for Beginners
 * The Rules of Improv with music

La Improvisación

title: Improvisational Acting


text:
Educational Technology Innovation and Impact/Multimedia Courseware

 * Using Online Demonstrations for Education
 * Using Animations for Education
 * Using Wireless Networking for Education
 * Using PDA's in Education
 * Using audio/media players in Education
 * Using Electronic Paper for Education
 * Using Educational Learning Object Repositories
 * Using Laptops for Education


text:
Educational Technology Innovation and Impact/Why use Technology in Education

This section will introduce some theories about learning and how they relate to technology.

 * Behaviourism
 * Cognitivism
 * Constructivism
 * Active Learning Theory
 * Visual Learners
 * Auditory Learners
 * Multiple Intelligences
 * Tactile-Kinesthetic Learners
 * Linguistic Intelligence
 * Logical-Mathematical Intelligence
 * Spatial Intelligence
 * Bodily Kinesthetic Intelligence
 * Musical Intelligence
 * Interpersonal Intelligence
 * Intrapersonal Intelligence
 * Naturalist Intelligence


text:
Geometry/Chapter 20

Some right triangles are particularly easy to solve; they are known as special right triangles. There are two kinds: 45-45-90 triangles and 30-60-90 triangles, named by their angles in degrees. All the triangles in each group are similar to each other.

Section 20.1 - 45-45-90 Triangles
45-45-90 triangles are the only triangles that are both isosceles and right. Their legs are of the same length, and their hypotenuse is the square root of two times the length of a leg. For example, if ABC is an isosceles right triangle with A being the right angle and AB having length 3, then AC also has length 3 and BC has length 3*sqrt(2), or 4.242... The relationship can easily be found by the Pythagorean theorem: 1^2+1^2=2, because a^2+b^2=c^2. Drawing the altitude to the hypotenuse of an isosceles right triangle splits into two smaller isosceles right triangles, each similar to the original with a side length ratio of sqrt(2).

Section 20.2 - 30-60-90 Triangles
30-60-90 triangles have a different length ratio--1:square root of three:2. This is confirmed by the Pythagorean theorem as well: 1^2+3=2^2. Clearly, the smallest side is opposite the smallest angle, so for example, in triangle ABC, with angles A, B, and C having measure 30, 60, and 90 degrees respectively and AB having length 1, BC will have length 1/2 and AC will have length sqrt(3)/2, or 0.866...

Of course, these triangles could be solved by trigonometry, but these ratios provide a shortcut. In fact, they help us remember the most important trigonometric values in the 0-to-90 degree range: sin(0)=0  sin(30)=1/2        sin(45)=sqrt(2)/2, or 1/sqrt(2)  sin(60)=sqrt(3)/2   sin(90)=1 cos(0)=1  cos(30)=sqrt(3)/2  cos(45)=sqrt(2)/2, or 1/sqrt(2)  cos(60)=1/2         cos(90)=0 tan(0)=0  tan(30)=sqrt(3)/3  tan(45)=1                        tan(60)=sqrt(3)     tan(90) is not defined.

Note that sine divided by cosine equals tangent, and also that sin(90-x)=cos x, cos(90-x)=sin x, and tan(90-x)=1/tan x.

Exercises

 * 1. A triangle ABC is right and has AB=BC=5.
 * Find AC and the angle measures.

 * 2. A triangle XYZ has X=30 degrees, Y=90 degrees, and XY=6 meters.
 * Find the measure of Z and the lengths of XZ and YZ.

 * 3. A right-triangular yard is to be fenced off behind a house 10 meters across. The house is to be the hypotenuse of the yard, and one of the fence-to-house angles is to be twice as large as the other.
 * Find the amount of fence needed.

title: Geometry/Chapter 20


text:
Introduction to Physical Science/2.2

=Density= Density is possibly one of the most useful properties when studying matter. Each substance has a unique density. Density is determined by using the "density formula". The density formula is as follows: D=M/V or Density equals Mass over (divided by) Volume. Density is the amount of matter that can be placed in one cm3 of space. The following section discusses the uses of density and the density formula.

Using the Formula
The variables of the density formula can be rearranged to solve the equation for different measurements. The density formula is capable of solving for Mass when Density and Volume are known, Volume when Density, and Mass are known, and Density when Mass and Volume are known.
 * D=M/V (Density equals Mass over Volume)
 * M=VxD (Mass equals Volume times Density)
 * V=M/D (Volume equals Mass over Density)

As a property
All substances have different densities although two densities may be similar and even undetectably different by some instruments, all densities are different because in each substance, the atoms are packed together in a different way. Solids are the most dense, because their atoms are packed closest together. Liquids are less dense then solids, and gasses are the least dense.

=Vocabulary and Questions=
 * Density is a measurement of the amount of a substance that can fit into one cubic centimeter of space
 * Density Formula D=M/V: Density equals mass over volume
 * Variables are placeholders in an equation that represent a number that is not yet known

Covering the Reading

 * 1) If copper has a density of 8.96 g/cm3 how much mass would a piece with a volume of 34cm3 have?
 * 2) If a material has a mass of 52.457 g and a volume of 13.5cm3, then what is the density of the material?

Critical Thinking

 * 1) Are there any other variables that the density formula can be rearranged to solve? why or why not?

title: Introduction to Physical Science/2.2


text:
Introduction to Library and Information Science/Technology and Libraries: Impacts and Implications

Technology and LIS: a historical perspective
In his prophetic 1945 article As We May Think, Vannevar Bush envisioned a machine called a memex, a collective memory machine that would make knowledge more accessible. The author begins his argument by discussing the growing amount of information in the world. The increasing amount and complexity of information along with the time gap between creation and dissemination requires a new technology. Bush's technology would focus on greater usability in information retrieval, allowing users to create their own "sort of mechanized private file and library". Through the miniaturization of data using photocells or microfilm, great amounts of information could be stored in very little space. Traditionally information is stored in index or hierarchical form, but this is not how the brain stores information. The memex would arrange things associatively, mimicking the way the human brain stores and contextualizes information.

This memex is remarkably similar to a modern day computer, in that it would be a new technology designed for personal use that would allow for the creation, storage, and organization of different materials and data. This is a fascinating article as it explains how the need of a new way to store, organize and retrieve increasing amounts of data led to the idea of modern day computers. It is a particularly interesting article in the modern context, where information and data continue to expand at an exponential rate. What new technologies and changes in data organization will the future hold? How will libraries adapt to these changes?

Technology began to transform libraries in the 1950s with microfilm and in the mid-1960s with the Xerox machine. Computerized databases were developed in the 1970s and offered more information and better ways to search and obtain it. Networks such as OCLC and RLIN made it easier to share resources. Although this article predates widespread use of the Internet, it is correct in predicting that technology will continue to change the future of libraries. Technology has allowed greater access to information for more people, but it was too early for the author to accurately predict the digital divide. He argues that libraries must innovate to stay alive and that change is happening so quickly that it often appears "chaotic." The World Wide Web, however, is often described as chaotic, unorganized, and confusing, but its benefits greatly outweigh its risks. Because new technology often helps libraries keep people connected to information, libraries must strive to make sense out of the technological chaos. The author makes a strong case for businesses’ need to compete but states that libraries’ structure and rules "inhibit us from making the kind of innovation that is needed to compete and survive." The challenge, he concludes, is not in introducing new technology but in creating new management structures for libraries. This plan seems to push libraries toward behaving like businesses, but I think this would restrict access and introduce new economic, cultural, and political problems.

Implementing information technologies in libraries
According to John Bushman, the implementation of information technology requires librarians to ask two basic questions:
 * Why is the technology good for libraries, librarians, or the public?
 * Where will the technology lead us?

It is the librarian's duty to ask these questions and become involved in finding the answers. All technological advances need to be approached critically, with the knowledge that they may have both social and political consequences. Librarians need to be able to evaluate technologies to determine whether a given technology will harm or help the library and its community. Funding, getting the public involved with the change in technology, getting them to deal with the positive and negative effects of change, and making sure the librarians are able to handle the pressures are all ways of becoming involved with finding the answers about information technology and the future of libraries.

Digital libraries
The Digital Library Federation looked at what it sees as the major issues regarding digital libraries in the future. These are the five challenges the organization have outlined: architectural and systems in libraries, standards and practices, collection development, how communities will use a digital library, and long-term access to digital libraries. In terms of designing and implementing new technology, information sharing about new technology is vital because few employees in libraries actually manage technological change. Libraries need to have a plan so adopting technology and training employees and users is a smooth transition. The library is simultaneously a consumer and supplier of information and needs to have standards to critique itself. Issues involved in collection development include costs, copyright and licensing, all facets of computerizing, support services, and the impact on the rest of the library. How information is presented online can determine whether and to what extent it is used by the public. The sources of digital information are coming from all kinds of places and shared resources can help defray costs. Making the decision about what information to digitize and anticipating the costs of preserving the information is the last of these challenges.

The digital library service environment is defined as a network online information space in which users can discover, locate, acquire access to, and increasingly use information. There is no distinction about the information format. The identity of a digital library is the way the library discloses, provides access to, and supports the use of its increasingly virtual collection. Managing, administering, monitoring and ensuring fair use of its collection are a part of the mix, as well as keeping up with new technologies to support education and cultural engagement so that the library can evolve and sustain itself. The prospect of a completely virtual library still seems in the future, but we seem headed in that direction.

The National Digital Library Program was created by the Library of Congress so libraries, schools and homes will have access to original documents of American history and culture. The goal by the year 2000 was to digitize over 5 million items. The challenge is selecting from over 110 million items and converting to a technological format that will last. Some funding is coming from private donations. The article is descriptive, informative, but at the same time unclear about how the selection of information to be digitized was made. The Library of Congress is a leading repository of information. Is their selection of information for this digitizing project representative of the body of knowledge that Americans and world scholars can look to understand what has shaped American history? Should we be questioning whether American history is more important than other cultures that have been influential in world history? For instance, the book, In Search of the Cradle of Civilization, (Frawley, et al) places east Indian settlements earlier than Sumerian, Mesopotamian, and Babylonian societies. India, the largest democracy in the world today, has been ignored by the rest of the world. Books like In Search of the Cradle can be found at The Theosophical Society which has been a part of Wheaton’s local history for over 100 years. A part of my role in the Olcott Library is to apply for a state grant that will digitize important elements of the collection that contribute to Illinois history.

Virtual reference
In an effort to reach patrons accessing the library via computers, many libraries and library consortia offer virtual reference services. These services can be either real-time or offset, and are offered via email, instant messaging, web form interfaces, SMS, and even virtual reality games. According to the Reference and User Services Association, "Virtual reference is responsive to patrons' need for convenient access to reference service."

Though virtual reference is a great convenience for library patrons, its implementation introduces several challenges for traditional libraries. Most individual institutions don't have the staffing levels necessary to monitor an IM service regularly enough for the service be attractive to users. For real-time virtual reference, many libraries are part of chat co-operatives or consortia, some of which are able to offer reference services 24 hours a day. However, this does mean that reference workers from other institutions, who may not be as familiar with the patrons' home institution's resources, may not be able to provide services of as high a quality as the home institution might.

In his introduction to Digital Reference Service in the New Millennium: Planning, Management, and Evaluation, R. David Lankes examines the emerging field of digital reference, how it affects the traditional reference staff and service, and addresses two key issues, "scalability" and "ambiguity".

Lankes makes the argument that the availability and use of digital resources are fundamentally re-defining the role of reference services. According to Lankes, library reference staff are now becoming "information brokers", because of the nature of the digital environment and changing user expectations. He discusses two issues, scalability (the ability to service growth), and ambiguity (identifying resources needed to meet user's needs). He describes several differing initiatives that have been or could be brought into play to address these issues, both alterations of existing reference practices, and new methods of providing relevant reference services in a digital age.

His arguments are sound, and pose fundamental questions as to what defines a “Library” and “Reference Services”, as one would expect in the introductory chapter of a book on the changing role the digital world plays in the reference field. Some of the questions and possible solutions, however, seem very radical and unrealistic given the fragmented standard reference environment based on local libraries, both from a funding and staffing perspective, and assumes that some “entity” (modeled on the private sector) will provide a more centralized construct more appropriate for the digital age.

Access to technology
Gordon Flagg explains how the FCC unanimously passed a new rule on May 7, 1997 that decreased the charges of telecommunication services to schools and libraries throughout the nation. The discounts range from 20-90% (the highest percent going to libraries and schools in low-income, rural, and high-cost communities). In order to raise the $2.25 billion needed for this plan they increased fees ($1.50 for residential and $3.00 for business) and taxes on second phone lines.

This decision was praised by the ALA because it allows more schools and libraries to access the internet where in the based it was too costly to do so. That way everyone has the opportunity to use this service even if they cannot afford it in their homes. Some experts feared that this reduction would be difficult to sustain in the long run, because it is such a big undertaking and that there may be legal challenges they might have to deal with.

Physical libraries in a cyber world
Rapidly-deteriorating materials create an urgent need to focus on preservation, particularly in research libraries. Preservation decisions often fall into two major categories: selection and medium.
 * Problems of selection are best answered by a team of both librarians and scholars, who employ criteria that is three-fold: collection-, subject-, and usage-based.
 * Problems of medium, on the other hand, are more subjective. Microfilm is quite stable and durable, but access is somewhat limited. Digitization, while alleviating access problems, poses concerns about cost, instability, and hardware and software change.

Abby Smith advocates a preservation strategy that includes a combination of microfilm and digital storage. To be sure, funding for this multi-pronged approach is unanswered, but Smith’s ideas in action will help ensure the selection of a broad scope of scholarly works for preservation in forms that meet researchers' needs of integrity and accessibility. Since the publication of Smith's article, however, digital storage has gained more potential. For instance, some problems of cost and changing technology can be mitigated by storing documents on, say, a one-terabyte hard drive. Drive size has certainly come down in cost since 1999, and a hard drive will not become obsolete as quickly as many removable formats. Moreover, accessibility may be benefited by the sheer amount of works that can fit on a terabyte hard drive. Nonetheless, it is clear that the mediums used for preservation should be reevaluated as digitization expands.

Cost of adoption
Libraries have been transformed and modernized by the application of information technology. Users do not have to go to libraries, and have the opportunity to retrieve information via Internet. Because of all the new technology being introduced to libraries, library administrators are forced to break down the budget, in order to make wise decisions when it comes to long-term benefits for the library. If a library administrator follows a cost structure model, he/she will have more success determining the direct and indirect costs. Also, the library administrator will be able to understand the initial and recurring costs within the life cycle of implied information technologies. It is common for administrators to forget to include training and other necessary costs, which may hurt their long-term budget. It is essential for library administrators to analyze each part of the budget, so he/she does not end up wasting any money.

I agree with the author’s statement about the “bigger picture” when it comes to a budget, and remembering the significance of keeping up with new technology offered. Chapter five brings up several great points about the importance of the growth of technology, and the awareness of people’s right to privacy. Much of society is getting comfortable with technology, and requires the programs offered. It is the library’s job to provide the programs to the public, and not go over the budget, while remembering the importance of an individual's privacy.

Monetary costs are not the only costs to adopting new technology. Author Nicholson Baker is a firm believer that adopting new technologies can come at the expense of preserving history. Libraries around the country, including those at academic institutions, have replaced many of their card catalogs with online access catalogs. They are throwing out their card catalogs, sometimes with fanfare. Despite some attempts to preserve data by microfilming the cards and proofing the new records, information is being lost because of errors and omissions.

Librarians rapidly adapted to technology to cope with a cataloging crisis caused by growing numbers of items to process. The author argues that they are overlooking their mission to preserve books. Instead of being archetype librarians, they want to be seen as technology specialists.

Author Nicholson Baker contended that disposing of the card catalog was akin to tossing out history. The notations made on each card over decades, make the card catalog itself an artifact worthy of preservation. It is ironic that while the goal of libraries is to preserve information, they are keen to dispose of the catalog, which he sees as more than a finding aid. With humor, wit and irony Baker described the evolution of the library catalog. Accession dates, provenance and notes in some catalogs might be of value to scholars, but the nostalgia for well-thumbed faded cards with carefully written notes seems to be Baker's primary object.

Nicholson again critiqued libraries' adoption of technologies in his 2001 book Double fold: libraries and the assault on paper, Nicholson Baker presents a strongly-worded critique of libraries' digital reproduction of paper materials. In one of his most compelling case studies, he examines the case of the Syracuse Daily Standard newspaper, which in 1858, claimed to have been printed on paper "said to be taken from Egyptian [sic] mummies." When he attempted to find the actual newspapers, he discovered that the local public library had since discarded its paper copies of the newspaper, instead offering a microfilm copy to its patrons.

The book, which the New York Times described as a "blistering and thoroughly idiosyncratic attack", was strongly criticized by the library community. A major argument against Baker's book was that libraries build their collections based on both current and anticipated use, rather than strictly preserving anything they can. Not every item ever published can be collected and preserved in its original format, nor will every item ever published be useful to library patrons, especially if it has disintegrated extensively. A second major argument against the book was the impracticality of maintaining print items, particularly acidic ones, on a large scale. A third argument notes that digitization and microfilm tend to enable more people access to a particular item, as microforms can be shared via Interlibrary Loan much more feasibly than can decaying print resources, and since digitized materials can often be shared with anyone who can access the Internet. For a bibliography of reactions to Baker's book, see the |Association of Research Library's exhaustive list.

Conclusion: Rutenbeck's "Five great challenges"
According to Jeff Rutenbeck, the continued growth of the digital world presents five major challenges to its users: malleability, selectivity, exclusivity, vulnerability, and superficiality.

Malleability
Malleability refers to the total impermanence of digital information, from data to pictures to even people's identities. Unlike print, digital information can be reconfigured in ways that print information cannot.

Selectivity
Selectivity addresses the preference by users to only consider information available online, dismissing information available only in print.

Exclusivity
The digital divide comes to the forefront with exclusivity, since new technology is being introduced constantly, but there is no universal way to bring everyone to the same levels of competence.

Vulnerability
Vulnerability highlights the inherent problems with our interconnectedness; while we enjoy the easy and constant flow of information and ideas, at the same time, we leave ourselves open to security breaches and systems failures.

Superficiality
What I feel is the greatest challenge in the digital age is superficiality. We have access to so much information, but there is no guarantee that what we see is accurate.

Conclusion
The author identifies the issues clearly, and offers suggestions as to how we can battle these challenges, but acknowledges that there is no clear cut answer to overcoming any of them. Most users, including myself, butt against these issues in our personal and business life, and struggle with how to reconcile them, since, as the author acknowledges, any answer leads to compromises.