#18529: Topological manifolds: basics
-------------------------------------+-------------------------------------
Reporter: egourgoulhon | Owner: egourgoulhon
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.10
Component: geometry | Resolution:
Keywords: topological | Merged in:
manifolds | Reviewers:
Authors: Eric Gourgoulhon | Work issues:
Report Upstream: N/A | Commit:
Branch: | 6dec6d592a09e56921b9a761827309dd31ae2533
public/manifolds/top_manif_basics | Stopgaps:
Dependencies: #18175 |
-------------------------------------+-------------------------------------
Comment (by egourgoulhon):
Replying to [comment:31 tscrim]:
>
> It really comes down to what you're doing mostly in the code. If you'd
be doing a lot of conversions between points thought of as being in the
subset and as in the manifold, then a facade is probably an okay way to
go. If you care about associating the point with a particular subset, then
it should not be a facade.
I think we are precisely in the first case. In particular we do not care
about associating the point with a particular subset (since many
overlapping subsets can be introduced that contain the point and none of
them is to be privileged with respect to the point). So I would say that
we should use the facade.
>
> The hyperbolic plane works well because it is uniquely defined. Also not
all parents are `UniqueRepresentations`, the reason why we do this is
because of the coercion framework and speed. Identity checks are typically
much faster than equality checks.
Thanks for these explanations.
>
> > > However the manifolds are essentially mutable, but by doing a
`__hash__` which only depends upon the name(s) and dimension means this is
okay (`__eq__` defaults to check by `is`). This would alleviate the need
for `UniqueRepresentation`.
> >
> > Why should we avoid `UniqueRepresentation`? It's true that manifolds
are mutable as Python objects, since the main idea is to add charts (and
vector frames for differentiable manifolds) "on the fly" (for, in a
concrete calculation, charts are often defined from previous ones by some
transition map that might depend on some computational result and
therefore it is impossible to introduce all charts at the instantiation of
the manifold object). But this mutability is "secondary": the primary
attributes of a manifold being its dimension, its name and its base field.
With respect to these, the manifold is immutable. The need for
`_clear_cache_()` in some doctests seems a very small annoyment, with
respect to the benefit of `UniqueRepresentation`, doesn't it ? (I am
afraid I have not understood the non-doctest case involving the garbage
collector that you mentioned)
>
> This comes down to the manifold not being well-defined by its dimension,
name, and base field. It also needs to be defined by its chart.
Indeed. More precisely, a manifold is defined by its maximal atlas. But
there is no way to represent the latter in Sage, nor in any computer
system. Accordingly, we cannot check the equality of two manifolds. This
is why equality by id seems reasonable here.
> I understand that giving two distinct manifolds the same name is bad
mathematically, and you are reflecting that in your code. However what if
I create a manifold `M`, then decide I want to create a new (and
different) manifold `M` of the same dimension over the same base field?
When I try to do this naïvely, I get all of the previous chart information
much to my surprise (the garbage collector this was more about temporary
objects).
You are right: a user may want to restart some computation by creating a
manifold with the same name as that used previously. If he is doing so in
the same session, the `UniqueRepresentation` behavior will return the
previously created object. We cannot demand that the user runs
`_clear_cache_()` before creating the manifold...
--
Ticket URL: <http://trac.sagemath.org/ticket/18529#comment:32>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
