At 02:36 PM 7/25/2014, you wrote:
>But it doesn't compensate for users to be aware of the problems. I
>think the docstring and the description of the dtype argument is pretty clear.
Most of the docs for the affected functions do not have a Note with
the same warning as mean()
- Ray
__
On 25.07.2014 23:51, Eelco Hoogendoorn wrote:
> Ray: I'm not working with Hubble data, but yeah these are all issues
> I've run into with my terrabytes of microscopy data as well. Given that
> such raw data comes as uint16, its best to do your calculations as much
> as possible in good old ints. Wh
Ray: I'm not working with Hubble data, but yeah these are all issues I've run
into with my terrabytes of microscopy data as well. Given that such raw data
comes as uint16, its best to do your calculations as much as possible in good
old ints. What you compute is what you get, no obscure shenanig
On Fri, Jul 25, 2014 at 4:25 PM, RayS wrote:
> At 11:29 AM 7/25/2014, you wrote:
> >On Fri, Jul 25, 2014 at 5:56 PM, RayS wrote:
> > > The important point was that it would be best if all of the
> > methods affected
> > > by summing 32 bit floats with 32 bit accumulators had the same Notes as
>
At 11:29 AM 7/25/2014, you wrote:
>On Fri, Jul 25, 2014 at 5:56 PM, RayS wrote:
> > The important point was that it would be best if all of the
> methods affected
> > by summing 32 bit floats with 32 bit accumulators had the same Notes as
> > numpy.mean(). We went through a lot of code yesterday,
It need not be exactly representable as such; take the mean of [1, 1+eps]
for instance. Granted, there are at most two number in the range of the
original dtype which are closest to the true mean; but im not sure that
computing them exactly is a tractable problem for arbitrary input.
Im not sure w
On Fri, Jul 25, 2014 at 5:56 PM, RayS wrote:
> The important point was that it would be best if all of the methods affected
> by summing 32 bit floats with 32 bit accumulators had the same Notes as
> numpy.mean(). We went through a lot of code yesterday, assuming that any
> numpy or Scipy.stats fu
Hi,
On Fri, Jul 25, 2014 at 9:52 AM, Jeff wrote:
> How does the build trigger? If its just a matter of clicking on something
> when released. I think we can handle that :)
>
The two options are:
* I add you and whoever else does releases to my repo, and you can
trigger builds by pressing a butt
On 7/25/2014 1:40 PM, Eelco Hoogendoorn wrote:
> At the risk of repeating myself: explicit is better than implicit
This sounds like an argument for renaming the `mean` function `naivemean`
rather than `mean`. Whatever numpy names `mean`, shouldn't it
implement an algorithm that produces the mean
Arguably, the whole of floating point numbers and their related shenanigans is
not very pythonic in the first place. The accuracy of the output WILL depend on
the input, to some degree or another. At the risk of repeating myself: explicit
is better than implicit
-Original Message-
From:
At 07:22 AM 7/25/2014, you wrote:
> We were talking on this in the office, as we
> realized it does affect a couple of lines dealing
> with large arrays, including complex64.
> As I expect Python modules to work uniformly
> cross platform unless documented otherwise, to me
> that includes 32 vs 6
On Fri, Jul 25, 2014 at 3:11 PM, RayS wrote:
> At 01:22 AM 7/25/2014, you wrote:
>> Actually the maximum precision I am not so
>> sure of, as I personally prefer to make an
>> informed decision about precision used, and get
>> an error on a platform that does not support
>> the specified precisio
At 01:22 AM 7/25/2014, you wrote:
> Actually the maximum precision I am not so
> sure of, as I personally prefer to make an
> informed decision about precision used, and get
> an error on a platform that does not support
> the specified precision, rather than obtain
> subtly or horribly broke
How does the build trigger? If its just a matter of clicking on something
when released. I think we can handle that :)
On Saturday, May 17, 2014 7:22:00 AM UTC-4, Jeff wrote:
>
> Hi,
>
> I'm pleased to announce the availability of the first release candidate of
> Pandas 0.14.0.
> Please try this
The dtype returned by np.where looks right (int64):
>>> import platform
>>> platform.architecture()
('64bit', 'WindowsPE')
>>> import numpy as np
>>> np.__version__
'1.9.0b1'
>>> a = np.zeros(10)
>>> np.where(a == 0)
(array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype=int64),)
--
Olivier
__
To elaborate on that point; knowing that numpy accumulates in a simple
first-to-last sweep, and does not implicitly upcast, the original problem
can be solved in several ways; specifying a higher precision to sum with,
or by a nested summation, like X.mean(0).mean(0)==1.0. I personally like
this ex
16 matches
Mail list logo