#16362: Orthogonal Polar Graph
-------------------------------------+-------------------------------------
Reporter: ncohen | Owner:
Type: enhancement | Status: positive_review
Priority: major | Milestone: sage-6.3
Component: graph theory | Resolution:
Keywords: | Merged in:
Authors: Nathann Cohen | Reviewers: Dima Pasechnik
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/ticket/16362 | ff7d3387b4436411ed6785e2a3b6c5c37f2ca1f6
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by dimpase):
Replying to [comment:48 ncohen]:
> Yooooooooo !!
>
> > No, you are simply misled by %time here.
>
> And by {{{sage -t}}} too.
>
> > I am not forcing anything. Certainly, you can convince me to change
it, or change it yourself. I gave you a number of arguments (readability
of the code, robustness) why there is an advantage to use libGAP. You
dismissed them all without any reasons, except that "slowdown".
>
> Well, yes. This is a reason that is reminded to me every time I start
Sage and create those strongly regular graphs. It is a down side for me, a
user of that code.
>
> > I may give you one more argument: my code makes sure that the finite
fields used by GAP and by Sage are the same (mathematically). Your code
does not really address this. Your code relies on an assumption, that
currently appears to be true (well, at least I think so) that GAP and Sage
use the same algorithm, based on Conway polynomials.
>
> You did not mention this before.
I did mention this in comment 4 above.
> Do you think that a lot of code in Sage is based on this assumption ?
I am not sure. There are ways to make sure that the same field is used in
GAP and in Sage with the classical interface. E.g. get the GAP's defining
polynomial:
{{{
sage: gap.GF(4).DefiningPolynomial()
x_1^2+x_1+Z(2)^0
}}}
and use it to create Sage's field.
>
> > What you appear to have suggested that you accept my code only to
change it later, in another branch, with another reviewer. And I found
this very worrying, as this undermines the way Sage reviews work.
>
> Indeed. Be worried of what may happen with the Graph code in Sage, it is
clearly unsafe when I am around.
>
> > You did not ask me to remove my commit. You asked me to change a part
of the code that relies on libGAP, didn't you?
>
> Indeed, I asked you to remove that part. Do you really believe that all
this discussion is about the typos that you fixed ?
>
> > Indeed, what is happening on this ticket is very abnormal, and you
might force me to draw attention to it on sage-devel.
>
> You keep mentionning this as if you thought that it might be a problem
for me. If you have something to bring up on sage-devel send an email. I
am not doing anything secret here that I would not want to be known.
>
> When I rape and commit murder, I usually don't mention it on public
tickets.
>
> I mean. There were exceptions, of course...
This discussion DID cost me a couple of hours of sleep, FYI :-)
>
> > I merely mentioned this to draw your attention to the fact that
arguing about the startup speed of something which is at best a prototype
implementation is silly.
>
> In what world do you live ? I *do not know* how to implement this, and
if I did it would still be a massive amount of work that I have no reason
to do, because it is totally useless to me.
Useless? You would hate to be able to work with polar graphs on 10000
vertices?
--
Ticket URL: <http://trac.sagemath.org/ticket/16362#comment:52>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
