#18640: Topological manifolds: scalar fields
-------------------------------------+-------------------------------------
Reporter: egourgoulhon | Owner: egourgoulhon
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-7.2
Component: geometry | Resolution:
Keywords: topological | Merged in:
manifolds | Reviewers:
Authors: Eric Gourgoulhon, | Work issues:
Michal Bejger | Commit:
Report Upstream: N/A | 3b92a85394e8fc6f7572c58d0a6ce8b1bebacce2
Branch: | Stopgaps:
public/manifolds/top_manif_scalar_fields|
Dependencies: #18529 |
-------------------------------------+-------------------------------------
Comment (by egourgoulhon):
Replying to [comment:30 tscrim]:
>
> I guess what I am asking is how much of concrete class
`CoordFunctionSym` can be lifted to the ABC?
>
Not much: I would say that `CoordFunctionSymb` is optimal: everything that
could be lifted to the ABC `CoordFunction` is already there.
> > > Moreover, you could probably make any numerical coordinate chart be
`._express` with the appropriate methods. However, I am wondering if there
should be a parent for `CoordFunction` (and have `CoordFunction` be a
subclass of `AlgebraElement`), which would allow you to not duplicate code
and use the coercion framework. Actually, perhaps `CoordFunction` should
be a subclass of `Morphism`.
> >
> > OK, I will give a try to this, introducing the proper algebra (no time
to do it right now, though...)
>
> It should be a fairly small class; a parent that takes a chart as input.
I can work on this for my next commit.
OK thanks.
>
>
> When you say "the manifold," you are saying there is a unique manifold.
Context makes it clear exactly which manifold you're talking about (and
hence unique), but for something like documentation, "this manifold"
better defines what you are reference (although personally, I would just
replace it by {{{``self``}}}...).
Thanks for these explanations. As you, I would favor `self` (which is
completely unambiguous), but I remember a discussion on sage-devel, the
conclusion of which was that one should avoid the mention of `self` in the
documentation, to make it more readable for newcomers. So let's go for
"this manifold".
>
> > >The question becomes what to attach the global options to. I am
thinking `Manifold` (a function is a Python object too, so we can attach
data to it) and `TopologicalManifold`.
> >
> > `TopologicalManifold` sounds good, since this where the charts live in
the current approach.
>
> I will do this on the next commit.
OK very good.
>
> > > - There are failing doctests in `utilities.py` likely due to recent
changes in the symbolic function code (independent of my changes).
> >
> > Indeed this reflects some bug in the latest pynac (cf. #20456);
fortunately it is fixed by #20475; so if the latter is merged before the
current ticket, we can leave the doctests as they are.
>
> So we will just watch what happens with #20475, which might means we
need to mark them as `# known bug` and revert them in #20475.
OK.
--
Ticket URL: <http://trac.sagemath.org/ticket/18640#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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
