On Wed, Jul 6, 2011 at 12:01 PM, Matthew Brett <[email protected]>wrote:
> Hi, > > On Wed, Jul 6, 2011 at 5:48 PM, Peter > <[email protected]> wrote: > > On Wed, Jul 6, 2011 at 5:38 PM, Matthew Brett <[email protected]> > wrote: > >> > >> Hi, > >> > >> On Wed, Jul 6, 2011 at 4:40 PM, Mark Wiebe <[email protected]> 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 > 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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
