There are two reasons I was planning to have AbstractAlgebraicGroup be UniqueRepresentation (1) The passage in this tutorial <http://sporadic.stanford.edu/thematic_tutorials/coercion_and_categories.html> which reads
You are encouraged to *make your parent “unique”*. That’s to say, parents should only evaluate equal if they are identical. Sage provides frameworks to create unique parents. We use here the most easy one: Inheriting from the class sage.structure.unique_representation.UniqueRepresentation <http://sporadic.stanford.edu/reference/structure/sage/structure/unique_representation.html#sage.structure.unique_representation.UniqueRepresentation> is enough. Making parents unique can be quite important for an efficient implementation, because the repeated creation of “the same” parent would take a lot of time. (2) It seems to me to make sense mathematically, since, mathematically speaking, the split connected reductive algebraic group with based root datum B is a unique mathematical object. I admit I don't understand the "cost" of "non-locality"? Can you point me somewhere I could read up on relevant issues? Are there rules of thumb for when parents should and should not be UniqueRepresentation? In a different direction: is there a good place to read about how to make something be hashable or implement _cache_key()? Thanks for your time. Best, JH On Friday, August 19, 2016 at 3:03:23 PM UTC-4, Nils Bruin wrote: > > On Friday, August 19, 2016 at 11:20:44 AM UTC-7, Joseph Hundley wrote: >> >> Context: I am playing around with implementing abstract algebraic groups >> which are recovered from based root data. >> So, one should eventually be able to say >> b = BasedRootDatum( suitable input ) >> g = AbstractAlgebraicGroup( b ) >> > > TypeError: <class 'sage.groups.alg_gps.based_root_datum.BasedRootDatum'> > is not hashable and does not implement _cache_key() > > Do you need your AbstractAlgebraicGroup to be UniqueRepresentation? In > that case you should probably put it first in inheritance (that is > independent of your error, though) > > Because AbstractAlgebraicGroup is UniqueRepresentation, it needs to store > its construction parameters (that's b) somehow in order to ensure that the > next time you call AbstractAlgebraicGroup, it knows to return the > identically same object if it still exists. That means that "b" needs to be > hashable (or at least implement _cache_key). > > UniqueRepresentation comes at a considerable cost. It introduces serious > non-locality in the code (someone else can grab the identical object > without weven meaning to!), so that UniqueRepresentation object must take > great care in how they behave. UniqueRepresentation is basically required > for parents that occur as "base" for other structures that have elements > that participate non-trivially in the coercion framework, because the > coercion framework assumes in some places that "==" means "is" in order to > operate faster. If you don't need that, it's worth considering not > declaring your parent UniqueRepresentation. > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
