«

On 2012-07-21 14:39, Tim Rentsch wrote:
>
> Because of the vagaries of how floating point is represented,
> I believe it is possible in principle for 0.0 to be seen as
> true (that is, != 0) in a conforming implementation, if that
> implementation (a) does not have an exact FP representation for zero,
> and (b) has implementation-defined rounding rules which are defined
> suitably. AFAIK both (a) and (b) may be true in a conforming
> implementation, that is, I don't know of any requirement that
> prevents the possibility of either (or of both together).

Even if it's possible that there isn't an exact representation for zero
and that '0.0' has to be represented as a non-zero, won't '0.0 == 0'
still be true because the right-hand side has to be converted to the
same non-zero FP value first? Then, the value of (bool)0.0, assuming
it is defined as '0.0 != 0', should be false as well.
In that case, the non-zero value may behave effectively as a substitute
for zero, or an "acting" zero, except that it might not print out as
an exact zero (just as an acting president doesn't look like the real
president, though having the same power ).

--
Seungbeom Kim

Seungbeom Kim <> writes:

> On 2012-07-21 14:39, Tim Rentsch wrote:
>>
>> Because of the vagaries of how floating point is represented,
>> I believe it is possible in principle for 0.0 to be seen as
>> true (that is, != 0) in a conforming implementation, if that
>> implementation (a) does not have an exact FP representation for zero,
>> and (b) has implementation-defined rounding rules which are defined
>> suitably. AFAIK both (a) and (b) may be true in a conforming
>> implementation, that is, I don't know of any requirement that
>> prevents the possibility of either (or of both together).
>
> Even if it's possible that there isn't an exact representation for zero
> and that '0.0' has to be represented as a non-zero, won't '0.0 == 0'
> still be true because the right-hand side has to be converted to the
> same non-zero FP value first? Then, the value of (bool)0.0, assuming
> it is defined as '0.0 != 0', should be false as well.
> In that case, the non-zero value may behave effectively as a substitute
> for zero, or an "acting" zero, except that it might not print out as
> an exact zero (just as an acting president doesn't look like the real
> president, though having the same power ).

The test involved in a conditional expression is whether the value of
the first expression "compares equal to zero". It's not absolutely
clear to me that this is intended to mean "exp == 0" or not (i.e. to
reference the semantics of the -- operator), but I can't think of any
better meaning.

That aside, 0.0 == 0 is interesting. On a machine that has an exact
floating zero, 0 must convert to it, but 0.0 need not (surely this is
unintended?). On one that does not have an exact floating zero, very
similar wording is used in 6.3.1.4 p2 (for the conversion) as is used in
6.4.4.2 p3 (for the representation of the constant):

"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."

"the result is either the nearest higher or nearest lower
representable value, chosen in an implementation-defined manner"

but there's nothing to say that the implementation must choose in the
same way in both cases. A perverse implementation could "round" 0.0 up
and convert 0 by going the other way!

--
Ben.

Tim Rentsch <> writes:

> Ralf Damaschke <> writes:
>
> > Tim Rentsch <> wrote:
> >
> >> I believe it is possible in principle for 0.0 to be seen as
> >> true (that is, != 0) in a conforming implementation, if that
> >> implementation (a) does not have an exact FP representation for
> >> zero, and (b) has implementation-defined rounding rules which
> >> are defined suitably. AFAIK both (a) and (b) may be true in a
> >> conforming implementation, that is, I don't know of any
> >> requirement that prevents the possibility of either (or of both
> >> together).
> >
> > There is one. An implementation (a) would not suffice C99 5.2.4.2.2
> > "Characteristics of floating types <float.h>"; esp. the sum used to
> > define a floating-point number gives 0 if f(k) = 0 for all
> > 1 <= k <= p.
>
> If you read the footnote to 5.2.4.2.2 p1, and also 5.2.4.2.2 p3,
> I think you'll agree that the condition you describe need not
> be an actual representable value in a particular conforming
> implementation. The value does exist in the model, but the
> model may not reflect what the implementation actually uses,
> and even if it does, the implementation might not provide FP
> numbers with f(1) == 0. Needless to say, I did consult this
> section (and these paragraphs) before making my earlier
> comments. So I still think it's possible for an implementation
> to not have zero as a representable FP value.

I don't see how there can be any meaningful values for 5.2.4.2.2 p13
if zero is non-zero. Zero must be less than epsilon, as epsilon must
be greater than it. And zero must me expressible.

And zero must compare equal to negative zero. That can only be true
if zero is zero.

Anyway, logic aside, in this particular case does F.1 apply?
"""
An implementation that de#nes _ _STDC_IEC_559_ _ shall conform to the
speci#cations in this annex.
"""
Which, if it applies, makes them bang to rights.

Phil
--
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

Tim Rentsch <> wrote in news:kfnwr1w1jgh.fsf@x-
alumni2.alumni.caltech.edu:

> Ralf Damaschke <> writes:
>
>> Tim Rentsch <> wrote:
>>
>>> I believe it is possible in principle for 0.0 to be seen as
>>> true (that is, != 0) in a conforming implementation, if that
>>> implementation (a) does not have an exact FP representation for
>>> zero, and (b) has implementation-defined rounding rules which
>>> are defined suitably. AFAIK both (a) and (b) may be true in a
>>> conforming implementation, that is, I don't know of any
>>> requirement that prevents the possibility of either (or of both
>>> together).
>>
>> There is one. An implementation (a) would not suffice C99 5.2.4.2.2
>> "Characteristics of floating types <float.h>"; esp. the sum used to
>> define a floating-point number gives 0 if f(k) = 0 for all
>> 1 <= k <= p.
>
> If you read the footnote to 5.2.4.2.2 p1, and also 5.2.4.2.2 p3,
> I think you'll agree that the condition you describe need not
> be an actual representable value in a particular conforming
> implementation. The value does exist in the model, but the
> model may not reflect what the implementation actually uses,
> and even if it does, the implementation might not provide FP
> numbers with f(1) == 0. Needless to say, I did consult this
> section (and these paragraphs) before making my earlier
> comments. So I still think it's possible for an implementation
> to not have zero as a representable FP value.
>
>
What about 6.7.9 paragraph 10?

10 If an object that has automatic storage duration is not initialized
explicitly, its value is
indeterminate. If an object that has static or thread storage duration
is not initialized
explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned)
zero;
— if it is an aggregate, every member is initialized (recursively)
according to these rules,
and any padding is initialized to zero bits;
— if it is a union, the first named member is initialized (recursively)
according to these
rules, and any padding is initialized to zero bits;

How could a real type be initialized to positive or unsigned zero if
there isn't one?

Martin Shobe

Tim Rentsch <> wrote:

> Ralf Damaschke <> writes:
>
>> Tim Rentsch <> wrote:
>>
>>> I believe it is possible in principle for 0.0 to be seen as
>>> true (that is, != 0) in a conforming implementation, if that
>>> implementation (a) does not have an exact FP representation
>>> for zero, and (b) has implementation-defined rounding rules
>>> which are defined suitably. AFAIK both (a) and (b) may be
>>> true in a conforming implementation, that is, I don't know of
>>> any requirement that prevents the possibility of either (or of
>>> both together).
>>
>> There is one. An implementation (a) would not suffice C99
>> 5.2.4.2.2 "Characteristics of floating types <float.h>"; esp.
>> the sum used to define a floating-point number gives 0 if f(k)
>> = 0 for all 1 <= k <= p.
>
> If you read the footnote to 5.2.4.2.2 p1, and also 5.2.4.2.2 p3,
> I think you'll agree that the condition you describe need not
> be an actual representable value in a particular conforming
> implementation.

Sorry, I won't. The only weak point I see is that the standard
uses the term "model" which admittedly might mean that the
implementation may use complete different approaches. But my
preferred interpretation is that "model" means that the
representation is not broken down to bits (such that e.g. digits
might be represented by BCD) and that there must be a homomorphism
to the implementation.

The footnote says that the floating-point _arithmetic_ [emphasis by
me] may differ from the model; that does not affect the definition
of a model's floating-point number in p2.

P3 only introduces additional FP numbers (and only for value != 0).

-- Ralf

"Bill Leary" <> writes:

> "Ben Bacarisse" wrote in message
> news:0.429927d9c3de3565a5c8.20120722142541BST.877g ...
>> but there's nothing to say that the implementation must choose
>> in the same way in both cases. A perverse implementation could
>> "round" 0.0 up and convert 0 by going the other way!
>
> I encountered just this case quite a few years ago. K&R compiler, so
> not as relevant to this exchange as it could be. It converted "0.0"
> to one thing, which wasn't all bits zero. But converted "0," used in
> an expression with a float, to all bits zero.

I think you quoted the wrong part. That looks like an example of
something I wrote a few paragraphs earlier:

| On a machine that has an exact floating zero, 0 must convert to it,
| but 0.0 need not (surely this is unintended?)."

<snip>
--
Ben.

On 2012-07-22, Bill Leary <> wrote:
> "Ben Bacarisse" wrote in message
> news:0.429927d9c3de3565a5c8.20120722142541BST.877g ...
>> but there's nothing to say that the implementation must choose
>> in the same way in both cases. A perverse implementation could
>> "round" 0.0 up and convert 0 by going the other way!
>
> I encountered just this case quite a few years ago. K&R compiler, so not as
> relevant to this exchange as it could be. It converted "0.0" to one thing,
> which wasn't all bits zero. But converted "0," used in an expression with a
> float, to all bits zero.
>
> Thus:
> float wocka = 0.0;
> if (wocka == 0.0)
>
> worked. But:
> float wocka = 0;
> if (wocka == 0.0)
>
> didn't.

Could that have been caused by float-to-double conversion
in the if condition?

What would that compiler do with

float wocka = 0;
if (wocka == 0.0f)

or

double wocka = 0;
if (wocka == 0.0)

?

On 2012-07-22, Ben Bacarisse <> wrote:
> That aside, 0.0 == 0 is interesting. On a machine that has an exact
> floating zero, 0 must convert to it, but 0.0 need not (surely this is
> unintended?). On one that does not have an exact floating zero, very
> similar wording is used in 6.3.1.4 p2 (for the conversion) as is used in
> 6.4.4.2 p3 (for the representation of the constant):
>
> "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."
>
> "the result is either the nearest higher or nearest lower
> representable value, chosen in an implementation-defined manner"
>
> but there's nothing to say that the implementation must choose in the
> same way in both cases. A perverse implementation could "round" 0.0 up
> and convert 0 by going the other way!

That also raises the question: in

static double d;

what would be the initial value of d?
0 or 0.0 ?

Ike Naar <> writes:

> On 2012-07-22, Ben Bacarisse <> wrote:
>> That aside, 0.0 == 0 is interesting. On a machine that has an exact
>> floating zero, 0 must convert to it, but 0.0 need not (surely this is
>> unintended?). On one that does not have an exact floating zero, very
>> similar wording is used in 6.3.1.4 p2 (for the conversion) as is used in
>> 6.4.4.2 p3 (for the representation of the constant):
>>
>> "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."
>>
>> "the result is either the nearest higher or nearest lower
>> representable value, chosen in an implementation-defined manner"
>>
>> but there's nothing to say that the implementation must choose in the
>> same way in both cases. A perverse implementation could "round" 0.0 up
>> and convert 0 by going the other way!
>
> That also raises the question: in
>
> static double d;
>
> what would be the initial value of d?
> 0 or 0.0 ?

I think it must be floating zero. My remarks about machine with no
exact zero are somewhat hypothetical. I am not yet convinced that such
a machine can support a conforming C implementation, but people whose
opinions I respect currently disagree.

As someone else has already point out (sorry, I don't recall who right
now), the rules for default initialisation of objects with static storage
duration state that arithmetic types are initialised to "(positive or
unsigned) zero;". I don't think that can mean anything but exact zero
(whatever that really means).

--
Ben.

On 7/20/2012 9:26 AM, Xavier Roche wrote:
> On 07/20/2012 04:22 PM, Noob wrote:
>> NB: You swapped 0 and 1 there.
>
> Yes, my mistake (but the tested code is the initial one and has the
> wrong value)
>
> I have reported the issue on the "Visual C++ Language" forums (I can't
> understand why they ditched the microsoft.* groups for this piece of
> webforum junk by the way)

Partly because their connection to Google Groups allowed a large
inflow of spam and posts saying that other operating systems are
better.

Partly because they are moving away from supporting newsgroups at
all.