On Mar 11, 2010, at 2:24 PM, Robert Bradshaw wrote:
On Mar 11, 2010, at 1:37 PM, William Stein wrote:
On Thu, Mar 11, 2010 at 1:10 PM, Robert Bradshaw
<rober...@math.washington.edu> wrote:
On Mar 11, 2010, at 12:36 PM, Mike OS wrote:
Thanks for all the comments, links on gap and Sage.
Rob, the two tracs on abelian groups and unit groups of rings are
just what we were wondering about. We'll look at them and see if
we
can do something. Please do send the worksheet you mentioned on
unit
groups.
What was the difficulty with subgroups?
Some questions:
[A warning: I'm not that adept with computational software, so some
questions may be naive. I'm relying on smart students on this
project!]
A fundamental issue is not clear to us: To what extent
functionality
for groups be sent via libgap to gap, vs doing things in Sage
itself?
Would the longterm (or midterm) goal be to have the Sage groups
package be mainly an efficient conduit to gap?
That's how it's currently structured (minus the efficient part)
and it has
several shortcomings. I would say a good example is how we use
Pari for
number fields. For basic arithmetic and simple functions, we use
native code
rather than wrap Pari objects all over the place. For the "heavy
lifting"
(e.g. computing class groups) we call off to Pari and get the
results
back--this is part of the philosophy of not re-inventing the
wheel. New code
is often written natively in Sage. I would imagine Sage would have
native
implementations of permutation groups, matrix groups, etc. and
call of to
Gap for things like solving the word problem, but not for basic
arithmetic
(or, in particular, for anything that could be done faster than
converting
the question into a string and parsing it both ways--libgap as it is
currently is still string-based).
If by "libgap" you mean the C library interface to GAP that I wrote
(and I call "libgap"), then I disagree with the above. I think it
could easily be suitable for basic arithmetic of elements, just like
PARI can be (e.g., we use pari for finite fields when there aren't
faster options). If you create two permutations in libgap, you can
multiply them by doing a single C library call, and it's really fast
(in fact, much faster than using the Pari library interface, since
there is no weird memory management overhead). The same goes for
arithmetic with any other elements defined in libgap. The only
way
in which strings are used in initially creating new objects, where
strings are an option.
I had thought that libgap was just hooking into the interpreter
loop, but looking at http://trac.sagemath.org/sage_trac/attachment/ticket/6391/trac_6391-part2.patch
I see it's much more. I still think native implementations have
advantages as well, but I'll leave design decisions up to those
actually developing (and using) the groups packages.
On the ironic side, I just found out 30% of the runtime of my program
was spent calling off to gap to compute the exponent of an abelian
group with known invariants (rather than using LCM).
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
