Subject: Re: What's up with IEEE Scheme?
From: (Rob Warnock)
Date: 2000/10/15
Newsgroups: comp.lang.scheme
Message-ID: <8sb33r$8u6ho$>
Dima Pasechnik  <> wrote:
| (Rob Warnock) writes:
| > Dima Pasechnik  <> wrote:
| > +---------------
| > | > So I think there are too many (i.e., >1) incompatible ways to 
| > | > implement GF(2^k) that are useful for different algorithms
| > | > to have a useful standard implementation.
| > | 
| > | What does prevent you from providing conversions from one 
| > | representation to another?
| > +---------------
| > 
| > Because in some (but not other!) representations, there's a direct
| > correspondence with *external* data, such that a change of GF
| > representation destroys the correspondence.
| I fail to get your point. Any data conversion can in principle destroy
| data's correspondence with external data. If your data are complex
| numbers in Cartesian representation, and you convert them into polar
| coord.  representation, you can lose a property that relies on
| "Cartesianness".

That's a good example, actually. If your basic application replies
on the ability to do *fast* vector addition, then changing to polar
representation internally can slow the entire application below the
threshold of usefulness. Or similarly, a conversion from Cartesian
to polar and back will probably destroy the truth of "equal?".

But Cartesian & polar are only two distinct representations for points.
When you get into higher-order GF codes, there may be many, *many*
different representations for the "same" GF, of which only one may be
useful in the a certain application, while a *different* one may have
to be chosen in some other applciation.

That's why trying to define a single "standard" GF representation
is doomed. IMHO.


Rob Warnock, 31-2-510
Network Engineering
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		PP-ASEL-IA
Mountain View, CA  94043