On 7 October 2014 12:13, Kurt Pagani <[email protected]> wrote:
>
> On Tuesday, 7 October 2014 05:36:26 UTC+2, Bill Page wrote:
>> ...
>> Your examples look good to me, except I would definitely prefer not to
>> have to pass a metric for each function call.
>
> In the first place I had included the functions,
>
>       g:SMR := diagonalMatrix([1 for j in 1..dim])
>
>       showMetric(x) == g
>
>       setMetric(x,m) ==
>         symmetric? m => g:=m
>         error("metric tensor should be symmetric.")
>
> to (re)set it when needed (Euclidean as default). Then I asked here what's
> better, parameter or inline. There is by now 2:1 against including :)  I
> believe most users will not write dot(a,b,g)/hodgeStar(a,g) anyway a lot but
> writing a macro or prefix/matchfix operator where you can hide the metric.
>

I also definitely don't like the idiom of stateful/destructive
operations on domains like 'setMetric'.  I would strongly prefer
either a package call or a new domain with additional static
parameter.

>
>> we were to create a
>> new domain that allows metric to be part of the definition,
>> what should it be called?
>
> I have no idea. You tell me?  I can't yet overview how the final module(s)
> should look like.

How about:

  DifferentialGeometry

It is consistent with your objectives below and gives some room to add
more.  It is a pretty obvious name for most applications even if the
orientation remains suitably abstract and generic in the FriCAS/Axiom
tradition..

> What I have in mind is first to complete this by functions like proj
> (projection on homogeneous parts, subspaces), push forward/pull
> back, interior product i_X and Lie derivative L_X which is possible
> which little effort, second to have simplicial homology (e.g. a type Simplex)
> then using FreeAbelianGroup(Simplex), defining boundaryOperator and
> so on such that one can deal with integration of differential forms over
> simplicial complexes (Stokes theorem, Hodge pairing and so on you
> know). It's almost all there but one has to organize it. It should be a
> teamwork to becoming really useful, so any suggestions welcome.

Yes!  I think your orientation and objectives are perfect. I would be
very glad to help where I can.

Bill Page.

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" 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/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to