On Jan 4, 2007, at 3:43 PM, David Harvey wrote:
On Jan 4, 2007, at 6:03 PM, William Stein wrote:
On Thu, 04 Jan 2007 13:40:19 -0800, Bill Hart
<[EMAIL PROTECTED]> wrote:
It occured to me that the best way to provide this stuff directly to
SAGE, and improve a whole raft of other things is to include our
code
in the SAGE version of Pari. But it occurs to me (just now) that
this
might be ill advised, given that many SAGE objects are not
implemented
through Pari, but through NTL. Unfortunately, integrating our
code into
NTL is not an option.
I'm happy if people think they can write wrappers etc in time,
to have
SAGE just work directly with FLINT objects. Polynomial
multiplication
should be working by Monday-ish. But how I proceed might depend
on what
people think about this. So, should I:
a) Try and incorporate FLINT into the SAGE pari; or
b) Keep writing FLINT and let someone else figure out how to
incorporate FLINT directly.
The advantage of (a) is that heaps of stuff gets sped up, since
heaps
of stuff in Pari is built on polynomial arithmetic. The
disadvantage is
that some NTL stuff will want to be changed over to Pari stuff
in SAGE.
The advantage of (b) is probably a faster end product and less
work for
me. The disadvantage is it only benefits basic arithmetic, i.e.
factoring, polynomial multiplication and integer multiplication and
stuff *in SAGE* that depends on any of the above.
I greatly prefer (a). Less of SAGE uses NTL than you might
think, and using
PARI in those places is easier (generally using PARI for SAGE is
quite easy).
Also, it will be tremendously exciting that the PARI included in
SAGE will
be much faster than the stand-alone PARI :-).
I definitely agree that (a) would be wonderful to have.
Nevertheless, I think we should concentrate on (b) first. My
reasoning is as follows.
First of all, FLINT doesn't even really exist yet. We have a bunch
of source files which maybe kind of compile on a bunch of systems,
if you fiddle with the makefile a bit. And sometimes they
multiply polynomials and integers really fast, and sometimes if
you are lucky they don't even segfault, and in many cases they
even get the correct answer.
Second, we eventually want to have both (a) and (b). We want (a)
because of the excellent reasons Bill mentioned above. We want (b)
because it means less overhead for polynomial objects in SAGE.
i.e. for exactly the same reason that SAGE uses mpz_t objects
directly instead of using PARI integer objects. (Also, don't
forget (c), which is to have FLINT as a standalone library that
doesn't require either SAGE or PARI.)
Third, I claim that (b) is going to be much easier to implement
than (a). This is my own personal bias, because I can see step-by-
step how it could be done; it is straightforward. PARI integration
sounds much harder. For a start it's not even clear to me how we
would be representing data. PARI already has its own data
structure for representing polynomials. Are we supposed to rewrite
our code to use its polynomial data type? Or do we convert between
the formats on the fly? Or do we change PARI to use our data type?
Is PARI designed to let you throw in new kinds of data structures
and memory management strategies? Do we have to store our data on
the PARI stack, or can we go with the heap, as our custom memory
manager currently does? Perhaps William Stein is well-placed to
offer an opinion on which of (a) and (b) would be easier, since he
knows the SAGE codebase very well (!), and he has plenty of
experience programming with PARI too. I've never programmed PARI,
so it's difficult for me to tell. And Bill has never programmed
SAGE, so it's difficult for him to compare too.
If someone can convince me that I'm wrong about PARI integration
being much more difficult, then I could be persuaded to change my
mind.
But if I'm right about that, then I reckon it is too early in the
FLINT development cycle to consider a big project like integrating
it into PARI. I would rather that we first do the easier job of
getting a SAGE data type that wraps FLINT polynomials, and
concentrate our development efforts on getting FLINT solid, more
functional, better tested, more portable. And then later come back
to PARI integration.
I reiterate, eventually both (a) and (b) will happen. It's just a
question of timing, and where our development resources are best
aimed.
David
You beat me too it--I think (a) and (b) are not at all mutually
exclusive, but it will probably pushing it to have the easier of the
two by sage 2.0. I think (b) would be very straightforward--I don't
know what the data structure is for FLINT, but I'd imagine there's
get_coefficient(mpz_t*, size_t), set_coefficient(mpz_t*, size_t) (or
similar variations), and the basic arithmetic that could be wrapped
with pyrex very easily.
On that note, I am realizing I don't even know, for instance, what
specific rings you're implementing polynomials over. Could you make a
list on http://sage.math.washington.edu:9001/FLINT (and the other
stuff FLINT will have, at least round 1)?
--~--~---------~--~----~------------~-------~--~----~
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-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
