Precision and CD's

[Bruce R Miller]

This is good; this forces me to clarify (to myself, as well!)

I hope we're agreed that bigfloats need to be somewhere in OM,
either as part of OMF, or in a CD.  There are at least 2 problems:
  1) How to represent a bigfloat, with sufficient accuracy and
generality needs to be addressed in either case.
  2) Do we lose something by putting them in CD?

[This was mostly composed when James's CD proposal came in!...edit,edit..]

ON PRECISION:

My precision attribute (essentially relative error) was intended
SOLELY to deal with _conversion_ issues such as those raised by
Fateman, NOT  as a general purpose concept of Error, for which
CD's are the only reasonable solution.  Unfortunately, the word
"precision" is way too overloaded, and I my use of the phrase
`Inexact reals' made matters worse --- my apologies!

My representation should be equivalent to Richard's:
 "those numbers among the reals that can be exactly represented
  in the form sign X fraction X radix^exponent,  with fraction=
  fixed length."
where my "precision" is the fixed length of the fraction, and
radix is, alas, restricted to 10.  Given the source & destination
`number of digits' & rounding model, it should be possible to
(almost) unambigously convert decimal <=> binary,  unless I've
misunderstood David Gay's work (quite possible).  It certainly
works for IEEE (using IEEE arithmetic).

James brilliantly sidesteps this `precision' nonsense by proposing
that the mantissa be an Integer!  This almost works for me.

Will it be possible to implement a formatter (or convert
to presentational MathML) without implementing BigFloat arith?
Consider conversion to LaTeX, for purpose of argument:

  bigfloat(1234567890,10,30) => 1234567890 \times 10^{30}
(ugh) but with a little trivial string processing:
  bigfloat(1234567890,10,30) => 1.234567890 \times 10^{39}
is fine.  However:
  bigfloat(1234567890,16,30) => 1234567890 \times 16^{30}
(blecch!) and there's not much more you can do (or?)

Do we expect formatters to implement bigfloat, or should we
just accept ugly output?
Or should we tune our representation according to who the
consumer is? (if so, then remind me why we're doing this! :>)

ON CD's:

It seems to me that OM should be a lossless representation of
mathematical information, without making too many assumptions
about the applications.   I should encode all the information
I have;  if it's lots of digits, or information on a distribution,
or  whatever.

Now if I am passing in an OMF, or a bigfloat, or possibly
even some Number_With_Peculiar_Error_Distribution, into
a purely numerical application which doesn't have bigfloats, etc.
what should happen?  I might reasonable expect all of those to
be downconverted/truncated  to the application's floats.

Should I not want that?
Does the application have to know all such CD's?
Should I define (potentially application specific) filters to
`dumb down' the representation, first?
Are there any potential automatic simplification mechanisms worth
considering?

I would hope that standard OM libraries would provide support to
convert bigfloats => double, _if_ the calling application requests.
(and maybe others: rational....)

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