On Sun, 15 Oct 2006 16:17:19 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
>> But SAGE pretty much has to do that,
>> as there is no package which offers everything. I understand that. But
>> this means there will be *some* limitations to what SAGE can offer
>> if I am not mistaken.
The limitations are on the interpreter part of SAGE. But SAGE is not
just the interpreter -- it's:
(1) a collection of software and C/C++ libraries
(2) a new computer algebra system (the Python/Pyrex libraries)
(3) interfaces to other math software.
It's important to keep all three aspects of SAGE in mind for this
discussion.
SAGE is an attempt to answer Gonzalo Tornaria's question: "if I design a
new
algorithm, what should I implement it in". My answer is to implement it
as something
that can be built in the SAGE environment (with the SAGE libraries etc.),
and which
provides an easy-to-use documented interface to the SAGE command line, so
people
can very easily use it.
> Absolutely there are limitations. As I said above, everything
> directly visible to the user needs to go via Python objects, and
> that's a fundamental bottleneck.
>
> On the other hand, there is nothing stopping us from writing C code
> in subroutines underneath. A good example is the work on exactly
> linear algebra being done at the moment. We're writing a bunch of
> generic python matrix classes, with specialised C versions (currently
> pyrex) for doing e.g. matrix arithmetic over Z/nZ for word-sized n.
With proper documentation, etc., there is nothing stopping
any user from writing speed-critical parts of their code in C. A big
part of what SAGE provides is a coherent collection of C/C++ accessible
libraries, with *lots* of examples (in Pyrex code mostly) of how to use
them. The Python-interpreter access to this functionality is often
useful, but it is not the only goal of SAGE (see above).
Even if you never touch the Python interpreter for your work or
contributions
to SAGE, you could create a very useful C library, which others
who write for "the SAGE collection of libraries" would greatly appreciate.
>> I don't plan to contribute directly to NTL at present. Although I
>> *could* speed up some of the algorithms within the context of NTL
>> itself (gcd, extgcd, modinvert, CRT so far seem to be the biggest
>> winners there), that would only be piecemeal optimization. The real
>> advantages in runtime come from changing the fundamental
>> implementation
>> strategy of NTL itself (something Victor no doubt would have strong
>> opinions about). That means a rewrite from the ground up, though
>> obviously the further you get from GMP basic types, the more the
>> library begins to look like NTL and become compatible with it.
>
> If you can write a library that's better than NTL, then SAGE will
> welcome it.
I second that!
> Also, it would not be necessary to rewrite everything. SAGE uses all
> kinds of libraries in bits and pieces. For example, if you could
> duplicate the most important functionality in ZZ_X, then we could
> talk to that directly without using NTL for that at all.
>
> But this is a big project, it's not the kind of thing anyone can pull
> off overnight. Victor Shoup knows his stuff and has obviously put a
> lot of time into it.
That said, I wouldn't underestimate what is possible. I've seen
some absolutely amazing mathematical programming happen, when the
timing is right and there is sufficient will power.
William
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
