Per my blog post of earlier today, I'm continuing to seek hooks in CS that'll help with a more MBA type curriculum, per recent sponsorships, and one of those hooks is "sorting", a paradigm activity in CS that typifies why we pay for computer services i.e. fast sorting capabilities are in some sense the sine qua non of computing. The whole idea of "keeping tabs" (Hollerith machine) relates to retrieving just the right punch cards based on whether a certain hole (or holes) obtain. http://worldgame.blogspot.com/2008/06/energy-economics.html Per an elementary mathematics curriculum, cardinality is about distinguishing objects (in memory, in inventory) without attempting a ranking, i.e. we might tell objects apart (Python's "is") without requiring sortability, whereas ordinality is all about ranking or arranging along an axis (a spectrum) from most to least (or the reverse) in some dimension (i.e. according to some measure). Cardinality: identifiers, location, uniqueness, same/different (==, is) Ordinality: ranking, comparison, more/less ( >, <) Cardinality is sufficient to sustain "matching" i.e. find the one needle in this haystack, the one book in this library, that matches whatever criteria. SQL is in principle able to pull a result set minus any primary key or global sort order, based simply on boolean filtering. The idea of "a sort" is it helps with matching in some cases i.e. speeds retrieval; instead of looking at each book title, you go right to it based on some addressing scheme (an alphabetical sort is a paradigm example).** Apropos of this, we don't define complex numbers according to rank, meaning we don't allow <, > (but do allow ==).
1j > 2j Traceback (most recent call last): File "<pyshell#48>", line 1, in <module> 1j > 2j TypeError: no ordering relation is defined for complex numbers 1j + 1j == 2J True
Ordinality implies the possibility of multiple axes, which Python helps describe by giving us the "key" parameter when sorting. But before we get to multiple keys, we'll probably want to demonstrate operator overloading with respect to >, < and == with basic Items i.e. some minimal class of object. Note that Python 3000 no longer includes __cmp__ so you need to do something more like:
class Item: def __gt__(self,other): return self.rank > other.rank def __lt__(self,other): return self.rank < other.rank def __eq__(self,other): return self.rank==other.rank
a,b,c,d = Item(), Item(), Item(), Item()
a.rank = 5 b.rank = 4 c.rank = 1 d.rank = 2
theitems = [a,b,c,d] theitems [<__main__.Item object at 0x83cc30c>, <__main__.Item object at 0x83cc24c>, <__main__.Item object at 0x83cc26c>, <__main__.Item object at 0x83cc4ac>]
sorted(theitems) [<__main__.Item object at 0x83cc26c>, <__main__.Item object at 0x83cc4ac>, <__main__.Item object at 0x83cc24c>, <__main__.Item object at 0x83cc30c>]
Key:
a <__main__.Item object at 0x83cc30c> b <__main__.Item object at 0x83cc24c> c <__main__.Item object at 0x83cc26c> d <__main__.Item object at 0x83cc4ac>
Kirby ** just because there's an addressing scheme e.g. organization, even a global one, doesn't mean there's a ranking in the sense of greater and less than. This gets us into deeper mathematical concepts e.g. of "a metric" wherein it's easy to talk about relative proximity, what's touching vs. not touching, without suggesting a global ranking. In CS, networks and trees (as a subclass of network) suggest retrieval strategies i.e. you can get around on New York subways, using a subway map, but there's no need to define > or < except maybe in terms of distance and/or time and/or number of stops between any two stations. The idea of "pure cardinality" might be "named stars" with constellations (networks) introducing early retreivability i.e. two navigators talk about the same star by saying "the bear's nose" or whatever. Web pages and search algorithms give another take on cardinality vs. ordinality.