On Sep 15, 8:16 pm, Bill Hart <[EMAIL PROTECTED]> wrote:
> All good questions.
>
> On 15 Sep, 18:26, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>
> > This is an interesting proposal. Would the user (of the Z_poly_t)
> > have control over what underlying representation is chosen?
>
> No. It would be automatic.
>
> > How would
> > it decide?
>
> At first it would make a decision solely based on whether or not
> memory allocation is likely to ask for too much memory when trying to
> do things the FLINT way. Because of the way fmpz_poly works, that's
> actually easy to implement. This will at least fix the problem David
> Harvey is worried about, which is a valid concern.
>
> Later on we'd have to add some heuristics for detecting sparse
> polynomials and polynomials with many small and a few very large
> coefficients, efficiently. I don't see any other way around it. Either
> SAGE has got to do this or FLINT has got to do it automatically. It's
> probably more efficient to have FLINT do it automatically.
>
> > Would there be automatic coercions from one type to
> > another doing arithmetic?
>
> Absolutely. But they would occur very rarely and be relatively
> efficient. There are already many automatic coercions that happen in
> FLINT's fmpz_poly module.
>
> > Would this slow the process to getting
> > FLINT "ready to go"?
>
> No. It's absolutely essential that we do something like this *before*
> FLINT is ready to go, or the problem David Harvey mentioned will
> become a major problem for SAGE.
>
> For the time being, I'll offer conversion functions to and from ZZX's,
> so SAGE can just treat a Z_poly_t as the FLINT polynomial type (it's a
> simple matter of doing a search and replace of fmpz_poly for Z_poly in
> your current pyrex file Robert) and away you go. That means I only
> have to implement this thin Z_poly layer for the functions you are
> currently working on putting into SAGE.
>
> Later I can add all of NTL's functionality to Z_poly, and then SAGE
> can do away with ZZX. But there's no requirement for that to happen
> immediately, and it's probably not wise until FLINT has undergone some
> more serious testing. But putting this thin layer over the NTL
> functions we don't currently implement is also not hard.
>
>
>
> > Also, would NTL then be a build requirement for FLINT?
>
> It would only be a build requirement when building the Z_poly module
> (which is what SAGE would use). And only for the time being, until we
> implement all the functions SAGE needs from NTL.
>
> > Would that
> > make FLINT into a C++ package? Or is this something on top of both?
>
> I don't know how to link C code with C++ code easily without compiling
> FLINT with g++.
Just do the following to the header files for FLINT:
#ifdef __cplusplus
extern "C"
{
#endif
. (the declaration of C-functions occurs
. here, e.g.:)
#ifdef __cplusplus
}
#endif
Then just include them from C++ as usual and call FLINT functions just
like in C.
> But this is only a matter of changing one line in the
> FLINT makefile. We'd still be developing FLINT as a C library, since
> this is a temporary fix until we get all of mpz_poly implemented. That
> will replace NTL at which point we can go back to compiling it using
> gcc.
>
> I'm some of the way through implementing this Z_poly_t layer already.
> I can do a little tonight, then I have to take a break from it for a
> few days. But then I can finish it off. It is an easy project and
> should only take a couple of days to code.
>
> Bill.
Let me know if you have some problems.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
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/
-~----------~----~----~----~------~----~------~--~---
