Hello all!
Right now, the _repr_ method for posets returns a very generic statement:
sage: Posets(4)[0]
Finite poset containing 4 elements
This makes two posets with the same number of elements indistinguishable
from their _repr_. I would like to change this. Possible suggestion:
Poset on n
Hi!
Homsets are used whenever a coercion or conversion map is involved, hence,
they are uniquitous in Sage and should thus be fast. Before I try to
convert homset.py into homset.pyx, I'd like to ask, because I suppose
people have already tried to make it Cython: Is there a reason why the
Hi everybody!
Actually because in sage-on-gentoo we use the system boost we hit that
particular doctest failure a long time ago. I then asked Alexander Dreyer
who
works on polybori if the output was ok and it didn't seem to be concerned.
Indeed, you can safely ignore the changes in the
The bug also occurs on Sage 5.7, and a quick-and-dirty bisection
script shows that n = 46341 does work and n = 46342 does not. Since
46341 is almost exactly the square root of 2^{31}, and the relevant
bits of code seem to use C int variables rather than Sage integers
(presumably for speed
Hey,
The problem is the align environment: it is not meant to be used in math
mode, but rather as a way to enter math mode instead of \[ \] delimiters
(or $$ $$ delimiters, etc.). Using the .. math:: markup tells Sphinx that
the following code should be typeset in math mode, and then using
On Thursday, February 28, 2013 10:46:37 AM UTC-5, Travis Scrimshaw wrote:
Hey,
The problem is the align environment: it is not meant to be used in math
mode, but rather as a way to enter math mode instead of \[ \] delimiters
(or $$ $$ delimiters, etc.). Using the .. math:: markup tells
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR (and MPFR and
MPC) decided to be smart enough to build as 64 bits, and then when Sage
tried to build its own GCC, which is 32 bits, it failed...
Exporting ABI=32
Hello!
I have noticed (at least in the fields to which I made some small
contributions) that the number of reviewers is arbitrary. Sometimes there
is only one reviewer sometimes two, three..
I cannot speak for others, but I wouldn't want to be the only reviewer of a
patch since I am quick to
On Thursday, February 28, 2013 11:26:20 AM UTC-5, Jernej Azarija wrote:
Hello!
I have noticed (at least in the fields to which I made some small
contributions) that the number of reviewers is arbitrary. Sometimes there
is only one reviewer sometimes two, three..
I cannot speak for
Helloo !!!
I have noticed (at least in the fields to which I made some small
contributions) that the number of reviewers is arbitrary. Sometimes there
is only one reviewer sometimes two, three..
I cannot speak for others, but I wouldn't want to be the only reviewer
On 28 feb, 17:26, Jernej Azarija azi.std...@gmail.com wrote:
Hello!
I have noticed (at least in the fields to which I made some small
contributions) that the number of reviewers is arbitrary. Sometimes there
is only one reviewer sometimes two, three..
I cannot speak for others, but I
The point is that I would be totally amazed if #12224 were to (ever) be
reviewed. Do you think that it could be reviewed twice ? :-P
Do not despair, my pet bug #10255 has the patch ready since two years
ago... ugh, that hurts. Anyone willing for reviewing it? :D
--
You received this
Do not despair, my pet bug #10255 has the patch ready since two years
ago... ugh, that hurts. Anyone willing for reviewing it? :D
Aahaah. Come on, your patch seems realistically reviewable ! 12224 weighs
1.3 MB :-D
Nathann
--
You received this message because you are subscribed to the Google
On Thu, Feb 28, 2013 at 9:19 AM, luisfe lftab...@yahoo.es wrote:
On 28 feb, 17:26, Jernej Azarija azi.std...@gmail.com wrote:
Hello!
I have noticed (at least in the fields to which I made some small
contributions) that the number of reviewers is arbitrary. Sometimes there
is only one
A single reviewer adds a lot of value, but the marginal benefit per
reviewer goes down quickly while the marginal cost goes up. That being
said, if you don't feel confortable giving something a positive
review, just leave some comments (perhaps even setting it to needs
work) and move
Jean-Pierre Flori wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR (and MPFR
and MPC) decided to be smart enough to build as 64 bits, and then when
Sage tried to build its own GCC, which is 32 bits, it
Good comments, Nathann, though some papers are read more than others :)
Ahahaah. Yeah, but research publications (at least in my field) are read by
three reviewers and buried forever, never to be read again. Sage's code is
doctested, and used.
THREE reviewers? Most of mine have had ONE,
Y !
Good comments, Nathann, though some papers are read more than others :)
Yepyep, definitely. Some smart ones. And it's actually because they are
read many times by guys who actually want too understand that you believe
them rather easily. A bit like we can trust some Sage code
On Thursday, February 28, 2013 7:06:18 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR (and MPFR
and MPC) decided to be smart enough to build as 64 bits,
A single reviewer adds a lot of value, but the marginal benefit per
reviewer goes down quickly while the marginal cost goes up. That being
said, if you don't feel confortable giving something a positive
review, just leave some comments (perhaps even setting it to needs
work) and move
On 2013-02-28, kcrisman kcris...@gmail.com wrote:
--=_Part_444_3892362.1362074924783
Content-Type: text/plain; charset=ISO-8859-1
Good comments, Nathann, though some papers are read more than others :)
Ahahaah. Yeah, but research publications (at least in my field) are read by
three
On 2013-02-28 17:12, Jean-Pierre Flori wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR (and MPFR
and MPC) decided to be smart enough to build as 64 bits, and then when
Sage tried to build its own GCC,
I've asked him in fact, but he is currently not working on it.
Bosman's code certainly performs well on the case which has been done by
him. This error occurs only on my computation, which seems too cumbersome
as far as it goes.
Anyway, thanks for all your advice.
On Wednesday, February
On Thursday, February 28, 2013 9:55:54 PM UTC+1, Jeroen Demeyer wrote:
On 2013-02-28 17:12, Jean-Pierre Flori wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR (and MPFR
and MPC) decided to be
That sounds quite reasonable. I try to read the code again and search a
solution. Thank you very much.
On Thursday, February 28, 2013 2:05:07 PM UTC+1, David Loeffler wrote:
The bug also occurs on Sage 5.7, and a quick-and-dirty bisection
script shows that n = 46341 does work and n = 46342
On 28 February 2013 16:12, Jean-Pierre Flori jpfl...@gmail.com wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR (and MPFR and
MPC) decided to be smart enough to build as 64 bits, and then when Sage
tried
On Thursday, February 28, 2013 10:41:15 PM UTC+1, Dr. David Kirkby wrote:
On 28 February 2013 16:12, Jean-Pierre Flori jpf...@gmail.comjavascript:
wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
because by default gcc produces 32 bits objects but then MPIR
On Thursday, February 28, 2013 11:38:24 PM UTC+1, Jean-Pierre Flori wrote:
On Thursday, February 28, 2013 10:41:15 PM UTC+1, Dr. David Kirkby wrote:
On 28 February 2013 16:12, Jean-Pierre Flori jpf...@gmail.com wrote:
For info, I'm trying to build Sage on a Debian sparc64, and it failed
I got a working gcc by exporting ABI=32 so that MPIR is 32 bits and
issueing sparc32 make rather than make so that GCC does not try to
build 64 bits apps by default, the build is now going one with other spkg.
On Thursday, February 28, 2013 9:55:54 PM UTC+1, Jeroen Demeyer wrote:
On
But only on one of the two machines.
On the other one it segfaulted later during gc build:
/sage-5.7-lame5/local/sparc-unknown-linux-gnu/sys-include-g -O2 -O2 -g
-O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem
Sage 5.7 on Ubuntu 12.04.2
sage:
integral(e^(-abs(x))/cosh(x),x,-infinity,infinity)
2*log(2)
sage: integral(e^(-abs(x))/cosh(x),x,-infinity,infinity)
---
ValueErrorTraceback (most recent call
31 matches
Mail list logo
