Re: Motion P1788/M007.01_NaI: Discussion period begins
<<I am using ∞ as Vincent does but it may not display properly on
all systems. It is the infinity character.>>
P1788 members
On 6 Aug 2009, at 00:35, Vincent Lefevre wrote:
Some comments [on the rationale document]:
2.1 says: "According to motion 3, if both arguments are finite numbers
and l ≤ u, or l equals −∞, or u equals +∞ that constructor
returns the
F interval [l,u] otherwise NaI is returned."
You should also exclude the cases l = u = −∞ and l = u = +∞.
Yes. Is it then equivalent to say
"... if both arguments are numeric [i.e. not NaN] and l ≤ u, and we
do not have u = −∞ or l = +∞, that constructor returns the F
interval [l,u], otherwise NaI is returned."
which is a bit simpler? (This assumes we accept my view expressed in
motion 6 rationale 3.5.2, that interval(−∞,−∞) and interval
(+∞,+∞) are "meaningless" rather than empty. Some may disagree.)
"Since there are many possible encodings of NaN, NaI and the empty set
both can be represented as different pairs of NaNs, NaI as [-NaN,-
NaN],
the empty set as [+NaN,+NaN], e.g."
Testing the sign bit of a NaN may not be optimal. I'd rather say:
Empty set: [NaN,NaN]
NaI: [NaN,non-NaN]
and any other implemention-defined encoding (e.g. if NaN is not
supported by the underlying arithmetic).
We should indeed consider different possible representations to see
which works most efficiently for whatever NaI definition(s) we
decide, but isn't it a bit early to make a decision on that?
2.2 Arguments
Another argument against NaI: there are different and contradictory
NaI concepts. For instance, if NaI is used for missing data, then
min(some_interval,NaI) should return some_interval, not NaI.
"There is an obvious analogy to 754 NaN"
Very partially. NaN can also mean [−∞,+∞] (any real number),
as in
hypot(+∞,qNaN), or also the empty set (e.g. result of sqrt(-1)).
Hmm. In 754, values are always point values, never sets of values. So
sqrt(-1) = Empty is incorrect in the 754 context. (Remember that in
the interval context, it is only correct inasmuch as sqrt(-1) is
syntactic sugar for sqrt( {-1} ) .)
Also, when you say NaN can also mean [−∞,+∞] (any real number),
are you sure that's what "754 thinks"? Or is it (any _extended real
number_)? If it's the former, then the same reasoning that leads to
hypot(NaN,+∞) = +∞
also leads to
0 * ∞ = 0,
which is not what 754 says. 754's arithmetic is based on the extended
reals, whereas by motion 3, P1788's is based on the reals, so we must
be careful which parts of the analogy between NaI and NaN are valid.
On 6 Aug 2009, at 14:24, Arnold Neumaier wrote:
The fact that there are different uses for NaI suggest that NaI, if it
is made available, should exist with a payload, so that different
uses can be distinguished.
More and more I support this.
On 6 Aug 2009, at 14:57, Michel Hack wrote:
As Arnold just reminded us, NaI should carry a payload -- and we
should
even standardize names for some essential kinds (if not actual
values),
together with whatever special propagation properties they entail. If
actual values are specified they should be specified as small
integers.
One nice property of Vincent's suggestion
NaI: [NaN,non-NaN]
is that the payload could be carried in the non-NaN...
That seems an excellent idea, and I agree with the proposal to
standardize names for some essential kinds. When we get down to level
3 stuff I hope we can standardize the "small integer" values too.
IBM's payload rule is a neat trick, and maybe we should do something
like it, but we need to agree the principles before the details.
Juergen, are you totally opposed to NaI with payload? Or would you be
amenable to a "friendly amendment" to your motion?
More to follow when I catch up with the rest of the NaI discussion.
Dr John D Pryce
46 Ponting Street
Swindon
Wiltshire
SN1 2BW
+44 1793 327341