Some Lie-Algebra Routines

[danle...@gmail.com]

Hi everyone,

I wrote some routines for computations with Lie-Algebras:

http://dweiss.jvimedia.org/PyLie.html

Please be patient, it is far away from being finished, but maybe you could have a look, and give a few comments.

Greetings,

Daniel

[Ondřej Čertík]

Hi Daniel,

I ran your code, it seems to work. If you want, you can create IPython
notebooks with demo usage and post them to
http://nbviewer.ipython.org/, then people can easily see how to use
your package together with results.

Ondrej

[Francesco Bonazzi]

Would you like your code to be included into SymPy?

[danle...@gmail.com]

Hi everyone,

yes, I want to include my code into sympy. But not now.

Before a possible inclusion, I would like to improve the coding-style, and add a sufficient exception handling.

Besides, some further goals for the near future are:
- The Implementation of the full functionality of the Gap-System for Lie-Algebras ( http://www.gap-system.org/Manuals/doc/ref/chap64.html ) on the Fields R, C, Q, Q+iQ
- The pooling of my classes with the Lie-Algebra classes, which is already implemented ( = mainly semisimple theory).
- The Implementation of connections between Lie-Theory and the physics module (Clebsch-Gordan, Commutation Relations, etc. etc.)

In this context, I would appreciate comments on other desirable features.

Becaues I'm still a (physics-) student, I'm also thinking on an application for the GSoC 2015, would this be a good idea?

Greetings,

Daniel

[Joachim Durchholz]

Am 15.01.2015 um 14:44 schrieb danle...@gmail.com:
> Hi everyone,
>
> yes, I want to include my code into sympy. But not now.
>
> Before a possible inclusion, I would like to improve the coding-style, and
> add a sufficient exception handling.

Sounds reasonable.
Personally, I think it would be reasonable to add proper caveats to the
docstrings and include the code anyway. It gives the code more
visibility, so other contributors might be interested in doing these
improvements.
I'm not sure what policy the SymPy project as a whole in these matters
has, it may well be that Aaron or Ondrej disagree.

However, at any rate, define an "imperfection tolerance" at which you're
willing to have the code included. If you want to deliver something
that's 100% perfect, you'll hone it for the rest of your life and it
won't get ever included, because there's *always* "one other thing to
improve".

(Not having any knowledge of group theory, I can't comment on what
features might or might not be desirable.)

> Becaues I'm still a (physics-) student, I'm also thinking on an application
> for the GSoC 2015, would this be a good idea?

Definitely.

Regard,
Jo

[Francesco Bonazzi]

OK that's nice. I think you had better post your code on github, it offers some advantages, such as commenting code on the lines.

[danle...@gmail.com]

I've put it on github: https://github.com/warpfel/PyLie

[Francesco Bonazzi]

As a first suggestion, if you want to create a SymPy object, I would suggest to inherit from sympy.core.basic.Basic, something like this:

class YourClass(Basic):
    # constructor:
    def __new__(cls, arg1, arg2, ... ):
        obj = Basic.__new__(cls, arg1, arg2, ... )
        return obj

    @property
    def arg1(self):
        return self.args[0]

    @property
    def arg2(self):
        return self.args[1]

An alternative would be to put obj._arg1 = arg1 in the constructor, the return self._arg1 in the properties.

In this way, some functions such as __eq__ and __hash__ will be automatically defined, __eq__ will compare the constructor arguments, and it's probably going to be more efficient, as SymPy's core uses hashes.

[Francesco Bonazzi]

On Friday, January 16, 2015 at 11:49:13 AM UTC+1, danle...@gmail.com wrote:

I've put it on github: https://github.com/warpfel/PyLie

I had a quick look at your code. I saw that LieStructureConstantTable takes only the dimension as a parameter. I suppose you fill the structure constant table by hand after the construction.

Objects in SymPy usually are fully defined by the arguments passed to the constructors. Just consider that some functions, such as simplify( ), may re-instantiate your object, so any data you add after its creation gets lost.

Furthermore, objects should also be immutable. Consider a SymPy object becoming part of an expression, while on some other part of the code the same object gets modified. This would alter all expressions containing references to that object. Modifying an object after it has been constructed is usually considered a bug in SymPy.

[Francesco Bonazzi]

Concerning a Lie algebra defined by the structure constants: keep in mind this is a way often used in Physics, which is not very rigorous. Structure constants define an equivalence class of bases in a Lie algebra.

For example, consider a Lie algebra with two generators: A, B. If you define X = 2*A - 3*B, Y = A + B, then X and Y are still generators, but will have generally different structure constants.

[danle...@gmail.com]

Hi Francesco,

I'm sorry for my long latency time.

Concerning a Lie algebra defined by the structure constants: keep in mind this is a way often used in Physics, which is not very rigorous. Structure constants define an equivalence class of bases in a Lie algebra.

For example, consider a Lie algebra with two generators: A, B. If you define X = 2*A - 3*B, Y = A + B, then X and Y are still generators, but will have generally different structure constants.

 
Yes, that is clear to me. Maybe the documentation is too imprecise at this point. Unfortunately a "real" Lie-Algebra class makes (except in the semisimple case) no sense, because the classification of Lie-Algebras is really a non-trivial problem. You may have a look on the method

 GLV_Action(self, a): #Computes the Action of an Element of GL(V) on the Variety of Structure Constants

Due to your other remarks, I will revise my code promptly.

Thank you very much,

Greetings,

Daniel

[Francesco Bonazzi]

On Wednesday, January 21, 2015 at 8:12:31 PM UTC+1, danle...@gmail.com wrote:

Hi Francesco,

I'm sorry for my long latency time.

Concerning a Lie algebra defined by the structure constants: keep in mind this is a way often used in Physics, which is not very rigorous. Structure constants define an equivalence class of bases in a Lie algebra.

For example, consider a Lie algebra with two generators: A, B. If you define X = 2*A - 3*B, Y = A + B, then X and Y are still generators, but will have generally different structure constants.

 
Yes, that is clear to me. Maybe the documentation is too imprecise at this point. Unfortunately a "real" Lie-Algebra class makes (except in the semisimple case) no sense, because the classification of Lie-Algebras is really a non-trivial problem. You may have a look on the method

 GLV_Action(self, a): #Computes the Action of an Element of GL(V) on the Variety of Structure Constants

By the way, there is already some support for Lie algebras in SymPy:

https://github.com/sympy/sympy/tree/998a9100f3c8493a2b6f1ff10c02024f36d48811/sympy/liealgebras

Have a look at this. It does not depend on numpy. Also notice where the tests are placed.
 

Due to your other remarks, I will revise my code promptly.

 
Actually, those remarks are necessary if you want your objects to be part of a SymPy expression tree. There are some exceptions in SymPy where classes do not inherit from Basic, but those objects are not meant to be part of the expression tree.

Concerning the style, usually in SymPy class names use CamelCase, while methods and functions use snake_case.

[Aaron Meurer]

We follow PEP 8 style, which is the style for all Python (not just SymPy). Though note that we do break PEP 8 sometimes (e.g., for mathematical functions, we don't always use these case conventions, for instance sin() is a class but we still use lowercase because that's how the mathematical function is spelled). In this case, I would always keep things like gl/GL capitalized according to the mathematical conventions. 

Aaron Meurer

 

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/239c3826-c4cc-41c2-a7d5-d936363a630d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.