Precision and CD's

[Andreas Strotmann]

I'd like to add another aspect to this discussion if I may.

As has been pointed out repeatedly, bigfloats (as they've been understood
in the discussion so far) represent those exact rationals that happen to
have some other mathematical property, namely, being an integer multiple
of a positive or negative power of a certain base.  There are many
rationals that do not have this property, and the property is only
conserved by the basic operations +,-,* on rationals, but not by /, and
not by changes of bases in the representation.

In other words, the concept of "bigfloats" is a very dubious notion
*mathematically*, though it is perfectly sensible as a *data*structure*.
However, bigfloats are the *only* concept in the OpenMath definition as it
currently stands that does *not* mirror some perfectly valid mathematical
domain.

It's actually fairly easy to change this -- that is, to make bigfloats
*exactly* represent the rationals -- by adding one more field to the
definition: a string of digits that is repeated indefinitely in the
expansion.  Example:
          ______
  1/7 = 0.142857   (exactly, not approximately)

I propose that OM (big)floats implement this concept rather than the one
currently being discussed.

The example shows that there is a widely accepted notation (i.e., such
numbers are easy to print even with such an extension -- or at least they
don't add any complication on their own).  The complexity of an algorithm
for parsing numbers of this sort is only marginally more complex than the
one for parsing numbers that do not have this part -- this is even true
for symbolically challenged applications ;-) .  Mathematically, this
computationally trivial extension has a huge benefit, adding (as it does)
a concept for elements of |Q.  Computationally, it helps sidestep at least
some of the problems that have been pointed out that come up in changes of
bases.  And I know of at least one CA system (REDUCE) that actually
handles these things.

I think my point is that if we do bigfloats as CDs, this (continued
fractions in a "scientific" format) should be the concept the core CD
should implement, simply because it makes so much more sense
mathematically, and mathematical concepts are what CDs are about.

BTW: this has nothing whatsoever to do with the precision issue -- which
it incidentally sidesteps nicely.  Arguments that were put forth against
including precision do not apply here -- on the contrary, as I've been
arguing, they support this proposal.

Also, this proposed change is conservative :-) -- an extension, not a
replacement.

It's also orthogonal to the question of whether to allow a general string
representation of floats as an OMF element content or whether to use a CD
representation with fields (though one would have to come up with some
ASCII string representation in the former case).

What do you think?

--  Andreas