I didn't realize that Sage could do Lie algebra manipulations. What are the pros and cons for writing an interface to LiE as opposed to simply extending Sage's existing functionality? Is LiE faster, or has it implemented some tricky algorithms that people don't want to write in sage?
I'd be happy to donate my code to Sage, although I don't know if it will have the right organization or be of the right quality standards. I haven't used Sage, but it looks like it has some kind of system for dealing with general mathematical objects, for instance keeping track of whether something is a group or ring element, or in a vector space over some field. I made some decisions about what kind of classes to include in my interface based on trying to achieve the simplest code for my particular applications, and not with an eye towards conforming to some general math system. For instance, whereas LiE uses a polynomial to stand for a representaion, I have a Rep object that wraps a polynomial and a group, where multiplication on Rep's is defined as tensor product. If I were writing a sage extension, I imagine I would have to somehow also encode that Rep is a type of ring over the integers, etc.. Would my code be useful even without conforming to sage's math conventions? I'd be interested in learning how to write a sage extension at some point, but I need my code for a physics project I'm actively working on now, and I'm not sure I have very much time to spend on programming. Thanks, David On Wed, Jul 8, 2009 at 12:22 PM, William Stein <[email protected]> wrote: > On Wed, Jul 8, 2009 at 9:17 AM, David > Simmons-Duffin<[email protected]> wrote: > > On Jul 8, 2009, at 1:32 AM, Robert Bradshaw wrote: > > > >>> One possible solution is to just replace the word "object" in the C > >>> source with something else throughout. But I'd like to make as few > >>> modifications of the C source as possible. Is there an alternate > >>> solution? > >> > >> Yes, you can use the magic c-namespace-renaming quotes. For your > >> example. > >> > >>> I actually have another unrelated question: what is the correct > >>> cython > >>> syntax for the union statement at the top of this message? Cython > >>> doesn't seem to like me putting > >>> > >>> struct any: > >>> objtype type > >>> reftype nfref > >>> > >>> in the middle of a union statement. > >> > >> Cython doesn't support anonymous structs. Give that struct a name, > >> and then you can declare your variable with that type. (The name you > >> choose will never actually be used.) > > > > Thanks, your suggestions worked perfectly. > > > >> Just out of curiosity, what are you wrapping? It looks like a math > >> library of sorts. > > > > I'm wrapping a program called LiE for doing computations in lie group > > representation theory. > > > > http://www-math.univ-poitiers.fr/~maavl/LiE/<http://www-math.univ-poitiers.fr/%7Emaavl/LiE/> > > > > This sort of thing is very useful in high energy theoretical physics, > > which is what I work on. The typical choice among us theorists for > > doing computations is Mathematica (with the exception of collider > > simulations, which are run with dedicated programs like Pythia). > > However, representation theory is something Mathematica doesn't seem > > to know about, and I haven't been able to find a package for it. > > > > LiE does basically what I want, except that everything is wrapped up > > in a custom language that's not very expressive, hard to debug, and > > generally unpleasant to use. Python is much lovelier, especially > > since the object-oriented-ness is well-suited for writing > > mathematics. So I'm doing my best to provide a python interface as an > > alternative to LiE's built-in lexer, parser, and interpreter. > > > > (1) The Sage project (http://sagemath.org) may be very interested in > getting your code that wraps LiE when you finish it. Having a Sage > <--> Lie interface has been requested feature. > > (2) Sage itself has substantial functionality for combinatorics of Lie > algebras. See, e.g., the talk by Dan Bump that is linked to from > here: http://wiki.sagemath.org/days14 > > > -- William > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev >
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
