Re: Discussion paper: what are the level 2 datums?
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Discussion paper: what are the level 2 datums?
> Date: Tue, 5 Oct 2010 17:19:36 +0100
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>
> P1788
>
> I submit the attached paper for discussion,
> following which I aim to make it a motion.
>
> John Pryce
>
John,
Normally I would return my comments to you privately.
But since you wanted to start a discussion on this
topic I will do so publically this time.
While most of what you say about the meaning of 754
Table 3.1 is correct, I have difficulty with the term
'tagged'. The phrase "for a particular format" is not
so much to tag a floating-point value as to define
which finite subset of the Reals lives at level 2 &,
therefore, which set of representations need to live
at level 3 to accomodate them. That is, there is a
different Table 3.1 for each floating-point datatype.
As far as 754 is concerned, the Binary32 value 2.0 is
the same as the Binary64 value 2.0 as well as the
Decimal128 value 2.0 (although this last is further
'tagged', if you will, with a particular element chosen
from the cohort of values that are all equal to 2).
The issue of whether two values chosen from two different
datatypes may be compared or not is a language issue.
For languages that are weakly typed (C & Fortran like
languages) to ask the question "Is this Binary32 value
of 2.0 equal to this Binary64 value of 2.0?" is really
to ask the question "If I promote this Binary32 value
of 2.0 to Binary64 is it equal to this Binary64 value
of 2.0?" And the answer is yes, they are equal. In
strong typed languages the former question cannot be
formulated & the latter question must be asked
explicitly.
The question of "Is this Binary32 value of 2.0 equal to
this Decimal32 value of 2.0?" is a harder one. Most
languages do not have a notion of strong or weak typing
between radices. Therefore, you must explicitly choose
a radix within which to perform the comparison & convert
one value or the other to that radix. As that conversion
often involves a rounding error, it cannot be said to be
carried out in some common level 2 set as there is no
such common set (for all practical purposes).
(We toyed with the idea of providing inter-radix comparisons
just for this purpose but ultimately rejected the idea as
both too hard to do & too silly. :-)
Still, issues of radix aside, a level 2 value is a level
2 value. That is, it is an element of the Reals. If two
such values exist in two different level 2 sets, they are
still considered equal without any consideration of the
type they came from.
This is why I have difficulty with the notion that 754
is 'tagging' its level 2 values. It is not.
Similarly, I think it should be true that the interval
[0,2] or [-0,2] or [+0,2] all be considered equal no
matter which level 2 set they are chosen from.
So I guess I have a problem with tagging them in 1788
as well.
Now it might be true that in some narrow dataset (say
implemented with 4 digit arithmetic) that
[0,1.999] + [0,0.0003] = [0,2] whereas some wider
dataset would have room for the answer [0,1.9993]. In
that sense I am OK with 'tagging' the OPERATION as being
done within a particular dataset. But if I am in a
language within which I am able to compare [0,2.000]
with [0,2.0000] I want them to compare equal.
Am I explaining this adequately? I'm not sure sometimes.
All that having been said, I like your notion of defining
NaIs to be intervals that have been decorated as illFormed.
If these objects then live at our level 3 the analogy to
754 & NaNs is a good one. Right down to using isNaI() to
test for them.
I am OK with the notion that bare(NaI) should return Empty.
However, I have been feeling lately that we should confine
ourselves to decorated intervals only in the standard,
introducing the notion of 'bare' intervals only as an
informative note to express how some compiler optimizations
can dispense with computing decorations if it is known that
they are not needed.
But this is likely a minority opinion so I'm OK with
defining a bare() function even though I feel it is a
problem for assured computing.
As for why 754 chose max(x,NaN) = x, that was controversial.
We originally had a maxNaN(x,NaN) = NaN & another
maxNum(x,NaN) = x. We ended up choosing the latter &
calling it max() largely on the grounds that max (actually
maxabs() ) is used to choose pivot elements in linear
programming. As future rows & columns would be scaled by
the inverse of the chosen value, we felt it better to
choose the number & minimize the impact of the NaN rather
than fill the entire matrix with NaNs.
This was controversial because it became an exception to
the propagate NaNs rule.
We later realized that this is only one example of a
selection function which already need not propagate NaNs.
So, for example, the C expression (condition)?x:NaN can
choose either x or the NaN depending on the value of (cond).
It is conceptually no different than the programmer that
chooses to test for a NaN (knowing that it is the result of
a bogus calculation) & eliminate it for good reason. The
most cited example was (x<=1)?sqrt(1-x^2):1/sqrt(x^2-1)
which derives from special relativity.
So, in our context, I would be OK with (cond)?[0,2]:NaI
propagating the NaI or not depending on the value of (cond).
I think you have another good generalization of NaN to NaI
when you conclude that NaI should compare false for all
non-negated comparisons. Just as I believe it is OK for
Empty to compare true for them. Well, some of them anyway.
Similarly, it sounds like having any decoration extraction
function return its most pessimistic value when applied to
an NaI is also a good idea.
I feel the same about bare decorations as I do about bare
intervals. In general, I think we should avoid them.
So, in summary, I like most of what you say here but for
the notion of 'tagging' a mathematical interval. A level
3 interval must be of some known datatype in order to be
properly interpreted. But mathematical intervals at level
2 have no such property.
Yours,
Dan