f



What shall return "0.0 ? 1 : 0" ?

Hi folks!

Is there a C standard expert who can confirm what shall return
	0.0 ? 1 : 0

With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result is.. 1.

Is the result undefined by the standard, by chance ?


Regards,
Xavier Roche
0
xroche (207)
7/20/2012 1:21:12 PM
comp.lang.c 30656 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

38 Replies
1357 Views

Similar Articles

[PageSpeed] 19

Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:

> Hi folks!
>
> Is there a C standard expert who can confirm what shall return
> 	0.0 ? 1 : 0
>
> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result
> is.. 1.

How odd.

> Is the result undefined by the standard, by chance ?

No, it's defined to be 0.

It does not violate any constraint that I can see, and the meaning
depends solely on whether 0.0 "compares equal to 0".  I can't find any
justification for 0.0 not comparing equal to 0.

The phases "x compares equal to 0" and "x compares unequal to 0" are
used a lot in the standard.  I've always taken them to mean x == 0 and x
!= 0, but I don't think that's ever stated explicitly.

-- 
Ben.
0
ben.usenet (6790)
7/20/2012 1:57:51 PM
Xavier Roche wrote:

> Is there a C standard expert who can confirm what shall return
> 	0.0 ? 1 : 0
> 
> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result is.. 1.
> 
> Is the result undefined by the standard, by chance ?

Lemme see...

3.3.15 Conditional operator

Syntax

  conditional-expression:
    logical-OR-expression
    logical-OR-expression ?  expression :  conditional-expression

Constraints

   The first operand shall have scalar type.
   [...]

Semantics

   The first operand is evaluated; there is a sequence point after
its evaluation.  The second operand is evaluated only if the first
compares unequal to 0; the third operand is evaluated only if the
first compares equal to 0; the value of the second or third operand
(whichever is evaluated) is the result[41].

[41] A conditional expression does not yield an lvalue.

0.0 is a 'floating-constant' which is a kind of 'primary-expression'
which is a kind of 'logical-OR-expression'.

(Scalar type means integral or floating or pointer.)

Since 0.0 (the floating constant) compares equal to 0 (the integral constant)
(0.0 ? 1 : 0) has value 0, as far as I can tell.

Regards.
0
Noob
7/20/2012 1:58:50 PM
On 07/20/2012 03:58 PM, Noob wrote:
> Since 0.0 (the floating constant) compares equal to 0 (the integral constant)
> (0.0 ? 1 : 0) has value 0, as far as I can tell.

Thanks a lot to both of you. It appears to be a bug in Visual C++ 2010 
(*) then.

This impression is confirmed when trying:
	static double zero = 0.0;
...
	zero ? 0 : 1
which returns the correct value (0).

(*) tested version: cl.exe 16.00.30319.01 for x64 (same issue using the 
x86 release)

0
xroche (207)
7/20/2012 2:02:47 PM
Xavier Roche wrote:
> On 07/20/2012 03:58 PM, Noob wrote:
>> Since 0.0 (the floating constant) compares equal to 0 (the integral constant)
>> (0.0 ? 1 : 0) has value 0, as far as I can tell.
> 
> Thanks a lot to both of you. It appears to be a bug in Visual C++ 2010 
> (*) then.
> 
> This impression is confirmed when trying:
> 	static double zero = 0.0;
> ..
> 	zero ? 0 : 1
> which returns the correct value (0).

NB: You swapped 0 and 1 there.

( 0.0 ? 42 : 666) evaluates to 666
(zero ? 42 : 666) evaluates to 666
0
Noob
7/20/2012 2:22:40 PM
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)

0
xroche (207)
7/20/2012 2:26:35 PM
Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>Is there a C standard expert who can confirm what shall return
>0.0 ? 1 : 0

  An expression does not return. A function may return. After

int f(){ return 0.0 ? 1 : 0; {

  , we can say that f �shall return 0.0 ? 1 : 0�.

0
ram (2986)
7/20/2012 3:21:34 PM
Le 20/07/12 15:21, Xavier Roche a écrit :
> Hi folks!
>
> Is there a C standard expert who can confirm what shall return
>      0.0 ? 1 : 0
>
> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result
> is.. 1.
>
> Is the result undefined by the standard, by chance ?
>
>
> Regards,
> Xavier Roche

The bug is at the level of the compile-time interpretation since the 
result is not calculated at run time (even without aptimizations!)

cl -FA bug.c yields this code:

; Listing generated by Microsoft (R) Optimizing Compiler Version 
16.00.30319.01

include listing.inc

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

_DATA   SEGMENT
$SG2584 DB      '???', 00H
         ORG $+4
$SG2585 DB      '0.0 ? ??? : OK = %s', 0aH, 00H
_DATA   ENDS
PUBLIC  main
EXTRN   printf:PROC
pdata   SEGMENT
$pdata$main DD  imagerel $LN3
         DD      imagerel $LN3+30
         DD      imagerel $unwind$main
pdata   ENDS
xdata   SEGMENT
$unwind$main DD 010401H
         DD      04204H
; Function compile flags: /Odtp
xdata   ENDS
_TEXT   SEGMENT
main    PROC
; File d:\lcc\bug.c
; Line 3
$LN3:
         sub     rsp, 40                                 ; 00000028H
; Line 4
         lea     rdx, OFFSET FLAT:$SG2584
         lea     rcx, OFFSET FLAT:$SG2585
         call    printf
; Line 5
         xor     eax, eax
         add     rsp, 40                                 ; 00000028H
         ret     0
main    ENDP
_TEXT   ENDS
END

0
jacob31 (877)
7/20/2012 4:15:36 PM
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>>Is there a C standard expert who can confirm what shall return
>>0.0 ? 1 : 0
>
>   An expression does not return. A function may return. After
>
> int f(){ return 0.0 ? 1 : 0; {
>
>   , we can say that f »shall return 0.0 ? 1 : 0«.

An expression *yields* a value. (I think earlier versions of the
standard used the word "return" for the results of expressions in
some places; as far as I know it's been cleaned up.)

I agree that it's not strictly correct to say that an expression
returns a value, but the intended meaning is clear enough.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
7/20/2012 4:51:43 PM
Keith Thompson <kst-u@mib.org> writes:
>An expression *yields* a value. (I think earlier versions of the
>standard used the word "return" for the results of expressions in
>some places; as far as I know it's been cleaned up.)

  I'd say that an expression /had/ a value (and that an /evaluation/
  yielded a value). Let me try to find quotations in N1570:

      �Its lifetime begins when the expression is evaluated
      and its initial value is the value of the expression.�
                                   �����������������������
      �An actual implementation need not evaluate part of an
      expression if it can deduce that its value is not used
      and that no needed side effects are produced�

      �the value of CHAR_MIN�

      �expressions with implementation-defined values�

      �Its lifetime begins when the expression is evaluated
      and its initial value is the value of the expression.�

      �If an expression of any other type is evaluated as a
      void expression, its value or designator is discarded.�

  The relationship between an expression and its value in all
  these quotes (selected without bias) is always /possessive/,
  hence /has/.

  However, I'd like to add that for run-time values, it would
  be more correct never to say that /an expression had/ a value,
  since the value is in a one-to-one correspondence only with
  a single /evaluation/, because each evaluation of an
  expression may yield a different value. But it might be too
  cumbersome to always write �the value of an evaluation of x�
  instead of �the value of x�.

0
ram (2986)
7/20/2012 5:07:20 PM
Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
> Is there a C standard expert who can confirm what shall return
> 	0.0 ? 1 : 0
>
> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result is.. 1.
>
> Is the result undefined by the standard, by chance ?

As other responses have said, the result is well defined, and this
appears to be a bug in Visual C++ 2010.

I just tried this program:

#include <stdio.h>
int main(void) {
    printf("%d\n", 0.0 ? 1 : 0);
    if (0.0) {
        puts("0.0 is true");
    }
    else {
        puts("0.0 is false");
    }
    if (0.0 == 0) {
        puts("0.0 compares equal to 0");
    }
    else {
        puts("0.0 does not compare equal to 0");
    }
    return 0;
}

With gcc, the output is:

0
0.0 is false
0.0 compares equal to 0

With Visual Studio, the output is:

1
0.0 is false
0.0 compares equal to 0

with the language set to C and extensions disabled.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
7/20/2012 5:08:09 PM
On 7/20/2012 10:02 AM, Xavier Roche wrote:
> On 07/20/2012 03:58 PM, Noob wrote:
>> Since 0.0 (the floating constant) compares equal to 0 (the integral constant)
>> (0.0 ? 1 : 0) has value 0, as far as I can tell.
>
> Thanks a lot to both of you. It appears to be a bug in Visual C++ 2010 (*)
> then.
>
> This impression is confirmed when trying:
>      static double zero = 0.0;
> ...
>      zero ? 0 : 1
> which returns the correct value (0).
>
> (*) tested version: cl.exe 16.00.30319.01 for x64 (same issue using the x86
> release)

Confirmed as well with cl.exe 16.00.40219.01 for 80x86.

=====
#include <stdio.h>

int main(void)
	{
	double zero = 0.0;
	printf("%d\n", ( 0.0 ? 1 : 0 ) );
	printf("%d\n", ( zero ? 1 : 0 ) );
	return(0);
	}
=====

Displays:

     1
     0

=====

Interestingly enough, if I turn optimization all the way on, it eliminates 
the conditionals altogether, as well as the variable "zero", and compiles to 
the equivalent of:

     printf("%d\n",1);
     printf("%d\n",0);

Ditto for a definition of "float zero".

Apparently, it thinks that a float/double with 0.0 in it is equivalent to 
zero, but a constant "0.0" is not.  ???

-- 
Kenneth Brody
0
kenbrody (1879)
7/20/2012 7:10:28 PM
On 7/20/2012 10: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)

Haven't you heard?  Usenet is dead.  :-)

-- 
Kenneth Brody
0
kenbrody (1879)
7/20/2012 7:11:28 PM
Keith Thompson wrote:
> 
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
> >>Is there a C standard expert who can confirm what shall return
> >>0.0 ? 1 : 0
> >
> >   An expression does not return. A function may return. After
> >
> > int f(){ return 0.0 ? 1 : 0; {
> >
> >   , we can say that f »shall return 0.0 ? 1 : 0«.
> 
> An expression *yields* a value. (I think earlier versions of the
> standard used the word "return" for the results of expressions in
> some places; as far as I know it's been cleaned up.)

Section "6.5 Expressions" in both C89 and in C99, 
described the bitwise operators as returning values.

-- 
pete
0
pfiland (6613)
7/21/2012 12:29:42 AM
pete <pfiland@mindspring.com> writes:
> Keith Thompson wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> > Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>> >>Is there a C standard expert who can confirm what shall return
>> >>0.0 ? 1 : 0
>> >
>> >   An expression does not return. A function may return. After
>> >
>> > int f(){ return 0.0 ? 1 : 0; {
>> >
>> >   , we can say that f »shall return 0.0 ? 1 : 0«.
>> 
>> An expression *yields* a value. (I think earlier versions of the
>> standard used the word "return" for the results of expressions in
>> some places; as far as I know it's been cleaned up.)
>
> Section "6.5 Expressions" in both C89 and in C99, 
> described the bitwise operators as returning values.

C99 says they "return" values; N1256 says they "yield" values,
as does N1570 (the C11 pre-release draft).

None of the three Technical Corrigenda (which in theory constitute
the difference between C99 and N1256) contain the word "yield".
I think the editor, Larry Jones, just made the change himself.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
7/21/2012 3:25:44 AM
Keith Thompson <kst-u@mib.org> writes:
> pete <pfiland@mindspring.com> writes:
> > Keith Thompson wrote:
> >> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >> > Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
> >> >>Is there a C standard expert who can confirm what shall return
> >> >>0.0 ? 1 : 0
> >> >
> >> >   An expression does not return. A function may return. After
> >> >
> >> > int f(){ return 0.0 ? 1 : 0; {
> >> >
> >> >   , we can say that f »shall return 0.0 ? 1 : 0«.
> >> 
> >> An expression *yields* a value. (I think earlier versions of the
> >> standard used the word "return" for the results of expressions in
> >> some places; as far as I know it's been cleaned up.)
> >
> > Section "6.5 Expressions" in both C89 and in C99, 
> > described the bitwise operators as returning values.
> 
> C99 says they "return" values; N1256 says they "yield" values,
> as does N1570 (the C11 pre-release draft).
> 
> None of the three Technical Corrigenda (which in theory constitute
> the difference between C99 and N1256) contain the word "yield".
> I think the editor, Larry Jones, just made the change himself.

Not just that, but he disclosed that here after a discussion
almost identical to this one. IIRC.

Whilst I think it's good to wean people off inappropriate use of
"return", I don't think it's worth making too big a thing of, at
least if the question has been understood by everyone who didn't
deliberately want to be adversarial.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)
0
7/21/2012 7:22:13 PM
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>
>> Hi folks!
>>
>> Is there a C standard expert who can confirm what shall return
>> 	0.0 ? 1 : 0
>>
>> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result
>> is.. 1.
>
> How odd.
>
>> Is the result undefined by the standard, by chance ?
>
> No, it's defined to be 0.
>
> It does not violate any constraint that I can see, and the meaning
> depends solely on whether 0.0 "compares equal to 0".  I can't find any
> justification for 0.0 not comparing equal to 0.  [snip elaboration]

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

Of course, I don't know of any ACTUAL implementation for which
even just (a) holds, but just theoretically I think it is possible.
0
txr1 (1467)
7/21/2012 9:39:55 PM
ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Keith Thompson <kst-u@mib.org> writes:
>>An expression *yields* a value. (I think earlier versions of the
>>standard used the word "return" for the results of expressions in
>>some places; as far as I know it's been cleaned up.)
>
>   I'd say that an expression /had/ a value (and that an /evaluation/
>   yielded a value). Let me try to find quotations in N1570:
>
>       >>Its lifetime begins when the expression is evaluated
>       and its initial value is the value of the expression.<<
>                                    -----------------------
>       >>An actual implementation need not evaluate part of an
>       expression if it can deduce that its value is not used
>       and that no needed side effects are produced<<
>
>       >>the value of CHAR_MIN<<
>
>       >>expressions with implementation-defined values<<
>
>       >>Its lifetime begins when the expression is evaluated
>       and its initial value is the value of the expression.<<
>
>       >>If an expression of any other type is evaluated as a
>       void expression, its value or designator is discarded.<<
>
>   The relationship between an expression and its value in all
>   these quotes (selected without bias) is always /possessive/,
>   hence /has/.  [snip]

There are also lots of places where the Standard uses phrasing like
'an expression yields the value ...' or 'x[3][5] yields ...'.
Generally speaking the Standard often doesn't do a good job of
observing the distinction between translation-time properties and
execution-time properties.  Strictly speaking, an expression is a
translation-time entity;  it is only an evaulation of an expression
that has (or yields) a value, or evaluating an expression that yields
a value.  Some expressions have the property that every time they are
evaluated the evaluations always yield the same value, and there it
might be more defensible to say that the expression /has/ that value.
But I don't think the Standard itself is careful about these
distinctions one way or the other.
0
txr1 (1467)
7/21/2012 9:52:23 PM
Keith Thompson <kst-u@mib.org> writes:

> pete <pfiland@mindspring.com> writes:
>> Keith Thompson wrote:
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> > Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>>> >>Is there a C standard expert who can confirm what shall return
>>> >>0.0 ? 1 : 0
>>> >
>>> >   An expression does not return. A function may return. After
>>> >
>>> > int f(){ return 0.0 ? 1 : 0; {
>>> >
>>> >   , we can say that f  >>shall return 0.0 ? 1 : 0 <<.
>>> 
>>> An expression *yields* a value. (I think earlier versions of the
>>> standard used the word "return" for the results of expressions in
>>> some places; as far as I know it's been cleaned up.)
>>
>> Section "6.5 Expressions" in both C89 and in C99, 
>> described the bitwise operators as returning values.
>
> C99 says they "return" values; N1256 says they "yield" values,
> as does N1570 (the C11 pre-release draft).  [snip]

Yes, and N1124 is like N1256 in this regard.
0
txr1 (1467)
7/21/2012 9:54:17 PM
Tim Rentsch <txr@alumni.caltech.edu> 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.

-- Ralf
0
rwspam (81)
7/21/2012 11:31:35 PM
Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>>
>>> Hi folks!
>>>
>>> Is there a C standard expert who can confirm what shall return
>>> 	0.0 ? 1 : 0
>>>
>>> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result
>>> is.. 1.
>>
>> How odd.
>>
>>> Is the result undefined by the standard, by chance ?
>>
>> No, it's defined to be 0.
>>
>> It does not violate any constraint that I can see, and the meaning
>> depends solely on whether 0.0 "compares equal to 0".  I can't find any
>> justification for 0.0 not comparing equal to 0.  [snip elaboration]
>
> 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).

I took the characteristics of floating point numbers presented in
5.2.4.2.2 to mean that C had to use a representation that includes (an
exact) zero.

But, as you say, it turns out that an implementation is not required to
represent exactly even exactly representable floating constants.
Fortunately, this must be documented so in the absence of any such
explanation, 0.0 will be equal to 0.

> Of course, I don't know of any ACTUAL implementation for which
> even just (a) holds, but just theoretically I think it is possible.

Well, I thought not, but it doesn't matter anyway as far as I can see.
Even if zero is representable, 0.0 can convert to any one of three
values according to 6.4.4.2 p3.

-- 
Ben.
0
ben.usenet (6790)
7/22/2012 1:43:43 AM
Ralf Damaschke <rwspam@gmx.de> writes:

> Tim Rentsch <txr@alumni.caltech.edu> 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.


0
txr1 (1467)
7/22/2012 4:57:34 AM
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
>>>
>>>> Hi folks!
>>>>
>>>> Is there a C standard expert who can confirm what shall return
>>>> 	0.0 ? 1 : 0
>>>>
>>>> With gcc 4.3/Linux, the result is 0. With Visual C++2010, the result
>>>> is.. 1.
>>>
>>> How odd.
>>>
>>>> Is the result undefined by the standard, by chance ?
>>>
>>> No, it's defined to be 0.
>>>
>>> It does not violate any constraint that I can see, and the meaning
>>> depends solely on whether 0.0 "compares equal to 0".  I can't find any
>>> justification for 0.0 not comparing equal to 0.  [snip elaboration]
>>
>> 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).
>
> I took the characteristics of floating point numbers presented in
> 5.2.4.2.2 to mean that C had to use a representation that includes (an
> exact) zero.
>
> But, as you say, it turns out that an implementation is not required to
> represent exactly even exactly representable floating constants.
> Fortunately, this must be documented so in the absence of any such
> explanation, 0.0 will be equal to 0.
>
>> Of course, I don't know of any ACTUAL implementation for which
>> even just (a) holds, but just theoretically I think it is possible.
>
> Well, I thought not, but it doesn't matter anyway as far as I can see.
> Even if zero is representable, 0.0 can convert to any one of three
> values according to 6.4.4.2 p3.

I had read this paragraph earlier, but either I misread it or
I missed the full implications of what it says.  I expected
that any FP constant that could be represented exactly must
necessarily be given that exact value, but now that you point
it out obviously it doesn't.  So this isn't just a theoretical
problem -- it's only QOI that saves us from some very surprising
results.

Thank you for following up with this observation.  Yet another
strange corner of C that I didn't realize was so strange.
0
txr1 (1467)
7/22/2012 5:05:38 AM
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 :D).

-- 
Seungbeom Kim
0
musiphil (33)
7/22/2012 10:20:12 AM
Seungbeom Kim <musiphil@bawi.org> 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 :D).

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.
0
ben.usenet (6790)
7/22/2012 1:25:41 PM
Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ralf Damaschke <rwspam@gmx.de> writes:
> 
> > Tim Rentsch <txr@alumni.caltech.edu> 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)
0
7/22/2012 2:27:22 PM
Tim Rentsch <txr@alumni.caltech.edu> wrote in news:kfnwr1w1jgh.fsf@x-
alumni2.alumni.caltech.edu:

> Ralf Damaschke <rwspam@gmx.de> writes:
> 
>> Tim Rentsch <txr@alumni.caltech.edu> 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

0
7/22/2012 6:43:04 PM
Tim Rentsch <txr@alumni.caltech.edu> wrote:

> Ralf Damaschke <rwspam@gmx.de> writes:
> 
>> Tim Rentsch <txr@alumni.caltech.edu> 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
0
rwspam (81)
7/22/2012 10:43:04 PM
"Ben Bacarisse"  wrote in message 
news:0.429927d9c3de3565a5c8.20120722142541BST.877gtw6i7e.fsf@bsb.me.uk...
> 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.

    - Bill

0
Bill_Leary (360)
7/22/2012 10:56:29 PM
"Bill Leary" <Bill_Leary@msn.com> writes:

> "Ben Bacarisse"  wrote in message
> news:0.429927d9c3de3565a5c8.20120722142541BST.877gtw6i7e.fsf@bsb.me.uk...
>> 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.
0
ben.usenet (6790)
7/23/2012 12:37:58 AM
On 2012-07-22, Bill Leary <Bill_Leary@msn.com> wrote:
> "Ben Bacarisse"  wrote in message 
> news:0.429927d9c3de3565a5c8.20120722142541BST.877gtw6i7e.fsf@bsb.me.uk...
>> 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)

?
0
ike8 (164)
7/23/2012 6:45:47 AM
On 2012-07-22, Ben Bacarisse <ben.usenet@bsb.me.uk> 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 ?
0
ike8 (164)
7/23/2012 6:49:36 AM
"Ben Bacarisse"  wrote in message 
news:0.5e9daff58e2377eec02e.20120723013758BST.87394j5n2x.fsf@bsb.me.uk...
> "Bill Leary" <Bill_Leary@msn.com> writes:
>> "Ben Bacarisse"  wrote in message
>> news:0.429927d9c3de3565a5c8.20120722142541BST.877gtw6i7e.fsf@bsb.me.uk...
>>> 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?)."

Yes, thank you for the correction.

    - Bill

0
Bill_Leary (360)
7/23/2012 11:27:00 AM
"Ike Naar"  wrote in message 
news:slrn3vfsk0psor.lad.ike@sverige.freeshell.org...
>
> On 2012-07-22, Bill Leary <Bill_Leary@msn.com> wrote:
>> "Ben Bacarisse"  wrote in message
>> news:0.429927d9c3de3565a5c8.20120722142541BST.877gtw6i7e.fsf@bsb.me.uk...
>>> 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?

I took a pointer to "wocka" and printed it out, byte by byte, in hex.  There 
was one bit set.  I don't recall that I went any further than that with it. 
I just warned the other people on the project that the second case would 
fail.

> What would that compiler do with
>
>  float wocka = 0;
>  if (wocka == 0.0f)
>
> or
>
>  double wocka = 0;
>  if (wocka == 0.0)
>
> ?

Sorry, so long ago I don't remember if I even tried anything like that.  And 
there's no opportunity to try it now.  Production and deadlines and all 
that.  I just figured out why it was failing and warned people about it. and 
went on to the next issue.  This compiler also didn't process precedence 
correctly.  In some cases it would do additions before multiplications if 
you didn't force it.  That is,  A + B * C evaluated to (A + B) * C.  I think 
it was triggered by the right mix of variables, and types of variables, and 
constants.  That company built the computers, and ported the operating 
system (a UNIX variant) and the tools to that hardware.  But they were a bit 
sloppy about pretty much all of it.

    - Bill

0
Bill_Leary (360)
7/23/2012 11:37:14 AM
Ike Naar <ike@sverige.freeshell.org> writes:

> On 2012-07-22, Ben Bacarisse <ben.usenet@bsb.me.uk> 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.
0
ben.usenet (6790)
7/23/2012 11:42:35 AM
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.

0
milesrf (102)
8/25/2012 5:16:10 AM
Martin Shobe <martin.shobe@yahoo.com> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote in news:kfnwr1w1jgh.fsf@x-
> alumni2.alumni.caltech.edu:
>
>> Ralf Damaschke <rwspam@gmx.de> writes:
>> 
>>> Tim Rentsch <txr@alumni.caltech.edu> 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?

I take this to mean the initialization is done the same as saying
'={0}' for the initializer, except also saying the result will
never be (a representation for) negative zero.  Of course it's
possible that it indicates a requirement elsewhere, and it's also
possible that it indicates a subconscious assumption that is not
actually a requirement, but I don't think this passge is meant to
/impose/ a requirement that zero be representable.  So basically
I don't draw any conclusions just from this paragraph one way or
the other.
0
txr1 (1467)
9/7/2012 5:14:48 PM
Ralf Damaschke <rwspam@gmx.de> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> Ralf Damaschke <rwspam@gmx.de> writes:
>> 
>>> Tim Rentsch <txr@alumni.caltech.edu> 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).

The point of mentioning paragraph 3 is that it only uses the word
'may'; it doesn't state any actual requirements that any
particular numbers, or forms of numbers, be representable.

The point of mentioning the footnote is that it gives a fairly
general licennse for implentations to use different schemes.  For
example, I think it would be conforming to implement "floating
point" numbers using scaled, fixed-point arithmetic and use
hundreds or thousands of bits in each 'float' or 'double'.
Focusing on the word 'arithmetic' in the footnote seems like a
red herring to me - a change in how numbers are represented will
naturally lead to a change in how arithmetic works, but if
representation is kept constant then we wouldn't expect a big
variation in how arithmetic works.

For paragraph 1, I think the right word to focus on is not
'model' but 'characteristics' - "The /characteristics/ of
floating types are defined in terms of a model".  The point of
this abstraction is to be able to talk about aspects of floating
point numbers without knowing anything about how they will be
represented.  Indeed, if floating point numbers are required to
be represented in terms of the model of paragraphs 1 and 2, then
all that is needed is the parameters listed in paragraph 1 -
everything else can be derived from these (plus a little more
information like infinities, NaN's, unnormalized/subnormals, etc,
but that's fairly negligible).  The point of the model is to be
able to talk about how we can expect floating-point numbers will
behave /without/ knowing spefically how they are represented.

Finally, last point - even if floating-point numbers are known to
be represented using the form shown in paragraph 2, I don't see
anything in the standard that requires any particular values be
representable;  they just have to satisfy the various macro
definitions laid out in 5.2.4.2.2.  I believe all of these can
be satisfied using a representation of the form shown in
paragraph 2, but without there being a representation that
is exactly zero.
0
txr1 (1467)
9/7/2012 5:59:31 PM
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ralf Damaschke <rwspam@gmx.de> writes:
>> 
>> > Tim Rentsch <txr@alumni.caltech.edu> 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.

I don't see what you're getting at here.  Taking 'double' as
the canonical floating-point type, are you talking about
DBL_EPSILON, DBL_MIN, or DBL_TRUE_MIN?  I don't see any
problem with any one of these, under a working assumption of
no reprsentation for zero.  What am I missing?

> Zero must be less than epsilon, as epsilon must
> be greater than it.

Certainly zero must be less than any positive number.  That
doesn't mean zero is representable.

> And zero must me expressible.

Isn't that exactly the question we are trying to answer, ie,
whether floating point types must have a representation for
zero?  I don't see that the Standard's requirements imply
that.

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

Yes, if there is a zero, and if there is a negative zero.  I
think the Standard is pretty clear that an implementation
need not have a floating-point negative 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.

I'm pretty sure you're right that supprting IEEE floating-point
means there will be a representation for zero.  In fact I would be
surprised (though not astonized) if any actual implementation
didn't have a floating-point representation for zero.  My question
is, do the Standard's requirements imply that the floating-point
types /must/ have a representation for zero?  So far I still think
the answer is no (at least in the hypothetical world of DS9000's,
etc).
0
txr1 (1467)
9/7/2012 6:15:17 PM
Reply: