[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #51283] function min/max inconsistent handling
From: |
Oliver Heimlich |
Subject: |
[Octave-bug-tracker] [bug #51283] function min/max inconsistent handling of -0 |
Date: |
Wed, 21 Jun 2017 16:54:47 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 |
Follow-up Comment #4, bug #51283 (project octave):
The floating point values -0 and 0 must be considered equal and the max
function may return either of them, see the maxNum function in IEEE Std
754-2008.
Also, the standard for floating point arithmetic says in chapter 11
(reproducible floating-point results) that users should write programs in such
a way that they do not depend “on the sign of a zero result … for …
maxNum (x, y) … when x and y are equal”.
Strictly speaking, Octave behaves well. However, I'd find it reasonable if
Octave could return bit-equal results for the expressions max (x, y) and max
([x, y]). And it should be irrelevant whether x and y are scalars or vectors
for choosing the first or second argument in cases where both are
(semantically) equal.
Regarding the interval package: That should be fixed in the sine function.
There already is a “l(l == 0) = -0;” for fixing the lower boundary. The
upper boundary can equally be fixed with “u(u == 0) = +0;”. I have added
these expressions in all cases where they could be needed, but obviously
forgot it in sine.
For intervals, the lower boundary may not be stored as +0 internally. And the
upper boundary may not be stored as -0 internally. This is enforced by the
constructor. Many arithmetic operations use a shortcut and don't call the
constructor, thus have to ensure this condition in the function file.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?51283>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/