Clebsch–Gordan coefficients
Lance W
I am looking for codes for Clebsch–Gordan coefficients operations. Are
there such codes already in sympy or is there a plan to put them in?
If yes please point me to them.
Thanks,
Lance
Brian Granger
The right place to put them would be in an appropriately named
submodule of sympy.physics. I am not sure of any plans to add them,
but we would love help!
Cheers,
Brian
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu
elli...@gmail.com
Ondrej Certik
> It would be great to have this, although we don't have them already.
> The right place to put them would be in an appropriately named
> submodule of sympy.physics. I am not sure of any plans to add them,
> but we would love help!
Yes. Lance, would you have time to start it? We will help with any
technical issues that you might hit. You can take this code from Sage:
http://trac.sagemath.org/sage_trac/ticket/5996
I got a permission from the author to relicense his code as BSD and
use it in SymPy.
(If you go this route, let me know, I'll ask him and all the people
who changed his patch again, just to make sure all is fine.)
Ondrej
Brian Granger
This would be great to have in sympy!
Cheers,
Brian
> Ondrej
spc93
Sorry - not sure how these things work!
I found some Numpy code for C-G coefficients by Michael V. DePalatis
on the web and it was very easy to Sympyfy. Only a few lines. Not sure
if it is acceptable to post something modified from someone else's
code. Perhaps you can advise?
Steve
On Jul 13, 6:58 am, Brian Granger <elliso...@gmail.com> wrote:
> On Mon, Jul 12, 2010 at 10:50 PM, Ondrej Certik <ond...@certik.cz> wrote:
> >> It would be great to have this, although we don't have them already.
> >> The right place to put them would be in an appropriately named
> >> submodule of sympy.physics. I am not sure of any plans to add them,
> >> but we would love help!
>
> > Yes. Lance, would you have time to start it? We will help with any
> > technical issues that you might hit. You can take this code from Sage:
>
> >http://trac.sagemath.org/sage_trac/ticket/5996
>
> > I got a permission from the author to relicense his code as BSD and
> > use it in SymPy.
> > (If you go this route, let me know, I'll ask him and all the people
> > who changed his patch again, just to make sure all is fine.)
>
> This would be great to have in sympy!
>
> Cheers,
>
> Brian
>
> > Ondrej
>
> > --
> > You received this message because you are subscribed to the Google Groups "sympy" group.
> > To post to this group, send email to sy...@googlegroups.com.
> > To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> elliso...@gmail.com
Aaron S. Meurer
Aaron Meurer
Brian Granger
Ondrej,
I am willing to help out in this capacity. Even if we just put this
stuff in a branch for now, we can pick away at integrating it with
sympy over time. Can you clear up the license questions?
Cheers,
Brian
> Ondrej
Ondrej Certik
> On Mon, Jul 12, 2010 at 10:50 PM, Ondrej Certik <ond...@certik.cz> wrote:
>> On Mon, Jul 12, 2010 at 10:47 PM, Brian Granger <elli...@gmail.com> wrote:
>>> It would be great to have this, although we don't have them already.
>>> The right place to put them would be in an appropriately named
>>> submodule of sympy.physics. I am not sure of any plans to add them,
>>> but we would love help!
>>
>> Yes. Lance, would you have time to start it? We will help with any
>> technical issues that you might hit. You can take this code from Sage:
>>
>> http://trac.sagemath.org/sage_trac/ticket/5996
>>
>> I got a permission from the author to relicense his code as BSD and
>> use it in SymPy.
>> (If you go this route, let me know, I'll ask him and all the people
>> who changed his patch again, just to make sure all is fine.)
>
> Ondrej,
>
> I am willing to help out in this capacity. Even if we just put this
> stuff in a branch for now, we can pick away at integrating it with
> sympy over time. Can you clear up the license questions?
Ok, I'll go ahead and do it.
Yes, I agree, we just need to get started.
I'll keep you informed how it goes.
Ondrej
spc93
The link for Numpy code is: http://mike.depalatis.net/code.html
These are not difficult calculations but they might not be optimized
for speed. As I said, converting to Sympy was quite trivial (I only
did the C-G's but the 3J/6J symbols should not be hard either).
Steve
>
> - Show quoted text -
Ondrej Certik
> Hi,
> The link for Numpy code is: http://mike.depalatis.net/code.html
> These are not difficult calculations but they might not be optimized
> for speed. As I said, converting to Sympy was quite trivial (I only
> did the C-G's but the 3J/6J symbols should not be hard either).
Cool. We already got permission from all people involved with the
Sage's implementation, you can follow the progress here:
http://groups.google.com/group/sage-devel/browse_thread/thread/33835976efbb3b7f
The last one is Jens, who I already got a permission in a private
email about a year ago, but let's wait to get it again, just to make
sure.
So we can compare which one is better.
Ondrej
Ondrej Certik
We just got the permission from Jens as well (above). So feel free to
take the wigner.py and start adapting it for sympy.
Ondrej
spc93
This is all I did. I kept as much of the original code as possible. No
guarantees but it seemed to work for the cases I tested it for. It is
basically identical to the original Numpy version from Michael
DePalatis except that it uses Sympy and I removed a parameter that
determines the number if terms to include in the calculation, which
did not seem to be necessary. And I added a warning for unphysical
values.
Steve
def ClebschGordan(j1, j2, m1, m2, J, M, warn=True):
"""
ClebschGordan(j1, j2, m1, m2, J, M,warn=True)
Computes exact sympy form for Clebsch-Gordan coefficient
<j1 j2; m1 m2|j1 j2; JM>.
For reference see
http://en.wikipedia.org/wiki/Table_of_Clebsch-Gordan_coefficients.
Clebsch Gordan numpy function by Michael V. DePalatis, modified and
converted to sympy by SPC
warn gives warning for unphysical coefficients
"""
#kron = KDelta(m, m1 + m2)
#if kron == 0:
# return kron
if not M==(m1+m2) or J>(j1+j2) or J<abs(j1-j2) or J<0 or abs(m1)>j1
or abs(m2)>j2 or abs(M)>J:
if warn:
print 'Warning: Unphysical Clebsch-Gordan coefficient
(j1,j2,m1,m2,J,M)='+str((j1,j2,m1,m2,J,M))
return 0
c1 = sympy.sqrt((2*J+1) * sympy.factorial(J+j1-j2) *
sympy.factorial(J-j1+j2) * \
sympy.factorial(j1+j2-J)/sympy.factorial(j1+j2+J+1))
c2 = sympy.sqrt(sympy.factorial(J+M) * sympy.factorial(J-M) *
sympy.factorial(j1-m1) * \
sympy.factorial(j1+m1) * sympy.factorial(j2-m2) *
sympy.factorial(j2+m2))
c3 = 0.
cglimit=max((j1+j2-J),(j1-m1),(j2+m1))+1 #max k that satisfies
requirement that all factorial args are non-neg
for k in range(cglimit):
use = True
d = [0, 0, 0, 0, 0]
d[0] = j1 + j2 - J - k
d[1] = j1 - m1 - k
d[2] = j2 + m2 - k
d[3] = J - j2 + m1 + k
d[4] = J - j1 -m2 + k
prod = sympy.factorial(k)
for arg in d:
if arg < 0:
use = False
break
prod *= sympy.factorial(arg)
if use:
#print k
c3 += (-1)**k/prod
return c1*c2*c3
On 15 July, 03:03, Ondrej Certik <ond...@certik.cz> wrote:
> On Wed, Jul 14, 2010 at 10:07 AM, Ondrej Certik <ond...@certik.cz> wrote:
> >> Hi,
> >> The link for Numpy code is:http://mike.depalatis.net/code.html
> >> These are not difficult calculations but they might not be optimized
> >> for speed. As I said, converting to Sympy was quite trivial (I only
> >> did the C-G's but the 3J/6J symbols should not be hard either).
>
> > Cool. We already got permission from all people involved with the
> > Sage's implementation, you can follow the progress here:
>
Ondrej Certik
On Fri, Jul 16, 2010 at 6:26 AM, spc93 <steve.c...@gmail.com> wrote:
> Hi,
> This is all I did. I kept as much of the original code as possible. No
> guarantees but it seemed to work for the cases I tested it for. It is
> basically identical to the original Numpy version from Michael
> DePalatis except that it uses Sympy and I removed a parameter that
> determines the number if terms to include in the calculation, which
> did not seem to be necessary. And I added a warning for unphysical
> values.
Thanks for the code. I think that in the long term, it'd be cool to
have the code from Sage, because it was written by the author of the
article about evaluating the coefficients. Also it implements also 3j
and 6j symbols.
I have started porting it, the basic Clebsches seem to work fine now:
http://github.com/certik/sympy/tree/wigner
Can someone please review it? The rest of the things (3j, 6s symbols)
are not tested yet and probably don't work, but Clebsches work and we
can improve this later. Important is to get started. So I think it's
ready to go in, if you agree. All tests pass.
Ondrej
Brian Granger
Hi Steve,
Thanks for the code. I think that in the long term, it'd be cool to
On Fri, Jul 16, 2010 at 6:26 AM, spc93 <steve.c...@gmail.com> wrote:
> Hi,
> This is all I did. I kept as much of the original code as possible. No
> guarantees but it seemed to work for the cases I tested it for. It is
> basically identical to the original Numpy version from Michael
> DePalatis except that it uses Sympy and I removed a parameter that
> determines the number if terms to include in the calculation, which
> did not seem to be necessary. And I added a warning for unphysical
> values.
have the code from Sage, because it was written by the author of the
article about evaluating the coefficients. Also it implements also 3j
and 6j symbols.
I have started porting it, the basic Clebsches seem to work fine now:
http://github.com/certik/sympy/tree/wigner
Can someone please review it? The rest of the things (3j, 6s symbols)
are not tested yet and probably don't work, but Clebsches work and we
can improve this later. Important is to get started. So I think it's
ready to go in, if you agree. All tests pass.
Ondrej
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
elli...@gmail.com
Ondrej Certik
I took the latest version from Sage hg. Are there some patches that I
am missing?
> * Let's put a note at the top about which functions have been tested/ported
> and which have not.
The problem is that there are not many tests. So I consider ported
only those functions, that have been fully tested. Which means none at
the moment. As you can see here:
http://github.com/certik/sympy/blob/wigner/sympy/physics/tests/test_clebsch_gordan.py#L4
All the numbers from wikipedia should be tested. And that's just
Clebsch Gordan coefficients.
> * In the module level docstring, let's add a comment about this coming from
> Sage with permission to be relicensed.
It's already there:
http://github.com/certik/sympy/blob/wigner/sympy/physics/wigner.py#L18
or do you mean to improve it somehow?
> * Should be update the docstrings/doctests for the ported functions? We can
> also do this later. I don't want to delay this getting in.
We should definitely port the docstrings. I'll try to do some tonight.
> * Does sage have a test suite for this module? If so, should we bring it
> over as well? If not we can just port their doctests.
> Other than this, it looks good and I would merge.
I didn't find any. If they do, we absolutely need that.
I think that Sage only uses doctests, which in many cases (like this)
I find insufficient. They have a "TESTS" section, which I think
doesn't show up in the documentation, but still I think it's better to
test all Clebsches in a separate file. We should test all of them from
wikipedia, to make sure we got all the corner cases right.
Ondrej
Brian Granger
> * Let's put a note at the top about which functions have been tested/portedThe problem is that there are not many tests. So I consider ported
> and which have not.
only those functions, that have been fully tested. Which means none at
the moment. As you can see here:
http://github.com/certik/sympy/blob/wigner/sympy/physics/tests/test_clebsch_gordan.py#L4
All the numbers from wikipedia should be tested. And that's just
Clebsch Gordan coefficients.
> * In the module level docstring, let's add a comment about this coming fromIt's already there:
> Sage with permission to be relicensed.
http://github.com/certik/sympy/blob/wigner/sympy/physics/wigner.py#L18
or do you mean to improve it somehow?
> * Should be update the docstrings/doctests for the ported functions? We canWe should definitely port the docstrings. I'll try to do some tonight.
> also do this later. I don't want to delay this getting in.
> * Does sage have a test suite for this module? If so, should we bring itI didn't find any. If they do, we absolutely need that.
> over as well? If not we can just port their doctests.
> Other than this, it looks good and I would merge.
I think that Sage only uses doctests, which in many cases (like this)
I find insufficient. They have a "TESTS" section, which I think
doesn't show up in the documentation, but still I think it's better to
test all Clebsches in a separate file. We should test all of them from
wikipedia, to make sure we got all the corner cases right.
Ondrej
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
klmn
I need Gaunt coefficients (see the neighboring thread) and I have also
started from the code wigner.py. Although Jens cites his paper there,
he doesn’t use it. The paper is about storing the coefficients (and
this is not implemented) and the calculation itself follows another
paper.
After I will have solved the simplification problem which hold also
for you guys who need CG and 3j, I will try to implement two storing
schemes: one from Rasch&Yu and one from Pinchon&Hoggan. If someone has
already made a Python script for this, I would be grateful for sharing
it.
As to the Sage code wigner.py, it needs some careful revision. For
example:
a) it has assignments just before conditional operators that may
return; thus these assignments may never be used;
b) several indices are repeatedly calculated, even inside a loop,
instead of being assigned to a variable (e.g. l_1 + l_2 - l_3 in
Gaunt);
c) type checking for being integer or half integer is not optimal;
d) usage of ``prec`` (precision) is not consistent throughout the
code.
Regards,
Konstantin
Ondrej Certik
On Wed, Jul 28, 2010 at 6:46 AM, klmn <kklem...@cells.es> wrote:
> Dear all,
>
> I need Gaunt coefficients (see the neighboring thread) and I have also
> started from the code wigner.py. Although Jens cites his paper there,
> he doesn’t use it. The paper is about storing the coefficients (and
> this is not implemented) and the calculation itself follows another
> paper.
>
> After I will have solved the simplification problem which hold also
> for you guys who need CG and 3j, I will try to implement two storing
> schemes: one from Rasch&Yu and one from Pinchon&Hoggan. If someone has
> already made a Python script for this, I would be grateful for sharing
> it.
That would be absolutely awesome! Let us know if you need any help.
>
> As to the Sage code wigner.py, it needs some careful revision. For
> example:
> a) it has assignments just before conditional operators that may
> return; thus these assignments may never be used;
> b) several indices are repeatedly calculated, even inside a loop,
> instead of being assigned to a variable (e.g. l_1 + l_2 - l_3 in
> Gaunt);
> c) type checking for being integer or half integer is not optimal;
> d) usage of ``prec`` (precision) is not consistent throughout the
> code.
Yes, I noticed. I just removed the "prec", for CG coefficients, so
that it works with sympy, at least somehow.
Ondrej
Ondrej Certik
Yep.
>
>>
>> > * In the module level docstring, let's add a comment about this coming
>> > from
>> > Sage with permission to be relicensed.
>>
>> It's already there:
>>
>> http://github.com/certik/sympy/blob/wigner/sympy/physics/wigner.py#L18
>>
>> or do you mean to improve it somehow?
>>
>
> Nope I just missed this. Looks great.
>
>>
>> > * Should be update the docstrings/doctests for the ported functions? We
>> > can
>> > also do this later. I don't want to delay this getting in.
>>
>> We should definitely port the docstrings. I'll try to do some tonight.
>>
>
> Great, but let's not let this prevent this from being merged soon.
I just ported the CG doctests (there were only 3...) to sympy and
pushed the whole thing in.
>
>>
>> > * Does sage have a test suite for this module? If so, should we bring
>> > it
>> > over as well? If not we can just port their doctests.
>> > Other than this, it looks good and I would merge.
>>
>> I didn't find any. If they do, we absolutely need that.
>>
>> I think that Sage only uses doctests, which in many cases (like this)
>> I find insufficient. They have a "TESTS" section, which I think
>> doesn't show up in the documentation, but still I think it's better to
>> test all Clebsches in a separate file. We should test all of them from
>> wikipedia, to make sure we got all the corner cases right.
>>
>
> Yes, I have some really good Russian angular momentum texts at work that
> have thousands of identities we can test...OK, maybe not all of them, but a
> representative set.
Cool. Let's keep improving it.
Ondrej
klmn
I have created a module `gaunt_tables` for calculating, storing,
retrieving and testing the Gaunt coefficients.
The module uses `sympy` for calculations and `pyTables` for efficient
handling of large amounts of data. Three various
indexing schemes are implemented for storing/retrieval.
The module is fully documented and prepared for Sphinx.
If someone is interested, I can share it. I just don't see how I can
upload an archive (I am using the web form of the maillist).
Dealing with CG and 3j symbols is very similar, it just requires an
additional step: calculation of intermediate indices.
Konstantin
Aaron S. Meurer
Aaron Meurer
Konstantin Klementiev
be the sphinx-built html manual in the attached archive. I put now a pdf
manual and hope it'll get through...
Konstantin
klmn
Aaron, thanks for the hint!
Konstantin
Ondrej Certik
thanks for this. I would like to have this in sympy itself.
I can see that problem in sympy/core/numbers.py with the "if b >
4294967296" now, we need to address it to make your code working.
Thanks for releasing it under the MIT license, so that we can include
it in sympy. Since it uses pytables, we should move the pytables
import inside the store_gaunts(), and the numpy include as well, so
that sympy works even if the user doesn't have numpy or pytables, and
it will get imported once the user calls such functions.
I think we should put this into sympy/physics/gaunt_tables.py (we
already have there wigner.py).
Ondrej
Aaron S. Meurer
On Sep 23, 2010, at 6:35 PM, Ondrej Certik wrote:
> Hi Konstantin,
>
> On Thu, Sep 23, 2010 at 12:11 PM, Konstantin Klementiev
> <kklem...@cells.es> wrote:
>> Host gmr-smtp-in.l.google.com detects an illegal attachment, this can only
>> be the sphinx-built html manual in the attached archive. I put now a pdf
>> manual and hope it'll get through...
>
> thanks for this. I would like to have this in sympy itself.
>
> I can see that problem in sympy/core/numbers.py with the "if b >
> 4294967296" now, we need to address it to make your code working.
Issue 2003 gives the correct solution for this by the way.
Aaron Meurer