The description in the reference manual regarding Real Double Field (RDF)
basically misses
part of the problem.
Any time you merge two programs to interchange their data representations,
you have
to make sure that their outliers are transferred correctly. Thus, IEEE-754
binary floats
include signed infinity, signed zeros, a large number of NaN (not a
numbers) -- not just one of them.
Transferring these all to some top-level "Sage" is probably not going to be
consistent with a
design that started with different constraints and had different goals.
One of the IEEE-754
constraints was that the numbers be of finite fixed size (e.g. 32 or 64
bits, or an extended version
with more bits, but still a fixed number.)
In Sage it is presumably possible to have any number of extra symbols
attached to something
you've made up that is not REALLY a field, e.g. "undefined" "complex
infinity", "defined but zero precision",
And you can import stuff from several programs -- e.g. is Maxima's inf the
same as (say) IEEE inf the same
as Mathematica's Inf?
Ordinarily you could get some resolution of these questions if everyone
agreed to be
Mathematically Clean. That is, everyone agreed to represent a well-known
Ring or Field.
Thus there is not much trouble figuring out The Right Thing for conveying
integers.
Unfortunately, calling something a Real Double Field does not make it a
Field unless it IS
a Field. The collection of IEEE floats does not constitute a Field because
its elements
do not all conform to the required axioms.
This kind of problem is, I suspect, widespread in the Sage design, and it
is sloughed over
for good or ill. I would have expected this to come from computer
programmers (e.g.
well, we call it a field because all elements have a multiplicative inverse
with the exception
of zero, oh, and a bunch of other things that maybe we'll fix later). But
this supposedly
comes from mathematicians.
>From the manual on RDF:
"
An approximation to the field of real numbers using double precision
floating point numbers. Answers derived from calculations in this
approximation may differ from what they would be if those calculations were
performed in the true field of real numbers. This is due to the rounding
errors inherent to finite precision calculations."
This description is poor for several reasons. It leaves out exponent
overflow and underflow. The statement about inaccuracy and rounding is
sloppy.
It suggests (falsely) that one is dealing with a field. I suppose one
could object to the imprecision of WHICH double-float number brand is used.
One could consider whether affine or projective infinity is supported in
transferring values to other systems that are in Sage.
IEEE 754 is affine (has 2 infinities, in particular).
On Thursday, January 31, 2013 3:22:12 PM UTC-8, Travis Scrimshaw wrote:
>
> This is a good thing IMO:
>
> sage: d = RDF(2.0)
> sage: d = d^100000000
> sage: inff = float('inf')
> sage: inff == f*f
> True
> sage: inff == d
> True
> sage: inff == r
> True
> sage: r == d
> True
>
>
OH, if the two infinities are equal, does that mean their difference is
zero?
And if their difference is NOT zero, how do you work around the problem that
A - A == 0
is sometimes false?
You get into trouble if you go one step further and end up with a statement
like
0 == 0 for some values of 0.
If their difference is zero, I leave it as an exercise for the reader to
show another
contradiction.
Is there a way out? I'm not prepared to say what else is involved with
Sage. For
example, to what extent are real intervals going to be incorporated?
At least some of these issues have been studied and described previously,
so
perhaps some Sage-ist will provide a summary/ links/ learned resolution.
Unfortunately some people still seem to follow the maxim:
"A few months in the laboratory can save a few hours in the library. "
RJF
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
