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.
