#20107: Add optional gap3_jm package
-------------------------------------+-------------------------------------
Reporter: stumpc5 | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.1
Component: packages: | Resolution:
experimental | Merged in:
Keywords: gap3, optional | Reviewers:
package | Work issues:
Authors: Christian Stump | Commit:
Report Upstream: N/A | ec01e305ae9dd29b90234183ad7b309172646ea6
Branch: u/stumpc5/20107 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by dimpase):
Replying to [comment:114 jmichel]:
> Replying to [comment:113 dimpase]:
> > Replying to [comment:112 jmichel]:
> > > Replying to [comment:107 stumpc5]:
> > > > Replying to [comment:104 dimpase]:
> > > > > IMvHO it is better to invest time into porting chevie to GAP4
than into this...
> > > >
> > > > Jean Michel clearly has a meaning about that, after not doing it
in 20 years...
> > >
> > > I asked for a new password, so I can reply myself.
> > > I examined several times over the past 15 years a possible port of
Chevie to GAP4.
> > > My conclusions:
> > > -it would be as much work as rewriting everything completely,
> >
> > Really? What are the crucial features you miss in GAP4 that are used
in Chevie?
> >
> > I use GAP (and hack a bit on it, too) for some 23 years, and I saw
transitions of packages like GRAPE from GAP3 to GAP4 without too much
pain. You don't need to make use of new GAP4 features, good old records
are still there.
>
> First, I should tell you that I looked at the problem of porting chevie
with Frank Luebeck, and he agrees with my conclusions. This is not the
place/time to give a detailed answer, but roughly:
> chevie contains about a hundred different types of mathematical objects,
which in gap3 are just records with a certain .operations fields, and
methods are just functions which dispatch based
> on various features, and then call the appropriate component field of
the .operations record. The way a new type of objects or a method is
constructed in GAP4 is completely different.
But you don't need this new type of objects!
>The worst of it is that any effort (which has been done by various
people) to port any substantial part of chevie (a few hundred lines) to
gap4 almost always produce longer and uglier code.
>
> > I (half)ported ve and anusq to GAP4, it was certainly not very
trivial, but quite doable and quick.
>
> I wanted to thank you for your modifications to the makefile in ve (It
seems you did not change anything else?). It also seems that you changed a
few lines in one gap function in anusq to translate it to gap4. I am sorry
to say that this is completely trivial compared to rewriting the several
hundred thousand lines of chevie.
Wow, I really appreciate the way you talk about my work :-)
If you cared to look at the diff of my changes to ve you could have seen
the changes done in full glory, OK?
https://github.com/gap-packages/ve/coommits/master
(the are mostly about switching to modern GMP, if you must know)
Whereas your GAP3 code would just work in GAP4, with very minimal and
trivial changes.
--
Ticket URL: <http://trac.sagemath.org/ticket/20107#comment:115>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
