#7013: [with code, needs work] prime_pi and nth_prime
----------------------------------------+-----------------------------------
Reporter: kevin.stueve | Owner: kevin.stueve
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.1.3
Component: number theory | Keywords: primes, sieve, table,LMO
Work_issues: | Author: Kevin Stueve
Reviewer: was,robertwb,GeorgSWeber | Merged:
----------------------------------------+-----------------------------------
Comment(by GeorgSWeber):
Hi Kevin,
to continue, we firstly need some fundamental design decisions.
As I understand it (please correct me, if I'm wrong), your code resp. its
functionality depends on C code written by T. Oliveira e Silva. (BTW, I
like the original name "prime_sieve.c" as given on
"http://www.ieeta.pt/~tos/software/prime_sieve.html"; better than
"Silva.c".) This is only one rather small C file, but nevertheless ---
Sage is written in Python/Cython, not C. Currently, you compile this C
code into an executable, which is called more or less directly from the
command line (piping input and output). To include this C code (resp. its
functionality) into Sage, I see (at least) four options:
1.) Keep the interfacing via commandline call --- this would mean that we
need to stick this code into its own spkg
2.) Make a shared/dynamic library out of the C code, sitting in/installed
by its own spkg, and write a small Cython wrapper, that links this library
in --- interfacing is no longer done via command line, but via function
call
3.) Write a small Cython wrapper, in order to interface via function call,
and stick the bulk of the C code into the corresponding Cython extension
(via "module_list.py" magic) as an external C file
4.) Rewrite it completely in Cython
Once this decision is made for the prime sieve C code of T. Oliveira e
Silva, it has to be made again for the Lagarias-Miller-Odlyzko "lmonew"
parts from Victor Miller, which also are written in plain C. If a new spkg
is created at all, it also could be placed there (either as another
standalone executable to be compiled, or as another library). But one
could use a step-by-step approach, leaving "lmonew" out in the first shot,
and include it back only later, as an update.
All four options are valid. The main decision is, whether we want to
create a new Sage spkg out of (parts of) the C code (options 1 and 2), or
not (options 3 and 4). I definitely think William should make this
decision (he has started and supervised this prime_pi stuff, and is the
Sage BDFL anyway) --- poke him about that.
Cheers, Georg
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7013#comment:12>
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
-~----------~----~----~----~------~----~------~--~---
