On Mar 27, 2007, at 11:01 AM, Nick Alexander wrote: > On 26 Mar 2007, at 16:42, Robert Bradshaw wrote: > >> In working with higher-precision real numbers, I've come across >> this odd behavior: >> >> sage: RealField(200)(1.2) >> 1.1999999999999999555910790149937383830547332763671875000000 >> >> I understand what's going on, it's creating a 53-bit float >> approximation for 1.2, then coercing that exactly into the real >> field of higher precision. I was thinking perhaps of pre-parsing >> this to a DecimalLiteral class thus postponing the binary >> approximation until we know what ring it should live in (e.g. via >> coercion or arithmetic). I am thinking that arithmetic between two >> such literal decimals would involve calling create_RealNumber() on >> both arguments (as the preparser does now) and then performing the >> arithmetic (to avoid slowness (or re-implementation) of the >> decimals package). > > It worries me that > > sage: type(1.1) > DecimalLiteral > > sage: type(1.1 + 1.2) > some real field > > I find that confusing. Would it be sensible to preparse into a > field that handled arbitrary precision (maybe the mpfi fields?) and > then use the existing coerce/call mechanism to handle the specific > field in question?
Unfortunately, we don't have a field right now that has arbitrary precision, though in a way this would be one. One could (potentially) make/use a lazy real field, but I am almost certain that arithmetic in such a field would be slow enough that it would be a bad choice for the "default" field. I do want to leverage the coercion/calling mechanism, but the problem is that every float is truncated down to 53 bits of precision on parsing before anything else can get to it. An alternative is making decimals a full "field." sage: type(1.1) DecimalLiteral sage: type(1.1 + 1.2) DecimalLiteral sage: 1.1 + 1.25 1.35 sage: 3.14159 ^ 10 # here we turn a number with 5 digits of precision to one with 50? 93647.25646787226922299505202262723704312737441654490401 sage: type(1.2 / 1.1) # can't be represented as a finite decimal, and the / operator often returns elements of a different field some real field sage: type(sqrt(1.1)) # same some real field I'm not sure this is the best approach. Right now one works implicitly in some default real field, but (typically) enters input as decimal strings. I think this is a good model, but makes it difficult/non-obvious when creating/mixing numbers with higher than default of precision. > >> P.S. Also, I was wondering what the implications would be of >> making the "default" 53-bit filed into QDF rather than RealField >> (53). (Other than vastly increased efficiency of course.) > > I expect lots of doctests would break. The number of different > "Real Field" implementations is getting such that I have no idea > which one to use in which situation. Yes, I am aware that lots of doctests would break, but if its just a change in the last decimal or two(?) I'm OK with fixing that. I'm wondering if anyone knows of any algorithms/etc. that rely on MPFR 53- bit rather than native cdef doubles (also 53 bit). Are there any ways that MPFR is better at this precision that native doubles (which are much faster)? For real fields we have: - MPFR (this is the default, and RR is a 53-bit MPFR): Arbitrary (fixed) precision, based on gmp. - RDF: Stores real numbers as cdef doubles, very fast (though not quite as fast as python floats (yet)). Sorry about the typo above, I meant using RDF by default. - floats: not sage objects, but the fastest if you want to do arithmetic in python (think int vs Integer) - RQDF (from __future__): 212 bit precision based on the exact sum of 4 doubles. Arithmetic almost equal to 212-bit MPFR. Trig functions almost 50% faster, other special functions on par to 50% slower. I think there may be potential here for additional speedup here especially in the object creation/destruction phase. MPFI: This is interval arithmetic over the reals, which is useful but a different goal. Thank you for your comments, Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
