Thanks for your suggestions. Le jeudi 5 novembre 2015 18:54:40 UTC+1, Nils Bruin a écrit : > > On Thursday, November 5, 2015 at 7:22:10 AM UTC-8, Travis Scrimshaw wrote: >> >> So I'm somewhat inclined to use EqualityById and let the pickling be >> broken (and redefining _test_pickling to do nothing (i.e., passes) with a >> docstring warning that it is intentionally broken). I'm starting to become >> really convinced that this is the way to go. >> > > I completely agree. There's really no problem if calling "TwoSphere()" two > times yields non-equal two-spheres: You've just created two manifolds that > are homeomorphic, but since they are different manifolds, there is not a > canonical homeomorphism between them, so treating them as distinct objects > is quite justified. If you want to keep talking about *the same* manifold. >
I agree. > > The fact that in sage QQ['x','y'] and QQ['x','y'] gives back equal > polynomial rings is because the correspondence in naming of the generators > suggests a distinguished isomorphism between the two polynomial rings > (well, that's a mathematical justification. It's mainly convenient). Sage > goes a step further by ensuring that the rings are *identical*, which has > turned out to have pros and cons. > > Clearly, for a manifold there is not a small set of parameters given at > construction that, when in agreement, suggest a distinguished isomorphism. > Indeed. > So I think the basis for any "CachedRepresentation" is rather weak (and > will lead to code the behaviour of which is hard to predict). > > Incidentally, I guess your "charts" need to be immutable if you use then > as keys, > 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. > but do your manifolds have to be? > > 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. Let me take an example: the addition of two vector fields, a and b say, on the 2-sphere S^2. To decompose S^2 into parallelizable parts (on which the addition can be performed by adding the vector components in some frame), let us introduce the open cover of S^2 formed by (i) the open subset U, domain of the stereographic chart from the North pole, and (ii) the open subset V, domain of the stereographic chart from the South pole. The addition s = a + b is then performed as follows: s._restrictions[U] = a._restrictions[U] + b._restrictions[U] s._restrictions[V] = a._restrictions[V] + b._restrictions[V] Indeed, each vector field on S^2 is represented by its restriction to U and its restriction to V. On U and V, which are endowed with global vector frames (the frames associated with stereographic coordinates), the vector fields are represented by their components w.r.t. these vector frames, so that each of the two above additions is performed by adding the components. The above example illustrates the use of the dictionary VectorField._restrictions with the manifolds U and V as keys. 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) ? > If you allow for atlasses to be refined and updates, it would be more > natural to leave manifolds mutable and hence unhashable (because clearly > you're mutating them). > 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? -- 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.
