#19661: the srgs from Cossidente and Penttila construction of hemisystems in
H(3,q^2)
-------------------------+-------------------------------------------------
Reporter: | Owner:
dimpase | Status: needs_review
Type: | Milestone: sage-7.0
enhancement | Resolution:
Priority: major | Merged in:
Component: graph | Reviewers:
theory | Work issues:
Keywords: | Commit:
Authors: | 16f1f711fce54ae770c81dd957e5cad2baea8fe1
Report Upstream: N/A | Stopgaps:
Branch: |
public/19661 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by ncohen):
Okay, before anything let's be clear: I won't give a review to this patch
if it injects 10 lines of GAP code. Perhaps you will find somebody who
will, but I will not. Now let us discuss.
> Nothing fuzzy - it's the right tool for the job. You don't know a better
one, right? In fact many functions in this file would've become much
cleaner, had I known about it then...
It may be a necessary tool for libgap, and I quite agree that this
function is necessary. I claim that it is not necessary here, and in
particular that the mathematical features you need from gap should not be
called *directly* from gap, and that we should instead expose in the Sage
mathematical objects those features from GAP that you need.
This code could then be Sage/Python code that calls other Sage/Python
functions. Those other functions may have reasons to rely on this
`function_factory` function, or they may not. I have absolutely no idea a
priori, and neither do I have any objection to that a priori.
> > What I mean is that there are apparently some mathematical
computations tht you do not know how to perform with Sage only.
>
> yes, I do know how to do them in Sage, in C, or on a Turing machine if I
must...
> But it's suboptimal, for reasons of efficiency, and of the code length.
We try to build a software that can handle all kind of maths. If you must
inject GAP code to get it to do what you want, then it means that we
should expose some feature somewhere. At least that's how I interpret it.
> Well, every time I talk to you guys about a graph backend that can do
things with symmetric graphs as good as GRAPE does it in Sage, I don't
hear cheers and screams "yes, let's do it!" I rather hear "hmm, how do we
remove an edge then" or something equally compelling...
I don't feel guilty of not writing your code for you.
On the other hand, I have to admit that I still do not know what you
exactly want this backend to be. So no, I don't feel terribly overjoyed
when you answer my "you code is ugly" remarks with "it's because we don't
have a backend for symmetric graphs".
Which, again, would not simplify in any way your need for GAP code
injection.
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/19661#comment:29>
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.
