Hellooo !!!
You are totally right about the performance issue, but do you know the
memory size of a Sage graph compared to dict of dict ? I have no idea -- I
have just been *VERY* scared by the size of a dict of dict compared to a C
array in the past.
Nathann
--
You received this
Le 02/01/2013 09:22, Nathann Cohen a écrit :
Hellooo !!!
You are totally right about the performance issue, but do you know the
memory size of a Sage graph compared to dict of dict ? I have no idea --
I have just been *VERY* scared by the size of a dict of dict compared to
a C array in
On 2013-01-01 14:05, -sam- wrote:
machine: AMD Athlon 64 X2 Dual Core Processor 5000+
operating system: Mandriva linux 2010.2 (32 bit)
This is a bug (or missing feature if you want) in Mandriva's version of
bash. The only workaround that I know is to install vanilla upstream bash.
--
You
On 2013-01-01 19:13, Rajeev Singh wrote:
I ran the tests again and this time only one test failed -
sage -t --long -force_lib devel/sage/sage/modular/modform/find_generators.py
There was a segmentation fault for this test. Sorry for the noise
about other tests earlier.
Could you apply the
On 2013-01-01 20:01, Volker Braun wrote:
The following ticket says that this was fixed in XCode 4.5. Are you sure
you don't have an old version floating around?
http://trac.sagemath.org/sage_trac/ticket/13309
It's also strange that nobody else reported this problem.
--
You received this
On 2013-01-01 21:31, Robert Zeier wrote:
I do not see how this would be possible as
I did upgrade Xcode to the latest version some time ago
and I have never installed a second version of Xcode:
Perhaps you still have some remnants of some old XCode on your system
which cause this problem. But
Heey!
Do we actually need to have a dict of a dict? Aren't sets implemented with
some other data structure? I suppose if networkX uses this approach then it
is doable!
Best,
Jernej
On Wednesday, 2 January 2013 09:22:08 UTC+1, Nathann Cohen wrote:
Hellooo !!!
You are totally right
Helloo !!!
Do we actually need to have a dict of a dict? Aren't sets implemented with
some other data structure? I suppose if networkX uses this approach then
it
is doable!
Oh. You wanted a dictionary of sets ?
Well, the main reason I have not rewritten this backend 10 times
I ended up patching also python and R in the same way as mercurial.
@Volker: Thanks for showing me how to do this.
Everything did build with the patches for mercurial, python, and R!
Am Mittwoch, 2. Januar 2013 10:08:11 UTC+1 schrieb Jeroen Demeyer:
On 2013-01-01 21:31, Robert Zeier wrote:
I
On 2013-01-02, Nathann Cohen nathann.co...@gmail.com wrote:
--20cf3003bcb0a9ec4404d24bbbff
Content-Type: text/plain; charset=ISO-8859-1
Helloo !!!
Do we actually need to have a dict of a dict? Aren't sets implemented with
some other data structure? I suppose if networkX uses
I suppose that for many graph algorithms the graph can well stay
immutable, and this does not really need a dictionary (perhaps at a
slight cost of efficiency of determining whether two vertices are
adjacent).
And many algorithms actually do not need the latter, as they parse the
Le 02/01/2013 13:54, Nathann Cohen a écrit :
I suppose that for many graph algorithms the graph can well stay
immutable, and this does not really need a dictionary (perhaps at a
slight cost of efficiency of determining whether two vertices are
adjacent).
And many algorithms actually do not need
On 31 dic 2012, 14:37, Julien Puydt julien.pu...@laposte.net wrote:
Hi,
it compiles well, except for conversion.c in libm4rie, which does
compile, but needs too much ram.
It passes all but three doctests (the gamma-related ones...).
I made a bdist available in the bdist/ directory of my
On Wednesday, January 2, 2013 2:41:14 PM UTC+1, mmarco wrote:
Is it available for download?
I don't know, if someone tells me where it is, I'll update the mirror with
the new version.
H
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
Le 02/01/2013 14:41, mmarco a écrit :
On 31 dic 2012, 14:37, Julien Puydt julien.pu...@laposte.net wrote:
I made a bdist available in the bdist/ directory of my home directory on
sage.math.washington.edu.
Is it available for download?
Well, as I said it's available on
On 1/2/13 6:29 AM, Thierry Dumont wrote:
The problem is that Python dictionaries are *very* slow. Do you know how
they are implemented?
a hash table:
http://hg.python.org/cpython/file/tip/Objects/dictobject.c
http://hg.python.org/cpython/file/tip/Include/dictobject.h
http://stackoverflow.com/questions/327311/how-are-pythons-built-in-dictionaries-implemented
has many good answers, it seems.
Wow. And they flagged it as non constructive. These guys are great.
Thank you very much Jason !!! O_O
Nathann
--
You received this message because you are subscribed
On Wed, Jan 2, 2013 at 4:24 PM, Julien Puydt julien.pu...@laposte.net wrote:
/home/jpuydt/bdist/sage-5.5-armv7l-Linux.tar.gz
ah, bdist :-)
thanks! file is being mirrored!
h
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To post to this group,
see inline.
On Wed, Jan 2, 2013 at 12:31 PM, Nathann Cohen nathann.co...@gmail.com wrote:
http://stackoverflow.com/questions/327311/how-are-pythons-built-in-dictionaries-implemented
has many good answers, it seems.
Wow. And they flagged it as non constructive. These guys are great.
Hello!
Has anyone already looked into this thing?
The bug appears to slow down all matrix computations related to pariGP. For
example it gets stuck computing the eigenvalues of a matrix as well. It's
quite annoying.
The pariGP guys confirmed it's a bug in pari so we should update the pari
On Jan 2, 5:29 am, Thierry Dumont tdum...@math.univ-lyon1.fr wrote:
The problem is that Python dictionaries are *very* slow. Do you know how
they are implemented?
That's an interesting observation. I think python developers have put
a lot of time into optimizing their dict structures, because
Thanks.
Should I open a trac ticket for this then?
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
On 1/2/13 5:54 AM, Nathann Cohen wrote:
I also prefer to write a good graph structure for my algorithms than
to use Sage's when it is worth spending the extra time :-)
FYI, often I will first convert a graph to a list of bitsets
representing the neighbors, then I use Cython to access the
On 1/2/13 10:22 AM, Nils Bruin wrote:
So perhaps your indices are slow
to hash? Or perhaps your code is written in such a way that there's
quite a bit of allocation/deallocation for lookup of a key (e.g. the
construction of a tuple)?
IIRC, our discussion is that the dict approach *is* the
On 1/2/13 11:56 AM, Jason Grout wrote:
To repeat the benchmark on my computer:
sage: G = graphs.RandomBarabasiAlbert(100,2)
sage: type(G.vertices()[0])
int
here is Sage's implementation:
sage: %timeit E = [(u,v) for u in G for v in G.neighbor_iterator(u)]
1000 loops, best of 3: 1.14 ms per
This was a cross post, but I didn't realize the original discuss wouldn't
be included. The discussion is at
https://groups.google.com/forum/?fromgroups=#!topic/sage-support/Ar7z2b5cOic
and, at its simplest, is that
R.y1,y2=PolynomialRing(Qp(5) ,2, order='lex')
G=[y1^2 + y2^2, y1*y2 + y2^2,
Helloo
A few more data points to narrow in on just the neighbors functionality:
We are definitely way behind when it comes to the enumeration of neighbors.
At the time we moved from default networkx backends to Sage's own
implementation, the point was more to improve the runtime of
Le 02/01/2013 18:22, Nils Bruin a écrit :
On Jan 2, 5:29 am, Thierry Dumont tdum...@math.univ-lyon1.fr wrote:
The problem is that Python dictionaries are *very* slow. Do you know how
they are implemented?
That's an interesting observation. I think python developers have put
a lot of time into
But anyway, why a hash table? In C++, to build these graph structures we
are talking about, I only use B-Tree based structures, for which we only
need to have an order (actually a weak ordering), and an order on pairs of
integers is something simple to compute;
Yeah. But we have labels to
I decided to do some profiling. And there is something that worries my
slightly more then the factor +/-10 difference in iteration speed that
caused the start of this topici. Namely conversion from a sparse sage graph
to a networkx graph seems to have quadratic runtime complexity instead of
I solved the problem by installing atlas-3.10.0 and recompiling numpy
and scipy. Now all the tests pass.
Rajeev
On Tue, Jan 1, 2013 at 11:43 PM, Rajeev Singh rajs2...@gmail.com wrote:
I ran the tests again and this time only one test failed -
sage -t --long -force_lib
31 matches
Mail list logo
