OM Floats

[David Carlisle]

> A precision attribute might be
> ...
> How close does this come to addressing your concerns about the doubled
> semantics and other things?

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.

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.

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:-)

David