Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- analyticalengine:cardhandling [2015-04-21 19:21] – created rainer
+++ analyticalengine:cardhandling [2015-10-22 22:33] (aktuell) – [Operation cards] rainer
@@ Zeile 6: / Zeile 6: @@
 So far, these card types have been used:
-  * operation cards
-  * variable cards
+    * operation cards
-  * number cards
+    * variable cards
+    * number cards
 ===== Operation cards =====
+It seems fairly clear, that the operation cards just set the mill to one out of four arithmetic modes, and that the operation cards never start an action of the mill:
-It seems fairly clear, that the operation cards just set the mill to one out of four arithmetic modes, and that the operation cards never start an action of the mill:
+>The Operation-cards merely determine the succession of operations in a general manner. They in fact throw all that portion of the mechanism included in the mill into a series of different states, which we may call the adding state, or the multiplying state, &c. respectively.
->The Operation-cards merely determine the succession of operations in a general manner. They in fact throw all that portion of the mechanism included in the mill into a series of different states, which we may call the adding state, or the multiplying state, &c. respectively.
 Throughout the text, it is often stressed that only a few operation cards are needed. This seems to be rather strange, as the operation cards are at most 25% of all cards, and they are small, as at most four holes are needed.
@@ Zeile 21: / Zeile 21: @@
 These control the transfer of numbers between the mill and the store, and come in to major flavors:
-  * Supplying-cards: transfer from the store to the mill
-  * Receiving-cards: transfer from the mill to the store
-Each also comes -- only hinted in the //Sketch// -- for two destinations (normal and primed ingress) as well as sources,
+    * Supplying-cards: transfer from the store to the mill
-and the Supplying cards also may either leave the storage cell cleared, or have the value restored (see [[analyticalengine:destructiveload|Destructive and retaining ingress operation]]).
+    * Receiving-cards: transfer from the mill to the store
-As the mill has no unary operations, in every operation of the mill, two Supplying-cards and one Receiving-card is needed (unless the result is only needed to control a loop).
+Each also comes – only hinted in the //Sketch//  – for two destinations (normal and primed ingress) as well as sources, and the Supplying cards also may either leave the storage cell cleared, or have the value restored (see [[:analyticalengine:destructiveload|Destructive and retaining ingress operation]]).
-A hard to understand remark is:
+As the mill has no unary operations, in every operation of the mill, two Supplying-cards and one Receiving-card is needed (unless the result is only needed to control a loop). Moreover, more than one receiving card may be used after the operation of the mill (Line 1 in the table for the calculation of Bernoulli's numbers).  Additional cards are needed for multiply and divide when a double precision operand/result is required.
->It should be understood that the Variable-cards are not placed in immediate contiguity with the columns. Each card is connected by means of wires with the column it is intended to act upon.
+A hard to understand remark is: >It should be understood that the Variable-cards are not placed in immediate contiguity with the columns. Each card is connected by means of wires with the column it is intended to act upon.  This simply refers to what we might call the "address decoder".  Cards were physically applied at a single location then the information they contained was distributed by control linkages to select the physical columns in the store.  There is nothing mystical here.
 ===== Number Cards =====
-Provided the storage can be cleared totally, the numbers initially required in the variables giving the function arguments, have to be provided by another card type.
+Provided the AE shall calculate the value of an analytical function, it has to  receive the arguments and constant numerical values used in the formula or algorithm.
+In the //Sketch//, nothing was found to provide the initial values of the variables. There, it was assumed that all numbers needed in a calculation are put into the respective colums before the machine starts.
+In the //Passages...//, Babbage refers to number cards, but these are **not**  cards sending a number encoded on a card to a storage column; the represent argument-value pairs, which could be requested -- by means not explained -- during the run of the machine, and supplied by an operator. It was not explained where the number goes.
+John Walker in his AE simulator (see [[http://fourmilab.ch/babbage/cards.html]]) has introduced number cards that allow to send a constant to a specified storage cell. It origins are left open.
+His cards have the disadvantage that they are rather large, as they have to contain the cell number as well as the constant.
+From today's point of view, it might be also an option just to transfer the number from a stack of cards via the ingress axis to the mill, and to be used instead of a variable card.
+One might even be tempted to provide that column 0 is just the next card from the constants card, and no physical column 0 exists.
+Note that while Babbage claims that results may be printed or punched, neither the //Sketch// nor the //Passages// give any indication how this is managed.
+===== Card Control =====
+Any attempt to visualize the action of the AE, either by a physical or a virtual model, needs to control the bunch of cards.
+As it is clear from various places in the //Sketch//, that operation cards only set the mill, but do not start its working, as a single operation card can be used as long as the same operation is required. While this is strange, and it would be better to use the operation cards as postfix operator, it seems useful to stick to this baroque means.
+One possiblilty is that the termination of the second transfer of a number from the store to the mill starts the operation as set with the last operation card used. ((This is what the HNF display will do.))
+Another solution might use another chain of cards, used to control the flow of execution.
+In its simplest form, there are three stacks:
+  * operation-cards
+  * supplying-cards
+  * receiving-cards
+The control cards have at least three columns:
+  * if the first column has a hole, the stack is advanced and the mill set to that operation
+  * if the second column has a hole, the next supplying-card is used
+  * if the third column has a hole, the next receiving-card is used
+A forth coulum could support number or constant cards.
-**Could not found the place** in the //Sketch//.
+A fifth coulum could be used to start the mill, although it is clear from the //Sketch// that any operation always requires two supplying-cards.
+The interesting feature of this model is that additional colums could be used for loop control:
+if there is a hole in such a column, the control cards are moved backwards, until a hole in the next column is found.
+((or to use a single column, if a transition from hole to non-hole is found, the backwards operation goes while there are holes.))
+According to the holes, the corresponding other cards are moved backwards too.
+This limits the nesting of loops to the number columns provided, but this is not a severe restriction, even if in hindsight would expect to jump to a label.
+((giving a relative backwards jump count might be possible, but with significantly more mechanical effort.))
+Clearly, the backward move must be suppressed if the overflow lever is set.