On Monday, December 1, 2014 12:49:27 PM UTC-8, Simon King wrote: > > > Hmm. Sounds like a mess. But I do think one should have a general > mechanism ("UniqueRepresentationOptional" or so) with which one can > choose by an optional argument whether caching and comparison by > identity should be used or not. > > I'm not so sure about that. UniqueRepresentation isn't so much a caching tool as it is a semantic one. It's the WithEqualityById that's the important ingredient, and to make that palatable one provides cached construction based on hashing&equality of the construction parameters (leading to the CachedRepresentation part). Being able to change behaviour of an object as fundamental as its hashing and equality with a simple flag seems like a bad idea to me. It should be very easy to distinguish what kind of version of the object you're facing. I'd expect to be able to tell this from the type.
So I think the design challenge here is to come up with a workable architecture where you can have a fast POset as an element of the *parent* "posets over/of type (qualified so that equality/isomorphy testing can be defined properly)" as well as a full-scale parent for heavy-duty computation in a fixed poset (is there such a thing?), with full support of coercing elements between different posets (again do people actually need that?), and a way to construct the second out of the first (and possibly the other way around too). In algebraic number theory this comes up with, say, fractional ideals. They are submodules of a number field, so in that respect can be considered full parents. But if you're doing ideal arithmetic you wouldn't want to treat them that way: they're elements of the ideal group, and you represent them by matrices or tuples of generators. Anything heavier than that is waste of resources. In fact, in that setting there's hardly any demand for having ideals as full parents. You may want to check if an element lies in an ideal, but you can support "in" on things that aren't parents. You probably do want to be ably to construct quotients by integral ideals and localizations etc. (probably as full parents), but again for that you don't need *ideals* to be parents. The easy solution for Nathann and Jori for now is just to write their high-performance code in terms of primitives: a tuple consisting of the base set and some suitable description of the PO (a set of generating a<=b pair or so?). Such a thing would be as light as possible. and can trivially be wrapped in a fancier interface should that ever be necessary. The obvious answer to the complaint "this data structure is too heavy for me" is "don't use it then". It might just be that they are discovering the current POset is too heavy to be useful in many settings, in which case a lighter alternative might be nice to have. And since this sounds like a likely scenario in many contexts, it would be nice to have some design ideas that help in accomplishing this. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.