On Sat, Feb 14, 2009 at 12:45 PM, Kasper Peeters
<kasper.peet...@googlemail.com> wrote:
>
> Hi Ondrej,
>
>> I'll play with it and reply later here. Have you considered creating a
>> cadabra package for Sage? They may even include it by default.
>
> I'm not sure that that is easy to do; in any case, no, I haven't done
> that yet.
>
>> In SymPy we will also be optionally using a Cythonized core, but if
>> possible, we'd like to stick to Python whenever possible. What is your
>> plan with Cadabra -- do you want to use it from Python?
>
> No, for me the interest is more in the other direction: I have a nice
> tensor algebra system with cadabra, but I need to link it to a
> 'scalar' CAS like sympy to do the rest of the algebra. (For example, I
> can manipulate Einstein equations and the like in abstract form, but I
> would like to be able to substitute values for the metric tensor
> components and compute with those.)
>
> But there is no reason why it couldn't beneficial in both directions.
>
>> I'll look into the sources of it to get a better idea.
>
> There are a couple of things which make cadabra different from other
> systems:
>
> - The input format. This is very carefully tuned to allow TeX-like
> input of tensorial expressions, and would need some translation
> if we want to connect this to sympy.
>
> - Algorithms actions are based on properties of symbols or objects.
> For instance, you can define a tensor to implicitly depend on a
> coordinate, and have derivative operators take that into account.
>
> - Centralised handling of indices and dummy indices. For instance,
> the system knows that
>
> \partial_{a}{ B_{c d} }
>
> is actually a tensor with three open indices, provided you
> declare \partial to have the 'IndexInherit' property.
>
> - Tensor polynomial canonicalisation (to reduce tensor polynomials
> to a canonical form when the tensors have symmetry properties,
> e.g. are symmetric or anti-symmetric in their indices, or
> something more complicated). Deals with arbitrary Young tableau
> symmetries.
>
> Some of these aspects are implemented in a way which is strongly tied
> to the C++ language, but they could certainly be re-implemented in
> Python if necessary. And if we can agree on a way to convert sympy
> input to cadabra input and vice versa, we might even just keep the
> cadabra core as-is.
Thanks for a detailed reply. I see --- actually I always wanted to
call sympy from C or C++. Thanks to Cython, it should be easy.
So your project could be the first application of that. I think it's
better to call sympy directly from your program, isn't it? As opposed
to convert the expressions to and from some string. What do you think?
Of course, if you are willing to link cadabra with Python.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---
