#7013: [with patch, needs work] prime_pi and nth_prime
-----------------------------+----------------------------------------------
Reporter: kevin.stueve | Owner: kevin.stueve
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.3
Component: number theory | Keywords: primes, sieve, table,LMO
Work_issues: | Author: Kevin Stueve
Upstream: N/A | Reviewer: was,robertwb,GeorgSWeber
Merged: |
-----------------------------+----------------------------------------------
Comment(by GeorgSWeber):
I'm glad that things are moving on!
Technically, there are various open points, e.g. the line 105 of the
modified da Silva code
{{{
m = (unsigned long) malloc(size + 255); // this assumes that sizeof(void
*) = sizeof(u32)
}}}
still looks suspicious to me w.r.t. 64bit platforms, since there,
sizeof(void *) usually is sizeof(u64). It might be benefical to do
something like
{{{
m = calloc(size/(64*sizeof(void *)), 64*sizeof(void *))
}}}
and we haven't even discussed the memory leakage question yet, since all
this "bucket" memory is never explicitly freed again ... (important if we
want to use the code as a library). Let alone "exit 1;" (line 107) in case
of memory shortage being suboptimal in a Sage subroutine.
OTOH, having read the "rough first patch", and thinking about it, I guess
we can't avoid creating a new spkg. It would be the optimal solution
anyway, no doubt about that, but currently I have no idea how the
data/prime_pi_tables/ could be handled otherwise in any clean way. (Of
course we could stick them too under sage/functions/, including them into
"Manifest.in", and so on, but I see this as a last resort only before this
work comes to a halt.) Last, but not least, the spkg way is "the" way to
make a library out of the da Silva "prime_sieve" functionality. How to
create such a library/spkg? It's probably easiest I just do it and say
"look and see", before trying to explain it in lengthy terms.
William recently has set up quite strict rules for the inclusion of new
spkgs, especially that there are to be individuals that are willing to
maintain these for the next one to two years, say. I cannot do that alone,
but might volunteer to be part of a team doing it. Anybody joining to form
a tag team? Let me know.
Cheers,
Georg
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7013#comment:14>
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.
