Paul Zimmermann commented to me that he doubts qd has proofs of correctness associated with it, as mpfr does.
The main advantage of qd is that it is a fixed precision package, which is faster than multiprecision but subject to overflow if not used correctly. If a port of mpfr were created to be built on the new fmpz type in the mpir package we want to create to replace GMP, arithmetic for small floats may be considerably faster, but in general you will never beat a fixed precision package for small precision. Someone ought to figure/ find out which parts of qd have proofs available and write them for the cases where they are not. Writing proofs for the transcendental functions may be quite hard, but it should be straightforward to produce them for the basic arithmetic operations, and indeed this is what we should be using qd for in SAGE in my opinion. Often getting a few extra bits of precision can add nearly a factor of two in time since the number of branches and floating point operations essentially doubles. This also happens in the use of floating point to do precomputed inverses, as happens in FLINT. Packages can offer both options if this is practical, but this is not a matter of errors vs speed. It is a matter of required precision vs speed. Bill. On 29 Apr, 15:41, "William Stein" <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 1:46 AM, mabshoff > > > > <[EMAIL PROTECTED]> wrote: > > > On Apr 29, 10:33 am, Francois <[EMAIL PROTECTED]> wrote: > > <SNIP> > > > Hi Francois, > > > > > Once you get some answer from upstream please open a ticket. I find it > > > > odd that the defaults are this way to say the least. > > > > I did email the author about the precision here is what he has to say: > > > > For ieee-add, it all depends on what kind of error bound you need. > > > If enabled, the error satisfies > > > > |e| <= |a+b| * epsilon > > > > It not enabled, the error satisfies > > > > |e| <= epsilon * max (|a|, |b|) > > > > For most uses the second one is just fine, but some times one needs > > > the > > > first one. > > > > Sloppy-mul and sloppy div usually degrades by few bits, so maybe you > > > lose a digit of accuracy. For double-double, the degredation is > > > smaller. > > > Ok. Thanks for finding out. > > > > ================ > > > The answer is not qualified by processors. He didn't say anything > > > about performance (I asked). > > > Ok. Is there anybody out there who can run some quick test with a > > decent runtime using quaddouble only in a tight loop, preferably in > > pure C? We can pay in credit ;) > > By the way, my understanding is that by far the main advantage of > quaddouble over mpfr is that it uses a very simple data structure, > which makes quaddouble more suitable for numerical linear algebra and > applications that involve supercomputing. > > -- William --~--~---------~--~----~------------~-------~--~----~ 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
