Loading Gap Packages in SAGE
DelD...@gmail.com
I want to do some work with Braid groups. I see that there is a GAP
package called CHEVIE which implements braid elements.
I tried installing the CHEVIE package in GAP4, but failed (I'm new to
GAP, so I can't really say what went wrong, but this package is
advertised as a GAP3 package. Does that matter? Also, CHEVIE is not in
the list of 'accepted packages' on the GAP webiste).
I would like to be able to do my work with this in SAGE. Any advice on
getting this package to work with GAP in SAGE, or, perhaps, any
recommendation of another package supporting Braids would be
appreciated.
Thanks,
-Dorian
David Joyner
Chevie in SAGE I think you must do the following:
(1) install GAP3 into SAGEHOME/local/lib (which may or may not
be possible on your machine - see Frank Luebeck's page for hints),
(2) install Chevie in GAP3,
(3) modify the gap.py pexpect module in the interfaces subdirectory
to call gap3 instead of gap4,
*or*
(4) translate all of Chevie from GAP3 to GAP4.
Unfortunately, both options are non-trivial.
+++++++++++++++++++++++++++++++++++++++++++
Dorian Raymer
I installed the all-in-one gap3r4p4.zoo into SAGEHOME/local/lib
I ended up using the gap-ibm-i386-linux-gcc precompiled binary they provided (compiling from src failed, but this binary worked on my system, which is kubuntu7.04) I ran some example code the install readme provided as a test, and it succeeded.
I edited the gap.sh for the sage environment and put a symlink in SAGEHOME/local/bin
I made a branch of sage so I could experiment with the gap.py pexpect interface...
It turns out that gap3 and 4 have different command line options (among other differences), so the sage interface was pretty broken. I got to the point where at least the gap3 console would start in sage, (it looked just like it did in the bash shell! (joking)).
After playing around with omitting different command line flags and disabling things related to saving and loading gap workspaces, the interface started to show signs of life! (i.e. there was no failure in spawning the gap process)
I called the version method 'gap.version()' and it returned the right thing (stuff about version 3). Unfortunately, evaluation of expressions (like n=gap(2323)) return 'Syntax error: expression expected'. Also, I tried tab-completing something and then everything blew up.
Are you familiar with the differences in the two versions? Is there something simple you know of to try to fix this (besides your suggestion (4))? Or is the interface maybe just too incompatible with gap3? Or did I do something wrong in my installation/hack process?
Thanks for your help. I'm guessing not too many people will want to be able to do this, so it's probably not a big deal/problem for sage.
-dorian
David Joyner
> I tried installing and using gap3 in sage, and this is what happened:
>
> I installed the all-in-one gap3r4p4.zoo into SAGEHOME/local/lib
>
> I ended up using the gap-ibm-i386-linux-gcc precompiled binary they
> provided (compiling from src failed, but this binary worked on my system,
> which is kubuntu7.04) I ran some example code the install readme provided as
> a test, and it succeeded.
>
> I edited the gap.sh for the sage environment and put a symlink in
> SAGEHOME/local/bin
>
> I made a branch of sage so I could experiment with the gap.py pexpect
> interface...
>
> It turns out that gap3 and 4 have different command line options (among
> other differences), so the sage interface was pretty broken. I got to the
> point where at least the gap3 console would start in sage, (it looked just
> like it did in the bash shell! (joking)).
> After playing around with omitting different command line flags and
> disabling things related to saving and loading gap workspaces, the interface
> started to show signs of life! (i.e. there was no failure in spawning the
> gap process)
This is great.
> I called the version method 'gap.version()' and it returned the right thing
> (stuff about version 3). Unfortunately, evaluation of expressions (like
> n=gap(2323)) return 'Syntax error: expression expected'. Also, I tried
What about gap("2323")? Does that fail too? What about gap.eval("2323")?
> tab-completing something and then everything blew up.
Don't try tab-completion. That part of the interface was written by
Steve Linton and William Stein and I think is highly non-trivial.
>
> Are you familiar with the differences in the two versions? Is there
> something simple you know of to try to fix this (besides your suggestion
> (4))? Or is the interface maybe just too incompatible with gap3? Or did I do
> something wrong in my installation/hack process?
I think you've made great progress but I'm at sagedays4 in Seattle now
and can't install gap 3 on my intel macbook to test any ideas.
Worst-comes-to-worst, I would ask Steve Linton (I'm ccing him)
for suggestions but maybe you basically have it except that your
pexpect interface needs a bit more tweeking.
>
> Thanks for your help. I'm guessing not too many people will want to be able
> to do this, so it's probably not a big deal/problem for sage.
I am interested in this and would be very interested in detailed step-by-step
instructions on how to install Chevie in SAGE.
Dorian Raymer
What about gap("2323")? Does that fail too? What about gap.eval("2323")?
gap.eval("2323") works, as does gap.eval("RequirePackage(\"chevie\")"), although the latter returns a raw, unformatted/unpretty string indicating the package loaded.
I am interested in this and would be very interested in detailed step-by-step
instructions on how to install Chevie in SAGE.
-Dorian
William Stein
> Sorry for the delay in response.
>
> > What about gap("2323")? Does that fail too? What about gap.eval("2323")?
>
> gap("2323") also returns the same Syntax error.
>
Just to add to this thread, Steve Linton wrote some clever C code for
the kernel of gap 4 in order to make some special "pexpect mode" work
better. For a long time we distributed a patched version of gap 4 with that
code in it. I'm sure gap 3 won't have that code, and this might have
something to do with the problems you are noticing.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
Nikos Apostolakis
> Chevie is a GAP3 package, not GAP4. (Yes it matters.) To using
> Chevie in SAGE I think you must do the following:
[...]
> *or*
> (4) translate all of Chevie from GAP3 to GAP4.
>
> Unfortunately, both options are non-trivial.
How hard is this option?
I would be interested to help with such a translation if needed.
Best,
Nikos
David Joyner
It is needed and is one of the most frequently asked questions on the
GAP support list.
The "hardness" depends on your programming expertise, energy level, and
knowledge of Lie theory. The chevie web page
http://www.math.rwth-aachen.de/~CHEVIE/chevie-gap.html
discusses the topics covered (though you probably know that).
Another option is to try to translate the GAP3 Chevie code directly to
SAGE/Python,
instead of GAP4. If you choose to go the GAP4 route, I strongly
suggest contacting Frank Luebeck at Aachen.
>
> Best,
> Nikos
>
>
> >
>
Nikos Apostolakis
> On 6/19/07, Nikos Apostolakis <niko...@gmail.com> wrote:
>>
>> "David Joyner" <wdjo...@gmail.com> writes:
>>
>> > Chevie is a GAP3 package, not GAP4. (Yes it matters.) To using
>> > Chevie in SAGE I think you must do the following:
>>
>> [...]
>>
>> > *or*
>> > (4) translate all of Chevie from GAP3 to GAP4.
>> >
>> > Unfortunately, both options are non-trivial.
>>
>> How hard is this option?
>>
>> I would be interested to help with such a translation if needed.
>
> It is needed and is one of the most frequently asked questions on the
> GAP support list.
>
> The "hardness" depends on your programming expertise, energy level, and
> knowledge of Lie theory.
I guess that none of the three qualities are high enough for me to
attempt to do the whole thing by myself -- I believe I can contribute if
such a project was to start though.
> The chevie web page
> http://www.math.rwth-aachen.de/~CHEVIE/chevie-gap.html
> discusses the topics covered (though you probably know that).
> Another option is to try to translate the GAP3 Chevie code directly to
> SAGE/Python,
> instead of GAP4.
I think this makes sense. Then all of chevie could be translated:
not only the gap part but the Maple part as well. From that point
of view it seems that SAGE is the natural place for chevie. For
practical considerations though, probably gap3 --> gap4 is an easier
translation, no?
> If you choose to go the GAP4 route, I strongly
> suggest contacting Frank Luebeck at Aachen.
>
I'll contact him before I start working on it.
Thanks,
Nikos