[sage-support] saving a java3d figure

2012-07-30 Thread entropy
Hi all!

How does one save an image created using java3d. Eg., 

T=Torus(1, .5, color='red',opacity=0.3)
T.show(aspect_ratio=1,frame=False,viewer='java3d')

displays a beautiful, interactive torus. But how can I save it?

thanks,
Jesse

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org


[sage-support] Re: sage graph -- why is c_graph so slow??

2011-12-30 Thread entropy
Nathann,

Many thanks! You're awesome! I looked at the patch, it looks tiny. :)
I'll try to test it asap. Having some patch application issues. :-|
Just in case you're familiar with this, I'll throw it out there. But
this is probably a job for google:

cd /Applications/sage/devel/sage  hg import   /Users/jberwald/src/
trac_12235.patch
applying /Users/jberwald/src/trac_12235.patch
patching file sage/graphs/base/c_graph.pyx
Hunk #1 FAILED at 2977
1 out of 1 hunks FAILED -- saving rejects to file sage/graphs/base/
c_graph.pyx.rej
patching file sage/graphs/digraph.py
Hunk #1 FAILED at 2561
1 out of 1 hunks FAILED -- saving rejects to file sage/graphs/
digraph.py.rej
abort: patch failed to apply

Thanks!
Jesse

On Dec 29, 10:48 am, Nathann Cohen nathann.co...@gmail.com wrote:
 Hell !!!

 and still much faster than the c_graph implementation.



 Well... I spent *quite* some time over this problem, wrote a LOT of code
 and documentation , to find out later that this could be solved in a *very
 small* patch. I hope all the work I did could be used later on anyway, but
 for the moment there should be no further worries about this SCC method. I
 created a patch for this just there [1], which you will find with some
 benchmarks.

 http://trac.sagemath.org/sage_trac/ticket/12235

 As a side note, I've also been

  testing subgraph functionality. Eg.,
   self.M.subgraph(self.rand_verts(K)), which maybe has a better
  implementation using subgraph_search() ??

 Nonononono ! This subgraph method has nothing to do with subgraph_search !
 The subgraph method takes as an argument a set of vertices and returns the
 graph induced by those vertices. The subgraph_search (and all the
 subgraph_search_* method) take as an argument *another graph*, and look for
 copies of this other graph inside of the first one. Which is dead harder :-D

  Anyways, I greatly appreciate your help with this. It would be great
  to be able to use Sage/Python to run all of our code.

 Please complain whenever you have the slightest thought that Sage may not
 be the best graph library in the world :-p

 Have fuun ! :-p

 Nathann

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org


[sage-support] Re: sage graph -- why is c_graph so slow??

2011-12-25 Thread entropy
Hi Nathann,
Thank you for the timely updates! I agree with you about the calls to
random. I can move those out of the timing portion. I suspected that
the passage to the backend was probably responsible for the slow speed
of the add/remove edge/vertices calls. The cost of method calls is
overhead I'm willing to swallow if the harder algorithms are
faster. :)
As for the scc() method, the _digraph() problem was my fault--I
didn't understand how scc_digraph() worked. Unfortunately, after
removing _digraph() the timings are just as bad. Sample below:
(1000 node graph)
scc() -- 10 trials: sage_cgraph 1362871.89 usec [ now computed using
self.M.strongly_connected_components() (see previous post in thread) ]
scc() -- 10 trials:    networkx    6015.06 usec I'm afraid I'm still
missing something crucial here? :-? Also, as a confirmation of your
argument concerning the calls to the backend, the Sage implementation
of NetworkX (implementation='networkx' instead of 'c_graph') does work
nearly as as fast as pure NetworkX after removing _digraph()--and
still much faster than the c_graph implementation.
As far as which functions/methods to benchmark, I am (or rather we
are) interested in a few specific graph algorithms, scc() among them.
That's why I've been picking on scc(). As a side note, I've also been
testing subgraph functionality. Eg.,
 self.M.subgraph(self.rand_verts(K)), which maybe has a better
implementation using subgraph_search() ??
Anyways, I greatly appreciate your help with this. It would be great
to be able to use Sage/Python to run all of our code.
Merry Christmas,Jesse
On Dec 25, 3:08 am, Nathann Cohen nathann.co...@gmail.com wrote:
 Oh yes, and something else about your benchmark : try to avoid using rand
 methods when you are doing one, especially when you test such low-level
 methods, because often the rand() method represents  an important part of
 the time.

 The best would be to compute all the random number you need in a first
 phase, then run %timeit on the add_edge part.

 Well, it probably will not reflect well on Sage because it should increase
 the differences between the libraries, but I think that it is very
 important in your benchmark, To give you an idea :

 sage: from numpy import random as rnd
 sage:
 sage: g = Graph(500)
 sage: def rand_entry(G):
 :     ...    n = G.order()
 :     ...    i = rnd.randint(0,n-1)
 :     ...    j = rnd.randint(0,n-1)
 :     ...    G.add_edge(i,j)
 :     ...    G.delete_edge(i,j)
 :
 sage: def just_rand(G):
 :     ...    n = G.order()
 :     ...    i = rnd.randint(0,n-1)
 :     ...    j = rnd.randint(0,n-1)
 :     ...    return i*j
 :
 sage: %timeit rand_entry(g)
 625 loops, best of 3: 20.4 µs per loop
 sage: %timeit just_rand(g)
 625 loops, best of 3: 4.93 µs per loop

 So 20% of the time used by this test method is actualy used by calls to
 random() :-)

 Nathann

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org


[sage-support] Re: sage graph -- why is c_graph so slow??

2011-12-24 Thread entropy
Hi Nathan,

Thanks for looking into this. I believe that I stayed within Sage's
library when I wrote my test code. The general outline and some
classes were originally written by a collaborator (I don't want to
take credit, but I'll take responsibility where there are errors!) I
couldn't find a way to attach files, so I've pasted the two classes
below (plus a base class):

SAGE
sage_cgraph_tester.py:

import numpy as np
from numpy import random as rnd
from sage.all import DiGraph
from tester import Tester

class Tester_sage_cgraph( Tester ):
def __init__(self):
self.name = 'sage_cgraph'

def set_graph(self,E,N):
self.N = N
self.M = DiGraph(N, implementation=networkx ) #c_graph,
sparse=True)
self.M.add_edges(E)

def rand_row(self,R):
i = self.rand_vert()
self.M.add_edges([(i,self.rand_vert()) for j in range(R)])

def rand_col(self,R):
i = self.rand_vert()
self.M.add_edges([(self.rand_vert(),i) for j in range(R)])

def rand_entry(self):
i = self.rand_vert()
j = self.rand_vert()
if not self.M.has_edge(i,j):
self.M.add_edge(i,j)

def subgraph(self,K):
self.M.subgraph(self.rand_verts(K))

def scc(self):
self.M.strongly_connected_components_digraph()

NETWORKX
networkx_tester.py (originally coded by my collaborator, but I'll take
full responsibility for any errors :) ):

import numpy as np
from numpy import random as rnd
import networkx
from tester import Tester
import rads_nx

class Tester_networkx(Tester):

def __init__(self):
self.name = 'networkx'

def set_graph(self,E,N):
self.N = N
self.M = networkx.DiGraph()
self.M.add_nodes_from(range(N))
self.M.add_edges_from(E)

def rand_row(self,R):
i = self.rand_vert()
self.M.add_edges_from([(i,self.rand_vert()) for j in range(R)])

def rand_col(self,R):
i = self.rand_vert()
self.M.add_edges_from([(self.rand_vert(),i) for j in range(R)])

def rand_entry(self):
i = self.rand_vert()
j = self.rand_vert()
if not self.M.has_edge(i,j):
self.M.add_edge(i,j)

def subgraph(self,K):
networkx.subgraph(self.M,self.rand_verts(K))

def scc(self):

networkx.algorithms.components.strongly_connected_components(self.M)

The base class Tester is in tester.py:

import numpy as np
from numpy import random as rnd

class Tester:
def rand_vert(self):
return rnd.randint(0,self.N-1)

def rand_verts(self,R):
return rnd.randint(0,self.N-1,R)

The NetworkX and Sage graph testers are initialize as follows:

G = networkx.read_adjlist('testmat%i.adjlist' % (N))
N = len(G.nodes())
E = G.edges()
E = map(lambda x: (int(x[0]),int(x[1])), E)

print 'initializing testers... ',
tester.set_graph(E,N)

Operations are timed using the timeit module. Eg.,

 test_str = 'testers[%i].%s(%s)' % ( tester, test['F'],test['args'] )
 timer = timeit.Timer( test_str, import_str),

where test['F'] is the method names and test['args'] contain any
necessary args.

Thanks again for your help.

Happy holidays!
Jesse

On Dec 23, 6:43 pm, Nathann Cohen nathann.co...@gmail.com wrote:
 Hello Jesse !

 Well, for a start it wouldn't be very fair to compare graph libraries if
 you do not use our graph methods and recode your own ! You seem to have
 rewritten your version of strongly connected components to test the
 libraries, and such low-level methods are in Sage written in Cython, so
 this kind of running times are only those you would get if you use Sage
 graphs but refuse to use any of the methods present in the library :-D

 This being said, I just did some tests and if they are far from being as
 bad for Sage as yours are, I was quite disappointed myself. I was under the
 impression we were leaving NetworkX far behind, and it looks like we
 actually are behind in some cases, which will need to be fixed. Could I ask
 you to provide examples of codes which have different running times for
 NetworkX and Sage ? I guess you only use the add/remove edge/vertices
 methods in your code, which may be the explanation. When you are doing that
 you are actually calling Cython methods through Python functions, and
 spending more time calling methods than actually getting the job done
 Though to be honest I do not want to have to explain why Sage is slower, I
 would like to show that it is faster :-)

 Hence, if you can provide the code, we could begin to talk about the
 technical reasons.

 Good night !

 Nathann

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 

[sage-support] sage graph -- why is c_graph so slow??

2011-12-23 Thread entropy
Hi all,

I'm benchmarking some graph libraries. I was excited to see that
Sage's graph library has a backend implemented in Cython.
Unfortunately, it seems to be orders of magnitude slower than a pure
NetworkX implementation. Here a code summary:

import networkx

# read in test adjacency matrix using networkx
 G = networkx.read_adjlist('testmat%i.adjlist' % (N))
 N = len(G.nodes())
 E = G.edges()
 E = map(lambda x: (int(x[0]),int(x[1])), E)

# set up test object
 tester.set_graph(E,N)

The tester object is either of two classes, Tester_networkx or
Tester_sage_cgraph, both of which set up the graph G in their
respective implementations. For instance, if N is the number of nodes,
tester is initialized as follows:

import networkx
...
self.M = networkx.DiGraph()
self.M.add_edges_from( range(N) )
self.M.add_edges(E)

or

from sage.all import DiGraph
…
self.M = DiGraph(N, implementation=c_graph) # tried sparse=True,
similar results
self.M.add_edges(E)

I am seeing the following timing results for the two different
implementations:

On a 1000 node graph, adding edges from node i to 100 randomly chosen
nodes (slowest of 100 trials):

 networkx 298.02 usec
 sage_cgraph 749.83 usec

Things get very bad when looking for strongly connected components
(slowest of 10 trials):

scc() -- 10 trials:
networkx5846.98 usec

scc() -- 10 trials:
sage_cgraph 1363383.05 usec  (231x networkx)

I tried changing the Sage Graph implementation to networkx, hoping
to see identical behavior to the pure NetworkX version. Unfortunately,
it is somewhere in between:

scc() -- 10 trials:
 sage_networkx  104291.92 usec  (20x networkx)

I'm assuming I must be doing something wrong to see such large
differences. Any ideas??

Thanks for your help,
Jesse

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org


[sage-support] An error occurred while installing python-2.6.4.p11

2011-12-08 Thread entropy
Hi all,

I'm attempting to build Sage on a SUSE Enterprise 10 (SLES 10)
cluster. I have run ./configure as follows:

./configure SAGE_FORTRAN_LIB=/usr/lib/libgfortran.so.1 SAGE_FORTRAN=/
usr/bin/gfortran CXX=g++ CC=gcc

The error is related to the install of python2.6. Why did configure
choose /local/scr/jberwald/TMPDIR/poG7ZVuA?

Any help would be greatly appreciated.

Thanks,
Jesse

 from install.log 

Extracting package /sciclone/home04/jberwald/src/sage-4.7.2/spkg/
standard/python-2.6.4.p11.spkg ...
-rw-r- 1 jberwald mathf 11748536 2011-07-05 07:28 /sciclone/home04/
jberwald/src/sage-4.7.2/spkg/standard/python-2.6.4.p11.spkg
Finished extraction

Host system
uname -a:
Linux ty71 2.6.16.53-0.16-smp #1 SMP Tue Oct 2 16:57:49 UTC 2007
x86_64 x86_64 x86_64 GNU/Linux


CC Version
gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --
with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/
share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-
languages=c,c++,objc,fortran,obj-c++,java,ada --enable-
checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --
enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --
with-system-zlib --enable-shared --enable-__cxa_atexit --enable-
libstdcxx-allocator=new --program-suffix= --enable-version-specific-
runtime-libs --without-system-libunwind --with-cpu=generic --
host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)

Patching src/setup.py for multiarch.
patch:  Can't create file /local/scr/jberwald/TMPDIR/poG7ZVuA :
Permission denied
Error patching src/setup.py

real0m0.011s
user0m0.000s
sys 0m0.004s
sage: An error occurred while installing python-2.6.4.p11

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org


[sage-support] Re: An error occurred while installing python-2.6.4.p11

2011-12-08 Thread entropy
I meant to say make instead of ./configure.

On Dec 8, 9:52 am, entropy jberw...@gmail.com wrote:
 Hi all,

 I'm attempting to build Sage on a SUSE Enterprise 10 (SLES 10)
 cluster. I have run ./configure as follows:

 ./configure SAGE_FORTRAN_LIB=/usr/lib/libgfortran.so.1 SAGE_FORTRAN=/
 usr/bin/gfortran CXX=g++ CC=gcc

 The error is related to the install of python2.6. Why did configure
 choose /local/scr/jberwald/TMPDIR/poG7ZVuA?

 Any help would be greatly appreciated.

 Thanks,
 Jesse

  from install.log 

 Extracting package /sciclone/home04/jberwald/src/sage-4.7.2/spkg/
 standard/python-2.6.4.p11.spkg ...
 -rw-r- 1 jberwald mathf 11748536 2011-07-05 07:28 /sciclone/home04/
 jberwald/src/sage-4.7.2/spkg/standard/python-2.6.4.p11.spkg
 Finished extraction
 
 Host system
 uname -a:
 Linux ty71 2.6.16.53-0.16-smp #1 SMP Tue Oct 2 16:57:49 UTC 2007
 x86_64 x86_64 x86_64 GNU/Linux
 
 
 CC Version
 gcc -v
 Using built-in specs.
 Target: x86_64-suse-linux
 Configured with: ../configure --enable-threads=posix --prefix=/usr --
 with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/
 share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-
 languages=c,c++,objc,fortran,obj-c++,java,ada --enable-
 checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --
 enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --
 with-system-zlib --enable-shared --enable-__cxa_atexit --enable-
 libstdcxx-allocator=new --program-suffix= --enable-version-specific-
 runtime-libs --without-system-libunwind --with-cpu=generic --
 host=x86_64-suse-linux
 Thread model: posix
 gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
 
 Patching src/setup.py for multiarch.
 patch:  Can't create file /local/scr/jberwald/TMPDIR/poG7ZVuA :
 Permission denied
 Error patching src/setup.py

 real    0m0.011s
 user    0m0.000s
 sys     0m0.004s
 sage: An error occurred while installing python-2.6.4.p11

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org