#4151: [with patch, with partial review] implementation of Dickman's function
---------------------------+------------------------------------------------
Reporter: robertwb | Owner: was
Type: enhancement | Status: new
Priority: major | Milestone: sage-3.1.3
Component: number theory | Resolution:
Keywords: |
---------------------------+------------------------------------------------
Changes (by davidloeffler):
* summary: [with patch, needs review] implementation of Dickman's
function => [with patch, with partial review]
implementation of Dickman's function
Comment:
OK, I changed setup.py and ran sage -ba and everything worked. I'm puzzled
by what you say about the build problems being an OS X issue: I'm running
SuSE Linux 10.3.
All doctests pass fine, but there are a couple of funny things:
- The definition states that rho(0) is 1 by definition, but your
implementation gives
{{{
sage: dickman_rho(0)
0.000000000000000
}}}
I encountered this while trying to replicate the plot on the Wikipedia
page, which fails nastily because log(rho(0)) is undefined.
Also, as discussed for Bessel functions at ticket #4102, it would be nice
if the new dickman_rho function derived from calculus.PrimitiveFunction,
as otherwise it doesn't play nicely with compositions etc:
{{{
sage: plot( log(dickman_rho(x)), (x, 0.0001, 15) )
# fails
sage: plot( lambda x: log(dickman_rho(x)), (0.001, 15))
# works, but not very intuitive for new users
}}}
Reading the code added to functions/transcendental.py, it's elegant and it
obviously works, but it seems to throw away information in one case.
Suppose I calculate dickman_rho(x) to d digits of precision. Then I want
to know dickman_rho(y) to e digits, where y is slightly bigger than x (or,
rather, bigger than 1.1x + 10) but e is *much* smaller than d. Then the
code empties the cache and goes ahead and recalculates all of the power
series from scratch, despite the fact that it already knows the first few
terms to more than enough precision. I don't know if the added
complication of getting around this problem is worth it; you'd have to
remember not just current_prec() but the precision of the calculation of
each series term. I guess in practice it's not something that's likely to
be a problem.
Also, perhaps the instance variable self.f should be self._f, since it's
very much for internal use. On a related note, perhaps it might be better
to have a hidden function _compute_power_series, which avoids users having
to know about this mysterious extra argument cache_ring, with a
corresponding non-hidden function power_series() that takes only 2
arguments rather than 3.
Anyway, I've uploaded a second patch which does the above attribute
hiding, and returns 1 rather than 0 for rho(0); with these small changes
I'd be more than happy to see this patch included, although I'm not sure
my very limited Sage development experience gives me the authority to say
this!
I wonder if there are other parts of the existing Sage library that would
benefit from using native MPFR polynomials, in place of Sage polynomials
over the MPFR real field?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/4151#comment:3>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
