#10132: Differential Geometry via Sage
------------------------------------+---------------------------------------
Reporter: mikarm | Owner: mhampton
Type: enhancement | Status: new
Priority: major | Milestone:
Component: geometry | Keywords: differential geometry,
parametrized surface
Author: Mikhail Malakhaltsev | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------------------+---------------------------------------
Old description:
> I am working in the field of differential geometry (research and
> teaching) and use SAGE for two or three years in the research work and in
> the teaching as well.
>
> SAGE includes rather developed methods in algebra, number theory,
> algebraic geometry, etc. but lacks the differential geometry. Therefore I
> would like to contribute to the SAGE development in this direction.
>
> To start with, I wrote a class 'parametrized_surface3d', and made a
> worksheet "Ellipsoid via SAGE" which demonstrates the methods of the
> class in work. I attached the corresponding files to this ticket.
> Note that, at this moment, the class is not optimized from the programing
> point of view (calculation time, catching exeptions, etc), but somehow it
> works.
>
> I plan to write also the similar classes for curves on the plane and in
> the 3-dimensional space, as well as a class for a surface given
> implicitly. The further plans are Riemannian geometry, etc, though the
> life is short :) so I do not know if I will be able to complete this
> program. Anyway, I hope I will write a text-book "Elementary differential
> geometry via SAGE" which in some sense will be similar to A.Gray's book
> "Differential geometry via Mathematica".
>
> So I would be thankful if I could get answers on the following questions:
>
> 1) What do you think, is it important to include the differential
> geometric stuff to SAGE?
>
> 2) Are there other people who work in the same direction? It would be
> good if I could cooperate with them.
>
> 3) What recommendations can you give concerning the code of the class for
> I could take into account in my future work.
New description:
--
Comment(by mikarm):
to Joris
The work you did is really great. Thank you also for the reference to the
page with instructions. I have just come back to Bogota, so I could not
look in details in the code improvements you did. I will carefully study
them and then comment in details. Anyway, it is incredible help.
Now concerning the remarks:
>Sometimes the terminology "vector" is used where "vector field" would be
more appropriate.
Yes, sure, we will change this.
>It seems as if this class would benefit from having a small template for
a generic tensor class. Right now, many of the member functions return
tensors as lists (which is fine), but there are also member functions
which take an optional argument to return only one component of that
tensor. This code then needs to check whether the optional argument is
valid, adding some complexity to the code. Maybe we could define a simple
tensor class which just has __getitem__ and __setitem__ and then let this
class deal with components, input checking, etc.
Also agree.
> I think that some of the functions in the vector_functions module have
Sage alternatives, which should be used instead.
It is interesting, I could not find these alternatives, maybe because I do
not know Sage well enough. If such alternatives exist, surely we need to
use them.
>We need to think on providing an interface to parametric_plot3d, so that
these kind of surfaces can easily be plotted.
I also had this idea, for example for plotting vector fields along the
surface (see examples in the worksheet). However, I decided to use Unix
way: small programs from which the user organizes something like a pipe to
get the result. The reason is that it is easier to tune small stones, than
to handle big rocks :) May be I am wrong, we should think about this
possibility: an interface to plotting routines.
> Caching the result of computing the fundamental forms, the Christoffel
symbols, etc. This would make subsequent calls to the components of these
tensors much faster, at the expense of some memory.
Sometimes, it is needed to find one Christoffel symbol, or a coordinate of
a metric tensor (we should take into account the fact that calculations in
differential geometry may be very very long). So, from my point of view,
it possible to use two approaches (as it was done in Maxima). If a user
needs all the information on the surface in order to solve some problem,
the class calculates everything (first and second fundamental forms,
curvatures, etc) and caches it. But also user may say that he needs only
one thing, then the class returns exactly the required object.
>The numerical routines should be optimized for float operations using
fast_float or similar.
Completely agree, we should do it.
To Andrei:
Wiki, it is a good idea, thank you! I will look how to do it, and surely
this is the decision.
>It may be useful to consider creating some classes for "generic
manifolds" and then specialize them to curves and surfaces. This can be
useful to ensure uniform interface in the future and have a possibility
right from the start to put "generic methods" into appropriate places.
Certainly, there are such methods, for example, find Christoffel symbols
of a metric, find a geodesic, etc. which can be included in the more
general class of Riemannian manifold.
I submitted a request to join the group Sage-devel, but there is no
response up to now. When I manage to join, I will post the information in
this group as well.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10132#comment:7>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
