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 l
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 ./in
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 2013
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 wrote:
>> > For info, I'm trying to build Sage on a Debian sparc64, and it failed
>> >
On Thursday, February 28, 2013 10:41:15 PM UTC+1, Dr. David Kirkby wrote:
>
> On 28 February 2013 16: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
>
On 28 February 2013 16: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 o
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 = 463
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
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 27,
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,
On 2013-02-28, kcrisman 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 reviewers and
> 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
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
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 be
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,
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 faile
> 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 mov
On Thu, Feb 28, 2013 at 9:19 AM, luisfe wrote:
> On 28 feb, 17:26, 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..
>>
> 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
>
>
> 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 th
On 28 feb, 17:26, 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 others, but I wouldn't want to be
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 reviewe
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 f
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 o
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 s
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::" mar
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
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 reasons),
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 t
29 matches
Mail list logo
