Floating Point and Wide Registers

[Robert Gamble]

When the "same" mathematical value is computed twice, the
results need not be the same, so long as each result is one
of the two nearest representable values to the "true" value.
Thus, not even 0.1==0.1 is guaranteed.

Where is this stated? 6.4.4.2p3 states in part:
"For decimal floating constants, and also for hexadecimal floating
constants when FLT_RADIX is not a power of 2, the result is either the
nearest representable value, or the larger or smaller representable
value immediately adjacent to the nearest representable value, chosen
in an implementation-defined manner."

There is similiar language for converting floating point numbers from
other types.

Since when is an implementation allowed to manifest
implementation-defined behavior in a non-consistent fashion?

Robert Gamble

 

[Chris Dollin]

Where is this stated? 6.4.4.2p3 states in part:
"For decimal floating constants, and also for hexadecimal floating
constants when FLT_RADIX is not a power of 2, the result is either the
nearest representable value, or the larger or smaller representable
value immediately adjacent to the nearest representable value, chosen
in an implementation-defined manner."

There is similiar language for converting floating point numbers from
other types.

Since when is an implementation allowed to manifest
implementation-defined behavior in a non-consistent fashion?

Could it not, for example, pick the lower value for left operands,
and the upper value for right operands?

That would be consistent. Stupid, perhaps, but consistent. Or
perhaps I mean "predictable".

 

[Wojtek Lerch]

Douglas A. Gwyn wrote: .... ....
Since when is an implementation allowed to manifest
implementation-defined behavior in a non-consistent fashion?

Where does the standard say that it must be consistent, or even describe
what "consistent" means in this context? The behaviour is unspecified --
the implementation is free to decide whether to round up or down, separately
for each case. I don't see a requirement that the decision must always be
the same, or that it must be the same for any two constants that have
identical spelling, or identical mathematical value. As long as the
implementation documents how it makes the decision, the requirement of
"implementation-defined" is satisfied.

 

[Richard Bos]

The number 1 can be exactly represented according to the model
described in 5.2.4.2.2 using any radix (b) since an exponent (e) of
zero must be allowed and b^e is 1 when e is zero. Since a floating
point number must be represented exactly if it can be exactly
represented it is guaranteed that 1 will always be represented exactly
in a floating point number. The same cannot be said for 2.

Yes, it can. 2 is exactly 0.100000e+2 if the base is 2 (or, if you want
the exponent expressed in the base as well, 0.100000e+10), and exactly
0.200000e+1 if the base is anything larger.

Richard

 

[Robert Gamble]

Could it not, for example, pick the lower value for left operands,
and the upper value for right operands?

That would be consistent. Stupid, perhaps, but consistent. Or
perhaps I mean "predictable".

No, the choices are "the larger representable value immediately
adjacent to the nearest representable value" and "the smaller
representable value immediately adjacent to the nearest representable
value"; "Larger for right operands" is not a valid choice. The
implementation needs to choice between which of these behaviors to use
and document it.

Robert Gamble

 

[Chris Dollin]

No, the choices are "the larger representable value immediately
adjacent to the nearest representable value" and "the smaller
representable value immediately adjacent to the nearest representable
value"; "Larger for right operands" is not a valid choice. The
implementation needs to choice between which of these behaviors to use
and document it.

I see your reading, but it isn't clear to me that the text quoted
above /excludes/ an instance-by-instance choice. But perchance the
way the Standard is written as a whole would make permitting
instance-by-instance readings generally unpaletable.

 

[Ancient_Hacker]

And just to muddy the waters a bit more, it will actually improve the
accuracy of calculations (in the long-term average) if 1/2 LSB bit of
random dither is thrown in.

 

[Robert Gamble]

Where does the standard say that it must be consistent, or even describe
what "consistent" means in this context? The behaviour is unspecified --
the implementation is free to decide whether to round up or down, separately
for each case. I don't see a requirement that the decision must always be
the same, or that it must be the same for any two constants that have
identical spelling, or identical mathematical value. As long as the
implementation documents how it makes the decision, the requirement of
"implementation-defined" is satisfied.

The Standard says that the implementation must "document how the choice
is made" which implies that there is a systematic way to determine how
the choice will be made in each instance. If the choice doesn't have
to be consistent there is no point in having implementation defined
behavior at all.

Robert Gamble

 

[Walter Roberson]

Where is this stated? 6.4.4.2p3 states in part:
"For decimal floating constants, and also for hexadecimal floating
constants when FLT_RADIX is not a power of 2, the result is either the
nearest representable value, or the larger or smaller representable
value immediately adjacent to the nearest representable value, chosen
in an implementation-defined manner."

Since when is an implementation allowed to manifest
implementation-defined behavior in a non-consistent fashion?

Your wording in this thread implies that it must choose one
of the two behaviours and stick with it. That isn't necessarily
the case: it could, for example, choose "round to even". This
method is consistant, easily documentable, and yet is neither
round to larger nor round to smaller.

http://citeseer.ist.psu.edu/context/1001006/0

 

[Robert Gamble]

Yes, it can. 2 is exactly 0.100000e+2 if the base is 2 (or, if you want
the exponent expressed in the base as well, 0.100000e+10), and exactly
0.200000e+1 if the base is anything larger.

How would you represent 2.0 with a radix of 3 in the floating point
model?

Robert Gamble

 

[Eric Sosman]

Robert Gamble wrote On 08/22/06 10:52,:

The Standard says that the implementation must "document how the choice
is made" which implies that there is a systematic way to determine how
the choice will be made in each instance. If the choice doesn't have
to be consistent there is no point in having implementation defined
behavior at all.

I don't think you can go from "document the choice" to
"document the choice in a systematic way." For one thing,
you've got to define what you mean by "systematic," which
probably means you've got to enumerate the conditions that
are and are not allowed to influence the choice.

DEATHSTATION 9000 OFFICIAL DOCUMENTATION
(quoted without permission)

When a floating-point result must be rounded, the
Rounding Mode Bit (RMB) is consulted. If the RMB
is clear, the floating-point result is rounded
toward zero. If the RMB is set, the result is
rounded toward infinity.

The RMB is set to zero when the system is shipped
from the factory, and thereafter inverts each time
the on-board detector observes the arrival of an
alpha particle.

All right, it's whimsical -- but doesn't it "document
how the choice is made?" There's a QoI issue, but I don't
think there's a conformance problem.

 

[Wojtek Lerch]

The Standard says that the implementation must "document how the choice
is made" which implies that there is a systematic way to determine how
the choice will be made in each instance. If the choice doesn't have
to be consistent there is no point in having implementation defined
behavior at all.

The point in having implementation-defined behaviour is to ensure that you
can determine, by reading an implementation's documentation, whether the
implementation satisfies your requirements.

 

[kuyper]

How would you represent 2.0 with a radix of 3 in the floating point
model?

As indicated above, 0.200000e+1. In terms of 5.2.4.2.2:

s = +1
b = 3
e = 1
f[1] = 2, all other f[k] = 0

The value give by the formula in 5.2.4.2.2p2 is then

x = +1*3*2*3^-1 == 2.0

For the model defined in 5.2.4.2.2, there do exist values of b, p,
emin, and emax such that 2.0 isn't exactly representable: if e-min is
high enough, 2.0 < DBL_MIN; if e-max were low enough, 2.0 >
DBL_EPSILON*DBL_MAX. but that would require DBL_MIN, and either
DBL_EPSILON or DBL_MAX, to have values inconsistent with
5.2.4.2.2p8-10.

Any implementation where 2.0 was either too large or too small to be
represented exactly would also be pretty unpopular, but that's a QoI
issue.

 

[Douglas A. Gwyn]

... Is the following guaranteed:
double d1 = 0.1;
double d2 = d1;
d1 == d2; /* always true? */

I don't think it's guaranteed, even if the declarations were
volatile-qualified (to prevent register caching). However,
it's hard to imagine code in that case that would fail the test.

 

[Douglas A. Gwyn]

Since when is an implementation allowed to manifest
implementation-defined behavior in a non-consistent fashion?

The implementation definition could be arbitrarily complicated,
specifying variations based on context (for example).

 

[Philip Potter]

How would you represent 2.0 with a radix of 3 in the floating point
model?

Others have already explained how this is possible. Perhaps you're thinking
of 0.5? That is indeed inexact in radix 3 floating-point.

Philip

 

[Francis Glassborow]

Where does the standard say that it must be consistent, or even describe
what "consistent" means in this context? The behaviour is unspecified --
the implementation is free to decide whether to round up or down, separately
for each case. I don't see a requirement that the decision must always be
the same, or that it must be the same for any two constants that have
identical spelling, or identical mathematical value. As long as the
implementation documents how it makes the decision, the requirement of
"implementation-defined" is satisfied.

And in some circumstances it might be preferred to either strictly
alternate up and down or do so randomly

 

[Francis Glassborow]

The Standard says that the implementation must "document how the choice
is made" which implies that there is a systematic way to determine how
the choice will be made in each instance. If the choice doesn't have
to be consistent there is no point in having implementation defined
behavior at all.

But suppose the implementation states that the rounding will be up and
down dependant on the lsb in a hardware random number generator? That
documents the choice but does not allow the programmer to know what it
is.

 

[lawrence.jones]

Thanks for the response. It's unfortunate that gcc doesn't follow the
Standard in this regard

As I recall, *most* of GCC tries to do it right, but the x86 back end
lies about what it can do and thus defeats the best efforts of the rest
of the compiler. I believe GCC on other platforms gets it right.

-Larry Jones

I'm not a vegetarian! I'm a dessertarian. -- Calvin

 

[Keith Thompson]

No, the choices are "the larger representable value immediately
adjacent to the nearest representable value" and "the smaller
representable value immediately adjacent to the nearest representable
value"; "Larger for right operands" is not a valid choice. The
implementation needs to choice between which of these behaviors to use
and document it.

The implementation needs to document how the choice is made.

Your reading would forbid different rounding methods for float and
double, which I don't think is the intent.