I ran lots of benchmarks before starting this post, I should have  
included them. Here they are some typical ones:

%pyrex
def foo(R, a, b, c, n):
     cdef int i
     a = R(a); b = R(b); c = R(c)
     for i from 0 <= i < n:
         z = a.sin().sin()

sage: time foo(RR, 3, 4.5, 200, 10^5)
CPU time: 2.58 s,  Wall time: 2.62 s
sage: time foo(RDF, 3, 4.5, 200, 10^5)  # this is using the GSL sin()  
function, _not_ the clib one.
CPU time: 0.11 s,  Wall time: 0.14 s

%pyrex
def foo(R, a, b, c, n):
     cdef int i
     a = R(a); b = R(b); c = R(c)
     for i from 0 <= i < n:
         z = a*b + b*c + c*a

sage: time foo(RR, 3, 4.5, 200, 10^5)
CPU time: 0.30 s,  Wall time: 0.31 s
sage: time foo(RDF, 3, 4.5, 200, 10^5)
CPU time: 0.15 s,  Wall time: 0.14 s


%pyrex
def foo(R a, b, c, n):
     cdef int i
     a = R(a); b = R(b); c = R(c)
     for i from 0 <= i < n:
         z = a/b + b/c + c/a

sage: time foo(RR, 3, 4.5, 200, 10^5)
CPU time: 0.33 s,  Wall time: 0.35 s
sage: time foo(RDF, 3, 4.5, 200, 10^5)
CPU time: 0.14 s,  Wall time: 0.15 s


Perhaps some more tests are in order, but I think the arithmetic vs.  
object-creation-time ratio for RDF is huge, and has more room for  
optimization (given the simple structure) than even the integers had  
(and it would be much easier). As for using SageX to do the  
benchmarks, I think that often if one cares about speed, the  
functions you will be passing such arguments into will be written in  
SageX.

This was actually all a footnote to the main question of the original  
post, namely having an UnparsedLiteralDecimal class used by the  
preparser to avoid awkwardness like

sage: RealField(100)('1.2') == RealField(100)(1.2)
False

I've received (good) feedback on this issue from only two people.

- Robert



On Mar 28, 2007, at 4:54 PM, William Stein wrote:

> On 3/28/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>>> If we decide that we value portability but not necessarily  
>>> precision,
>>> we could use RDF but avoid using C library implementations of the
>>> mathematical functions.  (Currently, RDF uses the C library for  
>>> tan(),
>>> acos(), asin(), atan(), cosh(), sinh(), tanh(), according to a quick
>>> scan of real_double.pyx -- I may have missed some.)  We would also
>>> want to verify that the GSL implementations are portable across
>>> architectures, and do something about 32-bit x86.
>>
>> I'm leaning towards this too. There area actually fpu_fix_* functions
>> in the quad double package to handle 32-bit x86 that might be useful
>> to look at.
>
> My impression of the discussion so far is this:
>    * There is a vague impression that RDF is "vastly faster" than  
> RR (mpfr),
>       so people are considering changing things so RDF is the  
> default 53-bit
>       real field in SAGE, purely for efficiency reasons.
>    * There is no discussions so far about actual benchmarks, and  
> how much
>       faster RDF really is.
>    * RDF  (=machine floats) mostly uses the C library float
>       special functions that are potentially very
>       inaccurate in comparison to mpfr special functions, so the  
> suggestion
>       is to maybe make RDF use better special functions.
>
> I did a few benchmarks (see below), and 53-bit RR mpfr arithmetic in
> the interpreter is maybe 10% slower than RDF, i.e., arithmetic doesn't
> make enough of a difference to warrant even considering switching to
> RDF from RR.  I then did benchmarks with some trig functions and there
> RDF is vastly faster, over 20 times faster in one benchmark.
>
> Conclusion: The only justifiable reason to switch to RDF for the
> default 53-bit real field is to speed up special function evaluation.
> But ironically, the fast special functions fror 53-bit floats have
> serious quality and precision issues, so we probably wouldn't switch
> unless we made them better, which will necessarily make them much
> slower (?).
>
> Benchmarks:
>
> {{{
> %time
> a = RDF(1.5); b = RDF(27.3)
> for i in range(10^6):
>     c = a*b + a+b + a-b
> ///
> CPU time: 2.09 s,  Wall time: 3.33 s
> }}}
>
> {{{
> %time
> a = RR(1.5); b = RR(27.3)
> for i in range(10^6):
>     c = a*b + a+b + a-b
> ///
> CPU time: 2.14 s,  Wall time: 3.95 s
> }}}
>
> {{{
> %time
> a = RDF(1.5); b = RDF(27.3)
> for i in range(10^6):
>     c = a*b
> ///
> CPU time: 0.58 s,  Wall time: 1.06 s
> }}}
>
> {{{
> %time
> a = RR(1.5); b = RR(27.3)
> for i in range(10^6):
>     c = a*b
> ///
> CPU time: 0.69 s,  Wall time: 0.97 s
> }}}
>
> {{{
> %time
> a = RDF(1.5); b = RDF(27.3)
> for i in range(10^6):
>     c = a.sin() * b.cos()
> ///
> CPU time: 1.64 s,  Wall time: 3.01 s
> }}}
>
> {{{
> %time
> a = RR(1.5); b = RR(27.3)
> for i in range(10^6):
>     c = a.sin() * b.cos()
> ///
> CPU time: 22.17 s,  Wall time: 36.39 s
> }}}
>
> 

--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---

Reply via email to