2007/8/28, Stefan van der Walt <[EMAIL PROTECTED]>:
> I find this behaviour odd for addition. Under python:
>
> In [7]: 0.8+0.2 > 1.0
> Out[7]: False
Keep in mind that both 0.2 and 0.8 cannot be represented exactly as
floating-point numbers (unless you use decimal floating points, like
the "decim
2007/8/28, Christopher Barker <[EMAIL PROTECTED]>:
> Stefan van der Walt wrote:
> > but using the Pyrex module, it yields true. You can find the code at
> >
> > http://mentat.za.net/html/refer/somesumbug.tar.bz2
>
> That link appears to be broken.
The correct one is probably:
http://mentat.z
Stefan van der Walt wrote:
> but using the Pyrex module, it yields true. You can find the code at
>
> http://mentat.za.net/html/refer/somesumbug.tar.bz2
That link appears to be broken.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(2
Stefan van der Walt wrote:
> I find this behaviour odd for addition. Under python:
>
> In [7]: 0.8+0.2 > 1.0
> Out[7]: False
>
> but using the Pyrex module, it yields true.
odd. I wonder if one is using extended floating point in the FPU, and
the other not? What hardware/OS/compiler are you us
Hi Chris
On Mon, Aug 27, 2007 at 11:07:00AM -0700, Christopher Barker wrote:
> Is the kahan_sum closer? -- it should be, though compensated summation
> is really for adding LOTS of numbers, for 4, it's pointless at best.
> Anyway, binary floating point has its errors, and compensated summation
On Mon, Aug 27, 2007 at 08:21:43PM +0200, Lino Mastrodomenico wrote:
> Hi Martin,
>
> 2007/8/27, Martin Wiechert <[EMAIL PROTECTED]>:
> > I could not reproduce the bug in a debug build of python
> > (--without-pymalloc)
> > or on another machine. The crashing machine is an eight-way opteron.
>
>
On 8/27/07, Sean Davis <[EMAIL PROTECTED]> wrote:
>
> I have a numpy recarray that I want to load into a database using insert
> statements. To do so, I need to convert each record to a tuple. Here is
> what I get (using psycopg2)
>
> In [1]: a[1]
> Out[1]: ('5151_0023_0001', 'FORWARD', 'interval
Hi Martin,
2007/8/27, Martin Wiechert <[EMAIL PROTECTED]>:
> I could not reproduce the bug in a debug build of python (--without-pymalloc)
> or on another machine. The crashing machine is an eight-way opteron.
Not sure if it's related to your problem, but on 64-bit architectures
sizeof(ssize_t) i
Matt Knox wrote:
> - put it in numpy as a separate module from numpy.ma initially?
> (eg. "numpy.ma_new" ?)
This is the best bet, or we could call the new one ma, and the old one
ma_old. In any case, the old one needs to stick around until the new one
has been fully tested for compatibility (a
Stefan van der Walt wrote:
> For some reason, the kahan_sum of [0.2,0.0,0.8,0.0] is ever so
> slightly larger than 1.0 (in the order of 1e-16), but I'm not sure
> why, yet (this isn't specific to kahan summation -- normal summation
> shows the same behavior).
Just to make sure -- is the khan_sum "
Pierre GM wrote:
> * Does anyone see any *disadvantages* to this aspect of maskedarray relative
> to numpy.ma?
Nope, but I sure do see the advantages!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point
I have a numpy recarray that I want to load into a database using insert
statements. To do so, I need to convert each record to a tuple. Here is
what I get (using psycopg2)
In [1]: a[1]
Out[1]: ('5151_0023_0001', 'FORWARD', 'interval rank', 'target_tm:76.00
;probe_tm:70.90;freq:27.93;count:01;ru
Hi list,
I'm suffering from a strange segfault and would appreciate your help.
I'm calling a small C function using ctypes / numpy.ctypeslib. The function
works in the sense that it returns correct results. After calling the
function however I can reliably evoke a segfault by using readline tab
13 matches
Mail list logo
