#18948: Strongly Regular Graphs database
-------------------------+-------------------------------------------------
Reporter: | Owner:
ncohen | Status: needs_review
Type: | Milestone: sage-6.8
enhancement | Resolution:
Priority: major | Merged in:
Component: graph | Reviewers:
theory | Work issues:
Keywords: | Commit:
Authors: | cf8f2dad1cd90ff5aaa0cec15a25f87c64289719
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
u/ncohen/18948 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by ncohen):
> How about functions like `is_paley()`? They also do not need `mu`...
If you think that this feature would be useful, I have nothing against
your adding it in another ticket. I do not see the point, as those
functions are not even meant to be called directly by users, who can do so
with 'strongly_regular_graph' (which can automatically guess 'mu' if
needed).
> By the way, what is the point of doing `return (lambda q :
PaleyGraph(q),v)` instead of
> `return PaleyGraph(v)` ?
That's in order to be able to tell if the construction *can* be done
without doing it (which can take quite some time). Very useful to know
which entries Sage can build to compare it to the list of those that are
known to exist. I used a design similar to the one used in
`sage.combinat.designs.orthogonal_arrays_find_construction`, where many
functions exist to *guess* the parameters of some constructions (exactly
like it is done here). With these design, knowing if something can be
built and getting the data to build it is done in the same operation.
There are two advantages:
1) No need of a 'exists=True' optional keyword when you call the function
2) No 'if exists' everywhere in the code's function, to return 'True'
instead of returning the graph
3) If you want to test the existence, THEN build the graph, you do not
call the function twice with different parameters (which would not use the
function's cache, and so you compute the decomposition twice).
Admittedly, the functions of the design code are computationally much more
expensive than those.
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/18948#comment:15>
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.
