F_NAN/D_NAN have wrong sign on Arm, PPC.
Status: Beta
Brought to you by:
m_schellens
TEST_FINITE fails on Arm and PPC architectures. The problem appears to be the way F_NAN/D_NAN is set, as "-sqrt((float) -1.0)". On arm this:
float f_nan=-sqrt((float) -1.0);
printf("signbit(nan)=%d\n",signbit(f_nan));
printf("signbit(-nan)=%d\n",signbit(-f_nan));
yields:
signbit(nan)=-2147483648
signbit(-nan)=0
Why not simply use the NAN macro as in attached patch?
Interestingly, 0.0/0.0 appears to be -nan on x86_64, but nan on arm.
Hi Orion, thanks for the tip and the patch.
However I do not see the validity of the TEST_FINITE procedure in this particular case. The use of FINITE() in GDL is obviously not primarily to test the validity of gdl's F_NaN but the infinity or NaNess of user data (which can be -1*sqrt(-1) ). Would'nt that rather mean that lib::finite_fun() is not correct in this sense on Big-Endian machines? Or that test_finite.pro is a bit off-topic?
what gives:
on a BigEndian machine?
Besides, the NAN macro is a GNU extension --- we would need to use it within complicated #ifdefs ...
On Arm I get:
GDL> a=-1*sqrt(-1)
GDL> print,a
-nan
GDL> print,finite(a,/nan,sign=1)
0
GDL> print,finite(a,/nan,sign=-1)
1
GDL> a=sqrt(-1)
GDL> print,finite(a,/nan,sign=1)
1
GDL> print,finite(a,/nan,sign=-1)
0
GDL> print,a
nan
I think the fundamental issue is that the sign of these operations is architecture dependent.
Hi,
Indeed the sign of something producing a NaN is platform-dependent. IDL has the same behaviour on sqrt(-1) than GDL. So as you said the real difference is that !values.f_nan should be set to the correct value as to give back a +NaN.
I've patched initsysvar to use NAN when ths macro is defined, and sqrt(-1) elsewhere.
~~~~~~~~~~~~~~~~~~~~~
GDL> a=!values.f_nan
GDL> print,a
nan
GDL> toto=finite(a,/nan,sign=-1) & print,toto
0
GDL> toto=finite(a,/nan,sign=1) & print,toto
1
GDL> a=sqrt(-1)
GDL> print,a
-nan
~~~~~~~~~~~~~~~~~~~~~~
Patch in CVS,
Thanks
Closing as fixed.