On Sat, Jun 6, 2009 at 4:42 AM, Neil Crighton <neilcrigh...@gmail.com> wrote: > Robert Cimrman <cimrman3 <at> ntc.zcu.cz> writes: > >> Anne Archibald wrote: >> >> > 1. add a keyword argument to intersect1d "assume_unique"; if it is not >> > present, check for uniqueness and emit a warning if not unique >> > 2. change the warning to an exception >> > Optionally: >> > 3. change the meaning of the function to that of intersect1d_nu if the >> > keyword argument is not present >> >
1. merge _nu version into one function ------------------------------------------------------- >> You mean something like: >> >> def intersect1d(ar1, ar2, assume_unique=False): >> if not assume_unique: >> return intersect1d_nu(ar1, ar2) >> else: >> ... # the current code >> >> intersect1d_nu could be still exported to numpy namespace, or not. >> > > +1 - from the user's point of view there should just be intersect1d and > setmember1d (i.e. no '_nu' versions). The assume_unique keyword Robert > suggests > can be used if speed is a problem. + 1 on rolling the _nu versions this way into the plain version, this would avoid a lot of the confusion. It would not be a code breaking API change for existing correct usage (but some speed regression without adding keyword) depreciate intersect1d_nu ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > intersect1d_nu could be still exported to numpy namespace, or not. I would say not, if they are the default branch of the non _nu version +1 on depreciation 2. alias as "in" --------------------- > > I really like in1d (no underscore) as a new name for setmember1d_nu. inarray > is > another possibility. I don't like 'ain'; 'a' in front of 'in' detracts from > readability, unlike the extra a in arange. I don't like the extra "a"s either, ones name spaces are commonly used alias setmember1d_nu as `in1d` or `isin1d`, because the function is a "in" and not a set operation +1 > > Can we summarise the discussion in this thread and write up a short proposal > about what we'd like to change in arraysetops, and how to make the changes? > Then it's easy for other people to give their opinion on any changes. I can do > this if no one else has time. > other points 3. behavior of other set functions ----------------------------------------------- guarantee that setdiff1d works for non-unique arrays (even when implementation changes), and change documentation +1 need to check other functions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ union1d: works for non-unique arrays, obvious from source setxor1d: requires unique arrays >>> np.setxor1d([1,2,3,3,4,5], [0,0,1,2,2,6]) array([2, 4, 5, 6]) >>> np.setxor1d(np.unique([1,2,3,3,4,5]), np.unique([0,0,1,2,2,6])) array([0, 3, 4, 5, 6]) setxor: add keyword option and call unique by default +1 for symmetry ediff1d and unique1d are defined for non-unique arrays 4. name of keyword ---------------------------- intersect1d(ar1, ar2, assume_unique=False) alternative isunique=False or just unique=False +1 less to write 5. module name ----------------------- rename arraysetops to something easier to read like setfun. I think it would only affect internal changes since all functions are exported to the main numpy name space +1e-4 (I got used to arrayse_tops) 5. keep docs in sync with correct usage --------------------------------------------------------- obvious That's my summary and opinions Josef > > Neil > > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion