II. Notes on Data Structuring * - Cornell University
II. Notes on Data Structuring * - Cornell University
II. Notes on Data Structuring * - Cornell University
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
106 c.A.R. HOARE<br />
variable of type raster, r.x and r.y are comm<strong>on</strong>ly known as the projecti<strong>on</strong>s<br />
of r <strong>on</strong>to the x and y axes respectively; however, we shall refer to the functi<strong>on</strong>s<br />
x and y as selectors rather than projecti<strong>on</strong>s.<br />
The cardinality of a Cartesian product type is obtained by multiplying<br />
together the cardinalities of the c<strong>on</strong>stituent types. This is fairly obvious<br />
from the visualisati<strong>on</strong> of a Cartesian product as a rectangle or box with<br />
sides equal in length to the cardinalities of the types which form the axes.<br />
thus the cardinaiity of the card type is thirteen times four, i.e., fifty-two, which<br />
is, as you might expect, the number of cards in a standard pack. The number<br />
of dates is 26 040, which slightly overestimates the actual number of days in<br />
the interval, since as explained above, it includes a small number of invalid<br />
dates.<br />
4.1 MANIPULATION<br />
Apart from assignment and test of equality, which are comm<strong>on</strong> to all types,<br />
the main operati<strong>on</strong>s defined for a product type are just those of c<strong>on</strong>structing<br />
a value in terms of comp<strong>on</strong>ent values, and of selecting the comp<strong>on</strong>ents.<br />
When c<strong>on</strong>structing a value of a Cartesian product type, it is in principle<br />
necessary to quote the name of the type as a transfer functi<strong>on</strong>. However,<br />
it is often more c<strong>on</strong>venient to follow the traditi<strong>on</strong>al mathematical practice,<br />
and leave the transfer functi<strong>on</strong> implicit in cases where no c<strong>on</strong>fusi<strong>on</strong> would<br />
arise. This is in any case necessary when a type is not even given an explicit<br />
name. For example, <strong>on</strong>e may write (heart, Jack) instead of cardface (heart,<br />
Jack).<br />
For selecti<strong>on</strong> of a comp<strong>on</strong>ent, a dot-notati<strong>on</strong> has been used, e.g.,<br />
n. imagpart. This is more c<strong>on</strong>venient than the normal functi<strong>on</strong>al notati<strong>on</strong><br />
imagpart (n), since it avoids unnecessarily deep nesting of brackets.<br />
Another most important operati<strong>on</strong> is the selective updating of the com-<br />
p<strong>on</strong>ents of a variable. This may be denoted by placing the comp<strong>on</strong>ent name<br />
<strong>on</strong> the left of an assignment<br />
u. imagpart: = 0;<br />
r.x:= axr.x + bxr.y.<br />
If a Cartesian product is declared as ordered, it is necessary that all the<br />
c<strong>on</strong>stituent types be ordered, and it is natural to define the ordering in a<br />
lexicographic manner, taking the earlier comp<strong>on</strong>ents as the more significant.<br />
Thus if suit and rank are ordered, the cardface type could be declared as<br />
ordered in the traditi<strong>on</strong>al ranking whereby all clubs precede all diam<strong>on</strong>ds,<br />
and these are followed by all hearts and all spades; whereas within each suit,<br />
the cards are ordered in accordance with their rank.