I'm not sure exactly what the speed differences are, but I think that
they are quite significant. When writing the partition counting code,
which uses quaddouble, I recall that things ran much slower if "sloppy"
multiplication and division were not enabled. (However, I have no hard
benchmarks to back this up right now, so this statement shouldn't be
taken too seriously, and I could be wrong -- it would be nice if I had
some real data.)
Anyway, I don't think that this isn't necessarily an issue of
correctness vs. noncorrectness. It's an issue of precision -- in one
implementation multiplication/division is correct to within X bits, and
in the other it is correct to within (X + a few more) bits, but it takes
[a lot?] longer. In at least some applications, it is very desirable to
accept a small loss of precision in exchange for a large speedup.
Also, regarding benchmarking, I wonder what the speed difference is
between quaddouble with IEEE error bounds vs. mprf at 212 bits. And
while I'm wondering, I also wonder whether there is any even any reason
for RQDF to exist:
sage: def f(x):
...: for i in xrange(1000000):
...: y = x * x
...:
sage: x = RQDF(1/1000)
sage: timeit("f(x)")
5 loops, best of 3: 802 ms per loop
sage: x = RealField(212)(1/1000)
sage: timeit("f(x)")
5 loops, best of 3: 872 ms per loop
quaddouble is certainly faster than mpfr, but it seems likely that in
any application from with sage the python overhead will eat up most of
the speed difference. (quaddouble is certainly good thing to have
"underneath the hood", but I just don't know that there is much use to
having it externally visible.)
On Mon, 2008-04-28 at 17:16 -0700, mabshoff wrote:
>
>
> On Apr 29, 1:54 am, Francois <[EMAIL PROTECTED]> wrote:
> > On Apr 29, 11:33 am, mabshoff <[EMAIL PROTECTED]
>
> Hi Francois,
>
> > Hi Michael,
> >
> > The latest upstream release has the same default.
>
> Ok.
>
> >I try to get what upstream
> > offers and I didn't see any archives of old release like the one used
> > in sage.
> > What about "sloppy" mult and div? I don't really have any benchmarks
> > to offer
> > we should ask upstream about the gains and loses.
>
> We should fix either issue, even if we were to pay some penalty since
> correctness is more important than speed. Getting wrong results faster
> is kind of pointless.
>
> > 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.
>
> Cheers,
>
> Michael
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
