= Forewords =
I investigated the numerical issues on my ARM build, and after much
poking around and searching, I found that I was chasing the dahu : the
tests were wrong, and the result were good.
Let's consider the numerical failures one by one :
= 1/4 ===
On Wednesday, February 1, 2012 5:01:41 AM UTC+8, R. Andrew Ohana wrote:
>
> On Mon, Jan 30, 2012 at 10:04, John H Palmieri
> wrote:
> >
> > On Tuesday, January 17, 2012 1:59:45 PM UTC-8, William wrote:
> >>
> >> On Tue, Jan 17, 2012 at 1:39 PM, William Stein
> wrote:
> >>
> >> > On Mon, Jan 1
On Wed, Feb 1, 2012 at 04:46, Dima Pasechnik wrote:
>
>
> On Wednesday, February 1, 2012 5:01:41 AM UTC+8, R. Andrew Ohana wrote:
>>
>> On Mon, Jan 30, 2012 at 10:04, John H Palmieri
>> wrote:
>> >
>> > On Tuesday, January 17, 2012 1:59:45 PM UTC-8, William wrote:
>> >>
>> >> On Tue, Jan 17, 2012
I was told to post here some code that I wrote about the free algebra.
I do not know what is the best way to make it useful and would be
thankful for any advice. If someone is interested in a collaboration
to improve it or publish it, please let me know...
Matthieu Deneufchâtel
## Lyndon
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
> = Forewords =
>
> I investigated the numerical issues on my ARM build, and after much poking
> around and searching, I found that I was chasing the dahu : the tests were
> wrong, and the result were good.
>
> Let's consi
Combinatorics isn't my field, so here are just some general remarks: There
is a very active combinatorics subproject, you should post to the
sage-combinat-devel group as well. Also, from a maintenance point of view
its very bad to have an english-french-mixed code. Now only combinatorists
that
Le 01/02/2012 18:26, William Stein a écrit :
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
So the tests should be modified not to depend on the specific implementation
: they're currently testing equality of floats!
See http://trac.sagemath.org/sage_trac/ticket/10952
Oh, dear! That is
Le 01/02/2012 20:43, Julien Puydt a écrit :
sage: SR(10.0r).gamma() # rel tol 1e-15
Out of tolerance 362880.0 vs 362880.0
In fact, the printed result is misleading : the floats *are* different,
and the difference is 4.6566...e-10, so the relative error is
1.2832...e-15, so it's indeed out of
On investigating #12403 I discovered this serious bug (version 4.8):
sage: pari.default('parisize')
1600
sage: pari.default('parisize',3200)
*** Warning: new stack size = 3200 (30.518 Mbytes).
*** Error in the PARI system. End of program.
so increasing the stacksize of the par
On 2012-02-01 21:31, John Cremona wrote:
> On investigating #12403 I discovered this serious bug (version 4.8):
>
> sage: pari.default('parisize')
> 1600
> sage: pari.default('parisize',3200)
> *** Warning: new stack size = 3200 (30.518 Mbytes).
> *** Error in the PARI system.
Hi Cython experts and generator expression fans,
Christian Stump had some code that worked under 4.7 and segfaults
under 4.8. Investigating it further, I managed to reduce it to the
following piece of code which, inserted in the matrix code, triggers a
segfault:
def _travel_column( se
On 22 January 2012 21:54, Stephen Montgomery-Smith wrote:
>
> I fixed the problem as follows:
>
> sed -i .bak -e 's/Commentator/Commensator/g' \
>
That's not a fix. The POSIX definition of 'sed' does not include a -i
option, so this will not be portable. I'm 99.9 % sure it would break on
Solaris
>From http://wiki.cython.org/ReleaseNotes-0.15:
The inlined generator expressions (introduced in Cython 0.13) were disabled
in favour of full generator expression support. This breaks code that
previously used them inside of cdef functions (usage in def functions
continues to work) and induces a p
On Wed, 01 Feb 2012 21:31:59 David Kirkby wrote:
> On 22 January 2012 21:54, Stephen Montgomery-Smith
wrote:
> > I fixed the problem as follows:
> >
> > sed -i .bak -e 's/Commentator/Commensator/g' \
>
> That's not a fix. The POSIX definition of 'sed' does not include a -i
> option, so this will
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
> = Forewords =
>
> I investigated the numerical issues on my ARM build, and after much poking
> around and searching, I found that I was chasing the dahu : the tests were
> wrong, and the result were good.
No, the tests
On 1 February 2012 21:00, Jeroen Demeyer wrote:
> On 2012-02-01 21:31, John Cremona wrote:
>> On investigating #12403 I discovered this serious bug (version 4.8):
>>
>> sage: pari.default('parisize')
>> 1600
>> sage: pari.default('parisize',3200)
>> *** Warning: new stack size = 32
I tried to remove all the french expressions in my code.
## Lyndon words ##
import sage.combinat.lyndon_word as LW
## Shuffle product ##
from sage.combinat.words.shuffle_product import ShuffleProduct_w1w2 as
SP
## Combinatorial Fre
On Feb 1, 2012, at 04:46 , Dima Pasechnik wrote:
>
> On Wednesday, February 1, 2012 5:01:41 AM UTC+8, R. Andrew Ohana wrote:
>>
>> On Mon, Jan 30, 2012 at 10:04, John H Palmieri wrote:
[snip]
>> I've started looking into the difficulties of getting sage to build
>> with clang (on lion), and hav
On 02/01/2012 03:31 PM, David Kirkby wrote:
On 22 January 2012 21:54, Stephen Montgomery-Smith mailto:step...@missouri.edu>> wrote:
I fixed the problem as follows:
sed -i .bak -e 's/Commentator/Commensator/g' \
That's not a fix. The POSIX definition of 'sed' does not include a -i
o
A comment on python-ideas made me realize that the sage preparsing of
integer literals and ".." invalidates otherwise valid syntax:
sage: preparser(False)
sage: 1..conjugate()
1.0
sage: preparser(True)
sage: 1..conjugate()
...
SyntaxError: invalid syntax
sage: preparse("1..conjugate()")
'Integer(1
On Thursday, 2 February 2012 06:24:18 UTC+8, Robert Bradshaw wrote:
>
> On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt <> wrote:
> > = Forewords =
> >
> > I investigated the numerical issues on my ARM build, and after much
> poking
> > around and searching, I found that I w
Here is an illustration of the same phenomenon on x86_64. There, of course,
8-byte floats are double, so the code to demonstrate
the problem is as follows:
#include
#include
int main ()
{
double x = 6.0;
printf("sizof(double)=%d\n",sizeof(double));
printf("lgamma (%.20f)=%.20f\n", x, lgamm
I've just been looking at this trying to figure out what was going on and I
was just going to say exactly the same thing.
I don't really know anything about the whole glibc vs eglibc thing, but I
bet the implementation is the same as
glibc-2.14.1/sysdeps/ieee754/dbl-64/e_gamma_r.c:
double
__ieee7
23 matches
Mail list logo
