Re: [sage-support] avoiding startup time cost with multiple invocations

On Wed, 10 Jan 2018, Berkeley Churchill wrote: (@Jori: unfortunately starting one process and doing all the computations at once won't work for us because we need to dynamically generate the n+1st computation based on the output of the nth computation.  We could theoretically port all that log

Re: [sage-support] avoiding startup time cost with multiple invocations

Thanks Vincent, this seems like it's in the right direction. One possible solution would be to combine the embedded python interpreter with some error handling (as Jori suggested) and wrap all the computations in functions to act as a namespace for variables. Can you explain to me what the sa

[sage-support] Bug in graphs.WheelGraph(3).show().

sage: graphs.WheelGraph(3).is_isomorphic(graphs.CompleteGraph(3)) True But graphs.WheelGraph(3).show() show(Graph(graphs.WheelGraph(3).edges())) is OK. So I do not kno

Re: [sage-support] avoiding startup time cost with multiple invocations

Have a look at https://docs.python.org/2/extending/embedding.html The following does work for me 1. Create a test.c file with {{{ #include int main(int argc, char *argv[]) { Py_SetProgramName("python"); /* optional but recommended */ Py_Initialize(); PyRun_SimpleString("from sage.all

Re: [sage-support] avoiding startup time cost with multiple invocations

On Wed, 10 Jan 2018, Berkeley Churchill wrote: As part of a research project we're using sage as a subroutine for some matrix computations over rings.  We have hundreds or thousands of these computations, but each computation is fairly quick.  Right now, for each computation we write python co

[sage-support] avoiding startup time cost with multiple invocations

As part of a research project we're using sage as a subroutine for some matrix computations over rings. We have hundreds or thousands of these computations, but each computation is fairly quick. Right now, for each computation we write python code into a .sage file, and then start a new proce