|
»
»
« Return to Thread: automatic Inf+NaN*i conversion
Re: automatic Inf+NaN*i conversion
by Jaroslav Hajek-2
::
Rate this Message:
On Fri, Apr 25, 2008 at 11:21 AM, Rolf Fabian <Rolf.Fabian@...> wrote:
>
> I consider the automatic conversion of input 'Inf+NaN*i'
> to 'NaN-NaN*i' as a bug because this may lead to strange
> illogical consequences.
>
> octave-3.0.0.exe:1> x = [Inf+NaN*i,NaN+Inf*i]
> x =
> NaN - NaNi NaN + Infi
>
> ( If you consider the 1st element result 'NaN-NaNi' as intended,
> can you please explain the meaning of the appearing minus sign? )
>The minus sign seems to be a bug. Actually, it appears that Octave can
deliberately use a NaN with sign bit set as the default NaN. The
problem can be tracked down to
liboctave/lo-ieee.cc, where the statement
octave_NaN = tmp_inf / tmp_inf;
can apparently return "negative" NaN - i.e. one with the signbit set.
Try this C program:
#include <math.h>
#include <stdio.h>
int main()
{
volatile double inf = HUGE_VAL;
volatile double nan = inf/inf;
printf ("%lf \n", inf);
printf ("%lf %d\n", nan, signbit (nan));
printf ("%lf %d\n", nan, signbit (-nan));
}
With my gcc, the output is:
inf
nan -2147483648
nan 0
the attached changeset seems to provide an acceptable quick-fix for
this (it works for me).
If this method does not work for some configurations (i.e. the sign
bit of NaN cannot be inverted, then we probably need to avoid using
lo_ieee_signbit in pr-output.cc).
The rest, as you have suspected, is intended behaviour, given by the
fact that `Inf' and `NaN' are functions.You can construct exceptional
complex numbers reliably using `complex'.
> octave-3.0.0.exe:2> isnan(x)
> ans =
> 1 1 # agree
>
> Checking x for finiteness :
> octave-3.0.0.exe:3> finite (x)
> ans =
> 0 0 # agree
>
> But the result of the following check contradicts
> above result because 1st element of x cannot be
> neither finite nor infinite !I believe that's exactly true for NaN - it is neither finite nor
infinite. What support do you have for the opposite claim?
> octave-3.0.0.exe:4> isinf (x)
> ans =
> 0 1 # disagree with respect to 1st element
>
> R:
>
>
>
> -----
> Rolf Fabian
> <r dot fabian at jacobs-university dot de>
>
> --
> View this message in context: http://www.nabble.com/automatic-Inf%2BNaN*i-conversion-tp16893696p16893696.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave@...
> https://www.cae.wisc.edu/mailman/listinfo/bug-octave
>regards,
--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
[nanbug.diff]
# HG changeset patch
# User Jaroslav Hajek <highegg@...>
# Date 1209122877 -7200
# Node ID c30d77db3568da03e7f0f0cb08575a447d15b86e
# Parent bb614b3883a9d4e1ff9439ee468f2569576c72f7
initialization check for correct NaN sign
diff --git a/liboctave/ChangeLog b/liboctave/ChangeLog
--- a/liboctave/ChangeLog
+++ b/liboctave/ChangeLog
@@ -1,3 +1,8 @@
+2008-04-25 Jaroslav Hajek <highegg@...>
+
+ * lo-ieee.cc (octave_ieee_init): Try to ensure that octave_NaN is
+ classified as positive by lo_ieee_signbit.
+
2008-04-24 Michael Goffioul <michael.goffioul@...>
* lo-sysdep.cc (octave_popen2): Don't set PIPE_NOWAIT for parentWrite.
diff --git a/liboctave/lo-ieee.cc b/liboctave/lo-ieee.cc
--- a/liboctave/lo-ieee.cc
+++ b/liboctave/lo-ieee.cc
@@ -94,6 +94,10 @@
octave_NaN = (*(X_CAST(double *, DQNAN)));
#else
octave_NaN = tmp_inf / tmp_inf;
+ // try to ensure that lo_ieee_sign gives false for a NaN.
+ if (lo_ieee_signbit (octave_NaN))
+ octave_NaN = -octave_NaN;
+
#endif
octave_Inf = tmp_inf;
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
>
> I consider the automatic conversion of input 'Inf+NaN*i'
> to 'NaN-NaN*i' as a bug because this may lead to strange
> illogical consequences.
>
> octave-3.0.0.exe:1> x = [Inf+NaN*i,NaN+Inf*i]
> x =
> NaN - NaNi NaN + Infi
>
> ( If you consider the 1st element result 'NaN-NaNi' as intended,
> can you please explain the meaning of the appearing minus sign? )
>
deliberately use a NaN with sign bit set as the default NaN. The
problem can be tracked down to
liboctave/lo-ieee.cc, where the statement
octave_NaN = tmp_inf / tmp_inf;
can apparently return "negative" NaN - i.e. one with the signbit set.
Try this C program:
#include <math.h>
#include <stdio.h>
int main()
{
volatile double inf = HUGE_VAL;
volatile double nan = inf/inf;
printf ("%lf \n", inf);
printf ("%lf %d\n", nan, signbit (nan));
printf ("%lf %d\n", nan, signbit (-nan));
}
With my gcc, the output is:
inf
nan -2147483648
nan 0
the attached changeset seems to provide an acceptable quick-fix for
this (it works for me).
If this method does not work for some configurations (i.e. the sign
bit of NaN cannot be inverted, then we probably need to avoid using
lo_ieee_signbit in pr-output.cc).
The rest, as you have suspected, is intended behaviour, given by the
fact that `Inf' and `NaN' are functions.You can construct exceptional
complex numbers reliably using `complex'.
> octave-3.0.0.exe:2> isnan(x)
> ans =
> 1 1 # agree
>
> Checking x for finiteness :
> octave-3.0.0.exe:3> finite (x)
> ans =
> 0 0 # agree
>
> But the result of the following check contradicts
> above result because 1st element of x cannot be
> neither finite nor infinite !
infinite. What support do you have for the opposite claim?
> octave-3.0.0.exe:4> isinf (x)
> ans =
> 0 1 # disagree with respect to 1st element
>
> R:
>
>
>
> -----
> Rolf Fabian
> <r dot fabian at jacobs-university dot de>
>
> --
> View this message in context: http://www.nabble.com/automatic-Inf%2BNaN*i-conversion-tp16893696p16893696.html
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave@...
> https://www.cae.wisc.edu/mailman/listinfo/bug-octave
>
--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
[nanbug.diff]
# HG changeset patch
# User Jaroslav Hajek <highegg@...>
# Date 1209122877 -7200
# Node ID c30d77db3568da03e7f0f0cb08575a447d15b86e
# Parent bb614b3883a9d4e1ff9439ee468f2569576c72f7
initialization check for correct NaN sign
diff --git a/liboctave/ChangeLog b/liboctave/ChangeLog
--- a/liboctave/ChangeLog
+++ b/liboctave/ChangeLog
@@ -1,3 +1,8 @@
+2008-04-25 Jaroslav Hajek <highegg@...>
+
+ * lo-ieee.cc (octave_ieee_init): Try to ensure that octave_NaN is
+ classified as positive by lo_ieee_signbit.
+
2008-04-24 Michael Goffioul <michael.goffioul@...>
* lo-sysdep.cc (octave_popen2): Don't set PIPE_NOWAIT for parentWrite.
diff --git a/liboctave/lo-ieee.cc b/liboctave/lo-ieee.cc
--- a/liboctave/lo-ieee.cc
+++ b/liboctave/lo-ieee.cc
@@ -94,6 +94,10 @@
octave_NaN = (*(X_CAST(double *, DQNAN)));
#else
octave_NaN = tmp_inf / tmp_inf;
+ // try to ensure that lo_ieee_sign gives false for a NaN.
+ if (lo_ieee_signbit (octave_NaN))
+ octave_NaN = -octave_NaN;
+
#endif
octave_Inf = tmp_inf;
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave
« Return to Thread: automatic Inf+NaN*i conversion
| Free embeddable forum powered by Nabble | Forum Help |
