Re: Floating point to integer casting
- From: "Morris Keesan" <mkeesan@xxxxxxxxxxxxxxxx>
- Date: Mon, 12 Oct 2009 20:20:39 -0400
On Mon, 12 Oct 2009 19:42:49 -0400, bartc <bartc@xxxxxxxxxx> wrote:
chad wrote:On Oct 12, 10:32 am, Tim Rentsch <t...@xxxxxxxxxxxxxxxxxx> wrote:Anand Hariharan <mailto.anand.hariha...@xxxxxxxxx> writes:On Oct 12, 5:36 am, Tim Rentsch <t...@xxxxxxxxxxxxxxxxxx> wrote:"bartc" <ba...@xxxxxxxxxx> writes:"Tim Rentsch" <t...@xxxxxxxxxxxxxxxxxx> wrote in message
A minor point -- assignment _always_ performs a conversion,
whether the types of the two sides are the same or different.
So what conversion is performed when assigning an int value to an
int destination of the same width?
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
6.5.16.1
6.3
Is there any context where this subtlety (viz., "conversion" is
performed even when the types of the operands on either side of = is
the same) is important? If so, is it important to the implementor or
even to the programmer? How/Why?
Yes there is, when floating-point types are involved.
Conversions in such cases are required to discard extra
precision and range (see 6.3.1.5p2). For example, in
double a, b, c;
...
a = b + c;
the plus operation can be computed in greater precision than
(double), but upon being assigned the value must be squeezed
back into a (double) again. For developers, this can matter
when deciding when to simplify expressions. For example:
Okay, I'm going to take the bait here. How can the plus operation be
computed with greater precision than double?
(Example)
Some floating point hardware works internally using 80-bits, when the precision of double is 64-bits, which can lead to inconsistencies when intermediate 80-bit results are written to memory as 64-bits then loaded again, compared with keeping the intermediate values in the registers.
I was going to say that the expression b + c has type (double), but after
looking in the standard for confirmation of this, I'm confused:
6.3.1.8 Usual arithmetic conversions
"Unless explicitly stated otherwise, the common real type is also
the corresponding real type of the result"
[so the result of b + c would have type double -- MK]
but I'm confused by paragraph 2 and its footnote, which say
"The values of floating operands and of the results of floating
expressions may be represented in greater precision and range
than that required by the type; the types are not changed thereby. 52)"
and "52) The cast and assignment operators are still required to perform
their specified conversions as described in 6.3.1.4 and 6.3.1.5."
What's meant by this? If "the types are not changed thereby", does this
mean that (b + c) has type double, or not? And if the type is not changed,
what conversion would be necessary to do the assignment to a?
Furthermore, if the result of a floating expression can be "represented
in greater precision and range" than that required, what does this say
about sizeof(b + c)? What can we predict about the value of the expression
sizeof(b + c) == sizeof(double)
in conforming implementations? Can a strictly conforming program rely on
this having the value 1?
Or is this "greater range and precision" clause merely giving implementations
permission to represent intermediate results in ways that could give
different results for more complicated floating expressions, e.g. potentially
giving different results for
((double)(b + c)) - ((double)(e * f))
vs.
(b + c) - (e * f)
where b, c, e, and f are all doubles?
--
Morris Keesan -- mkeesan@xxxxxxxxxxxxxxxx
.
- Follow-Ups:
- Re: Floating point to integer casting
- From: Phil Carmody
- Re: Floating point to integer casting
- From: Tim Rentsch
- Re: Floating point to integer casting
- References:
- Floating point to integer casting
- From: Albert
- Re: Floating point to integer casting
- From: Richard Heathfield
- Re: Floating point to integer casting
- From: Tim Rentsch
- Re: Floating point to integer casting
- From: bartc
- Re: Floating point to integer casting
- From: Tim Rentsch
- Re: Floating point to integer casting
- From: Anand Hariharan
- Re: Floating point to integer casting
- From: Tim Rentsch
- Re: Floating point to integer casting
- From: chad
- Re: Floating point to integer casting
- From: bartc
- Floating point to integer casting
- Prev by Date: Re: Floating point to integer casting
- Next by Date: Re: Little help with free()
- Previous by thread: Re: Floating point to integer casting
- Next by thread: Re: Floating point to integer casting
- Index(es):
Relevant Pages
|