On Mar 11, 2009, at 5:47 PM, Nicolas M. Thiery wrote: > On Wed, Mar 11, 2009 at 10:07:35AM -0800, Carl Witty wrote: >> >> On Tue, Mar 10, 2009 at 11:05 PM, Nicolas M. Thiery >> <nicolas.thi...@u-psud.fr> wrote: >>> I guess it all boils down to what are the convention for membership >>> testing, and how much freedom one has in implementing it. >>> >>> Here are some typical options: >>> >>> (1) x is in P if there is an element of P that is equal to x >>> under == >>> or if x is already an element of self (this is the doc of >>> __contains__ in Parent; is this a fixed rule engraved in the >>> marble for every Parent?) >>> >>> (2) x is in P if P(x) raises no error (this is the current default >>> implementation in Parent) >>> >>> (3) x is in P if it can be coerced into P (which could be >>> implemented >>> by just testing for the existence of a coercion, without actually >>> applying it). >>> >>> (4) x is in P if x.parent() = P >>> >>> (1) is non trivial to implement. In principle, the __contains__ >>> function of ZZ should be able to handle all parents, now and in >>> the future, into which there is a natural embedding of ZZ. >>> >>> (2) seems completely off balance to me. Being able to construct a P >>> from some data does not convey any mathematical link between that >>> data and P. >>> >>> (3) sounds reasonable, at least as a widely used default >>> implementation. And possibly with a couple well marked exceptions >>> for the really common cases like 4/2 in ZZ, to be introduced on a >>> case by case basis when really it feels unnatural without them. >>> >>> I personally lean for (4), but am ready to call myself an >>> extremist on >>> this one. >> >> Where did you get (2)? That's not what the implementation in Parent >> does. (Actually, the implementation in Parent is trying to implement >> (1), and doing a pretty good job. It boils down to "x in ZZ" if >> "x == >> ZZ(x)", where TypeError and ValueError exceptions are caught and >> translate to False.) > > Oh, right. I misread the code. Good. One option that we don't have to > consider any more. > >> I dislike the idea of exceptions (from (3)); I prefer the current >> situation, where there's a general rule that applies everywhere and >> is simple enough to be memorized, even if the general rule isn't >> exactly what you want always. Once you start adding exceptions "on a >> case by case basis", it would be really easy to get a rule that was >> too complicated to memorize... and if you can't remember what a >> function does, it's pretty much useless. > > Yes, I also dislike exceptions. The rules should be as uniform as > possible. I was thinking really really really rare exceptions. Maybe > just that particular case 2/2 in ZZ.
Allowing any exceptions is going to be a slippery slope, and also a very fuzzy rule. Are constant polynomials in their basering? Further out on the limb, is int(1) in Z? >> If you want (4), I think you should just write x.parent() == P (or if >> you know that P is unique, x.parent() is P). > > Yup. The question is: am I allowed to do it? You're asking if you're allowed to redefine your __contains__? I'd rather preserve consistency. Why not just write parent(x) == P if that's what you're trying to test? I think "x in P" should be finer information than a relationship between parent(x) and P. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
