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

2016-09-16 Thread Yu Liu 
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


On Thu, Sep 15, 2016 at 1:20 PM, Patrick Alken 
wrote:

> Follow-up Comment #4, bug #47646 (project gsl):
>
> I'm also not sure how to properly test for this case, as the PDF
> integration
> test fails for these small arguments.
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
>   Message sent via/by Savannah
>   http://savannah.gnu.org/
>
>

[Bug-gsl] [bug #47345] arccosh(1) wrong sign

2016-09-16 Thread Yu Liu 
Additional Item Attachment, bug #47345 (project gsl):

File name: gsl_complex_arccosh.diff   Size:1 KB


___

Reply to this item at:

  

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

[Bug-gsl] [bug #47347] Complex tangent failure for -1000i

2016-09-11 Thread Yu Liu 
Follow-up Comment #1, bug #47347 (project gsl):

Please see test_tan.c for trouble shooting process and gsl_complex_tan.diff
for a proposed fix.
1. This proposed fixed is based on 7141c7adb8100207ef01ff87a94d5179103fcebc
which add a branch in  gsl_complex_tanh to handle a similar issue. In this
commit, tanh was modified to have a separate branch to handle large real part
in input. This is what gsl_complex_tan.diff is doing in essense. In
test_tan.c, this idea is implemented in `gsl_complex_tan_2` for testing
purposes.
2. glibc implementation
(https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb263b4cf4caaea138c4ad/math/s_ctan.c)
converts everything to exponential when the imagineary part is big. Is this a
better implementation?



___

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

2016-07-15 Thread Yu Liu 
Follow-up Comment #2, bug #47646 (project gsl):

Following up based on numpy issues
(please let me know if this kind of information should be sent over the
mailing list.)

numpy fixed this problem around March 2015
https://github.com/numpy/numpy/pull/5858
It was related to a Dirichlett distribution bug that is still open.
https://github.com/numpy/numpy/issues/5851

As for the code, the while loop is there to handle the very RARE cases of `u`
and `v` being zero, because `rk_double` could give a zero. But with
`gsl_ran_uniform_pos` this loop is redundant. 

In terms of test, `numpy` code only check if there is `nan` generated. See
numpy #5858 above.

___

Reply to this item at:

  

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