#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: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`.
> - 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?
> - 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`.
>
> - Related to the above, we want parents to be hashable and have a good
equality. I know that by making it a `UniqueRepresentation`, many of these
issues are solved.
Indeed!
> 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)
>
> - In the tests for `_element_constructor_`, you shouldn't call it
explicitly but via `X(...)`, which also checks that it is working
correctly with the coercion framework.
OK, I will change this.
>
> - I don't quite agree with checking `self._field == RR` for real charts
as the precision should not matter. I would check `isinstance(self._field,
RealField)` instead.
Yes, I agree. I was also not satisfied with this.
>Granted, we probably should have a function that checks against all known
real field implementations...
>
> - In a similar vein, I don't like the input of `'real'` to `RR` (and
`'complex'` to `CC`). I would make the user be explicit about what they
want unless you are doing to do some special handling to make this pass
special arguments to an underlying `SR` implementation.
Yes, I agree too.
--
Ticket URL: <http://trac.sagemath.org/ticket/18529#comment:28>
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.
