Ondrej,

On Thu, Jun 16, 2011 at 11:12 PM, Ondrej Certik <[email protected]> wrote:
> On Thu, Jun 16, 2011 at 9:27 PM, Brian Granger <[email protected]> wrote:
>> Sean,
>>
>> Here are some notes I sent to you earlier in the summer.  The points
>> made here are quite important..
>>
>> So there are some things you should know about the Wigner D matrix:
>>
>> * While I implemented it, I have 0 confidence that the current
>> implementation is free of bugs.  Because of this, one of the first
>> tasks should be to test this part of the code extensively, both for
>> numerical and symbolic arguments.
>>
>> I would test the D and d matrix code thoroughly *before* moving on to
>> anything else.  It would be great to see a pull request for that.
>>
>> * The current method of computing the D matrix is not optimal.  This
>> is because we probably want to use a different form for the integer
>> and half integer spin values.  This is to get the canonical forms
>> where, for 1/2 integer spins there are things like sin(theta/2) and
>> cos(theta/2), but for integer spins, sin(theta) and cos(theta) appear.
>>  This should be implemented and then tested extensively.
>>
>> This will also help in testing and comparing to the tables in Varsh.
>>
>> * Let's use the convention of Varshalovich for the D-matrices.  He
>> follows the convention of most of the other main people in the field
>> (see Table 4.2 for a list).
>>
>> * We should use his convention for Euler angles as well.
>>
>> * Because of the intimate relationship between CG, Wigner 3j6j, etc
>> and the rotation matrices, we probably want to have a symbolic DMatrix
>> class that we can use when we are representing various sum and
>> integrals symbolically.  This should be separate from the rotation
>> matrix operator and should be in the same category object as the GC
>> and Wigner symbols.  This will allow us to implement all of the
>> symmetry relationships that D satisfies as well.
>>
>> * Currently I have implemented one of the differential representations
>> of d(J,m,m') from section 4.3.2.  I think that is probably OK for
>> integer spin, but for half integer spins we should use one of the
>> formulas from section 4.3.1 that are a sum over k.
>
>
> Brian, Sean, I think that we should have a WignerD class, that will
> behave just like this:
>
> http://reference.wolfram.com/mathematica/ref/WignerD.html

I am +1 on this with one exception.  I think that it should be
symbolic and not return the actual function be default. This way we
can use this class in a symbolic manner when manipulating various
kinds of sums and integrals.  This mean that the class would have a
method that returns the actual representation in terms of cos(),
sin().

> except that it will be called like WignerD(j, m, mp, alpha, beta,
> gamma), at least that's what I would propose,

Yep.

> and it will be thoroughly tested and so on. Then Rotation.D() will
> return WignerD(j, m, mp, alpha, beta, gamma)
> and Rotation.d() will return WignerD(j, m, mp, 0, beta, 0).

Yep.

> Let me know what you think. This will keep things simple and clean and
> be compatible with Mathematica.

I like this idea.

Brian

> Ondrej
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" 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/sympy?hl=en.
>
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
[email protected] and [email protected]

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" 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/sympy?hl=en.

Reply via email to