Violation of Conversion rule of C99.

[Rajesh S R]

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.

[Eric Sosman]

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
es*****@acm-dot-org.invalid

[William Hughes]

On Mar 12, 7:49 am, "Rajesh S R" <[e-mail]:

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

[Rajesh S R]

On Mar 12, 5:56 pm, Eric Sosman <[e-mail]:

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
[e-mail]- 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?

[William Hughes]

On Mar 12, 8:15 am, "Rajesh S R" <[e-mail]:

On Mar 12, 5:56 pm, Eric Sosman <[e-mail]:

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
[e-mail]- 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.

[Richard Tobin]

In article <11**********************@v33g2000cwv.googlegroups .com>,
Rajesh S R <SR**********@gmail.comwrote:

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.

[micans]

On Mar 12, 1:08 pm, "William Hughes" <[e-mail]:

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

[Richard Tobin]

In article <11**********************@j27g2000cwj.googlegroups .com>,
<mi****@gmail.comwrote:

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

[micans]

On Mar 12, 3:00 pm, [e-mail] (Richard Tobin) wrote:

In article <[e-mail] .com>,

<[e-mail]:

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

[micans]

On Mar 12, 3:07 pm, [e-mail] wrote:

On Mar 12, 3:00 pm, [e-mail] (Richard Tobin) wrote:

In article <[e-mail] .com>,

<[e-mail]:

>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

[micans]

On Mar 12, 3:00 pm, [e-mail] (Richard Tobin) wrote:

In article <[e-mail] .com>,

<[e-mail]:

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

[Rajesh S R]

On Mar 12, 6:33 pm, "William Hughes" <[e-mail]:

On Mar 12, 8:15 am, "Rajesh S R" <[e-mail]:

On Mar 12, 5:56 pm, Eric Sosman <[e-mail]:

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
[e-mail]- 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.

[Richard Tobin]

In article <11*********************@s48g2000cws.googlegroups. com>,
<mi****@gmail.comwrote:

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

[mark_bluemel]

On 12 Mar, 16:17, "Rajesh S R" <[e-mail]:
....

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

[Mark McIntyre]

On 12 Mar 2007 09:17:13 -0700, in comp.lang.c , "Rajesh S R"
<SR**********@gmail.comwrote:

>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

[Rajesh S R]

On Mar 12, 9:49 pm, [e-mail] wrote:

On 12 Mar, 16:17, "Rajesh S R" <[e-mail]:
...

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

[William Hughes]

On Mar 12, 11:17 am, "Rajesh S R" <[e-mail]:

On Mar 12, 6:33 pm, "William Hughes" <[e-mail]:

On Mar 12, 8:15 am, "Rajesh S R" <[e-mail]:

On Mar 12, 5:56 pm, Eric Sosman <[e-mail]:

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
[e-mail]- 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

[user923005]

On Mar 12, 5:49 am, "Rajesh S R" <[e-mail]:

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.

[Thad Smith]

Rajesh S R wrote:

>>On 12 Mar, 16:17, "Rajesh S R" <[e-mail]:

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

[Dik T. Winter]

In article <11*********************@s48g2000cws.googlegroups. commi****@gmail.com writes:

On Mar 12, 3:00 pm, [e-mail] (Richard Tobin) wrote:

In article <[e-mail] .com>,

<[e-mail]:

>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, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[William Hughes]

On Mar 12, 9:50 am, [e-mail] wrote:

On Mar 12, 1:08 pm, "William Hughes" <[e-mail]:

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.

Well, there is no easy way to tell if a comparison with zero
is to avoid an exception (e.g. divide by 0) or
an implicit equality comparison (f1-f2)==0.
Still, a warning that warns agains a needed construct
with no good altenate form is (to say the least)
questionable.

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

It is always safe. It may even make sense at times. Although
not guaranteed, you can expect integers to be exaclty represented
and exactly converted. So

if( (float)1 == 1.0 )

will probably do what you expect. It is still however stupid.

The more likely case is

a: if ( f1 == 1.0 )

This is (probably) equivalent to

b: if( (floor(f1) == 1.0) && (ceil(f1) == 1.0))

If you know enough about f1 to know that b will work then
you can use a. If you do not know that b will work then you do not
know that
a will work.
- William Hughes

[Richard Bos]

"William Hughes" <wp*******@hotmail.comwrote:

On Mar 12, 9:50 am, [e-mail] wrote:

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

It is always safe. It may even make sense at times. Although
not guaranteed, you can expect integers to be exaclty represented
and exactly converted. So

if( (float)1 == 1.0 )

will probably do what you expect. It is still however stupid.

Actually, it must. See FLT_DIG in <float.h>.

The more likely case is

a: if ( f1 == 1.0 )

This is (probably) equivalent to

b: if( (floor(f1) == 1.0) && (ceil(f1) == 1.0))

Yes, in the sense that if f1 is very close to 1.0, it will probably
compare equal to 1.0. No, in the sense that if f1 was last set to 1, it
must still compare equal to 1.0, with no probably about it.

Richard

[William Hughes]

On Mar 13, 10:56 am, [e-mail] (Richard Bos) wrote:

"William Hughes" <[e-mail]:

On Mar 12, 9:50 am, [e-mail] wrote:

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

It is always safe. It may even make sense at times. Although
not guaranteed, you can expect integers to be exaclty represented
and exactly converted. So

if( (float)1 == 1.0 )

will probably do what you expect. It is still however stupid.

Actually, it must. See FLT_DIG in <float.h>.

If (and this is indeed unlikely) the floating point system does not
have exact representations for integers, then I cannot see why
the cast to float of the integer 1 should have to equal the double
constant 1.0.
Or does the standard mandate exact representations for integers?

The more likely case is

a: if ( f1 == 1.0 )

This is (probably) equivalent to

b: if( (floor(f1) == 1.0) && (ceil(f1) == 1.0))

Yes, in the sense that if f1 is very close to 1.0, it will probably
compare equal to 1.0. No, in the sense that if f1 was last set to 1, it
must still compare equal to 1.0, with no probably about it.

The question is not "when will f1 compare equal to 1.0?", but "when
is a equivalent to b?". Assume that 1.0 is accurately represented,
but floor(1.0) and ceil(1.0) both return values very slightly greater
than
1.0 (very poor QOI but the standard does not set accuracy limits on
library functions).
- William Hughes

[Richard Bos]

"William Hughes" <wp*******@hotmail.comwrote:

On Mar 13, 10:56 am, [e-mail] (Richard Bos) wrote:

"William Hughes" <[e-mail]:

On Mar 12, 9:50 am, [e-mail] wrote:
I also think it will be generally safe to compare with 1.0
(based on typical floating point implementations).

It is always safe. It may even make sense at times. Although
not guaranteed, you can expect integers to be exaclty represented
and exactly converted. So

if( (float)1 == 1.0 )

will probably do what you expect. It is still however stupid.

Actually, it must. See FLT_DIG in <float.h>.

If (and this is indeed unlikely) the floating point system does not
have exact representations for integers, then

....it is not a C implementation.

Or does the standard mandate exact representations for integers?

See the explanation of FLT_DIG in the Standard.

Richard

[William Hughes]

On Mar 14, 9:27 am, [e-mail] (Richard Bos) wrote:

"William Hughes" <[e-mail]:

On Mar 13, 10:56 am, [e-mail] (Richard Bos) wrote:

"William Hughes" <[e-mail]:
On Mar 12, 9:50 am, [e-mail] wrote:
I also think it will be generally safe to compare with 1.0
(based on typical floating point implementations).

It is always safe. It may even make sense at times. Although
not guaranteed, you can expect integers to be exaclty represented
and exactly converted. So

if( (float)1 == 1.0 )

will probably do what you expect. It is still however stupid.

Actually, it must. See FLT_DIG in <float.h>.

If (and this is indeed unlikely) the floating point system does not
have exact representations for integers, then

...it is not a C implementation.

Or does the standard mandate exact representations for integers?

See the explanation of FLT_DIG in the Standard.

Are you referring to
number of decimal digits, q, such that any floating-
point number with q decimal digits can be rounded into
a floating-point number with p radix b digits and back
again without change to the q decimal digits,

plog10b if b is a power of 10

|(p-1)log10b|otherwise

FLT_DIG 6
This certainly requires invertability, so there must be a float
value,x, which represents the real number 1.0. Futhermore
1.0 must "round" to this value. Also there must be a double value,
y,
which represents, 1.0 and 1.0 must "round" to this number. However,
I do not see why we need to assume that x is equal to y is equal to
1.0 unless we read the standard to insist that the floating point
numbers must be fixed point with respect to some base.
This would certainly seem to be implied by:

The characteristics of floating types are defined in
terms of a model that describes a representation of
floating-point numbers and values that provide information
about an implementation's floating-point arithmetic.14) The
following parameters are used to define the model for each
floating-point type:

s sign (1)
b base or radix of exponent representation (integer 1)
e exponent (integer between a min emin and a max emax)
p precision (number of base-b digits in the significand)
fk nonnegative integers less than b (significand digits)

But

The floating-point model is intended to clarify the
description of each floating-point characteristic and
does not require the floating-point arithmetic of the
implementation to be identical.

might be interpreted in such a way as to give a perverse
implementation
wiggle room.

- William Hughes