Hanni Ali wrote:
> > Interesting example thanks. I can't however seem to get anything
> other than
> > zero for the 100,000 to 1 sum.
what is the "100,000 to 1 sum." this is my interpretation:
a = np.linspace(10, 1, 10)
>>> a
array([ 1.e+05, 9.e+04, 9.9
On Tue, 9 Sep 2008, David Cournapeau wrote:
> We don't use SSE and co in numpy, and I doubt the compilers (even
> Intel one) are able to generate effective SSE for numpy ATM. Actually,
> double and float are about the same speed for x86 (using the x87 FPU
> and not the SSE units), because intern
I already was...
2008/9/9 Matthieu Brucher <[EMAIL PROTECTED]>
> Use 1./n instead of 1/n. If n is an integer, 1/n equals 0.
>
> Matthieu
>
> 2008/9/9 Hanni Ali <[EMAIL PROTECTED]>:
> > Hi Matthieu,
> >
> > Interesting example thanks. I can't however seem to get anything other
> than
> > zero for
Use 1./n instead of 1/n. If n is an integer, 1/n equals 0.
Matthieu
2008/9/9 Hanni Ali <[EMAIL PROTECTED]>:
> Hi Matthieu,
>
> Interesting example thanks. I can't however seem to get anything other than
> zero for the 100,000 to 1 sum.
>
> Cheers,
>
> Hanni
>
> 2008/9/9 Matthieu Brucher <[EMAIL P
>
>
> I think it is a fallacy to say you prefer accuracy over speed: the
> fallacy is in thinking it is binary choice. You care about speed,
> because otherwise, you would not use a computer at all, you would do
> everything by hand [1]. Floating point is by itself an approximation: it
> can not ev
Hi Matthieu,
Interesting example thanks. I can't however seem to get anything other than
zero for the 100,000 to 1 sum.
Cheers,
Hanni
2008/9/9 Matthieu Brucher <[EMAIL PROTECTED]>
> > I now have a distinct dislike of float values (it'll probably wear off
> over
> > time), how can the sum of 10
On Tue, 2008-09-09 at 07:53 +0100, Hanni Ali wrote:
> Hi David,
>
> Forgot to answer last week, I was under a fair bit of pressure time
> wise, but thanks for your input. I sorted it all in the end and just
> in time, but the main issue here was the change from numarray to
> numpy. Previously wher
> I now have a distinct dislike of float values (it'll probably wear off over
> time), how can the sum of 100,000 numbers be anything other than the sum of
> those numbers. I know the reasoning, as highlighted by the couple of other
> e-mails we have had, but I feel the default should probably lean
Hi David,
Forgot to answer last week, I was under a fair bit of pressure time wise,
but thanks for your input. I sorted it all in the end and just in time, but
the main issue here was the change from numarray to numpy. Previously where
a typecode of 'f' was used in numarray, the calculation was pe
On Tue, Sep 9, 2008 at 6:55 AM, Sebastian Stephan Berg
<[EMAIL PROTECTED]> wrote:
> Yeah, I memory wise it doesn't matter to sum to a double, but just
> trying around it seems that the mixing of float and double is very slow
Yes, the memory argument explains why you would float32 data vs
float64 d
Yeah, I memory wise it doesn't matter to sum to a double, but just
trying around it seems that the mixing of float and double is very slow
(at least on my comp) while if the starting array is already double
there is almost no difference for summing. Generally double precision
calculations should be
Matthieu Brucher wrote:
> People are concerned by memory consumption, so if you use more memory
> than what you think, you can encounter bugs. Least surprise is always
> better ;)
sure, but I'm a bit confused -- there is a tiny amount of memory
involved in the accumulator -- isn't it a single num
Hanni Ali wrote:
> Hi,
>
> Is there a way I can set numpy to use dtype='float64' throughout all
> my code or force it to use the biggest datatype without adding the
> dtype='float64' to every call to mean, stdev etc..
Since it is the default type for the functions you mention, you can just
remove
Hi,
Is there a way I can set numpy to use dtype='float64' throughout all my code
or force it to use the biggest datatype without adding the dtype='float64'
to every call to mean, stdev etc..
2008/9/3 Sebastian Stephan Berg <[EMAIL PROTECTED]>
> Hi,
>
> just guessing here. But numarray seems to
We used to care about memory when we were running on 32-bit platforms, but
with the move to 64-bit, enabled by the current work, the issue is removed
and I will probably be changing everything for more accuracy.
Thanks
Hanni
2008/9/3 David Cournapeau <[EMAIL PROTECTED]>
> Hanni Ali wrote:
> >
Oh ok, I shall have to find where I did that then. Thanks
2008/9/3 Matthieu Brucher <[EMAIL PROTECTED]>
> By default, numpy uses float64, but you told it to use float32 ;)
>
> Matthieu
>
> 2008/9/3, Hanni Ali <[EMAIL PROTECTED]>:
> > Also can you think of a way either dtype is always float64? I h
Hanni Ali wrote:
> Understood, but I would generally be more concerned with accuracy than
> memory?
It is a tradeof: you can choose accuracy if you want, but by using
float32, you are already kind of hinting that you care about memory and
speed (otherwise, why not using double, which is the defaul
By default, numpy uses float64, but you told it to use float32 ;)
Matthieu
2008/9/3, Hanni Ali <[EMAIL PROTECTED]>:
> Also can you think of a way either dtype is always float64? I have a lot of
> functions and to add dtype='float64' would require *loads* of testing,
> whereas if I can set it cent
Hanni Ali wrote:
> I'm afraid the matrix is not available anywhere and I would not be
> able to make it available.
>
Forget it, Sebastian is right. I was confused by the range of the error,
but the error between two floating point numbers is indeed 1e-7 for
float on most runtimes (FLT_EPS in C, wh
Understood, but I would generally be more concerned with accuracy than
memory?
2008/9/3 Matthieu Brucher <[EMAIL PROTECTED]>
> It should never do some black magic without telling you.
> People are concerned by memory consumption, so if you use more memory
> than what you think, you can encounter
Also can you think of a way either dtype is always float64? I have a lot of
functions and to add dtype='float64' would require *loads* of testing,
whereas if I can set it centrally on the matrix or in the environment that
would be so much easier.
Hanni
2008/9/3 Hanni Ali <[EMAIL PROTECTED]>
> S
It should never do some black magic without telling you.
People are concerned by memory consumption, so if you use more memory
than what you think, you can encounter bugs. Least surprise is always
better ;)
Matthieu
2008/9/3, Hanni Ali <[EMAIL PROTECTED]>:
> Sebastian you legend, that seems to be
Sebastian you legend, that seems to be it.
Thank you very much.
>>> matrix.mean(dtype='float64')
0.41582015156745911
What seems odd is that numpy doesn't do this on it's own...
2008/9/3 Sebastian Stephan Berg <[EMAIL PROTECTED]>
> Hi,
>
> just guessing here. But numarray seems to calculate t
I'm afraid the matrix is not available anywhere and I would not be able to
make it available.
However I can demonstrate by simply generating a random number and filling a
10x10 matrix with it.
I generated a random number in numpy and used that to do the same exercise
in numarray.
In numpy:
>>>
Hi,
just guessing here. But numarray seems to calculate the result in a
bigger dataype, while numpy uses float32 which is the input arrays size
(at least I thought so, trying it confused me right now ...). In any
case, maybe the difference will be gone if you
use .mean(dtype='float64') (or whateve
Hanni Ali wrote:
> Hi Matthieu,
>
> I thought as much, regarding the computations, but was just presenting
> the information.
Is your matrix available somewhere so that we can reproduce the problem
? Off-hand, I can't see any explanation, but I am not familiar with
numarray, so maybe I am missing
Hi Matthieu,
I thought as much, regarding the computations, but was just presenting the
information.
Thanks for the set_printoptions but it doesn't seem to apply when accessing
a specific item:
>>> numpy.set_printoptions(precision=12)
>>> port_result.agg_matrix[0]
array([ 2.11549568e+08,
Hi,
I can't help you with the first issues, but the display has nothing to
do with the quality of the computation. Numpy only prints a part of a
float value, but fir the computations, it obviously uses the correct
value. All this can be parametrized by using set_printoptions().
Matthieu
2008/9/3
Hi,
I have encountered a worrying problem, during migration of software from
numarray to numpy, perhaps someone could help me determine how this could be
addressed.
I have a large array or values 1 long 12 items per line. The matrix
contains floats, dtype=float32 in numpy and type=Float32 in
29 matches
Mail list logo
