An earlier topic on the same problem is
http://groups.google.com/group/sage-devel/browse_thread/thread/2821c770f3c62efd
Apparently True*2 was fixed (now returns 2), but True*SR(2) wasn't
(still returns 1). I think Robert Bradshaw made the patch back then,
so he knows how to fix this (something to
Hi!
This is related with #9583.
If the patch from #1396 is applied, Sage segfaults on t2 at startup.
It seems that the offending part of the code is in sage/libs/singular/
option.pyx.
I thought that Cython generates C code, which is then processed
further with gcc. But in this case, it seems
Hi!
This is related with #9583.
If the patch from #1396 is applied, Sage segfaults on t2 at startup.
It seems that the offending part of the code is in sage/libs/singular/
option.pyx.
I thought that Cython generates C code, which is then processed
further with gcc. But in this case,
On Jul 25, 1:50 am, Marco Streng marco.str...@gmail.com wrote:
[...]
I like the TypeError here to avoid bugs, but don't mind following
python convention either.
http://docs.python.org/library/warnings.html
Maybe using (soft) warnings in the interim (while maintaining
workarounds) could be a
Nathann,
Using the following instead fixes the problem:
g.add_edges( (Mod(i,n),Mod(i+j,n)) for i in range(n) for j in range(1,k+1) )
This is more consistent, since we are actually using the same vertex
objects. However, that should just work, right? Why doesn't it?
This is coming from the code
On Sun, Jul 25, 2010 at 02:06:11AM -0700, Simon King wrote:
Hi!
This is related with #9583.
If the patch from #1396 is applied, Sage segfaults on t2 at startup.
It seems that the offending part of the code is in sage/libs/singular/
option.pyx.
I thought that Cython generates C code,
Hi!
On 25 Jul., 11:29, François Bissey f.r.bis...@massey.ac.nz wrote:
...
c++ is requested in module_list.py.
I see. Probably it has to be c++. But still, shouldn't it g++ rather
than gcc, then?
What compiles what is decided
by distutils. I don't observe this problem...
Me neither, not
Hello !!!
This is coming from the code around line 1000 of c_graph, which goes
from vertex labels to ints and back. The IntegerMod case was not in
mind when this code was written. The real problem is that when the
Python int 0 gets passed to get_vertex, it does not add the entry to
the
Nathann,
I understood from your explanation why Mod(1,n) is considered
different from 0, and it is to me the correct behaviour... But what
about this
g has 21 vertices
len(g.vertices) == 20 ?
Sorry if you answered already ! :-)
I think the information was there, but I was not very clear.
Nononon, I understood why there are two copies of what appears to
be a zero, and I think it's fine like that !
My question was about the number of vertices as remembered by the graph :
in one case, it says 21, but g.vertices() is only long of 20 elements.
Why aren't there two zeroes in
Hi,
After
1. copying the following to the directory sage-4.5.1/spkg/standard
http://boxen.math.washington.edu/home/kirkby/patches/readline-6.1.spkg
2. Installing the system-wide readline-dev package for your linux
distro.
sage compiles successfully in Opensue 11.3.
Thanks,
Jae
On
On Sun, Jul 25, 2010 at 2:01 PM, Nathann Cohen nathann.co...@gmail.com wrote:
Nononon, I understood why there are two copies of what appears to
be a zero, and I think it's fine like that !
This is definitely *not* fine, since we have
sage: int(0) == Mod(0, 20)
True
As input, the
On Sun, Jul 25, 2010 at 10:27 AM, Robert Miller r...@rlmiller.org wrote:
On Sun, Jul 25, 2010 at 2:01 PM, Nathann Cohen nathann.co...@gmail.com
wrote:
Nononon, I understood why there are two copies of what appears to
be a zero, and I think it's fine like that !
This is definitely *not*
On Sun, Jul 25, 2010 at 8:10 PM, Carl Witty carl.wi...@gmail.com wrote:
You seem to want to make the vertex dictionary respect the equivalence
relation defined by Sage equality. If so, you're going to be in
trouble, since Sage equality actually is not an equivalence relation:
Is it really too
Hello,
Ticket #9590 fixes a problem with hashing; it looks like the hash value
in the doctest is 32- or 64-bit specific, and of course it fails on
systems that don't match. The solution there is to change a doctest like
sage: hash(foo)
574575757575
into
sage: hash(foo)
On Sun, Jul 25, 2010 at 6:33 PM, Dan Drake dr...@kaist.edu wrote:
Hello,
Ticket #9590 fixes a problem with hashing; it looks like the hash value
in the doctest is 32- or 64-bit specific, and of course it fails on
systems that don't match. The solution there is to change a doctest like
On Sun, 25 Jul 2010 at 07:11PM -0700, Carl Witty wrote:
Hmm... looks like the current state of affairs is a mess. Looking
through the 'def __hash__' grep hits in sage/rings, there are quite a
few of each of the following:
1) no doctest at all
2) provide both 32-bit and 64-bit doctests
3)
On Jul 14, 5:30 pm, Nathann Cohen nathann.co...@gmail.com wrote:
Has this
already been done, or should I file a patch for this?
If you would be so kind... I saw no mention of it until I read your
message :-)
Done, including patch, at
http://trac.sagemath.org/sage_trac/ticket/9598
Also,
On Sun, Jul 25, 2010 at 8:11 PM, Dan Drake dr...@kaist.edu wrote:
On Sun, 25 Jul 2010 at 07:11PM -0700, Carl Witty wrote:
Hmm... looks like the current state of affairs is a mess. Looking
through the 'def __hash__' grep hits in sage/rings, there are quite a
few of each of the following:
1)
If you make a binary with sage -bdist, and then try to do sage
-sdist in the resulting tree, you get a perfectly good tarball, but it
won't build Sage, since the tarball doesn't have a spkg/base directory.
I just learned this the hard way, as my 4.5.2.alpha1 tree started out
somehow as a bdist'ed
On Sunday, July 25, 2010, Dan Drake dr...@kaist.edu wrote:
If you make a binary with sage -bdist, and then try to do sage
-sdist in the resulting tree, you get a perfectly good tarball, but it
won't build Sage, since the tarball doesn't have a spkg/base directory.
I just learned this the hard
21 matches
Mail list logo
