On Thursday, November 5, 2015 at 2:35:57 PM UTC-8, Eric Gourgoulhon wrote: > > Yes charts are immutable: a chart is defined by two parameters, which are > passed to the constructor: its domain (a manifold) and its coordinates (a > list of symbolic variables). These two parameters do not change during the > object life. I think that using UniqueRepresentation for charts is then > well justified. Same thing for vector frames. >
It indicates they could be if they needed to be. However, making things UniqueRepresentation or CachedRepresentation has a very real cost and makes the job of the garbage collector *much* harder. You can get very subtle memory leaks via weak references once global caches are involved. So what specifically do you *gain* from making them UniqueRepresentation? Is it ever the case that two charts are constructed independently from each other (with the same construction parameters!) and that it is important that the resulting charts are actually identical? Given that one of the construction parameters is a manifold, which is going to be EqualityById anyway, I expect this will not happen. It'll be much more straightforward to look the chart up on the manifold (where it'll be stored anyway, right?) if you need to retrieve it. > EqualityById objects have relatively little use for being hashable. >> Certainly as dictionary keys they are hardly useful: >> >> D[eq_by_id_obj] could always be spelled as eq_by_id_obj.D , since you >> have to have the exact object in hand to look it up in a dictionary anyway. >> > > I am afraid I don't quite understand the above. > That's just a general remark that might sometimes be useful to consider. There might be performance/logic considerations that might lead you to prefer using such an object as a key anyway. > > Considering your example (taking into account that U is an eq-by-id > object), how could we spell a._restrictions[U] as something like > U.(a_restrictions) ? > Technically, by having a dict or a list on U that, for each vector field in existence, has the restriction to a on it. So you could write it as U.restrictions_of_vector_fields[s] = U.restrictions_of_vector_fields[a] + V.restrictions_of_vector_fields[b] I won't claim that doing so is a good idea (in fact, it looks like a horrible idea). However, there are other scenarios where this transposition of index and indexee can be fruitful to consider. Technically speaking, yes, we are mutating them, by adding charts and > vector frames. But if we make them eq-by-id, we guarantee that they don't > change: they are recognized only by their id, which is constant during all > their lives. So why not using them as dictionary keys as in the example > above? > > By making manifolds hashable you're entering into a contract that doesn't >> sound so natural (although EqualityById guarantees you'll keep your >> contract). >> > > Yes we keep the contract. If this does not sound so natural, which > alternative would you propose to deal with the restrictions of a vector > field to parallelizable open subsets? > At least one of the alternatives looks horrible, so I would not propose any alternative. It does force your hand on EqById, basically, because otherwise it is nontrivial to keep the contract. -- 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.
