#18175: Implement categories for topological and metric spaces and related
categories
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: tscrim
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.8
Component: categories | Resolution:
Keywords: geometry, | Merged in:
topology, sd67 | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | 95a30aa57fc62f23a884790b57835d107d8bdeef
public/categories/topological_metric_spaces-18175| Stopgaps:
Dependencies: #18174 #17160 |
-------------------------------------+-------------------------------------
Comment (by bpillet):
Replying to [comment:25 tscrim]:
> Hey Basile,
Hi,
>
> I'm not quite sure what you're proposing we should do for organizing the
manifolds category. For the (a) <=> (b) condition, we aren't doing any
sort of checking. By a user constructing a object (parent) in a category,
the user is simply promising that it carries that structure.
>
> We could make it so there is no parameterization of the categories (on
the underlying field), but instead have the condition for objects to be in
the category that their base field be '''R''' or '''C''' as appropriate.
However I think this leads to ambiguity of dimension (e.g., for complex
manifolds, do you want the real or complex dimension?) and what you want
your charts to be.
I'm sorry I was not very clear. In my opinion it is important to
distinguish manifolds over '''R''' and over '''C'''. `AlmostComplex`
should be seen as manifolds over '''R''' enriched, but `ComplexManifold`
should not inherit from `AlmostComplex`. At least so that dimension or
charts would be unambiguous.
(There would still exist a coercion from `ComplexManifold` to
`AlmostComplex` but not coming from class heritage).
> Are you perhaps suggesting we should do something like the digram in
comment:21?
Yes actually. Because in the following diagram where everything is
parametrised on the underlying field, the case '''F'''='''C''' makes no
sense. Indeed `Differentiable/C` cannot exist since usual differentiable
maps are not '''C'''-linear. Or else if you define it to be
'''C'''-differentiable then it is the same as `Smooth/C` and `Analytic/C`
{{{
Manifolds/F
|
Differentiable/F
|
Smooth/F
|
Analytic/F
}}}
I'm not sure, where, in the implementation the issue may appear...
For example, in the case of finite fields : x --> x^p^ is not smooth on
F_p but it is analytic, which contradicts the heritage.
Basile
--
Ticket URL: <http://trac.sagemath.org/ticket/18175#comment:26>
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.
