Open xgluo opened 1 year ago
For now, the workaround is to convert the parameters a, b, c
back into double via
arb_set_d(a, arf_get_d(arb_midref(a), ARF_RND_NEAR));
arb_set_d(b, arf_get_d(arb_midref(b), ARF_RND_NEAR));
arb_set_d(c, arf_get_d(arb_midref(c), ARF_RND_NEAR));
which temporarily solves the problem and prints
a = 2.555524321768503121670747246785282413839013315737247467041015625e-5
b = 2.0000255552432175676358383498154580593109130859375
c = 3.000049999375324460970659856684505939483642578125
z = [-22222713825.8777617408682136116353946930165426890196513822582 +/- 4.83e-50]
F = [0.9994041175506549726202688333505541814603498257699103208789 +/- 5.20e-59]
The original code is quite complicated for me (without software engineering background) to pinpoint where exactly the problem is. How could the additional digits in the parameters result in NaNs? I would highly appreciate it if this could be investigated further, as the high precision and the speed of the arb library (arb_hypgeom in particular) help my research a lot.
I tried to run the following script. With valid inputs, the function "arb_hypgeom_2f1" does not compute properly but output nan. Any ideas why this is the case?
Code:
The output of the code is