How big is the graph6 or sparse6 string? Can you just store that, along
with the vertex label and position dictionaries?
What is the autmorphism group? You may be able to uniquely identify each
I guess that's a bit harder question. It looks like sparse6 format just
uses the order of vertices returned by self.vertices(). The output is
always sorted, so you can just store the mapping by storing
(I haven't tried it, though...)
Another thing you could do is store it in the graph database that we
already distribute with Sage, or in an optional database that a user
could tap into. Both of those are a bit more work, but might open up
interesting future possibilities.
Can we include binary data files with Sage? I thought for some reason
this was frowned upon.
If we can include pickles, then I agree, pickling it would be the
It is frowned upon, but only if they can't easily be removed, and/or
easily recreated from some text form.
I've been meaning to add a script that takes an existing Sage tarball
and makes a "clean" binary-free tarball. This would mean removing the
pickle jar and all the hg repositories.
> If we can include pickles, then I agree, pickling it would be the
> easiest option.
We already include hundreds of pickles in the pickle jar, which is
used by doctesting to verify that new versions of sage don't break old
So really, the code to construct the graph should be there, but it
should just treat the pickle as a cached version of the output?
It sounds like this could be made more general, like a @cache_output
decorator that saves a pickle. We could ship Sage with or without those
pickles, or maybe we could just bundle all of the pickles into an spkg
that is a standard install.
Do you have any idea how it is possible to call the "load" function
from graph_generators.py ?
I cannot use "load" as the function is not defined yet, nor can I
directly write :
as sage is not defined at that time either...
When you start up Sage, a lot of things are imported automaticaly, but you
need to import them manually to use them from the library itself.
In this case you could do
from sage.structure.sage_object import load
Your graph should go somewhere in SAGE_ROOT/data/something...
On 22 Aug., 12:25, William Stein <wst...@gmail.com> wrote:
> No, use the SAGE_DATA variable, which is defined in misc/misc.py:Thank you, I didn't know about that one.
Is it for data that concern the whole Sage installation, or is it
specific to a single user (like DOT_SAGE)?
In the former case, probably it would also be the right place for my
group cohomology data base (that I currently put into SAGE_LOCAL/
pGroupCohomology/), wouldn't it?
But how can one tell setup.py that it is supposed to use SAGE_DATA?
'cause, if one has
name = "packagename",
then the data files seem to be copied to SAGE_ROOT/local/Folder and
SAGE_ROOT/local/Folder/Subfolder, if I'm not mistaken. Note, in
particular, that they all go into SAGE_LOCAL, not SAGE_DATA
Done, and it works.... But now I wonder how to build the patch, as
SAGE/DATA is not monitored.. :-)
I could also just attach it to the Trac ticket, and let it be merged
to Sage, as it does not seem worth building a spkg....
On Aug 22, 12:25 pm, William Stein <wst...@gmail.com> wrote:
> On Sat, Aug 22, 2009 at 1:56 AM, Simon King <simon.k...@nuigalway.ie> wrote:
> > Hi!
> > On 22 Aug., 10:11, Nathann Cohen <nathann.co...@gmail.com> wrote:
> > > Is there a variable defining the path of sage up to the current
> > > branch ?
> > There is SAGE_ROOT, and if I am not mistaken then SAGE_ROOT+'/devel/
> > sage/' is a link to the current mercurial branch.
> > But there is also a folder SAGE_ROOT+'/local/'. Your package could
> > create a sub-folder (this is what distutils would do for local data of
> > a package, IIRC) and store all its data in that sub-folder.
> No, use the SAGE_DATA variable, which is defined in misc/misc.py:
> sage: sage.misc.misc.SAGE_DATA
> Your graph should go somewhere in SAGE_ROOT/data/something...