[sage-devel] Re: How much code to convert to IEEE 754 format ?

2010-01-02 Thread Jason Grout
Dr. David Kirkby wrote: > The IEEE 754 representation of a floating point number is basically > > (-1)^2 x c x 2^q > s=sign bit > c=significand (or 'coefficient') > q=exponent > > http://en.wikipedia.org/wiki/IEEE_754-2008 > > E is most accurately represented by: > > 6121026514868073 x 2^-51 >

[sage-devel] Re: How much code to convert to IEEE 754 format ?

2010-01-02 Thread Jason Grout
Dr. David Kirkby wrote: > The IEEE 754 representation of a floating point number is basically > > (-1)^2 x c x 2^q > s=sign bit > c=significand (or 'coefficient') > q=exponent > > http://en.wikipedia.org/wiki/IEEE_754-2008 > > E is most accurately represented by: > > 6121026514868073 x 2^-51 >

Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

2010-01-02 Thread Robert Bradshaw
On Jan 1, 2010, at 2:08 PM, TimDaly wrote: >> That is to say, if the Sage >> documentation says: >> >>sage: foo(bar) >>1.2345 >> >> but in fact in Sage one has >> >>sage: foo(bar) >>1.2351 >> >> then I would consider this misleading documentation, i.e., a bug. >> Your statement

Re: [sage-devel] How much code to convert to IEEE 754 format ?

2010-01-02 Thread Alex Ghitza
On Sun, 3 Jan 2010 05:35:37 +, David Kirkby wrote: > > Was there a good reason for choosing the name 'sgn'? It sems a bit > strange to me. > That's the standard mathematical notation for this function, see http://en.wikipedia.org/wiki/Sign_function Best, Alex -- Alex Ghitza -- Lecture

Re: [sage-devel] How much code to convert to IEEE 754 format ?

2010-01-02 Thread David Kirkby
2010/1/3 Mike Hansen : > On Sat, Jan 2, 2010 at 11:22 PM, Robert Bradshaw > wrote: >> It is sad we don't have a top-level sign function. > > We do, but it's called sgn. > > sage: sgn(3.0) > 1 > > --Mike Was there a good reason for choosing the name 'sgn'? It sems a bit strange to me. Dave -- T

Re: [sage-devel] How much code to convert to IEEE 754 format ?

2010-01-02 Thread Mike Hansen
On Sat, Jan 2, 2010 at 11:22 PM, Robert Bradshaw wrote: > It is sad we don't have a top-level sign function. We do, but it's called sgn. sage: sgn(3.0) 1 --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+

Re: [sage-devel] How much code to convert to IEEE 754 format ?

2010-01-02 Thread Robert Bradshaw
On Jan 2, 2010, at 9:00 PM, Dr. David Kirkby wrote: > The IEEE 754 representation of a floating point number is basically > > (-1)^2 x c x 2^q > s=sign bit > c=significand (or 'coefficient') > q=exponent > > http://en.wikipedia.org/wiki/IEEE_754-2008 > > E is most accurately represented by: > > 61

[sage-devel] How much code to convert to IEEE 754 format ?

2010-01-02 Thread Dr. David Kirkby
The IEEE 754 representation of a floating point number is basically (-1)^2 x c x 2^q s=sign bit c=significand (or 'coefficient') q=exponent http://en.wikipedia.org/wiki/IEEE_754-2008 E is most accurately represented by: 6121026514868073 x 2^-51 though on my SPARC the best one gets is 61210265

[sage-devel] Re: doctest failures due to rounding errors on Solaris.

2010-01-02 Thread Jason Grout
Peter Jeremy wrote: > There are some gotchas here. On an i387 in default (80-bit) mode, a > local double variable may be 80-bits if kept in a register but 64-bits > if written to memory. This means the precision of working variables > in a function can alternate between 64 and 80 bits depending

[sage-devel] Re: Solaris in VirtualBox

2010-01-02 Thread Jaap Spies
Dr. David Kirkby wrote: >> Jaap > > I've raised tickets for some of these simple spkg-install fixes. > > > opencdk > http://trac.sagemath.org/sage_trac/ticket/7817 > > freetype: > http://trac.sagemath.org/sage_trac/ticket/7138 > > flint > http://trac.sagemath.org/sage_trac/ticket/7815 > > ecllib:

Re: [sage-devel] doctest failures due to rounding errors on Solaris.

2010-01-02 Thread Peter Jeremy
On 2010-Jan-01 11:56:02 +, "Dr. David Kirkby" wrote: >But if FreeBSD's libm for the 387 chips is based on Sun's library for a SPARC >processor one needs to be cautious before making that assumption. If FreeBSD's >implementation was based on Sun's library for the x86 processor, then I'd say

[sage-devel] Re: Exciting developments on Python packaging

2010-01-02 Thread Georg S. Weber
Hi Dag Sverre, thank you very much for the pointer! I heartily agree to the direction where this discussion is going to, and especially to the following snippet from there: > And any improvement will be very welcome, especially if we start with > a more widespread use of cython. I'm reluctant to

Re: [sage-devel] Re: Solaris in VirtualBox

2010-01-02 Thread Dr. David Kirkby
Jaap Spies wrote: > As you stated before many spkgs are not in a good shape to handle this. > > I'm surprised I got so far > j...@opensolaris:~/Downloads/sage-4.3$ ls spkg/installed > bzip2-1.0.5 gnutils-2.2.1.p4 libpng-1.2.35 readline-6.0.p1 > termcap-1.3.1.p0 > cliquer-1.2.

[sage-devel] Re: sage 4.3 compile error Unknown compiler flag: --incref-local-binop

2010-01-02 Thread Georg S. Weber
Hi Rado, this flag is part of a command given to the Cython-to-C compiler. Maybe a wrong (and outdated) version of Cython is picked up/used? What is your $SAGE_ROOT (it seems to be /home/rado/, is that correct)? What is the output of 'which cython' (both not inside and inside a Sage shell, i.e.