Re: Discussion paper: what are the level 2 datums?
> Date: Wed, 06 Oct 2010 04:49:29 -0500
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> To: Michel Hack <hack@xxxxxxxxxxxxxx>
> CC: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Discussion paper: what are the level 2 datums?
>
> Michel,
>
> On 10/5/2010 20:15, Michel Hack wrote:
> > Dan Zuras already expressed some of my concerns rather well,
> > so I can be brief here.
> .
> .
> .
> > but one of the nice properties of Interval Arithmetic is
> > that mixed-format and even mixed-radix expressions can
> > generally be defined nicely, exploiting the hull concept,
> > so there is no need to restrict them. (Users would however
> > have to be aware of possible performance implications.)
> >
>
> Is there a possible problem with the "hull concept" in this
> context, if we want to maintain cross-platform reproducibility?
> (This is a bona fide question, not a rhetorical one.)
>
> Baker
>
Baker,
The simple answer is no, there is no problem with a
hull.
Fast & accurate decimal <--> binary conversions (even
with directed roundings) have existed since the mid 80s.
And they are better still today with large FMA hardware
to assist them.
So even tightest possible hulls across radices will be
no problem.
I presume Michel will concur.
The problem with mixed radix comparisons was that if
you did it by converting one number into the radix of
the other, there was a rounding error involved. So the
outcome of such a comparison depended on which way you
went.
And, for similarly sized formats like Binary32 versus
Decimal32, there was no obviously 'correct' direction
as some numbers are more accurately represented (i.e.
more dense) in one radix & other numbers are more dense
in the other.
As I recall Michel was deeply involved in this problem
at the time. He pointed out that because of this it
would be impossible for the user to construct a cross
radix comparison if we did not provide one for them.
I'll let Michel give you his own take on the matter but
let me give a quick illustration.
Comparing a binary floating-point number to a decimal
decimal floating-point number is equivalent to asking
the question:
a/2^b (<,=,>)? c/10^d
with all of a, b, c, & d integers. This is, in turn,
equivalent to asking:
a*10^d (<,=,>)? c*2^b
so it is solvable among the integers. (This is a bit
simplistic. Negative b & d might have to go the other
way. But you get the idea.)
And the size of the integers is not a strong function
of the precision but it is a VERY strong function of
the exponent range. Even for 32 bit floating-point
datatypes this could run into the hundreds of bits.
Or digits. With integers it mostly doesn't matter. :-)
And with the 128 bit datatypes we were standardizing
in 754-2008, it ran into the tens of thousands.
And much like the range reduction problem among the
transcendental functions, it cannot be replaced by
some reasonably narrow approximation that is good
enough because there really ARE binary numbers out
there that are so close to decimal numbers that it
takes tens of thousands of bits to find the difference.
(Michel, do I have that right? I'm not sure anymore.)
So, in the end, we gave up on standardizing cross
radix comparisons.
We had to settle for the implementation documenting
how they decided to implement them.
Its a compromise.
By now you must have come to realize that standards
making is not doing mathematics. There is not always
a proof that this way or that way is the best of all
possible ways. And even if there is, it is not always
something to be desired.
Sad but true...
Dan
P.S. - As I look back on this it turned out to be a
bit more than a quick example. Sorry about that.
Its almost 5 AM & I can't sleep with all this
standards discussion rattling around in my head. :-)