[Bug-gsl] [bug #47646] gsl_ran_beta returns NaN for small arguments

[Patrick Alken]

Follow-up Comment #5, bug #47646 (project gsl):

[From Yu]

Patrick,
   I was thinking if it's worthwhile to allow the use of close-form cdf for
some functions. Currently, the test routine calculates the expected
probability in each bin using numerical integration of pdf. In this particular
case, it blows up. Using cdf in stead of integration can avoid the problem,
but I am not sure if this is appropriate. There are other functions with
close-form cdf as well, and I am wondering whether it can be used to replace
integration as well.
  In a modified test routine, I added a flag to indicate whether the input
function ``pdf" is actually a cdf, and if that is the case, the probability in
each bin would be simply cdf[x+dx] - cdf[x]. Please see the relevant lines
here
https://github.com/ohliumliu/gsl-playground/blob/issue2/scratchpad/test_beta_small.c#L461-#L464
One obvious issue is that in this function, the input ``pdf" could mean pdf or
cdf depending on the value of the flag. This may be confusing.
   Without much experience in numerical computation, maybe I am proposing
something crazy.

Best,
yu

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-gsl] [bug #47646] gsl_ran_beta returns NaN for small arguments

[Patrick Alken]

Update of bug #47646 (project gsl):

 Open/Closed:  Closed => Open   


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [Bug-gsl] Bug in akima.c - indexing of the arrays is out of order

[Patrick Alken]

Hello, I am trying to organize the recent bug reports, but I noticed
that your two emails about akima.c did not contain any text in the
email. Could you resend the bug report to me?

Thanks,
Patrick

On 08/24/2017 10:51 PM, Thomas Walter wrote:

[Bug-gsl] [bug #52322] gsl_multifit_linear's output differs on 32 bit vs 64 bit linux

[Patrick Alken]

URL:
  

 Summary: gsl_multifit_linear's output differs on 32 bit vs 64
bit linux
 Project: GNU Scientific Library
Submitted by: psa
Submitted on: Wed 01 Nov 2017 09:09:27 AM UTC
Category: Runtime error
Severity: 3 - Normal
Operating System: 
  Status: None
 Assigned to: None
 Open/Closed: Open
 Release: 
 Discussion Lock: Any

___

Details:

asulaiman4 =at= bloomberg =dot= net

Hello,

Please refer to {https://github.com/sulaimn2/gsltest/blob/master/gsltest.cpp}
for code.
Noticed weird output when I ran my library on 64 bit linux in dev, so I tried
to hunt down where the problem was.
In my library I am using gsl_multifit_linear from libgsl. I have to tried to
reproduce the problem with a simpler setup as follows.

Setup:
We have an X matrix with 26 coefficients and 151 observations. See x_matrix []
in gsltest.cpp
We also have a Y vector with 151 observations. See y_matrix [] in gsltest.cpp
We run gsl_multifit_linear on X and Y and produce a c vector as the output.
In 32 bit, the output was: 

c = [2.70409, 9.5864, -0.670502, 24.2728, 13.9393, 3.23134, 8.22729, 9.4926,
-0.213974, 6.85192, 0.215701, 7.49826, 7.22713, -3.39073, 13.5852, 17.3663,
-0.559321, -1.70083, 18.8802, 5.18303, 3.48551, 1.42608, 9.17107, 22.2,
-5.66091, 2.83766] //formatted for human readability.

In 64 bit, the output was:
c = [2.87233e+13, 2.87233e+13, 2.87233e+13, 2.87233e+13, 2.87233e+13,
2.87233e+13, 2.87233e+13, 2.87233e+13, 2.87233e+13, 2.87233e+13, 2.87233e+13,
2.87233e+13, 2.87233e+13, 2.87233e+13, -2.87233e+13, -2.87233e+13,
-2.87233e+13, -2.87233e+13, -2.87233e+13, -2.87233e+13, -2.87233e+13,
-2.87233e+13, -2.87233e+13, -2.87233e+13, -2.87233e+13, -2.87233e+13]

gsl_multifit_linear works when I had smaller test cases (with less
observations) so I tried to hunt down and see if there was a threshold. In
gsltest.cpp line 171, all outputs matched between 32 bit and 64 bit for all
number of observations until n=100. The moment n=101, the outputs started
being all garbage values for 64 bit linux. This number might just be a
coincidence but I am not sure.

Thanks and regards,
Ahmed



___

File Attachments:


---
Date: Wed 01 Nov 2017 09:09:27 AM UTC  Name: gsltest.cpp  Size: 15KiB   By:
psa


---
Date: Wed 01 Nov 2017 09:09:27 AM UTC  Name: README.md  Size: 2KiB   By: psa



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-gsl] [bug #52321] gsl_linalg_bidiag_unpack2 functioan has wrong householder transform call for V in GSL1.8

[Patrick Alken]

URL:
  

 Summary: gsl_linalg_bidiag_unpack2 functioan has wrong
householder transform call for V in GSL1.8
 Project: GNU Scientific Library
Submitted by: psa
Submitted on: Wed 01 Nov 2017 09:05:27 AM UTC
Category: Runtime error
Severity: 3 - Normal
Operating System: 
  Status: None
 Assigned to: None
 Open/Closed: Open
 Release: 
 Discussion Lock: Any

___

Details:

from actionafterthought =at= gmail =dot= com

Hey,

This bug might have been fixed. Since it is in GSL 1.8 source. And it is
noticed that the wrong householder transform
Function call is made for a row vector from V (see below code). And the
correct function call for highlighted line is
supposed to be:

gsl_linalg_householder_mh (ti, , );

int
gsl_linalg_bidiag_unpack2 (gsl_matrix * A, 
   gsl_vector * tau_U, 
   gsl_vector * tau_V,
   gsl_matrix * V)
{
…

  /* Initialize V to the identity */

  gsl_matrix_set_identity (V);

  for (i = N - 1; i > 0 && i--;)
{
  /* Householder row transformation to accumulate V */
  gsl_vector_const_view r = gsl_matrix_const_row (A, i);
  gsl_vector_const_view h = 
gsl_vector_const_subvector (, i + 1, N - (i+1));
  
  double ti = gsl_vector_get (tau_V, i);
  
  gsl_matrix_view m = 
gsl_matrix_submatrix (V, i + 1, i + 1, N-(i+1), N-(i+1));
  
  gsl_linalg_householder_hm (ti, , );
}




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/