#12449: Improve the way that sage evaluates symbolic functions on basic types
---------------------------+------------------------------------------------
Reporter: bober | Owner: bober
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: symbolics | Keywords: gamma function
Work_issues: | Upstream: N/A
Reviewer: | Author: bober
Merged: | Dependencies:
---------------------------+------------------------------------------------
Changes (by newvalueoldvalue):
* status: new => needs_review
* author: => bober
* cc: Snark (added)
* component: basic arithmetic => symbolics
Old description:
> There are numerical inaccuracies in the gamma function on python floats
> on some platforms. See, e.g.
> http://groups.google.com/group/sage-
> devel/browse_thread/thread/3c8c61ea113ea60c
>
> Also, the current implementation is slower than it should be on basic
> types:
>
> {{{
> sage: timeit('gamma(6.0r)')
> 625 loops, best of 3: 32 µs per loop
> sage: timeit('gamma(6r)')
> 625 loops, best of 3: 44.3 µs per loop
> sage: timeit('gamma(6.0)')
> 625 loops, best of 3: 22.9 µs per loop
> sage: timeit('gamma(6)')
> 625 loops, best of 3: 3.29 µs per loop
> }}}
New description:
Currently when a symbolic function (e.g. gamma(), exp(), sin()) gets a
python float, it passes it off to ginac, and let's ginac evaluate it. This
can be very slow, e.g.:
{{{
sage: timeit('exp(6.0r)')
625 loops, best of 3: 476 µs per loop
}}}
This also leads to possibly undesirable inconsistencies across different
platforms: for example, ginac ends up calling the local libc tgammal to
evaluate the gamma function, and even when this tgammal is evaluated by
the same version of eglibc on two different platforms the answer varies
depending on whether 80 bit doubles are available.
To fix this, we make Sage check its types which correspond most closely to
python type for the function that should be called, and use the functions
for those types if available.
Now we have
{{{
sage: timeit('exp(6.0r)')
625 loops, best of 3: 1.02 µs per loop
}}}
For the specific case of the gamma function, the is also a change here to
make RDF use python's math.gamma(). It is more accurate than gsl. It is
perhaps not as accurate as eglibc's gamma(), but it should give reliable
results on different platforms.
I think this will fix 3 of the 4 failing numerical accuracy doctests on
ARM, though the test for binomial(.5r, 5) had to be weakened slightly.
(see http://groups.google.com/group/sage-
devel/browse_thread/thread/3c8c61ea113ea60c ) binomial() is currently not
computed in a very good way, though, so it is reasonable to weaken this
test temporarily. (see http://trac.sagemath.org/sage_trac/ticket/12448 )
Finally, I'll remark that these improvements could probably be much
better. The above timings should be compared to
{{{
sage: timeit('math.exp(6.0r)')
625 loops, best of 3: 112 ns per loop
}}}
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12449#comment:1>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
