20.03.2013 Views

II. Notes on Data Structuring * - Cornell University

II. Notes on Data Structuring * - Cornell University

II. Notes on Data Structuring * - Cornell University

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!