OM Floats

[Bruce R Miller]

On Jul 8, 10:29am, David Carlisle wrote:
> Subject: Re: OM Floats
> If you were to flesh out your proposal, in particular to propose how the
> binary encoding would change, how big an impact would this have on
> existing OM software, specifically the inria and naiomi libraries.

OK, I'll put something together.

> I can't answer that as my knowledge of the library internals is
> `limited' at best. As I assume the implementers of all such software are
> on this list, I'd have to let them answer that I think.
>
> Any change to any part of the language will potentially break the
> existing libraries, I don't say that we should never do that (there are
> some changes I'd like to see in the XML encoding....) but I think that
> we need to have some idea of the amount of extra work any change would
> make for the library implementors, and then just consider each case on
> its merits.

Agreed.

> Whatever happens about the float proposal, I am not sure I agree with
> the comment you made about CDs.
> > And that is another concern I have with the CD approach: that we'll
> > end up with a bunch of special purpose CD, with the result that most
> > applications wont understand most numbers.
>
> You could say the same about `addition' or `the sin function'. OpenMath
> only works as a communication language if people agree on the CDs.
> That is just the nature of the beast. As far as possible I'd see the
> OpenMath language itself just containing the tree constructors,
> `application, attribution,..' with as much semantic information as
> possible being offloaded to CDs rather than being hardwired into
> the language.  However you do need something in the language to form
> leaf nodes to get you started, hence OMI, OMF, ... where you draw the
> line between something to stick in a leaf and something to construct
> will always be somewhat arbitrary and open to debate, hence this
> thread:-)

To the extent there's agreement that bigfloats belong somewhere in the
standard, my worry is somewhat overstated.  Even so, I would hope whatever form
bigfloats are included is sufficiently general that people aren't unduely
encouraged to use a special CD.

Otherwise, I agree with your Tree, just different Leaves! :>
I think an arbitrary precision, decimal string is much more generally useful to
the range of applications than an IEEE double, and doesn't preclude any
particular application from converting to IEEE if it chooses.

A related question: Can XSL handle the translation from OM to MathML with the
current XML encoding including hex encoded IEEE floats?  Or is it already
unable to, independent of the float issue?



-- 
--
bruce.miller at nist.gov
http://math.nist.gov/~BMiller/