On Sat, Feb 2, 2013 at 9:46 AM, rjf <fate...@gmail.com> wrote: > 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.
I don't think that this is the location to discuss the many caveats in dealing with floating point representations which, despite your accusations, is a well understood problem in the Sage community. Which double-float number brand is used is intentionally not specified, as it's platform dependent (whatever the native C double precision floating point number is; maximal speed at the possible expense of control/accuracy). To guarantee IEEE-753 with correct rounding one uses RR (which is the default). > 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). Sage has both, and the proposed fix (which you did not address at all) handles them correctly. I've positively reviewed the ticket. - Robert -- 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.
