Stored fields ordered left to right

"Joe "Nuke Me Xemu" Foster" wrote in message


...
 >
  > > Marshall agreed with me on something, so I'll dare post one of the many
  > > questions I have related to relational database theory.
  > >
  > > In Date's June 2003 paper entitled "What First Normal Form Really Means"
he
  > > asks questions about MultiValue systems, which he (and no one else I've
  > > read) abbreviates as "MVS". I am preparing answers to these questions.
  > > Date writes "...MVS fields are ordered left to right (and so MVS files
are
  > > certainly not relations, and the system is certainly not relational)."
  > >
  > > I've been puzzled by this for quite a while, just figuring that
relational
  > > theorists have this wrong. But the writings seem so sure of this. I had
  > > thought that the relations in relational database theory were
mathematical
  > > relations, but I am beginning to think that might not be the case. My
  > > masters in mathematics was quite some time ago, so I hauled out some
books
  > > and googled a bit and everything I find that is mathematics, rather than
  > > database theory, indicates what I thought about relations -- a relation
is a
  > > set of ordered tuples -- right? What am I missing here? An element of
a
  > > relation would be of the form (a1, a2, ... an) where a1 is an element of
S1
  > > etc. They ARE ORDERED LEFT TO RIGHT. Am I misunderstanding something
or is
  > > there some other mathematical definition of "relation" that is the one
on
  > > which relational database theory is based?
 >
 > A tuple is a set of ordered pairs of the form (attribute, value).
 > Defining an ordering for the attributes would be superfluous.
 >
 > URL:http://en2.wikipedia.org/wiki/Ordered_pair

So a tuple is NOT ordered? Why not? Why even call an unordered set a
tuple? Tuples imply ordering, right? They are elements of Set1 x Set2 x
Set3 x ... Setn. It is fine with me if you want those sets to be sets of
ordered pairs -- they can be sets of whatever, but the relation is then a
set of tuples (s1, ... sn) where s1 is an element of S1 (and in your def,
that means it would be an ordered pair).

But a RELATION itself is a set of ORDERED TUPLES -- RIGHT? Else please
point me to a MATHEMATICS definition that allows for relations that are not
ordered. I'm not finding any such definitions.
 >
 > You have much to unlearn, Grasshopper.

Ditto, methinks. Smiles. --dawn

 >
 > --
 > Joe Foster <mailto:jlfoster%40znet.com> On the cans?
<http://www.xenu.net/>
 > WARNING: I cannot be held responsible for the above They're
coming to
 > because my cats have apparently learned to type. take me away,
ha ha!
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Dawn M. Wolthuis" wrote in message ...




  > > A tuple is a set of ordered pairs of the form (attribute, value).
  > > Defining an ordering for the attributes would be superfluous.
  > >
  > > URL:http://en2.wikipedia.org/wiki/Ordered_pair
 >
 > So a tuple is NOT ordered? Why not? Why even call an unordered set a
 > tuple? Tuples imply ordering, right? They are elements of Set1 x Set2 x
 > Set3 x ... Setn. It is fine with me if you want those sets to be sets of
 > ordered pairs -- they can be sets of whatever, but the relation is then a
 > set of tuples (s1, ... sn) where s1 is an element of S1 (and in your def,
 > that means it would be an ordered pair).
 >
 > But a RELATION itself is a set of ORDERED TUPLES -- RIGHT? Else please
 > point me to a MATHEMATICS definition that allows for relations that are not
 > ordered. I'm not finding any such definitions.

Yes, a "relation" built from ordered n-tuples would be quite broken!
Consider an ordered 4-tuple, (a, b, c, d), or, { {a}, {a, b}, {a, b, c},
{a, b, c, d} }. What would happen if any two attributes were *equal*?
A set of ordered pairs, OTOH, wouldn't lose information if any or all of
its ordered pairs collapsed to sets containing just a single element.
Even if {{{a}, {a, a0}}, {{b}, {b, b0}}, {{c}, {c, c0}}, {{d}, {d, d0}}}
collapses to just { {a}, {b}, {c}, {d} } you could still figure out what
was what. It's a good thing relational tuples aren't ordered n-tuples!

--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

Dawn M. Wolthuis wrote:


 >

 >

 >
<snip>


   >>>Date writes "...MVS fields are ordered left to right (and so MVS files
 >
 > are
 >
   >>>certainly not relations, and the system is certainly not relational)."
   >>>

  <big snip>

Allow me to play the role of the fool jumping in where angels
fear to tread.....

Two points which may clarify RDBMS implementation (as opposed to
theory).

1. The relationships are imposed externally to the data in the
form of indexes and/or foreign keys. The data itself is
unordered. If I remember correctly Codd specifically stated
that the data was not ordered. From an implementation point of
view (circa 1970 when the largest mainframes weren't much faster
than my Palm IIIc) this allowed signifiantly better performance
when adding rows that should logically be anyplace other than
the end of the table.

2. Within a table row the physical order of the columns as
stored on disk need not conform to the logical order of the
columns as specified in the CREATE TABLE statement. Again
looking at the mainframe computers of 1970 when all but the very
largest had less than 16MB of RAM, the highest capacity disk
drives only had 33MB of storage and there were arcane rules
about floats and integers starting on word boundaries while
short integers and strings could start on any byte in a word it
became desirable to store all of the floats and integers at the
beginning of the physical disk record and the shorts and strings
after them in order not to waste any space in either memory or
on disk.

HTH<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Jerry Gitomer" wrote in message

 > Dawn M. Wolthuis wrote:


  > >

  > >

  > >
 > <snip>
 >
 >
   > >>>Date writes "...MVS fields are ordered left to right (and so MVS files
  > >
  > > are
  > >
   > >>>certainly not relations, and the system is certainly not relational)."
   > >>>
 >
 > <big snip>
 >
 > Allow me to play the role of the fool jumping in where angels
 > fear to tread.....
 >
 > Two points which may clarify RDBMS implementation (as opposed to
 > theory).
 >
 > 1. The relationships are imposed externally to the data in the
 > form of indexes and/or foreign keys. The data itself is
 > unordered. If I remember correctly Codd specifically stated
 > that the data was not ordered. From an implementation point of
 > view (circa 1970 when the largest mainframes weren't much faster
 > than my Palm IIIc) this allowed signifiantly better performance
 > when adding rows that should logically be anyplace other than
 > the end of the table.
 >
 > 2. Within a table row the physical order of the columns as
 > stored on disk need not conform to the logical order of the
 > columns as specified in the CREATE TABLE statement. Again
 > looking at the mainframe computers of 1970 when all but the very
 > largest had less than 16MB of RAM, the highest capacity disk
 > drives only had 33MB of storage and there were arcane rules
 > about floats and integers starting on word boundaries while
 > short integers and strings could start on any byte in a word it
 > became desirable to store all of the floats and integers at the
 > beginning of the physical disk record and the shorts and strings
 > after them in order not to waste any space in either memory or
 > on disk.
 >
 > HTH

Yes, this is most helpful. This is PRECISELY my understanding -- that
deciding to remove the ordering from relational tuples is an implementation
issue and not about the logical theory of relations.

I work with relations that are mathematical relations and are therefore
ordered tuples. The model behind XML documents is also one of ordered
tuples. So, if you hear of folks who might sometimes spout that their
database model is "more relational" than RDBMS's it sometimes is due to this
particular issue.

Based on this, it sounds like a response to Date that says that mathematical
relations are ORDERED and not unordered tuples so that this particular point
is irrelevant (and, in fact, wrong) would be an accurate response, right?

Thanks a bunch! --dawn<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Dawn M. Wolthuis" wrote in message
 >
 > I've been puzzled by this for quite a while, just figuring that relational
 > theorists have this wrong. But the writings seem so sure of this. I had
 > thought that the relations in relational database theory were mathematical
 > relations, but I am beginning to think that might not be the case. My
 > masters in mathematics was quite some time ago, so I hauled out some books
 > and googled a bit and everything I find that is mathematics, rather than
 > database theory, indicates what I thought about relations -- a relation is a
 > set of ordered tuples -- right? What am I missing here?

I'll give you my perspective, but I don't know how much it'll help.

The question is, how does one distinguish the attributes in the relation?
There are two choices: numerically/positionally, or by name. That is,
one either has a mapping from 1, 2, ... n to attribute, or one has
a mapping from name1, name2, ... namen to attribute. To me, it's
not all that great a difference. It's just a question of what the application
is.

If one is writing a page of equations, the convenience of using
positional identification is high. One is likely working with a single
relation at a time, and it is relatively simple to keep the ordering
straight in the author's and the reader's head.

If one is part of a team building an enormous software system,
then by-name is the better way to go, because of the mnemonic
value of the names. There are likely a lot of relations with a lot
of attributes.

It doesn't affect the semantics of relations or relational operators;
it just affects how attributes are identified.


Marshall<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Marshall Spight" wrote in message



  > >
<snip>
 > It doesn't affect the semantics of relations or relational operators;
 > it just affects how attributes are identified.
 >
 >
 > Marshall
 >

OK. Then a model in which there are relations where the tuples are ordered
but where values can be retrieved either by name or by position would be
different from a relational model where they are not accessible by position.
Then Date's point is not that the MultiValue model is not made up of
mathematical relations, but that it is a different model based on relations
than what Codd and company call the relational model.

Then we are in agreement. Now I just need words to make it clear that a
particular model is based on mathematical relations (ORDERED tuples) even
though it is not based on all of the other rules imposed within a theory
that names itself the "relational theory" (even though it is based on not
perceiving the relation's tuples as ordered).

The developers of MultiValue databases (such as IBM) promote them as
relational databases and they are mathematically correct. These databases
stem from the Nelson-Pick data model, however and not from the work of Codd.
If any company is permitted to decide what is relational and what is not, it
would be IBM, I would think, so I'll figure they have as much a right as
Date does to define what is and is not relational.

So, it seems to me we have a problem with our vocabularly. One group of
database theorists have taken a mathematical theory -- that of relations --
and have named their theory after it, even though they do not stick to the
mathematical definition and they extend the mathematics with many other
rules. They then tell people working with other models that are equally
mathematically relational that they do not conform to relational database
theory.

To try to straighten this out, I have referred to "the relational database
theory" instead as the RDBMS theory or the SQL database theory, but because
those are both implementation-based terms they do not sit well with
"relational databsae theorists". Is there a term for the "relational
database theory" that we (at least I) could use to indicate that it is the
relational database theory that does not include all databases that conform
to the mathematical theory of relations?

I want to be able to agree wtih IBM that both DB2 and U2 are relational
databases (since I DO agree with them) and also agree with Date that the U2
databases are not based on his version of a "relational database theory".
Thanks in advance for any help with this vocabulary issue. --dawn<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Marshall Spight" wrote in message



  > >
  > > I've been puzzled by this for quite a while, just figuring that
relational
  > > theorists have this wrong. But the writings seem so sure of this. I had
  > > thought that the relations in relational database theory were
mathematical
  > > relations, but I am beginning to think that might not be the case. My
  > > masters in mathematics was quite some time ago, so I hauled out some
books
  > > and googled a bit and everything I find that is mathematics, rather than
  > > database theory, indicates what I thought about relations -- a relation
is a
  > > set of ordered tuples -- right? What am I missing here?
 >
 > I'll give you my perspective, but I don't know how much it'll help.
 >
 > The question is, how does one distinguish the attributes in the relation?
 > There are two choices: numerically/positionally, or by name. That is,
 > one either has a mapping from 1, 2, ... n to attribute, or one has
 > a mapping from name1, name2, ... namen to attribute. To me, it's
 > not all that great a difference. It's just a question of what the
application
 > is.

Physical dependence vs. physical independence is not that big a
difference?!?


 > If one is writing a page of equations, the convenience of using
 > positional identification is high.

You are confusing an external physical representation with a logical
representation.


 > It doesn't affect the semantics of relations or relational operators;
 > it just affects how attributes are identified.

Huh? Of course it affects the semantics if positional ordering has meaning!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

Do you agree, Bob, that relational database theory seems to require
constructs that are NOT mathematical relations (because they have no logical
ordering among attributes)?

Do you also agree that some of the data models that are not considered by
relational theorists to be relational are, in this way, actually MORE
relational in that they do require logical constructs (ordered tuples) that
correspond to mathematical relations?

This is one of several issues I'm trying to square away or at least get a
vocabulary that is not so contradictory. Thanks --dawn
 >> Stay informed about: Stored fields ordered left to right 

"Bob Badour" wrote in message ...




  > > It doesn't affect the semantics of relations or relational operators;
  > > it just affects how attributes are identified.
 >
 > Huh? Of course it affects the semantics if positional ordering has meaning!

SELECT * really ought to rearrange the attributes each time it's
used! >=) However, alignment can still matter in modern system
architectures. Intel CPUs might still be happiest when floating
point values are 8-byte-aligned, but this is an implementation,
not a logical, detail.

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Dawn M. Wolthvis" wrote in message ...
 > Do yov agree, Bob, that relational database theory seems to reqvire
 > constrvcts that are NOT mathematical relations (becavse they have no logical
 > ordering among attribvtes)?
 >
 > Do yov also agree that some of the data models that are not considered by
 > relational theorists to be relational are, in this way, actvally MORE
 > relational in that they do reqvire logical constrvcts (ordered tvples) that
 > correspond to mathematical relations?
 >
 > This is one of several issves I'm trying to sqvare away or at least get a
 > vocabvlary that is not so contradictory. Thanks --dawn

To clear this very issve Date & Darwen define a relation in a
relational database as a set of sets, each set consisting of a set
triplets. For example, we covld have the relation valve

Person =
{
{ (person_id, integer, 1), (person_name, string, 'Jill') },
{ (person_id, integer, 2), (person_name, string, 'Joe') }
}

(the second component is there to allow for svbtyping)

So, I gvess, strictly speaking, yov covld argve that this is not
really a relation. However, the distinction is svperficial, since
there is a simple mapping from this strvctvre to a mathematical
relation by jvst mapping each attribvte name to an ordinal nvmber,
e.g.

Person_mapping = {(person_id, 1), (person_name, 2)} and simply obtain
the "trve" mathematical relation

Person_math =
{ (1, 'Jill'), (2, 'Joe') }

or, if yov want to inclvde type information,

Person_math =
{ (1, integer, 'Jill', string ), (2, integer 'Joe', string) }

Given a certain ordering there is a trivial 1:1 mapping from the valve
of Person to the valve of Person_math.

Since the ordinal position is immaterial for the vser (or it shovld
be) we can assvme any order of attribvtes, and, hence, jvst forget
abovt the whole issve.

The conversion from the "Codd" or "D&D" "relation" to the mathematical
relation is (logically) done by the system. Note, that all relational
operators (UNION, PROJECTION, RESTRICTION, etc..) are expressed very
simply even with these "relational database relations" and the mapping
to the corresponding mathematical operations is trivial.

The reasons (in my view) why Codd got rid of ordinal positions in his
definition of a relation in a relational database were

1) so as not to bvrden the vser with ordinal positions
(e.g. colvmn nvmber 87, instead of, say, colvmn named 'discovnt')

2) to not imply that the system actvally stores the valves in a
certain order
(=the system is free to map the colvmns to physical storage as it
wishes)

However, there is no easy mapping between SQL-tables and mathematical
relations.
Take the SQL-table

SQL-Person

person_id person_name
--------- -----------
1 Joe
1 Joe

In order to get a mathematical relation ovt of this we have to nvmber
the dvplicates, or inclvde some hidden valves in the original table.
However way this is done, it complicates the mapping.


best regards,
Lavri Pietarinen<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

Dawn M. Wolthuis wrote:

  >>Dawn M. Wolthuis wrote:


  >><snip>
   >>>>> Date writes "...MVS fields are ordered left to right (and
   >>>>> so MVS files are certainly not relations, and the system is
   >>>>> certainly not relational)."
   >>>>>
  >>
  >><big snip>
  >>
  >>Allow me to play the role of the fool jumping in where angels
  >>fear to tread.....
  >>
  >>Two points which may clarify RDBMS implementation (as opposed to
  >>theory).
  >>
  >>1. The relationships are imposed externally to the data in the
  >>form of indexes and/or foreign keys. The data itself is
  >>unordered. [...]
  >>
  >>2. Within a table row the physical order of the columns as
  >>stored on disk need not conform to the logical order of the
  >>columns as specified in the CREATE TABLE statement. [...]
 >
 > Yes, this is most helpful. This is PRECISELY my understanding --
 > that deciding to remove the ordering from relational tuples is an
 > implementation issue and not about the logical theory of relations.
 >
 > I work with relations that are mathematical relations and are
 > therefore ordered tuples. The model behind XML documents is also
 > one of ordered tuples. So, if you hear of folks who might sometimes
 > spout that their database model is "more relational" than RDBMS's
 > it sometimes is due to this particular issue.
 >
 > Based on this, it sounds like a response to Date that says that
 > mathematical relations are ORDERED and not unordered tuples so that
 > this particular point is irrelevant (and, in fact, wrong) would be
 > an accurate response, right?

It depends on the premises from which you work.

One of the documented differences between mathematical relations and
relations used in database theory is precisely this one - that the
elements in a tuple of a mathematical relation are ordered (usually
ordered pairs, in fact) but database theory uses unordered tuples,
where each element logically consists of the combination attribute
name, attribute type and attribute value. Of course, in a system
without inheritance to complicate matters, the attribute type
associated with a given attribute name is the same for all tuples in
the relation (but the converse is not true). The difference between
ordered mathematical relations and the unordered database equivalent
is clearly stated in Codd's original (1970) paper, incidentally:

Accordingly, we propose that users deal, not with relations
that are domain-ordered, but with relationships which are
their domain-unordered counterparts.

[Note the implied distinction between what users see and what the
system manages, too.]

Many practical systems store each record (physical analogue of a
tuple) with the fields (the physical analogue of an attribute) stored
in the same order, which makes it easier to locate a given field
within a given record. And many systems make life still easier by
storing the data for a given field in a constant width, so it is
trivially possible to pre-calculate the offset into the record for a
given attribute value.

To get back to the question - if you change the premises on which your
version of relational theory is based to state that your tuples are
indeed ordered, then of course Date's statements no longer apply. The
theory about which he is making statements states that tuples are
unordered. Both are valid sets of premises, but they are different
sets of premises, and statements made about one are not valid for the
other.

As to which set of premises is better - that is a separate discussion.
I strongly suspect there are a rather large number of issues that
have to be resolved when you use ordered tuples rather than unordered
tuples. Most notably, A JOIN B is not the same a B JOIN A under the
ordered scheme - with consequences that need to be considered very
carefully.

And, reverting to the final question again - no, Date's comments are
neither irrelevant nor wrong in the system about which the comments
were made.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler.DeleteThis@earthlink.net, jleffler.DeleteThis@us.ibm.com
Guardian of DBD::Informix v2003.04 -- <a style='text-decoration: underline;' href="http://dbi.perl.org/" target="_blank">http://dbi.perl.org/</a><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Jonathan Leffler" wrote in message

<big snip>
 > One of the documented differences between mathematical relations and
 > relations used in database theory is precisely this one - that the
 > elements in a tuple of a mathematical relation are ordered (usually
 > ordered pairs, in fact) but database theory uses unordered tuples,

Be careful not to equate Codd's database theory with all database theory. I
work with alternative database theories. The primary one that I work with
has, in the logical model, the concept of ordered tuples, aka mathematica
relations. In fact, they are relations which are mathematical functions as
well. It appears to me that relational database theory works with relations
that are not, by definition, mathematical relations while at least one
database theory that actually uses mathematical relations is often accused
by relational theorists of not being relational. Am I the only one
intrigued by this?

 > where each element logically consists of the combination attribute
 > name, attribute type and attribute value. Of course, in a system
 > without inheritance to complicate matters, the attribute type
 > associated with a given attribute name is the same for all tuples in
 > the relation (but the converse is not true). The difference between
 > ordered mathematical relations and the unordered database equivalent
 > is clearly stated in Codd's original (1970) paper, incidentally:
 >
 > Accordingly, we propose that users deal, not with relations
 > that are domain-ordered, but with relationships which are
 > their domain-unordered counterparts.
 >
 > [Note the implied distinction between what users see and what the
 > system manages, too.]
 >
 > Many practical systems store each record (physical analogue of a
 > tuple) with the fields (the physical analogue of an attribute) stored
 > in the same order, which makes it easier to locate a given field
 > within a given record. And many systems make life still easier by
 > storing the data for a given field in a constant width, so it is
 > trivially possible to pre-calculate the offset into the record for a
 > given attribute value.
 >
 > To get back to the question - if you change the premises on which your
 > version of relational theory is based to state that your tuples are
 > indeed ordered, then of course Date's statements no longer apply. The
 > theory about which he is making statements states that tuples are
 > unordered. Both are valid sets of premises, but they are different
 > sets of premises, and statements made about one are not valid for the
 > other.

I agree, so I'm trying to get some common language. Taking mathematical
vocabulary and then changing it (and in this particular case changing
relations to require that they be unordered when mathematically they are
ordered !!) is more than likely to cause problems when discussing database
theories (as I have seen time and again, which is why I'm trying to align my
language with that of relational theorists EXCEPT THAT I AM NOT WILLING TO
SACRIFICE ACCURATE MATHEMATICS, if we can avoid that)

 >
 > As to which set of premises is better - that is a separate discussion.
 > I strongly suspect there are a rather large number of issues that
 > have to be resolved when you use ordered tuples rather than unordered
 > tuples. Most notably, A JOIN B is not the same a B JOIN A under the
 > ordered scheme - with consequences that need to be considered very
 > carefully.

Yes, you are absolutely right. In fact, the model I work with is more of a
di-graph of data and instead of joins, it uses data trees (much like the
web). This is accomplished with functions as well. Instead of using two
different concepts -- sets/relations combined with operators, the model I
work with uses functions in both cases. All work with computers can be seen
in terms of functions that map one "object" to another, in fact. Both
functions and objects can be stored in memory, disk or wherever. [sorry,
I'm digressing]

 >
 > And, reverting to the final question again - no, Date's comments are
 > neither irrelevant nor wrong in the system about which the comments
 > were made.
 >

I can see that he is not using the mathematical term "relation" but a
definition that has evolved from the work of Codd and has redefined relation
so that it means something different in database theory. Don't you hate it
when that happens!!!??? Now I need to have a term that stands for database
theory that is based on the mathematical definition of relation and
distinguish that from what is currently called relational database theory
that does not match the mathematical definition of relation. UGH! Please
help. --dawn

 > --
 > Jonathan Leffler #include <disclaimer.h>

<font color=purple> > Guardian of DBD::Informix v2003.04 -- <a style='text-decoration: underline;' href="http://dbi.perl.org/</font" target="_blank">http://dbi.perl.org/</font</a>>
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right 

"Lauri Pietarinen" wrote in message


...
  > > Do you agree, Bob, that relational database theory seems to require
  > > constructs that are NOT mathematical relations (because they have no
logical
  > > ordering among attributes)?
  > >
  > > Do you also agree that some of the data models that are not considered
by
  > > relational theorists to be relational are, in this way, actually MORE
  > > relational in that they do require logical constructs (ordered tuples)
that
  > > correspond to mathematical relations?
  > >
  > > This is one of several issues I'm trying to square away or at least get
a
  > > vocabulary that is not so contradictory. Thanks --dawn

Apparently, Dawn does not realise she has been in my twit-filter for months
now.

For anyone who doesn't know, ignore Dawn--she's an idiot. Mathematical
relations do not have any particular attribute order. The physical
representation of mathematical relations using written symbols on planar
surfaces relies on physical order for succinctness.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Stored fields ordered left to right