>> Also, how does something like this get handled?
>>
> a = [1, 2, IGNORED(3), NaN]
>>
>> If I were to say, "What is the mean of 'a'?", then I think most of the time
>> people would want 1.5.
>
> I would want NaN! But that's because the only way I get NaN's is when
> I do dumb things like comp
On Fri, Nov 4, 2011 at 1:03 PM, Gary Strangman
wrote:
To push this forward a bit, can I propose that IGNORE behave
as: PnC
>>> x = np.array([1, 2, 3])
>>> y = np.array([10, 20, 30])
>>> ignore(x[2])
>>> x
[1, IGN
> NAN and NA apparently fall into the PdS class.
>
Here is where I think we need ot be a bit more careful. It is true that we want
NAN and MISSING to propagate, but then we additionally want to ignore it
sometimes. This is precisely why we have functions like nansum. Although
people
are wel
On Fri, Nov 4, 2011 at 11:08 AM, Lluís wrote:
Gary Strangman writes:
[...]
> destructive + non-propagating = the data point is truly
missing, this is the
> nature of that data point, such missingness should be
replicated in elementwise
> o
>> destructive + propagating = the data point is truly missing (satellite fell
>> into
>> the ocean; dog ate my source datasheet, or whatever), this is the nature of
>> that
>> data point, such missingness should be replicated in elementwise operations,
>> and
>> the missingness SHOULD interfer
On Fri, 4 Nov 2011, Benjamin Root wrote:
On Friday, November 4, 2011, Gary Strangman
wrote:
>
>> > non-destructive+propagating -- it really depends on exactly what
>> > computations you want to perform, and how you expect them to work. The
>> > main difference i
> non-destructive+propagating -- it really depends on exactly what
> computations you want to perform, and how you expect them to work. The
> main difference is how reduction operations are treated. I kind of
> feel like the non-propagating version makes more sense overall, but I
> don't know if
For the non-destructive+propagating case, do I understand correctly that
this would mean I (as a user) could temporarily decide to IGNORE certain
portions of my data, perform a series of computation on that data, and the
IGNORED flag (or however it is implemented) would be propagated from
comp
>> I wonder if that might be handled as a scikits-image extension, rather
>> than core numpy?
>
> I think Stefan and Nathaniel and Gary Strangman and others are saying
> we don't want to pay the price of a large memory hike for masking. I
> suspect that Nathani
(snip discussion of open kimono)
> On the other hand, to try and conceal these implementation
> differences, seems to me to break my feeling for numpy arrays, and
> make me feel I have an object that is rather magic, that I don't fully
> understand, and for which clever stuff is going on, under th
It seems to me, that what ``func`` should do, if it wants you to be
able to unmask the NAs, is to make a masked array view of ``arr``, and
return that. And indeed the simplicity of the separated API
immediately makes that clear - in my view at least.
I agree on this example. My only concern
Clearly there are some overlaps between what masked arrays are
trying to achieve and what Rs NA mechanisms are trying to achieve.
Are they really similar enough that they should function using
the same API?
Yes.
And if so, won't that be confusing?
No, I don't be
Accidental (virus?) post. Humblest apologies for the noise. Please ignore.
Gary
On Sat, 19 Jul 2008, Gary Strangman wrote:
> day pot-luck invite was a SHAM! The real party is on Saturday, and is not
> a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real
> party is on
day pot-luck invite was a SHAM! The real party is on Saturday, and is not
a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real
party is on Saturday, and is not a pot-luck.Remember -- the Sunday
pot-luck invite was a SHAM! The real party is on Saturday, and is not a
pot-luck.Re
If you're looking for user input ... +1 on having a keepdims capability. I
have myself implemented many such functions with a keepdims=1 keyword. No
real preference on how it's impelemented, though the potential for
breakage is a concern ...
Gary
On Wed, 2 Apr 2008, Charles R Harris wrote:
>
>>> http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
>>
>> I realize this is a bit of a johnny-come-lately comment, but I was
>> surprised to see that the list of sections does not seem to include the
>> single most common reason I usually try to access a doc string ... the
>> fu
> 4. Update the docstring, using the format suggested in
>
> http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
I realize this is a bit of a johnny-come-lately comment, but I was
surprised to see that the list of sections does not seem to include the
single most common reason I
17 matches
Mail list logo
