bugGNU Scientific Library - Bugs: bug #39466, errors in gsl_sf_coupling_6j_e and...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #39466: errors in gsl_sf_coupling_6j_e and gsl_sf_coupling_9j_e

Submitter:  Patrick Alken <psa>
Submitted:  Thu 11 Jul 2013 05:49:47 PM UTC
   
 
Category:  Runtime error Severity:  3 - Normal
Operating System:  Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release: 

Fri 12 Jul 2013 04:00:47 PM UTC, comment #5: 

Fixed in revision 4836

Patrick Alken <psa>
Group administrator
Fri 12 Jul 2013 03:42:28 PM UTC, comment #4: 

Yes, this is a duplicate of #29606.  Sorry for not finding that.

Attached is a new patch (based on Alexey's suggestion) that now should
apply cleanly to bzr trunk. The previous was against v1.15.  It also
includes the tested case in #29606 in test_sf.c.

For completeness, while the case in #29606 is correct (6j to be 0 as
half-integer with integer cannot couple to integer), I think there were
a typo in the report: jc=21 should be jd=22, giving

abs(1-21.5)=20.5 <= 22 <= 22.5.

instead of

abs(1-21.5)=20.5 <= 21 <= 22.5.

Cheers,
Håkan

(file #28555)

Patrick Alken <psa>
Group administrator
Thu 11 Jul 2013 05:53:01 PM UTC, comment #3: 

This may be a repeat of bug #29606

Patrick Alken <psa>
Group administrator
Thu 11 Jul 2013 05:52:27 PM UTC, comment #2: 

(From Alexey Illarionov)

Hi, the function should be

static
int
triangle_selection_fails(int two_ja, int two_jb, int two_jc)
{
  return ((two_jb < abs(two_ja - two_jc)) || (two_jb > two_ja +
two_jc)) || GSL_IS_ODD(two_jb + two_ja + two_jc);
}

This should also solve the problem of 6j and 9j.

Btw, the the algorithm of evaluation of 3j, 6j, 9j in GSL is the worst
possible. It just follows the Racah formula and does not use any
symmetry properties. See [Tuzun et all, Comp Phys Comm, 1998] for 3j,
6j algorithms.

Patrick Alken <psa>
Group administrator
Thu 11 Jul 2013 05:51:28 PM UTC, comment #1: 

In bzr trunk, the function triangle_selection_fails in specfunc/coupling.c
has grown a number of redundant tests since v1.15.  It is enough to check
the triangle condition for one spin vs the other two.  (See attached test
program.)  Perhaps put a comment to keep the function lean?

Cheers,
Håkan Johansson

(file #28545)

Patrick Alken <psa>
Group administrator
Thu 11 Jul 2013 05:49:47 PM UTC, original submission:  

The coupling of three spins requires the total sum to be integer.  This is
not checked on gsl_sf_coupling_6j_e or gsl_sf_coupling_9j_e.

We discovered it when trying to evaluate the 9j symbol:

(1/2 1/2 1/2)
(1/2 1/2 1/2)
( 0   0   0 )

and got a non-zero result.  We believe that the recursive calculations of
6j should have given the zero, but found also that lacking similar checks.

The attached patch also include some test cases.  The 6js have been
cross-checked with Mathematica.

Best regards,
Håkan Johansson

Patrick Alken <psa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #28545:  triangle.c added by psa (1KiB - text/x-c)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psa (Submitted the item)
  •  

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-12 psa StatusNone Fixed
        Open/ClosedOpen Closed
    2013-07-12 psa Attached File- Added coupling_6_9_halfint_check_2.diff, #28555
    2013-07-11 psa Attached File- Added triangle.c, #28545
    2013-07-11 psa Attached File- Added coupling_6_9_halfint_check.diff, #28544

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code