Violation of Conversion rule of C99.

Discussion in 'C Programming' started by Rajesh S R, Mar 12, 2007.

  1. Rajesh S R

    Rajesh S R Guest

    Isn't this code violation of C99 standard?

    #include <stdio.h>
    int main( void )
    {
    float a = 0.7;

    if(a < 0.7)
    printf("Wrong");
    else
    printf("Right! God job");
    return 0;
    }



    The output of the code is "wrong".

    Isnt the output violating C99 standard which states:

    *6.3.1.5 Real floating types*
    When a float is promoted to double or long double, or a double is
    promoted
    to long double, its value is unchanged.

    I am using DEV-CPP (MingW32) compiler for windows.

    Thanks in advance for the reply.
    Rajesh S R, Mar 12, 2007
    #1
    1. Advertising

  2. Rajesh S R

    Eric Sosman Guest

    Rajesh S R wrote:
    > Isn't this code violation of C99 standard?
    >
    > #include <stdio.h>
    > int main( void )
    > {
    > float a = 0.7;
    >
    > if(a < 0.7)
    > printf("Wrong");
    > else
    > printf("Right! God job");
    > return 0;
    > }
    >
    >
    >
    > The output of the code is "wrong".
    >
    > Isnt the output violating C99 standard which states:
    >
    > *6.3.1.5 Real floating types*
    > When a float is promoted to double or long double, or a double is
    > promoted
    > to long double, its value is unchanged.


    Right. But when a double is *de*moted to a float,
    which happens in the initialization of `a', there is
    no such guarantee.

    --
    Eric Sosman
    lid
    Eric Sosman, Mar 12, 2007
    #2
    1. Advertising

  3. On Mar 12, 7:49 am, "Rajesh S R" <> wrote:
    > Isn't this code violation of C99 standard?
    >
    > #include <stdio.h>
    > int main( void )
    > {
    > float a = 0.7;
    >
    > if(a < 0.7)
    > printf("Wrong");
    > else
    > printf("Right! God job");
    > return 0;
    >
    > }
    >
    > The output of the code is "wrong".
    >
    > Isnt the output violating C99 standard which states:
    >
    > *6.3.1.5 Real floating types*
    > When a float is promoted to double or long double, or a double is
    > promoted
    > to long double, its value is unchanged.
    >
    > I am using DEV-CPP (MingW32) compiler for windows.
    >
    > Thanks in advance for the reply.



    No, the code appears to work correctly. Note that 0.7 is
    a *double*. When you convert this to a float you get a slightly
    smaller value (there is no float value that can hold
    the double value). So a is now slightly smaller
    than 0.7 double, and when you compare a to 0.7
    a is promoted to double without changing its value so
    you correctly get this result.
    Try changing the comparison to "if(a < 0.7f)"

    However, comparing floating point values for equality
    is a mug's game. Even if you get things right it
    is not worth the effort, and there is always the chance
    (high probability) that some implementor will get
    things wrong.


    - William Hughes
    William Hughes, Mar 12, 2007
    #3
  4. Rajesh S R

    Rajesh S R Guest

    On Mar 12, 5:56 pm, Eric Sosman <> wrote:
    > Rajesh S R wrote:
    > > Isn't this code violation of C99 standard?

    >
    > > #include <stdio.h>
    > > int main( void )
    > > {
    > > float a = 0.7;

    >
    > > if(a < 0.7)
    > > printf("Wrong");
    > > else
    > > printf("Right! God job");
    > > return 0;
    > > }

    >
    > > The output of the code is "wrong".

    >
    > > Isnt the output violating C99 standard which states:

    >
    > > *6.3.1.5 Real floating types*
    > > When a float is promoted to double or long double, or a double is
    > > promoted
    > > to long double, its value is unchanged.

    >
    > Right. But when a double is *de*moted to a float,
    > which happens in the initialization of `a', there is
    > no such guarantee.
    >
    > --
    > Eric Sosman
    > - Hide quoted text -
    >
    > - Show quoted text -


    Thanks for the reply.
    So due to demotion the value initialised is not represented exactly,
    so you get the output as "wrong".
    But C standard further states that:

    If the value being converted is in the range of values that can be
    represented but cannot be represented exactly, the result is either
    the nearest higher or nearest lower representable value, chosen in an
    *implementation-defined manner*.

    So the output may also be "Right! God job" ,by some other compilers
    and the output is implementation dependent.
    Am I right?
    Rajesh S R, Mar 12, 2007
    #4
  5. On Mar 12, 8:15 am, "Rajesh S R" <> wrote:
    > On Mar 12, 5:56 pm, Eric Sosman <> wrote:
    >
    >
    >
    > > Rajesh S R wrote:
    > > > Isn't this code violation of C99 standard?

    >
    > > > #include <stdio.h>
    > > > int main( void )
    > > > {
    > > > float a = 0.7;

    >
    > > > if(a < 0.7)
    > > > printf("Wrong");
    > > > else
    > > > printf("Right! God job");
    > > > return 0;
    > > > }

    >
    > > > The output of the code is "wrong".

    >
    > > > Isnt the output violating C99 standard which states:

    >
    > > > *6.3.1.5 Real floating types*
    > > > When a float is promoted to double or long double, or a double is
    > > > promoted
    > > > to long double, its value is unchanged.

    >
    > > Right. But when a double is *de*moted to a float,
    > > which happens in the initialization of `a', there is
    > > no such guarantee.

    >
    > > --
    > > Eric Sosman
    > > - Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Thanks for the reply.
    > So due to demotion the value initialised is not represented exactly,


    Well the real number 0.7 can (very probably) not be represented
    exactly as a double.
    So inexactness is due to more than just the demotion. More precisely,
    "due to demotion the value initialised is not the same as the value
    of the real number 0.7 converted to a double."

    > so you get the output as "wrong".
    > But C standard further states that:
    >
    > If the value being converted is in the range of values that can be
    > represented but cannot be represented exactly, the result is either
    > the nearest higher or nearest lower representable value, chosen in an
    > *implementation-defined manner*.
    >
    > So the output may also be "Right! God job" ,by some other compilers
    > and the output is implementation dependent.
    > Am I right?


    Yes. In this case even if the implementors get things right.

    - William Hughes.
    William Hughes, Mar 12, 2007
    #5
  6. In article <>,
    Rajesh S R <> wrote:

    >> > float a = 0.7;

    >>
    >> > if(a < 0.7)


    >If the value being converted is in the range of values that can be
    >represented but cannot be represented exactly, the result is either
    >the nearest higher or nearest lower representable value, chosen in an
    >*implementation-defined manner*.
    >
    >So the output may also be "Right! God job" ,by some other compilers
    >and the output is implementation dependent.
    >Am I right?


    You may well find that this happens if you use 0.8 instead of 0.7.

    -- Richard



    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Mar 12, 2007
    #6
  7. Rajesh S R

    Guest

    On Mar 12, 1:08 pm, "William Hughes" <> wrote:
    > However, comparing floating point values for equality
    > is a mug's game. Even if you get things right it
    > is not worth the effort, and there is always the chance
    > (high probability) that some implementor will get
    > things wrong.


    I've noted that compilers (usually in some strict mode) even emit
    warnings for comparing with 0.0. I have enough faith in implementors
    that that seems too much of a stretch. Not to mention that there is no
    other way to check for division-by-zero. I also think it will be
    generally safe to compare with 1.0 (based on typical floating point
    implementations).

    Stijn
    , Mar 12, 2007
    #7
  8. In article <>,
    <> wrote:

    >I've noted that compilers (usually in some strict mode) even emit
    >warnings for comparing with 0.0. I have enough faith in implementors
    >that that seems too much of a stretch. Not to mention that there is no
    >other way to check for division-by-zero.


    Why would you want to check for division by zero? Wouldn't
    division-by-anything-small-enough-to-cause-overflow usually be just as
    bad?

    >I also think it will be
    >generally safe to compare with 1.0 (based on typical floating point
    >implementations).


    Why is 1.0 any better than, say, 3.5? Both have exact binary
    floating-point representations.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Mar 12, 2007
    #8
  9. Rajesh S R

    Guest

    On Mar 12, 3:00 pm, (Richard Tobin) wrote:
    > In article <>,
    >
    > <> wrote:
    > >I've noted that compilers (usually in some strict mode) even emit
    > >warnings for comparing with 0.0. I have enough faith in implementors
    > >that that seems too much of a stretch. Not to mention that there is no
    > >other way to check for division-by-zero.

    >
    > Why would you want to check for division by zero? Wouldn't
    > division-by-anything-small-enough-to-cause-overflow usually be just as
    > bad?


    In my work, the first is inmeasurably more common than the latter.
    Think of computing an average where there the number of summands is
    zero.

    > >I also think it will be
    > >generally safe to compare with 1.0 (based on typical floating point
    > >implementations).

    >
    > Why is 1.0 any better than, say, 3.5? Both have exact binary
    > floating-point representations.


    It is not better. There are quite a lot of numbers that have exact
    binary floating point representation, that goes without saying.

    In my work, the number 1.0 somehow seems more common than 3.5 . YMMV.

    Stijn
    , Mar 12, 2007
    #9
  10. Rajesh S R

    Guest

    On Mar 12, 3:07 pm, wrote:
    > On Mar 12, 3:00 pm, (Richard Tobin) wrote:
    >
    > > In article <>,

    >
    > > <> wrote:
    > > >I've noted that compilers (usually in some strict mode) even emit
    > > >warnings for comparing with 0.0. I have enough faith in implementors
    > > >that that seems too much of a stretch. Not to mention that there is no
    > > >other way to check for division-by-zero.

    >
    > > Why would you want to check for division by zero? Wouldn't
    > > division-by-anything-small-enough-to-cause-overflow usually be just as
    > > bad?

    >
    > In my work, the first is inmeasurably more common than the latter.
    > Think of computing an average where there the number of summands is
    > zero.


    Probably someone is pointing this out in parallel, but in that case
    the number being tested is likely of integer type, so my argument does
    not make sense.

    Stijn
    , Mar 12, 2007
    #10
  11. Rajesh S R

    Guest

    On Mar 12, 3:00 pm, (Richard Tobin) wrote:
    > In article <>,
    >
    > <> wrote:
    > >I've noted that compilers (usually in some strict mode) even emit
    > >warnings for comparing with 0.0. I have enough faith in implementors
    > >that that seems too much of a stretch. Not to mention that there is no
    > >other way to check for division-by-zero.

    >
    > Why would you want to check for division by zero? Wouldn't
    > division-by-anything-small-enough-to-cause-overflow usually be just as
    > bad?


    your stance make sense, yes. Going back to the code that generated the
    warnings,
    they were mostly in my sparse graph library, where zero values are not
    stored.

    Stijn
    , Mar 12, 2007
    #11
  12. Rajesh S R

    Rajesh S R Guest

    On Mar 12, 6:33 pm, "William Hughes" <> wrote:
    > On Mar 12, 8:15 am, "Rajesh S R" <> wrote:
    >
    >
    >
    >
    >
    > > On Mar 12, 5:56 pm, Eric Sosman <> wrote:

    >
    > > > Rajesh S R wrote:
    > > > > Isn't this code violation of C99 standard?

    >
    > > > > #include <stdio.h>
    > > > > int main( void )
    > > > > {
    > > > > float a = 0.7;

    >
    > > > > if(a < 0.7)
    > > > > printf("Wrong");
    > > > > else
    > > > > printf("Right! God job");
    > > > > return 0;
    > > > > }

    >
    > > > > The output of the code is "wrong".

    >
    > > > > Isnt the output violating C99 standard which states:

    >
    > > > > *6.3.1.5 Real floating types*
    > > > > When a float is promoted to double or long double, or a double is
    > > > > promoted
    > > > > to long double, its value is unchanged.

    >
    > > > Right. But when a double is *de*moted to a float,
    > > > which happens in the initialization of `a', there is
    > > > no such guarantee.

    >
    > > > --
    > > > Eric Sosman
    > > > - Hide quoted text -

    >
    > > > - Show quoted text -

    >
    > > Thanks for the reply.
    > > So due to demotion the value initialised is not represented exactly,

    >
    > Well the real number 0.7 can (very probably) not be represented
    > exactly as a double.
    > So inexactness is due to more than just the demotion. More precisely,
    > "due to demotion the value initialised is not the same as the value
    > of the real number 0.7 converted to a double."
    >
    > > so you get the output as "wrong".
    > > But C standard further states that:

    >
    > > If the value being converted is in the range of values that can be
    > > represented but cannot be represented exactly, the result is either
    > > the nearest higher or nearest lower representable value, chosen in an
    > > *implementation-defined manner*.

    >
    > > So the output may also be "Right! God job" ,by some other compilers
    > > and the output is implementation dependent.
    > > Am I right?

    >
    > Yes. In this case even if the implementors get things right.
    >
    > - William Hughes.- Hide quoted text -
    >
    > - Show quoted text -


    Thanks for the reply
    But even the following code gives "Wrong".


    int main(void)
    {
    float a = 0.7f;

    if(a < 0.7)
    printf("Wrong");
    else
    printf("God job");
    return 0;
    }

    I think the explanation that the declaration
    float a = 0.7f;
    is equivalent to
    float a = (float)0.7;/*Conversion from double to float might truncate
    the result*/
    will work.

    The expression '0.7f' forces the compiler to interpret 0.7 as a float
    directly, rather than as a double converted to float as clearly stated
    by the standard.

    So this explanation will fail.

    So an explanation as you stated above, will work.
    That is, the float value 0.7f can (very probably) not be represented
    exactly as a float.

    My question in this context is:
    How this inaccurate representation complies with ANSI standards?

    I hope my question is clear.
    Please reply.

    Thanks in advance for the reply.
    Rajesh S R, Mar 12, 2007
    #12
  13. In article <>,
    <> wrote:

    >> Why would you want to check for division by zero? Wouldn't
    >> division-by-anything-small-enough-to-cause-overflow usually be just as
    >> bad?


    >In my work, the first is inmeasurably more common than the latter.
    >Think of computing an average where there the number of summands is
    >zero.


    Why would the number of summands be a floating point number? There's
    no problem comparing integers with zero.

    >> >I also think it will be
    >> >generally safe to compare with 1.0 (based on typical floating point
    >> >implementations).


    >> Why is 1.0 any better than, say, 3.5? Both have exact binary
    >> floating-point representations.


    >It is not better. There are quite a lot of numbers that have exact
    >binary floating point representation, that goes without saying.
    >
    >In my work, the number 1.0 somehow seems more common than 3.5 . YMMV.


    In my work, I rarely if ever fund myself comparing floating point
    numbers with constants. But a floating point number that's supposed
    to be 1.0 - or 3.5 - may well not be, even though those numbers can be
    represented exactly.

    In most cases where you can be sure that a floating point number will
    be exactly what you want, you could have done it with integers
    instead.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Mar 12, 2007
    #13
  14. Rajesh S R

    Guest

    On 12 Mar, 16:17, "Rajesh S R" <> wrote:
    ....
    > ... even the following code gives "Wrong".
    >
    > int main(void)
    > {
    > float a = 0.7f;
    >
    > if(a < 0.7)


    make this "if(a < 0.7f)" so that you are comparing float with float.
    If you compare with "0.7", you first of all approximate 0.7 in a
    double, then find the nearest float to this approximation, which is
    not necessarily the nearest float to 0.7. (I think).

    > printf("Wrong");

    Missing '\n' makes that less useful than I'd like.
    > else
    > printf("God job");

    Missing '\n' and misspelling "Good" - unless you really meant "God".
    > return 0;
    >
    > }


    I'm not sure what you're trying to achieve. Some background reading on
    floating-point representation may be more useful than experimentation
    and posting to this newsgroup.
    , Mar 12, 2007
    #14
  15. On 12 Mar 2007 09:17:13 -0700, in comp.lang.c , "Rajesh S R"
    <> wrote:

    >Thanks for the reply
    >But even the following code gives "Wrong".
    >
    >
    >int main(void)
    >{
    > float a = 0.7f;
    >
    > if(a < 0.7)
    > printf("Wrong");
    > else
    > printf("God job");
    > return 0;
    >}


    Looks to me like you need to read Goldberg: "What Every Computer
    Scientist Should Know About Floating-Point Arithmetic".

    You can't reliably compare floating point data,especially of different
    widths. C99

    >How this inaccurate representation complies with ANSI standards?


    5.2.4.2.2 of the Standard specifically states that the accuracy is
    implementaiton defined. That said, many implementations adhere to the
    IEEE standard.

    But there is no accurate representation anyway - see Goldberg.

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Mar 12, 2007
    #15
  16. Rajesh S R

    Rajesh S R Guest

    On Mar 12, 9:49 pm, wrote:
    > On 12 Mar, 16:17, "Rajesh S R" <> wrote:
    > ...
    >
    > > ... even the following code gives "Wrong".

    >
    > > int main(void)
    > > {
    > > float a = 0.7f;

    >
    > > if(a < 0.7)

    >
    > make this "if(a < 0.7f)" so that you are comparing float with float.
    > If you compare with "0.7", you first of all approximate 0.7 in a
    > double, then find the nearest float to this approximation, which is
    > not necessarily the nearest float to 0.7. (I think).
    >
    > > printf("Wrong");

    >
    > Missing '\n' makes that less useful than I'd like.> else
    > > printf("God job");

    >
    > Missing '\n' and misspelling "Good" - unless you really meant "God".
    >
    > > return 0;

    >
    > > }

    >
    > I'm not sure what you're trying to achieve. Some background reading on
    > floating-point representation may be more useful than experimentation
    > and posting to this newsgroup.



    I am aware about floating point representation a little.

    My question is related with C!

    My question is,
    if the inaccurate representation violates C99 standards?
    I guess nothing is said about accuracy or inaccurate representation in
    C99 standards.

    If nothing is said about something in a C99 document, is it
    implementation dependent?

    I hope I'm clear.
    Rajesh S R, Mar 12, 2007
    #16
  17. On Mar 12, 11:17 am, "Rajesh S R" <> wrote:
    > On Mar 12, 6:33 pm, "William Hughes" <> wrote:
    >
    >
    >
    > > On Mar 12, 8:15 am, "Rajesh S R" <> wrote:

    >
    > > > On Mar 12, 5:56 pm, Eric Sosman <> wrote:

    >
    > > > > Rajesh S R wrote:
    > > > > > Isn't this code violation of C99 standard?

    >
    > > > > > #include <stdio.h>
    > > > > > int main( void )
    > > > > > {
    > > > > > float a = 0.7;

    >
    > > > > > if(a < 0.7)
    > > > > > printf("Wrong");
    > > > > > else
    > > > > > printf("Right! God job");
    > > > > > return 0;
    > > > > > }

    >
    > > > > > The output of the code is "wrong".

    >
    > > > > > Isnt the output violating C99 standard which states:

    >
    > > > > > *6.3.1.5 Real floating types*
    > > > > > When a float is promoted to double or long double, or a double is
    > > > > > promoted
    > > > > > to long double, its value is unchanged.

    >
    > > > > Right. But when a double is *de*moted to a float,
    > > > > which happens in the initialization of `a', there is
    > > > > no such guarantee.

    >
    > > > > --
    > > > > Eric Sosman
    > > > > - Hide quoted text -

    >
    > > > > - Show quoted text -

    >
    > > > Thanks for the reply.
    > > > So due to demotion the value initialised is not represented exactly,

    >
    > > Well the real number 0.7 can (very probably) not be represented
    > > exactly as a double.
    > > So inexactness is due to more than just the demotion. More precisely,
    > > "due to demotion the value initialised is not the same as the value
    > > of the real number 0.7 converted to a double."

    >
    > > > so you get the output as "wrong".
    > > > But C standard further states that:

    >
    > > > If the value being converted is in the range of values that can be
    > > > represented but cannot be represented exactly, the result is either
    > > > the nearest higher or nearest lower representable value, chosen in an
    > > > *implementation-defined manner*.

    >
    > > > So the output may also be "Right! God job" ,by some other compilers
    > > > and the output is implementation dependent.
    > > > Am I right?

    >
    > > Yes. In this case even if the implementors get things right.

    >
    > > - William Hughes.- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Thanks for the reply
    > But even the following code gives "Wrong".
    >
    > int main(void)
    > {
    > float a = 0.7f;
    >
    > if(a < 0.7)
    > printf("Wrong");
    > else
    > printf("God job");
    > return 0;
    >
    > }
    >


    Unsurprisingly as a still has the value of 0.7 represented as a float
    which
    can be (and in this case is) smaller than 0.7 represented as a double.

    try

    int main(void)
    {
    float a = 0.7;

    if(a < 0.7f)
    printf("Wrong\n");
    else
    printf("Good job\n");
    return 0;

    }

    or

    int main(void)
    {
    float a = 0.7;

    if(a < (double)((float)0.7))
    printf("Wrong\n");
    else
    printf("Good job\n");
    return 0;

    }



    > I think the explanation that the declaration
    > float a = 0.7f;
    > is equivalent to
    > float a = (float)0.7;/*Conversion from double to float might truncate
    > the result*/
    > will work.
    >
    > The expression '0.7f' forces the compiler to interpret 0.7 as a float
    > directly, rather than as a double converted to float as clearly stated
    > by the standard.


    Yes, more precisely

    According to the standard 0.7f must be the float value that best
    approximates the
    real number 0.7, or the second best or the third best. (float) 0.7
    must be the
    the float value that is the nearest value higher or the nearest value
    lower to the value chosen for the double which
    represents 0.7 (again the standard allows three possible choices).

    So 0.7f does not have to equal (float)0.7 (however, Karnac is willing
    to
    bet that it does).

    >
    > So this explanation will fail.
    >
    > So an explanation as you stated above, will work.
    > That is, the float value 0.7f can (very probably) not be represented
    > exactly as a float.


    No 0.7f (approx 0.699999988 on my machine)
    is a possible float value
    so it can with certainty be represented exactly as a float.
    It is the real number 0.7 that ( very probably) can't be represented
    exactly as a float. And very probably, the float value used to
    represent the real number 0.7 (whether selected as 0.7f or as
    (float)0.7)
    will be smaller that the double value used to represent the
    real number 0.7.


    >
    > My question in this context is:
    > How this inaccurate representation complies with ANSI standards



    The ANSI standards do not impose the restriction that every
    decimal value be representable as a float and/or double
    (this is not possible using base 2) or that every double value
    be representable as a float value (this is usually not possible).
    In general the float value used to represent x can be greater
    than, less than or equal to the double value used to represent x.
    (try 0.8, 0.7 and 0.5)

    - William Hughes
    William Hughes, Mar 12, 2007
    #17
  18. Rajesh S R

    user923005 Guest

    On Mar 12, 5:49 am, "Rajesh S R" <> wrote:
    > Isn't this code violation of C99 standard?
    >
    > #include <stdio.h>
    > int main( void )
    > {
    > float a = 0.7;
    >
    > if(a < 0.7)
    > printf("Wrong");
    > else
    > printf("Right! God job");
    > return 0;
    >
    > }
    >
    > The output of the code is "wrong".
    >
    > Isnt the output violating C99 standard which states:
    >
    > *6.3.1.5 Real floating types*
    > When a float is promoted to double or long double, or a double is
    > promoted
    > to long double, its value is unchanged.
    >
    > I am using DEV-CPP (MingW32) compiler for windows.
    >
    > Thanks in advance for the reply.


    Here is a clue:

    C:\tmp>splint foo.c
    Splint 3.0.1.6 --- 11 Feb 2002

    foo.c: (in function main)
    foo.c(7,8): Dangerous comparison involving float types: a < 0.7
    Two real (float, double, or long double) values are compared
    directly using a
    C primitive. This may produce unexpected results since floating
    point
    representations are inexact. Instead, compare the difference to
    FLT_EPSILON
    or DBL_EPSILON. (Use -realcompare to inhibit warning)

    Finished checking --- 1 code warning

    For any comparison operation against floating point, we should imagine
    (at best) a sphere of uncertainty of radius (FLT_EPSILON/DBL_EPSILON/
    LDBL_EPSILON)*magnitude around the point in question (depending upon
    type). Worse if the value is far from the origin.

    It is also a mistake to imagine that we can take a double, push it
    into a float, then reconstitute it as a double and have the same value
    as the original. Clearly, that's not going to work. Once we shave
    off the precision by stuffing a double into a float, those trailing
    bits are gone -- floating off into the ether-bits.
    user923005, Mar 12, 2007
    #18
  19. Rajesh S R

    Thad Smith Guest

    Rajesh S R wrote:
    >>On 12 Mar, 16:17, "Rajesh S R" <> wrote:


    >>>... even the following code gives "Wrong".
    >>> [original code restored]
    >>>
    >>>#include <stdio.h>
    >>>int main(void)
    >>>{
    >>> float a = 0.7f;
    >>>
    >>> if(a < 0.7)
    >>> printf("Wrong");
    >>> else
    >>> printf("God job");
    >>> return 0;
    >>>}

    >
    > My question is,
    > if the inaccurate representation violates C99 standards?


    Be precise. What "inaccurate representation" are you referring to? The
    program above (after correcting for a missing header) may output either
    "Wrong" or "God job") when run with a conforming implementation, so does
    not illustrate a problem with C99, as has been explained by others.

    > I guess nothing is said about accuracy or inaccurate representation in
    > C99 standards.


    Standard C specifies the minimum accuracy for representations in
    standard floating point types. It says nothing, that I am aware of,
    concerning the accuracy of calculations. If an implementation uses
    IEEE-754, then a lot more can be said about the accuracy of
    calculations, as well as representation.
    >
    > If nothing is said about something in a C99 document, is it
    > implementation dependent?


    Yes.

    > I hope I'm clear.


    Alas, I don't know what specific inaccuracies you are questioning.

    --
    Thad
    Thad Smith, Mar 13, 2007
    #19
  20. In article <> writes:
    > On Mar 12, 3:00 pm, (Richard Tobin) wrote:
    > > In article <>,
    > >
    > > <> wrote:
    > > >I've noted that compilers (usually in some strict mode) even emit
    > > >warnings for comparing with 0.0. I have enough faith in implementors
    > > >that that seems too much of a stretch. Not to mention that there is no
    > > >other way to check for division-by-zero.

    > >
    > > Why would you want to check for division by zero? Wouldn't
    > > division-by-anything-small-enough-to-cause-overflow usually be just as
    > > bad?

    >
    > In my work, the first is inmeasurably more common than the latter.
    > Think of computing an average where there the number of summands is
    > zero.


    The number of summands is an integer, not a floating point number.
    --
    dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
    home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
    Dik T. Winter, Mar 13, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jurjen de Groot

    Re: Business rule implementation

    Jurjen de Groot, Aug 6, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    339
    Jurjen de Groot
    Aug 6, 2003
  2. Replies:
    0
    Views:
    1,336
  3. Replies:
    3
    Views:
    3,633
    Chris Torek
    Feb 20, 2006
  4. Replies:
    3
    Views:
    575
    Keith Thompson
    Mar 31, 2007
  5. , India
    Replies:
    2
    Views:
    436
    Fraser Ross
    Sep 15, 2009
Loading...

Share This Page