On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe <mwwiebe@gmail.com> wrote:
It appears to me that one of the biggest reason some of us have been
talking
past each other in the discussions is that different people have different definitions for the terms being used. Until this is thoroughly cleared up, I feel the design process is tilting at windmills. In the interests of clarity in our discussions, here is a starting
On Wed, Jul 6, 2011 at 5:48 PM, Peter <numpy-discussion@maubp.freeserve.co.uk> wrote: point
which is consistent with the NEP. These definitions have been added in a glossary within the NEP. If there are any ideas for amendments to these definitions that we can agree on, I will update the NEP with those amendments. Also, if I missed any important terms which need to be added, please propose definitions for them. NA (Not Available) A placeholder for a value which is unknown to computations. That value may be temporarily hidden with a mask, may have been lost due to hard drive corruption, or gone for any number of reasons. This is the same as NA in the R project.
Really? Can one implement NA with a mask in R? I thought an NA was always bitpattern in R?
I don't think that was what Mark was saying, see this bit later in this email:
I think it would make a difference if there was an implementation that had conflated masking with bitpatterns in terms of API. I don't think R is an example.
Of course R is not an example of that. Nothing is. This is merely conceptual. Separate NA from np.NA in Mark's NEP, and you will see his point. Consider it the logical intersection of NA in Mark's NEP and the aNEP.
The most important distinctions I'm trying to draw are: 1) NA vs IGNORE and bitpattern vs mask are completely independent. Any combination of NA as bitpattern, NA as mask, IGNORE as bitpattern, and IGNORE as mask are reasonable.
This point as I understood it is there is the semantics of the special values (not available vs ignore), and there is the implementation (bitpattern vs mask), and they are independent.
Yes.
Good, that's all Mark's definition guide is trying to do.
Although, we can see from the implementations that we have to hand that
a) bitpatterns -> propagation (NaN-like) semantics by default (R) b) masks -> ignore semantics by default (masked arrays)
The above is extraneous and out of the scope of Mark's definitions. We are taking this little-by-little.
I don't think Mark accepts that there is any reason for this tendency of implementations to semantics, but Nathaniel was arguing otherwise in the alterNEP.
Then that is what we will debate *later*, once we establish definitions.
I think we all accept that it's possible to imagine masking have propagation semantics and bitpatterns having ignore semantics.
Good! I think that is what Mark wanted to get across in this set of definitions. It kinda seems like you are champing at the bit here to continue the debate, but I agree with Mark that after yesterday's discussion, we need to make sure that we have a solid foundation for understanding each other. Ben Root