#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 tscrim):
Replying to [comment:28 egourgoulhon]:
> Replying to [comment:27 tscrim]:
>
> Thanks for your comments/suggestions.
>
> > Some things from looking over the current structure:
> >
> > - I would separate out parts of the subset class that applies to
`Top(ological)Manifold` and `TopManifoldSubset` into an ABC (abstract base
class) so you don't have to do things like `self is manifold`.
> >
>
> I am not sure an ABC would help here: this would make a clear
distinction between the manifold and strict subsets of it (thus avoiding
the very few tests `self is self._manifold`), but on the other hand, we
need open strict subsets to be in the class `TopologicalManifolds`.
The diagram you have below is what I was thinking (at least the first 2
levels). This gives better separation of concerns and better distinguishes
the two classes.
> > - Maybe put the subsets into the `Subobjects` class and maybe consider
not making it a facade?
> >
>
> I had the impression that the facade feature is exactly what we need,
since we can have the same point created from different facade parents by
means of different charts: if `U` and `V` are two overelapping open
subsets of manifold `M`, it may happen that the same point of `M` is
declared in two different ways:
> {{{
> p = U((x,y), chart=C1)
> q = V((u,v), chart=C2)
> }}}
> Thanks to the facade mecanism, `p` and `q` will have the same parent:
`M` and then it is possible to check whether `p == q`; this will hold if
the coordinates `(x,y)` in chart `C1` correspond to coordinates `(u,v)` in
chart `C2`. Is there something bad in using facade parents?
It depends on what you want the points associated with. If they are to be
considered proper subsets of the manifold, where you want to do
operations, then the point should know that it belongs to the subset. If
it is really just reflecting a particular chart, then you probably should
reconsider your entire class hierarchy because I think it shouldn't quack
like a manifold in that case.
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.
> > - Should manifolds and their subsets be `UniqueRepresentation`? I
understand that the name as the only input means they are essentially
treated as variables, but it means you have to do things like
`TopManifold._clear_cache_()` (which may be needed not just necessarily in
doctests if one does this before the gc comes around).
>
> Actually, I don't see any use case (except for confusing the reader!)
where one would define two different manifolds with the same name and same
dimension over the same topological field. So `UniqueRepresentation` seems
quite appropriate here. Moreover, I thought this is Sage's credo to have
parents be `UniqueRepresentation`, cf. the phrase ''You are encouraged to
make your parent "unique"'' in the tutorial
[http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html
#coercion-and-categories How to implement new algebraic structures in
Sage]. Also, most parents in `src/sage/geometry` (in particular the
hyperbolic plane) have `UniqueRepresentation`.
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.
> > 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. 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).
--
Ticket URL: <http://trac.sagemath.org/ticket/18529#comment:31>
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.
