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. > This reminds me of another confusion I've seen in the list. I'd like to suggest that we ban the word API by itself from the present discussion, and always specify Python API or C API for clarity's sake. Here are my suggested definitions for these two terms: Python API All the interface mechanisms that are exposed to Python code for using missing values in NumPy. This API is designed to be Pythonic and fit into the way NumPy works as much as possible. C API All the implementation mechanisms exposed for CPython extensions written in C that want to support NumPy missing value support. This API is designed to be as natural as possible in C, and is usually prioritizes flexibility and high performance. Before we proceed to any discussion of what are good/bad choices, I really want to nail this down from just the definition perspective. I don't want arbitrary choices baked into the terms we use, because that implies already having made a design decision. -Mark > > >>> 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. 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) > > 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. > > I think we all accept that it's possible to imagine masking have > propagation semantics and bitpatterns having ignore semantics. > > Cheers, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
