Nathaniel Smith writes:
So assignment is not destructive -- the old value is retained as the
payload.
I never assumed (and I think it is also the case for others) that the payload
was retaining the old value. In fact, AFAIR, the payloads were introduced as a
way of having more than one special
On Sat, Nov 5, 2011 at 3:22 PM, T J tjhn...@gmail.com wrote:
So what do people expect out of ignored values? It seems that we might need
to extend the list you put forward so that it includes these desires. Since
my primary use is with MISSING and not so much IGNORED, I'm not in a very
good
On Fri, Nov 4, 2011 at 8:33 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 8:03 PM, Nathaniel Smith n...@pobox.com wrote:
Again, I really don't think you're going to be able to sell an API where
[2] + [IGNORED(20)] == [IGNORED(22)]
I mean, it's not me you have to convince, it's Gary,
Hi,
05.11.2011 03:43, T J kirjoitti:
[clip]
I thought that PdC satisfied (a) and (b).
Let me show you what I thought they were. Perhaps I am not being
consistent. If so, point out my mistake.
Yes, propagating + destructive assigment + do-computations-on-payload
should satisfy (a) and (b).
04.11.2011 19:59, Pauli Virtanen kirjoitti:
[clip]
This makes inline binary ops
behave like Nn. Reductions are N. (Assignment: dC, reductions: N, binary
ops: PX, unary ops: PC, inline binary ops: Nn).
Sorry, inline binary ops are also PdX, not Nn.
--
Pauli Virtanen
On Fri, Nov 4, 2011 at 11:59 AM, Pauli Virtanen p...@iki.fi wrote:
I have a feeling that if you don't start by mathematically defining the
scalar operations first, and only after that generalize them to arrays,
some conceptual problems may follow.
Yes. I was going to mention this point as
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
On Fri, Nov 4, 2011 at 1:03 PM, Gary Strangman
str...@nmr.mgh.harvard.eduwrote:
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, IGNORED(2), 3]
x + 2
[3, IGNORED(4), 5]
x + y
[11,
On Fri, Nov 4, 2011 at 1:03 PM, Gary Strangman str...@nmr.mgh.harvard.edu
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, IGNORED(2), 3]
x +
On Fri, Nov 4, 2011 at 1:59 PM, Pauli Virtanen p...@iki.fi wrote:
For shorthand, we can refer to the above choices with the nomenclature
shorthand ::= propagation destructivity payload_type
propagation ::= P | N
destructivity ::= d | n | s
payload_type ::= S | E | C
I really
On Fri, Nov 4, 2011 at 1:22 PM, T J tjhn...@gmail.com wrote:
I agree that it would be ideal if the default were to skip IGNORED values,
but that behavior seems inconsistent with its propagation properties (such
as when adding arrays with IGNORED values). To illustrate, when we did
x+2, we
04.11.2011 20:49, T J kirjoitti:
[clip]
To push this forward a bit, can I propose that IGNORE behave as: PnC
The *n* classes can be a bit confusing in Python:
### PnC
x = np.array([1, 2, 3])
y = np.array([4, 5, 6])
ignore(y[1])
z = x + y
z
np.array([5, IGNORE(7), 9])
x += y
On Fri, Nov 4, 2011 at 2:41 PM, Pauli Virtanen p...@iki.fi wrote:
04.11.2011 20:49, T J kirjoitti:
[clip]
To push this forward a bit, can I propose that IGNORE behave as: PnC
The *n* classes can be a bit confusing in Python:
### PnC
x = np.array([1, 2, 3])
y = np.array([4, 5, 6])
On Fri, Nov 4, 2011 at 11:59 AM, Pauli Virtanen p...@iki.fi wrote:
I have a feeling that if you don't start by mathematically defining the
scalar operations first, and only after that generalize them to arrays,
some conceptual problems may follow.
On the other hand, I should note that
On Fri, Nov 4, 2011 at 2:29 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Nov 4, 2011 at 1:22 PM, T J tjhn...@gmail.com wrote:
I agree that it would be ideal if the default were to skip IGNORED
values,
but that behavior seems inconsistent with its propagation properties
(such
as when
On Fri, Nov 4, 2011 at 3:04 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Nov 4, 2011 at 11:59 AM, Pauli Virtanen p...@iki.fi wrote:
If classified this way, behaviour of items in np.ma arrays is different
in different operations, but seems roughly PdX, where X stands for
returning a masked
04.11.2011 22:57, T J kirjoitti:
[clip]
(m) mark-ignored
a := SPECIAL_1
# - a == SPECIAL_a ; the payload of the RHS is neglected,
# the assigned value has the original LHS
# as the payload
[clip]
Does this behave as expected for x + y
On Fri, Nov 4, 2011 at 3:08 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 2:29 PM, Nathaniel Smith n...@pobox.com wrote:
Continuing my theme of looking for consensus first... there are
obviously a ton of ugly corners in here. But my impression is that at
least for some simple cases,
04.11.2011 23:04, Nathaniel Smith kirjoitti:
[clip]
Assuming that, I believe that what people want for IGNORED values is
unop(SPECIAL_1) == SPECIAL_1
which doesn't seem to be an option in your taxonomy.
Well, you can always add a new branch for rules on what to do with unary
ops.
[clip]
On Fri, Nov 4, 2011 at 3:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Nov 4, 2011 at 3:08 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 2:29 PM, Nathaniel Smith n...@pobox.com wrote:
Continuing my theme of looking for consensus first... there are
obviously a ton of ugly
04.11.2011 23:29, Pauli Virtanen kirjoitti:
[clip]
As the definition concerns only what happens on assignment, it does not
have problems with commutativity.
This is of course then not really true in a wider sense, as an example
from T J shows:
a = 1
a += IGNORE(3)
# - a := a + IGNORE(3)
# - a
On Fri, Nov 4, 2011 at 4:29 PM, Pauli Virtanen p...@iki.fi wrote:
04.11.2011 23:29, Pauli Virtanen kirjoitti:
[clip]
As the definition concerns only what happens on assignment, it does not
have problems with commutativity.
This is of course then not really true in a wider sense, as an
04.11.2011 22:29, Nathaniel Smith kirjoitti:
[clip]
Continuing my theme of looking for consensus first... there are
obviously a ton of ugly corners in here. But my impression is that at
least for some simple cases, it's clear what users want:
a = [1, IGNORED(2), 3]
#
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 compute log(0), and
05.11.2011 00:14, T J kirjoitti:
[clip]
a = 1
a += 2
a += IGNORE
b = 1 + 2 + IGNORE
I think having a == b is essential. If they can be different, that will
only lead to confusion. On this point alone, does anyone think it is
acceptable to have a != b?
It seems to me
On Fri, Nov 4, 2011 at 6:31 PM, Pauli Virtanen p...@iki.fi wrote:
05.11.2011 00:14, T J kirjoitti:
[clip]
a = 1
a += 2
a += IGNORE
b = 1 + 2 + IGNORE
I think having a == b is essential. If they can be different, that will
only lead to confusion. On this point
On Fri, Nov 4, 2011 at 7:43 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 6:31 PM, Pauli Virtanen p...@iki.fi wrote:
An acid test for proposed rules: given two arrays `a` and `b`,
a = [1, 2, IGNORED(3), IGNORED(4)]
b = [10, IGNORED(20), 30, IGNORED(40)]
[...]
(A1)
On Fri, Nov 4, 2011 at 8:03 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Nov 4, 2011 at 7:43 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 6:31 PM, Pauli Virtanen p...@iki.fi wrote:
An acid test for proposed rules: given two arrays `a` and `b`,
a = [1, 2,
On Fri, Nov 4, 2011 at 10:33 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 8:03 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Nov 4, 2011 at 7:43 PM, T J tjhn...@gmail.com wrote:
On Fri, Nov 4, 2011 at 6:31 PM, Pauli Virtanen p...@iki.fi wrote:
An acid test for proposed
On Thu, Nov 3, 2011 at 7:54 PM, Gary Strangman
str...@nmr.mgh.harvard.edu wrote:
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,
On Friday, November 4, 2011, Nathaniel Smith n...@pobox.com wrote:
On Thu, Nov 3, 2011 at 7:54 PM, Gary Strangman
str...@nmr.mgh.harvard.edu wrote:
For the non-destructive+propagating case, do I understand correctly that
this would mean I (as a user) could temporarily decide to IGNORE certain
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
Gary Strangman writes:
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)
On Fri, 4 Nov 2011, Benjamin Root wrote:
On Friday, November 4, 2011, Gary Strangman str...@nmr.mgh.harvard.edu
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 is how reduction
Gary Strangman writes:
[...]
Given I'm still fuzzy on all the distinctions, perhaps someone could try to
help
me (and others?) to define all /4/ logical possibilities ... some may be
obvious
dead-ends. I'll take a stab at them, but these should definitely get edited by
others:
On Fri, Nov 4, 2011 at 11:08 AM, Lluís xscr...@gmx.net 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
operations, but such missingness
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 interfere with
On Fri, Nov 4, 2011 at 11:08 AM, Lluís xscr...@gmx.net 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
Benjamin Root writes:
On Fri, Nov 4, 2011 at 11:08 AM, Lluís xscr...@gmx.net 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
04.11.2011 17:31, Gary Strangman kirjoitti:
[clip]
The question does still remain what to do when performing operations like
those above in IGNORE cases. Perform the operation underneath? Or not?
I have a feeling that if you don't start by mathematically defining the
scalar operations first,
On Wed, Nov 2, 2011 at 8:20 PM, Benjamin Root ben.r...@ou.edu wrote:
On Wednesday, November 2, 2011, Nathaniel Smith n...@pobox.com wrote:
By R compatibility, I specifically had in mind in-memory
compatibility. rpy2 provides a more-or-less seamless within-process
interface between R and Python
I also mentioned this at the bottom of a reply to Benjamin, but to
make sure people joining the thread see it: I went ahead and put this
up on a github wiki page that everyone should be able to edit
https://github.com/njsmith/numpy/wiki/NA-discussion-status
We could move it to the numpy wiki or
On 2011-11-03 04:22, numpy-discussion-requ...@scipy.org wrote:
Message: 1
Date: Wed, 2 Nov 2011 22:20:15 -0500
From: Benjamin Rootben.r...@ou.edu
Subject: Re: [Numpy-discussion] in the NA discussion, what can we
agree on?
To: Discussion of Numerical Pythonnumpy-discussion@scipy.org
Nathaniel Smith writes:
4) There is consensus that whatever approach is taken, there should be
a quick and convenient way to identify values that are MISSING,
IGNORED, or both. (E.g., functions is_MISSING, is_IGNORED,
is_MISSING_or_IGNORED, or some equivalent.)
Well, maybe it's too low
On Thu, Nov 3, 2011 at 9:28 AM, Lluís xscr...@gmx.net wrote:
Nathaniel Smith writes:
4) There is consensus that whatever approach is taken, there should be
a quick and convenient way to identify values that are MISSING,
IGNORED, or both. (E.g., functions is_MISSING, is_IGNORED,
On 11/2/11 7:16 PM, Nathaniel Smith wrote:
By R compatibility, I specifically had in mind in-memory
compatibility.
The R crowd has had a big voice in this discussion, and I understand
that there are some nice lessons to be learned from it with regard to
the NA issues.
However, I think making
Hi Chris,
On Thu, Nov 3, 2011 at 9:45 AM, Chris.Barker chris.bar...@noaa.gov wrote:
On 11/2/11 7:16 PM, Nathaniel Smith wrote:
By R compatibility, I specifically had in mind in-memory
compatibility.
The R crowd has had a big voice in this discussion, and I understand
that there are some
Hi Lluís,
On Thu, Nov 3, 2011 at 7:28 AM, Lluís xscr...@gmx.net wrote:
Well, maybe it's too low level, but I'd rather decouple the two concepts into
two orthogonal properties that can be composed:
* Destructiveness: whether the previous data value is lost whenever you
assign a
special
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
On Thursday, November 3, 2011, Gary Strangman str...@nmr.mgh.harvard.edu
wrote:
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,
On Wed, Nov 2, 2011 at 6:37 PM, Nathaniel Smith n...@pobox.com wrote:
Hi again,
Okay, here's my attempt at an *uncontroversial* email!
Specifically, I think it'll be easier to talk about this NA stuff if
we can establish some common ground, and easier for people to follow
if the basic
Hi Benjamin,
On Wed, Nov 2, 2011 at 5:25 PM, Benjamin Root ben.r...@ou.edu wrote:
I want to pare this down even more. I think the above lists makes too many
unneeded extrapolations.
Okay. I found your formatting a little confusing, so I want to make
sure I understood the changes you're
On Wednesday, November 2, 2011, Nathaniel Smith n...@pobox.com wrote:
Hi Benjamin,
On Wed, Nov 2, 2011 at 5:25 PM, Benjamin Root ben.r...@ou.edu wrote:
I want to pare this down even more. I think the above lists makes too
many
unneeded extrapolations.
Okay. I found your formatting a little
53 matches
Mail list logo
