#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: | f342e03e7008831c4789b94b03674c1a0cbbf3a6
public/manifolds/top_manif_basics | Stopgaps:
Dependencies: #18175 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:40 egourgoulhon]:
> I've already noticed some important loss of performance due to the
equality not being by id; I am afraid that for tensor computations this
will become much worse.
Did you have as the first lines of the `__eq__` being
{{{
if self is other:
return True
}}}
since "most" equality checks should be by identity. Granted, we do lose
some speed because this is a python check, as opposed to a cython check.
> Moreover, a sophisticated equality check (either with `__eq__` or
`is_isomorphic_to`) seems difficult to acheive: checking the equality of
the user-defined atlases is definitevely not sufficient to assert the
mathematical equality of two manifolds; one should compare the maximal
atlases instead, which is impossible. For example, if one first construct
S^2^ with an atlas of two stereographic charts and then another S^2^ with
an atlas of two polar charts, the two atlases differ, while both objects
represent the same manifold.
`__eq__` does not have to represent mathematical equality; IIRC we already
have examples of this in Sage, both when `__eq__` is weaker and stronger
than mathematical equality (which often times people wish it could be
isomorphism). So we are okay with making `__eq__` not reflect the
mathematical equality.
> There is also the issue of endless loop mentioned in comment:39.
The design reflects the mathematics as charts are morphism from '''R'''^n^
-> ''M'' and that the manifold ''M'' is an abstract set of points. My
proposal goes around the mathematical definition of a manifold as a set of
points by saying the manifold ''M'' is defined by its charts. So this
approach is definitely bad.
> For the above reasons, I am considering to revert to the
`UniqueRepresentation` for manifolds. To solve the issue of the
redefinition by the end user disccused in comment:32, we could have some
handling of the cache in the function `Manifold`, so that
> {{{
> M1 = Manifold(2, 'M')
> M2 = Manifold(2, 'M')
> }}}
> will construct two different objects. What do you think?
I worry that this will cause subtle issues with pickling. For example, if
we clear the cache when creating `M2`, then `loads(dumps(M1))` will
probably not equal `M1`, but instead equal `M2`. I haven't checked if this
actually happens.
There are a few different options that I see at this point.
- Drop pickling `==` support and use
`sage.misc.fast_methods.WithEqualityById` (this will get your speed back).
However we could get close by implementing pickling as saving the current
atlas.
- Go back to `UniqueRepresentation`, but also have it additionally keyed
by the time it was created:
{{{
sage: import time
sage: time.time()
1446566813.121567
}}}
You could do this by having
{{{
@staticmethod
def __classcall__(cls, dim, name, latex, R, time_key=None):
if time_key is None:
from time import time
time_key = time()
return super(TopologicalManifold, cls).__classcall__(cls, dim, latex,
R, time_key=time_key)
def __init__(self, dim, name, latex, R, time_key):
# Just ignore the time_key input
}}}
(or doing it via a `UniqueFactory`).
- Warn the user that they can only create one manifold of a given (latex)
name of a given dimension over a given field.
- Figure out some other way to better uniquely specify a manifold.
- Ask someone else, like Jeroen, Simon, Volker, and/or sage-devel, for
other options.
Personally I would go for first one since pickling within a session is, I
believe, usually not needed/used.
--
Ticket URL: <http://trac.sagemath.org/ticket/18529#comment:41>
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.
