Re: GSL_Wigner_6J error

Re: GSL_Wigner_6J error

[Peter Roche]

Cheers, that solved the problem.

Peter

*********************************************************

Peter Roche
Department of Applied Mathematics and Theoretical Physics,
University of Cambridge, Silver Street, Cambridge, CB3 9EW

email: p.j.p.roche@damtp.cam.ac.uk

*********************************************************

On Thu, 14 Nov 2002, iwamae atsushi wrote:

> Dear Peter
>
> One of my friend have found the same problem on the 6j symbol in GSL.
> In order to get the correct value, the order of J value should be written
> as
> follows,
>
> gsl_sf_coupling_6j(Ja, Jb, Jc, Jd, Je, Jf)
>
> { Ja, Jb, Je }
>   Jd, Jc, Jf
>
> The manual discription is not consistent.
> It says
> {Ja, Jb, Jc}
>  Jd, Je, Jf
> , but this order gives wrong value as you noticed
>
>
>
>
> Atsushi Iwamae
>
>
> >From: Peter Roche <P.J.P.Roche@damtp.cam.ac.uk>
> >To: gsl-discuss@sources.redhat.com
> >Subject: GSL_Wigner_6J error
> >Date: Wed, 13 Nov 2002 19:36:40 +0000 (GMT)
> >
> >
> >Dear All,
> >
> >I hope this isn't a repeat of an already dealt with problem. I have been
> >trying to use the GSL Wigner 6j coefficients routines
> >(gsl_sf_coupling_6j(2*ja, 2*jb, 2*jc, 2*jd,2*je,2*jf))  and have found,
> >I think, that some of the returned values from the GSL
> >routine are not correct, even for small input values.
> >
> >I have included a table showing, in the first column, the input
> >parameter values, the angular mometa (which are multiplied by 2 in my
> >actual program), the second column shows the 'correct' values, obtained
> >from another program/published tables, and the third column shows the
> >return values from the GSL routine.
> >
> >   Input       Correct values          GSL return
> >  (011100)     0.5773502691896257      0.0000000000000000
> >  (101101)     0.3333333333333335      0.0000000000000000
> >  (121101)     0.3333333333333334      0.0000000000000000
> >  (101101)     0.3333333333333335      0.0000000000000000
> >  (022200)     0.4472135954999579      0.0000000000000000
> >  (132201)     0.2581988897471612      0.0000000000000000
> >  (242202)     0.2000000000000000      0.0000000000000000
> >  (213302)     0.1690308509457034      0.0000000000000000
> >  (233302)     0.1690308509457033      0.0000000000000000
> >  (253302)     0.1690308509457033      0.0000000000000000
> >
> >
> >Has anyone encountered the same problems, or can explain the differences.
> >
> >Cheers,
> >Peter Roche
> >
> >*********************************************************
> >
> >Peter Roche
> >Department of Applied Mathematics and Theoretical Physics,
> >University of Cambridge, Silver Street, Cambridge, CB3 9EW
> >
> >email: p.j.p.roche@damtp.cam.ac.uk
> >
> >*********************************************************
>
>
> _________________________________________________________________
> ^[$B%&%$%k%9%a!<%k!"LBOG%a!<%kBP:v$J$i^[(B MSN Hotmail http://www.hotmail.com/
>
>

Re: GSL_Wigner_6J error

[Gerard Jungman]

Hi all. Sorry for the confusion here. I implemented this code,
but I never looked closely at it. Is there a consensus about
how it should work? It is definitely true that, as implemented,
the function returns

/ Ja Jb Je \
\ Jd Jc Jf /

I'm not sure where this convention comes from, if anywhere.

Should I change the interface or just change the documentation?

Thanks.

--
G. Jungman


On Mon, 2002-11-18 at 11:07, Peter Roche wrote:
> Cheers, that solved the problem.
> 
> Peter
> 
> *********************************************************
> 
> Peter Roche
> Department of Applied Mathematics and Theoretical Physics,
> University of Cambridge, Silver Street, Cambridge, CB3 9EW
> 
> email: p.j.p.roche@damtp.cam.ac.uk
> 
> *********************************************************
> 
> On Thu, 14 Nov 2002, iwamae atsushi wrote:
> 
> > Dear Peter
> >
> > One of my friend have found the same problem on the 6j symbol in GSL.
> > In order to get the correct value, the order of J value should be written
> > as
> > follows,
> >
> > gsl_sf_coupling_6j(Ja, Jb, Jc, Jd, Je, Jf)
> >
> > { Ja, Jb, Je }
> >   Jd, Jc, Jf
> >
> > The manual discription is not consistent.
> > It says
> > {Ja, Jb, Jc}
> >  Jd, Je, Jf
> > , but this order gives wrong value as you noticed
> >
> >
> >
> >
> > Atsushi Iwamae
> >
> >
> > >From: Peter Roche <P.J.P.Roche@damtp.cam.ac.uk>
> > >To: gsl-discuss@sources.redhat.com
> > >Subject: GSL_Wigner_6J error
> > >Date: Wed, 13 Nov 2002 19:36:40 +0000 (GMT)
> > >
> > >
> > >Dear All,
> > >
> > >I hope this isn't a repeat of an already dealt with problem. I have been
> > >trying to use the GSL Wigner 6j coefficients routines
> > >(gsl_sf_coupling_6j(2*ja, 2*jb, 2*jc, 2*jd,2*je,2*jf))  and have found,
> > >I think, that some of the returned values from the GSL
> > >routine are not correct, even for small input values.
> > >
> > >I have included a table showing, in the first column, the input
> > >parameter values, the angular mometa (which are multiplied by 2 in my
> > >actual program), the second column shows the 'correct' values, obtained
> > >from another program/published tables, and the third column shows the
> > >return values from the GSL routine.
> > >
> > >   Input       Correct values          GSL return
> > >  (011100)     0.5773502691896257      0.0000000000000000
> > >  (101101)     0.3333333333333335      0.0000000000000000
> > >  (121101)     0.3333333333333334      0.0000000000000000
> > >  (101101)     0.3333333333333335      0.0000000000000000
> > >  (022200)     0.4472135954999579      0.0000000000000000
> > >  (132201)     0.2581988897471612      0.0000000000000000
> > >  (242202)     0.2000000000000000      0.0000000000000000
> > >  (213302)     0.1690308509457034      0.0000000000000000
> > >  (233302)     0.1690308509457033      0.0000000000000000
> > >  (253302)     0.1690308509457033      0.0000000000000000
> > >
> > >
> > >Has anyone encountered the same problems, or can explain the differences.
> > >
> > >Cheers,
> > >Peter Roche
> > >
> > >*********************************************************
> > >
> > >Peter Roche
> > >Department of Applied Mathematics and Theoretical Physics,
> > >University of Cambridge, Silver Street, Cambridge, CB3 9EW
> > >
> > >email: p.j.p.roche@damtp.cam.ac.uk
> > >
> > >*********************************************************
> >
> >
> > _________________________________________________________________
> > ^[$B%&%$%k%9%a!<%k!"LBOG%a!<%kBP:v$J$i^[(B MSN Hotmail http://www.hotmail.com/
> >
> >
-- 
Gerard Jungman <jungman@lanl.gov>
Los Alamos National Laboratory

Re: GSL_Wigner_6J error

[Peter Roche]

I think the convention is like that which relates the Racah W
coefficients and Wigner 6J symbols:

W(Ja Jb Jc Jd; Je Jf)  = pow(-1,(Ja+Jb+Jc+Jd)) / Ja Jb Je \
                                               \ Jd Jc Jf /

I think the simplest way to solve the problem is change the manual entry,
rather than the source code?

Regards,
Peter

*********************************************************

Peter Roche
Department of Applied Mathematics and Theoretical Physics,
University of Cambridge, Silver Street, Cambridge, CB3 9EW

email: p.j.p.roche@damtp.cam.ac.uk

*********************************************************

On 20 Nov 2002, Gerard Jungman wrote:

>
> Hi all. Sorry for the confusion here. I implemented this code,
> but I never looked closely at it. Is there a consensus about
> how it should work? It is definitely true that, as implemented,
> the function returns
>
> / Ja Jb Je \
> \ Jd Jc Jf /
>
> I'm not sure where this convention comes from, if anywhere.
>
> Should I change the interface or just change the documentation?
>
> Thanks.
>
> --
> G. Jungman
>
>
> On Mon, 2002-11-18 at 11:07, Peter Roche wrote:
> > Cheers, that solved the problem.
> >
> > Peter
> >
> > *********************************************************
> >
> > Peter Roche
> > Department of Applied Mathematics and Theoretical Physics,
> > University of Cambridge, Silver Street, Cambridge, CB3 9EW
> >
> > email: p.j.p.roche@damtp.cam.ac.uk
> >
> > *********************************************************
> >
> > On Thu, 14 Nov 2002, iwamae atsushi wrote:
> >
> > > Dear Peter
> > >
> > > One of my friend have found the same problem on the 6j symbol in GSL.
> > > In order to get the correct value, the order of J value should be written
> > > as
> > > follows,
> > >
> > > gsl_sf_coupling_6j(Ja, Jb, Jc, Jd, Je, Jf)
> > >
> > > { Ja, Jb, Je }
> > >   Jd, Jc, Jf
> > >
> > > The manual discription is not consistent.
> > > It says
> > > {Ja, Jb, Jc}
> > >  Jd, Je, Jf
> > > , but this order gives wrong value as you noticed
> > >
> > >
> > >
> > >
> > > Atsushi Iwamae
> > >
> > >
> > > >From: Peter Roche <P.J.P.Roche@damtp.cam.ac.uk>
> > > >To: gsl-discuss@sources.redhat.com
> > > >Subject: GSL_Wigner_6J error
> > > >Date: Wed, 13 Nov 2002 19:36:40 +0000 (GMT)
> > > >
> > > >
> > > >Dear All,
> > > >
> > > >I hope this isn't a repeat of an already dealt with problem. I have been
> > > >trying to use the GSL Wigner 6j coefficients routines
> > > >(gsl_sf_coupling_6j(2*ja, 2*jb, 2*jc, 2*jd,2*je,2*jf))  and have found,
> > > >I think, that some of the returned values from the GSL
> > > >routine are not correct, even for small input values.
> > > >
> > > >I have included a table showing, in the first column, the input
> > > >parameter values, the angular mometa (which are multiplied by 2 in my
> > > >actual program), the second column shows the 'correct' values, obtained
> > > >from another program/published tables, and the third column shows the
> > > >return values from the GSL routine.
> > > >
> > > >   Input       Correct values          GSL return
> > > >  (011100)     0.5773502691896257      0.0000000000000000
> > > >  (101101)     0.3333333333333335      0.0000000000000000
> > > >  (121101)     0.3333333333333334      0.0000000000000000
> > > >  (101101)     0.3333333333333335      0.0000000000000000
> > > >  (022200)     0.4472135954999579      0.0000000000000000
> > > >  (132201)     0.2581988897471612      0.0000000000000000
> > > >  (242202)     0.2000000000000000      0.0000000000000000
> > > >  (213302)     0.1690308509457034      0.0000000000000000
> > > >  (233302)     0.1690308509457033      0.0000000000000000
> > > >  (253302)     0.1690308509457033      0.0000000000000000
> > > >
> > > >
> > > >Has anyone encountered the same problems, or can explain the differences.
> > > >
> > > >Cheers,
> > > >Peter Roche
> > > >
> > > >*********************************************************
> > > >
> > > >Peter Roche
> > > >Department of Applied Mathematics and Theoretical Physics,
> > > >University of Cambridge, Silver Street, Cambridge, CB3 9EW
> > > >
> > > >email: p.j.p.roche@damtp.cam.ac.uk
> > > >
> > > >*********************************************************
> > >
> > >
> > > _________________________________________________________________
> > > ^[$B%&%$%k%9%a!<%k!"LBOG%a!<%kBP:v$J$i^[(B MSN Hotmail http://www.hotmail.com/
> > >
> > >
> --
> Gerard Jungman <jungman@lanl.gov>
> Los Alamos National Laboratory
>
>

Re: GSL_Wigner_6J error

[Brian Gough]

Gerard Jungman writes:
 > 
 > Hi all. Sorry for the confusion here. I implemented this code,
 > but I never looked closely at it. Is there a consensus about
 > how it should work? It is definitely true that, as implemented,
 > the function returns
 > 
 > / Ja Jb Je \
 > \ Jd Jc Jf /
 > 
 > I'm not sure where this convention comes from, if anywhere.
 > 
 > Should I change the interface or just change the documentation?

We should use the most definitive version of 6j and 9j.  Here
is my suggestion:

http://wwwinfo.cern.ch/asdoc/psdir/shortwrups.dir/u111.ps.gz

Re: GSL_Wigner_6J error

[Gerard Jungman]

On Thu, 2002-11-21 at 04:57, Brian Gough wrote:
> We should use the most definitive version of 6j and 9j.  Here
> is my suggestion:
> 
> http://wwwinfo.cern.ch/asdoc/psdir/shortwrups.dir/u111.ps.gz

Peter Roche wrote:
> I think the simplest way to solve the problem is change the
> manual entry, rather than the source code?
>
> Regards,
> Peter


Well, after all two votes were counted, it's a tie.

I have to favor Brian here. The error in the interface
is just a dumb mistake on my part. The current function
actually calculates the Wigner function in the permuted
form directly related to Racah coefficients.

So I will have to fix it. I will also add a function
for Racah-W. The current functions will survive as
gsl_sf_coupling_6j_INCORRECT_e() and
gsl_sf_coupling_6j_INCORRECT(),
so anybody using them doesn't have to think
hard about changing their code. But these will
be deprecated and undocumented.

Does that seem reasonable to everybody?.


-- 
Gerard Jungman <jungman@lanl.gov>
Los Alamos National Laboratory

Re: GSL_Wigner_6J error

[Brian Gough]

Gerard Jungman writes:
 > So I will have to fix it. I will also add a function for
 > Racah-W. The current functions will survive as
 > gsl_sf_coupling_6j_INCORRECT_e() and
 > gsl_sf_coupling_6j_INCORRECT(), so anybody using them doesn't have
 > to think hard about changing their code. But these will be
 > deprecated and undocumented.
 >  Does that seem reasonable to everybody?.

Sounds fine.  

If you want to be safe with the deprecation here is a useful trick
from the Guile developers:

1) Define new versions of the functions, e.g. gsl_sf_wigner_3j,
gsl_sf_wigner_6j, gsl_sf_wigner_9j (by making a copy of the source
file and doing a search/replace, then making any fixes. Leave the
original file untouched). Document that people should start using
the new functions in the NEWS file.

2) Wrap the old gsl_sf_coupling_ versions with

#if (GSL_DEBUG_DEPRECATED == 0)
...
#endif

This allows people to test whether they are using any deprecated
functions by compiling with -DGSL_DEBUG_DEPRECATED=1 (which removes
the definitions).

3) Remove the actual gsl_sf_coupling_ definitions one release later
(remove its source file).

Brian

Re: GSL_Wigner_6J error

[Gerard Jungman]

On Tue, 2002-11-26 at 15:14, Brian Gough wrote:

> 2) Wrap the old gsl_sf_coupling_ versions with
> 
> #if (GSL_DEBUG_DEPRECATED == 0)
> ...
> #endif
> 
> This allows people to test whether they are using any deprecated
> functions by compiling with -DGSL_DEBUG_DEPRECATED=1 (which removes
> the definitions).

Sorry. What is the intention here? I find this construct
confusing, as if it were a double negative. If DEBUG_DEPRECATED
is 0 (or undefined... I had to look that up in the cpp manual),
then the user does not want deprecated functions? Or is
it the other way around?

Why isn't the macro name something obvious like
HIDE_DEPRECATED or EXPOSE_DEPRECATED (depending on
the default)?

-- 
Gerard Jungman <jungman@lanl.gov>
Los Alamos National Laboratory

Re: GSL_Wigner_6J error

[Brian Gough]

Gerard Jungman writes:
 > Sorry. What is the intention here? I find this construct
 > confusing, as if it were a double negative. If DEBUG_DEPRECATED
 > is 0 (or undefined... I had to look that up in the cpp manual),
 > then the user does not want deprecated functions? Or is
 > it the other way around?
 > 
 > Why isn't the macro name something obvious like
 > HIDE_DEPRECATED or EXPOSE_DEPRECATED (depending on
 > the default)?

That's the way it is in Guile, not sure why.  With DEBUG_DEPRECATED=1
the functions are removed, for anything else they are defined.

The general idea of a preprocessor variable to #ifdef out deprecated
functions is a useful one anyway.

Re: GSL_Wigner_6J error

[iwamae atsushi]

Hi all 
In order to avoid the confusion of the order of 6js, the description
in appendix C of "Me'canique Quantique" by Albert Messiah is helpful. 

Each side of a tetragon in 3D, with four surfaces, is correspond to the j 
values and the face two sides in a column of 6j-symbol. (not reactangle in 
2D, sorry for miss using the last mail)

see Fig C.2 in Messiah 
(It is not easy to draw the tetrapack using asci code)

{ ja, jb, je } 
  jd, jc, jf 

     __jb__ 
   /       \ 
ja/         \jd
 /___________\ 
       jc 
 
ja + jb = je 
jb + jd = jf 

Atsushi Iwamae 
Department of Engineering Physics and Mechanics 
Kyoto University, 606-8501, Kyoto, Japan 





_________________________________________________________________
ネットを使うひとに有利な特典いっぱい MSN カード  http://card.msn.co.jp/ 

Re: GSL_Wigner_6J error

[iwamae atsushi]

Hi all
In order to avoid the confusion of the order of 6js, the description in 
appendix C
of "Me'canique Quantique" by Albert Messiah is helpful, I think.

Each side of a quadrangle is correspond to the j values and the face two 
sides in a column of 6j-symbol.

see Fig C.2 in Messiah

{ ja, jb, je }
  jd, jc, jf

      __jb__
    /       \
 ja/         \jd 
  /___________\
        jc

diagonal lines
  ja + jb = je
  jb + jd = jf

Atsushi Iwamae
Department of Engineering Physics and Mechanics
Kyoto University, 606-8501, Kyoto, Japan






















_________________________________________________________________
最新のファイナンス情報とライフプランのアドバイス MSN マネー 
http://money.msn.co.jp/ 

GSL_Wigner_6J error

[Peter Roche]

Dear All,

I hope this isn't a repeat of an already dealt with problem. I have been
trying to use the GSL Wigner 6j coefficients routines
(gsl_sf_coupling_6j(2*ja, 2*jb, 2*jc, 2*jd,2*je,2*jf))  and have found,
I think, that some of the returned values from the GSL
routine are not correct, even for small input values.

I have included a table showing, in the first column, the input
parameter values, the angular mometa (which are multiplied by 2 in my
actual program), the second column shows the 'correct' values, obtained
from another program/published tables, and the third column shows the
return values from the GSL routine.

  Input       Correct values          GSL return
 (011100)     0.5773502691896257      0.0000000000000000
 (101101)     0.3333333333333335      0.0000000000000000
 (121101)     0.3333333333333334      0.0000000000000000
 (101101)     0.3333333333333335      0.0000000000000000
 (022200)     0.4472135954999579      0.0000000000000000
 (132201)     0.2581988897471612      0.0000000000000000
 (242202)     0.2000000000000000      0.0000000000000000
 (213302)     0.1690308509457034      0.0000000000000000
 (233302)     0.1690308509457033      0.0000000000000000
 (253302)     0.1690308509457033      0.0000000000000000


Has anyone encountered the same problems, or can explain the differences.

Cheers,
Peter Roche

*********************************************************

Peter Roche
Department of Applied Mathematics and Theoretical Physics,
University of Cambridge, Silver Street, Cambridge, CB3 9EW

email: p.j.p.roche@damtp.cam.ac.uk

*********************************************************