Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #5815 > unrolled thread

implicit promotion

Back to article view | Back to comp.lang.c++

Contents

  implicit promotion Ruben Safir <ruben@mrbrklyn.com> - 2011-05-30 01:44 +0000
    Re: implicit promotion red floyd <no.spam.here@its.invalid> - 2011-05-29 20:35 -0700
      Re: implicit promotion ruben safir <ruben@mrbrklyn.com> - 2011-05-30 00:01 -0400
        Re: implicit promotion Ian Collins <ian-news@hotmail.com> - 2011-05-30 16:08 +1200
          Re: implicit promotion Paavo Helde <myfirstname@osa.pri.ee> - 2011-05-30 01:18 -0500
            Re: implicit promotion Juha Nieminen <nospam@thanks.invalid> - 2011-05-30 11:45 +0000
              Re: implicit promotion Öö Tiib <ootiib@hot.ee> - 2011-05-30 05:49 -0700
                Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 08:58 -1000
                  Re: implicit promotion Öö Tiib <ootiib@hot.ee> - 2011-05-30 12:01 -0700
                    Re: implicit promotion Öö Tiib <ootiib@hot.ee> - 2011-05-30 12:07 -0700
                    Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 09:07 -1000
                      Re: implicit promotion Öö Tiib <ootiib@hot.ee> - 2011-05-30 12:13 -0700
                        Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 09:27 -1000
              Re: implicit promotion Paavo Helde <myfirstname@osa.pri.ee> - 2011-05-30 10:17 -0500
                Re: implicit promotion Juha Nieminen <nospam@thanks.invalid> - 2011-05-30 18:20 +0000
                  Re: implicit promotion Paavo Helde <myfirstname@osa.pri.ee> - 2011-05-30 14:06 -0500
                    Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 09:23 -1000
                      Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 09:29 -1000
                      Re: implicit promotion Ruben Safir <ruben@mrbrklyn.com> - 2011-05-31 01:24 +0000
                        Re: implicit promotion Ian Collins <ian-news@hotmail.com> - 2011-05-31 13:30 +1200
                          Re: implicit promotion ruben safir <ruben@mrbrklyn.com> - 2011-05-31 00:52 -0400
                        Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 17:36 -1000
                Re: implicit promotion Öö Tiib <ootiib@hot.ee> - 2011-05-30 11:39 -0700
                  Re: implicit promotion Pete Becker <pete@versatilecoding.com> - 2011-05-30 09:02 -1000

Page 1 of 2  [1] 2  Next page →

#5815 — implicit promotion

I feel like an idiot asking this, but why does this need a cast


float tot = (float)sum/(float)(tally->size());


Ruben

[toc] | [next] | [standalone]

#5816

On 5/29/2011 6:44 PM, Ruben Safir wrote:
> I feel like an idiot asking this, but why does this need a cast
>
>
> float tot = (float)sum/(float)(tally->size());
>
>

Depends.  What type is sum?  What is the return type of
tally->size()?

[toc] | [prev] | [next] | [standalone]

#5817

On 05/29/2011 11:35 PM, red floyd wrote:
> On 5/29/2011 6:44 PM, Ruben Safir wrote:
>> I feel like an idiot asking this, but why does this need a cast
>>
>>
>> float tot = (float)sum/(float)(tally->size());
>>
>>
>
> Depends. What type is sum? What is the return type of
> tally->size()?
>
>
ints

[toc] | [prev] | [next] | [standalone]

#5818

On 05/30/11 04:01 PM, ruben safir wrote:
> On 05/29/2011 11:35 PM, red floyd wrote:
>> On 5/29/2011 6:44 PM, Ruben Safir wrote:
>>> I feel like an idiot asking this, but why does this need a cast
>>>
>>>
>>> float tot = (float)sum/(float)(tally->size());
>>>
>>>
>>
>> Depends. What type is sum? What is the return type of
>> tally->size()?
>>
>>
> ints

An int divided by an int is an int, not a float.

so if you wrote

float tot = sum/tally->size();

and sum == 3, tally->size() == 2, tot would be 1.

If you write

float tot = (float)sum/tally->size();

you then have a float divided by an int, 1.5.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#5820

Ian Collins <ian-news@hotmail.com> wrote in news:94gjh4Fr2iU9
@mid.individual.net:

> On 05/30/11 04:01 PM, ruben safir wrote:
>> On 05/29/2011 11:35 PM, red floyd wrote:
>>> On 5/29/2011 6:44 PM, Ruben Safir wrote:
>>>> I feel like an idiot asking this, but why does this need a cast
>>>>
>>>>
>>>> float tot = (float)sum/(float)(tally->size());
>>>>
>>>>
>>>
>>> Depends. What type is sum? What is the return type of
>>> tally->size()?
>>>
>>>
>> ints
> 
> An int divided by an int is an int, not a float.
> 
> so if you wrote
> 
> float tot = sum/tally->size();
> 
> and sum == 3, tally->size() == 2, tot would be 1.
> 
> If you write
> 
> float tot = (float)sum/tally->size();
> 
> you then have a float divided by an int, 1.5.


Yes, for getting floating-point division one needs to cast only one 
operand to a floating-point type, the other would be cast to the type of 
the first automatically. In the original line from OP both operands were 
cast, possibly because the original author liked symmetry or clarity.

hth
Paavo

[toc] | [prev] | [next] | [standalone]

#5828

Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> If you write
>> 
>> float tot = (float)sum/tally->size();
>> 
>> you then have a float divided by an int, 1.5.
> 
> 
> Yes, for getting floating-point division one needs to cast only one 
> operand to a floating-point type, the other would be cast to the type of 
> the first automatically. In the original line from OP both operands were 
> cast, possibly because the original author liked symmetry or clarity.

  Actually, if a float is divided by an int, aren't both of them cast
to double first? (Not that it probably makes any difference in practice,
but just pointing out.)

[toc] | [prev] | [next] | [standalone]

#5829

On May 30, 2:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >> If you write
>
> >> float tot = (float)sum/tally->size();
>
> >> you then have a float divided by an int, 1.5.
>
> > Yes, for getting floating-point division one needs to cast only one
> > operand to a floating-point type, the other would be cast to the type of
> > the first automatically. In the original line from OP both operands were
> > cast, possibly because the original author liked symmetry or clarity.
>
>   Actually, if a float is divided by an int, aren't both of them cast
> to double first? (Not that it probably makes any difference in practice,
> but just pointing out.)

Most things about floating point arithmetics is implementation defined
so what really happens depends on platform and compiler. I have here a
static analysis tool that (if to check for portability then) warns
even on unary minus applied to floating literal that some floating
point arithmetic is going on. :D

[toc] | [prev] | [next] | [standalone]

#5836

On 2011-05-30 02:49:08 -1000, Öö Tiib said:

> On May 30, 2:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>> If you write
>> 
>>>> float tot = (float)sum/tally->size();
>> 
>>>> you then have a float divided by an int, 1.5.
>> 
>>> Yes, for getting floating-point division one needs to cast only one
>>> operand to a floating-point type, the other would be cast to the type of
>>> the first automatically. In the original line from OP both operands were
>>> cast, possibly because the original author liked symmetry or clarity.
>> 
>>   Actually, if a float is divided by an int, aren't both of them cast
>> to double first? (Not that it probably makes any difference in practice,
>> but just pointing out.)
> 
> Most things about floating point arithmetics is implementation defined
> so what really happens depends on platform and compiler.

Not here. Read about "usual arithmetic conversions". If one argument is 
float and the other is int, the int is converted to float.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

[toc] | [prev] | [next] | [standalone]

#5838

On May 30, 9:58 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2011-05-30 02:49:08 -1000, Öö Tiib said:
>
>
>
>
>
> > On May 30, 2:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >>>> If you write
>
> >>>> float tot = (float)sum/tally->size();
>
> >>>> you then have a float divided by an int, 1.5.
>
> >>> Yes, for getting floating-point division one needs to cast only one
> >>> operand to a floating-point type, the other would be cast to the type of
> >>> the first automatically. In the original line from OP both operands were
> >>> cast, possibly because the original author liked symmetry or clarity.
>
> >>   Actually, if a float is divided by an int, aren't both of them cast
> >> to double first? (Not that it probably makes any difference in practice,
> >> but just pointing out.)
>
> > Most things about floating point arithmetics is implementation defined
> > so what really happens depends on platform and compiler.
>
> Not here. Read about "usual arithmetic conversions". If one argument is
> float and the other is int, the int is converted to float.

Or into something bigger and more precise if implementation wants. Or
that is how i read the 5/10 in "usual arithmetic conversions".

[toc] | [prev] | [next] | [standalone]

#5841

On May 30, 10:01 pm, Öö Tiib <oot...@hot.ee> wrote:
>
> Or into something bigger and more precise if implementation wants. Or
> that is how i read the 5/10 in "usual arithmetic conversions".

I meant under the "usual arithmetic conversions" that are 5/9.

[toc] | [prev] | [next] | [standalone]

#5842

On 2011-05-30 09:01:48 -1000, Öö Tiib said:

> On May 30, 9:58 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2011-05-30 02:49:08 -1000, Öö Tiib said:
>> 
>> 
>> 
>> 
>> 
>>> On May 30, 2:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>>>> Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>>>> If you write
>> 
>>>>>> float tot = (float)sum/tally->size();
>> 
>>>>>> you then have a float divided by an int, 1.5.
>> 
>>>>> Yes, for getting floating-point division one needs to cast only one
>>>>> operand to a floating-point type, the other would be cast to the type of
>>>>> the first automatically. In the original line from OP both operands were
>>>>> cast, possibly because the original author liked symmetry or clarity.
>> 
>>>>   Actually, if a float is divided by an int, aren't both of them cast
>>>> to double first? (Not that it probably makes any difference in practice,
>>>> but just pointing out.)
>> 
>>> Most things about floating point arithmetics is implementation defined
>>> so what really happens depends on platform and compiler.
>> 
>> Not here. Read about "usual arithmetic conversions". If one argument is
>> float and the other is int, the int is converted to float.
> 
> Or into something bigger and more precise if implementation wants. Or
> that is how i read the 5/10 in "usual arithmetic conversions".

No, the type of the result is float. There is general license to do 
floating-point math at higher precision, but that doesn't affect the 
type of the result.

void f(float);
void f(double);

f(1.0f/3);	// calls f(float)

The relevant wording is [emphasis added]:

	Otherwise, if either operand is float, the other *shall be* converted 
to float.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

[toc] | [prev] | [next] | [standalone]

#5843

On May 30, 10:07 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2011-05-30 09:01:48 -1000, Öö Tiib said:
>
>
>
>
>
> > On May 30, 9:58 pm, Pete Becker <p...@versatilecoding.com> wrote:
> >> On 2011-05-30 02:49:08 -1000, Öö Tiib said:
>
> >>> On May 30, 2:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >>>> Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >>>>>> If you write
>
> >>>>>> float tot = (float)sum/tally->size();
>
> >>>>>> you then have a float divided by an int, 1.5.
>
> >>>>> Yes, for getting floating-point division one needs to cast only one
> >>>>> operand to a floating-point type, the other would be cast to the type of
> >>>>> the first automatically. In the original line from OP both operands were
> >>>>> cast, possibly because the original author liked symmetry or clarity.
>
> >>>>   Actually, if a float is divided by an int, aren't both of them cast
> >>>> to double first? (Not that it probably makes any difference in practice,
> >>>> but just pointing out.)
>
> >>> Most things about floating point arithmetics is implementation defined
> >>> so what really happens depends on platform and compiler.
>
> >> Not here. Read about "usual arithmetic conversions". If one argument is
> >> float and the other is int, the int is converted to float.
>
> > Or into something bigger and more precise if implementation wants. Or
> > that is how i read the 5/10 in "usual arithmetic conversions".
>
> No, the type of the result is float. There is general license to do
> floating-point math at higher precision, but that doesn't affect the
> type of the result.
>
> void f(float);
> void f(double);
>
> f(1.0f/3);      // calls f(float)

Certainly. That is what Juha asked as i understood above:
Both the 1.0f and 3 may be casted to double and result may be casted
back to float for passing to f(float).

[toc] | [prev] | [next] | [standalone]

#5845

On 2011-05-30 09:13:08 -1000, Öö Tiib said:

> On May 30, 10:07 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2011-05-30 09:01:48 -1000, Öö Tiib said:
>> 
>> 
>> 
>> 
>> 
>>> On May 30, 9:58 pm, Pete Becker <p...@versatilecoding.com> wrote:
>>>> On 2011-05-30 02:49:08 -1000, Öö Tiib said:
>> 
>>>>> On May 30, 2:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>>>>>> Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>>>>>> If you write
>> 
>>>>>>>> float tot = (float)sum/tally->size();
>> 
>>>>>>>> you then have a float divided by an int, 1.5.
>> 
>>>>>>> Yes, for getting floating-point division one needs to cast only one
>>>>>>> operand to a floating-point type, the other would be cast to the type of
>>>>>>> the first automatically. In the original line from OP both operands were
>>>>>>> cast, possibly because the original author liked symmetry or clarity.
>> 
>>>>>>   Actually, if a float is divided by an int, aren't both of them cast
>>>>>> to double first? (Not that it probably makes any difference in practice,
>>>>>> but just pointing out.)
>> 
>>>>> Most things about floating point arithmetics is implementation defined
>>>>> so what really happens depends on platform and compiler.
>> 
>>>> Not here. Read about "usual arithmetic conversions". If one argument is
>>>> float and the other is int, the int is converted to float.
>> 
>>> Or into something bigger and more precise if implementation wants. Or
>>> that is how i read the 5/10 in "usual arithmetic conversions".
>> 
>> No, the type of the result is float. There is general license to do
>> floating-point math at higher precision, but that doesn't affect the
>> type of the result.
>> 
>> void f(float);
>> void f(double);
>> 
>> f(1.0f/3);      // calls f(float)
> 
> Certainly. That is what Juha asked as i understood above:
> Both the 1.0f and 3 may be casted to double and result may be casted
> back to float for passing to f(float).

There are no casts involved. There may be conversions, but that's all 
internal; there is no requirement that conversions be limited to the 
same representation as float, double, or long double. But unless you're 
a serious number cruncher, this is just a distraction. 1.0f/3 has type 
float. How it gets there is irrelevant.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

[toc] | [prev] | [next] | [standalone]

#5831

Juha Nieminen <nospam@thanks.invalid> wrote in
news:4de3835d$0$2833$7b1e8fa0@news.nbl.fi: 

> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> If you write
>>> 
>>> float tot = (float)sum/tally->size();
>>> 
>>> you then have a float divided by an int, 1.5.
>> 
>> 
>> Yes, for getting floating-point division one needs to cast only one 
>> operand to a floating-point type, the other would be cast to the type
>> of the first automatically. In the original line from OP both
>> operands were cast, possibly because the original author liked
>> symmetry or clarity. 
> 
>   Actually, if a float is divided by an int, aren't both of them cast
> to double first? (Not that it probably makes any difference in
> practice, but just pointing out.)

As far as I can see from 5/9, no, float-int are converted to float-float. 
There is a thingie called "floating-point promotion" which promotes to 
double, but this is not mentioned in this section (unlike integral 
promotion) and seems to be used only for converting floats passed as 
va_arg arguments.

cheers
Paavo
 

[toc] | [prev] | [next] | [standalone]

#5834

Paavo Helde <myfirstname@osa.pri.ee> wrote:
> As far as I can see from 5/9, no, float-int are converted to float-float. 

  Isn't that bad? An int might not be representable as a float, even though
it may be as a double. The result of the division may be representable
with a float even though the int might not.

[toc] | [prev] | [next] | [standalone]

#5840

Juha Nieminen <nospam@thanks.invalid> wrote in
news:4de3dfee$0$2848$7b1e8fa0@news.nbl.fi: 

> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> As far as I can see from 5/9, no, float-int are converted to
>> float-float. 
> 
>   Isn't that bad? An int might not be representable as a float, even
>   though 
> it may be as a double. The result of the division may be representable
> with a float even though the int might not.
> 

An int is quite surely representable as a float, up to some precision. 

In principle, when you have a symmetric operation involving two 
fractional numbers, then it does not pay off to have one operand 
specified much more precisely than the other. The idea is that floating-
point numbers are used as an approximation of physical quantitities or 
mathematical real numbers, so if one such number is approximated as a 
float, this means a significant portion of information loss which cannot 
be recovered however precisely the other operand is represented. In this 
sense there is nothing wrong with the compiler converting an float-int 
operation to float-float.

(Here is a hidden assumption that having more precision will cause some 
penalty. If using higher precision would not cost anything at all, then 
it would not harm to use it.)


Integer numbers are quite another realm however and in some cases as the 
int-int division in the OP-s example, doubles would probably be indeed 
better choice. But this is the responsibility of the programmer to decide 
how to convert ints to floating-point numbers; it was a programmer who 
wrote the explicit float cast there, wasn't it?

cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#5844

On 2011-05-30 09:06:28 -1000, Paavo Helde said:

> Juha Nieminen <nospam@thanks.invalid> wrote in
> news:4de3dfee$0$2848$7b1e8fa0@news.nbl.fi:
> 
>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>>> As far as I can see from 5/9, no, float-int are converted to
>>> float-float.
>> 
>> Isn't that bad? An int might not be representable as a float, even
>> though
>> it may be as a double. The result of the division may be representable
>> with a float even though the int might not.
>> 
> 
> An int is quite surely representable as a float, up to some precision.

Well, yes, up to some precision. But it's often the case that the 
largest value that can be represented as an int cannot be represented 
exactly as a float. 32-bit ints and 32-bit doubles, for example.

In any case, the problem here is one of my favorite rants: programmers 
aren't taught how floating-point math works, so they end up treating it 
as magic. Nobody's bothered by 3*(1/3) not being 1, but somehow there's 
a perception that there's something unsavory about 10*(1.0/10.0) not 
having to be 1, even though it's exactly the same issue.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

[toc] | [prev] | [next] | [standalone]

#5846

On 2011-05-30 09:23:52 -1000, Pete Becker said:

> 
> Well, yes, up to some precision. But it's often the case that the 
> largest value that can be represented as an int cannot be represented 
> exactly as a float. 32-bit ints and 32-bit doubles, for example.
> 

Whoops, should have been: "32-bit ints and 32-bit floats, for example."

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

[toc] | [prev] | [next] | [standalone]

#5859

On Mon, 30 May 2011 09:23:52 -1000, Pete Becker wrote:

> Nobody's bothered by 3*(1/3) not being 1, but somehow there's a
> perception that there's something unsavory about 10*(1.0/10.0) not
> having to be 1, even though it's exactly the same issue.

These are both huge problems that really shouldn't happen.  It's crazy.
You have to do 3 *(1.0f/3.0f) in order to get a mathmatically valid 
calculation that a standard calculator does.

Just nuts...

[toc] | [prev] | [next] | [standalone]

#5860

On 05/31/11 01:24 PM, Ruben Safir wrote:
> On Mon, 30 May 2011 09:23:52 -1000, Pete Becker wrote:
>
>> Nobody's bothered by 3*(1/3) not being 1, but somehow there's a
>> perception that there's something unsavory about 10*(1.0/10.0) not
>> having to be 1, even though it's exactly the same issue.
>
> These are both huge problems that really shouldn't happen.  It's crazy.
> You have to do 3 *(1.0f/3.0f) in order to get a mathmatically valid
> calculation that a standard calculator does.

Why is it crazy?  Integer arithmetic is well defined.  Would you have 
the language magically assume you wanted a floating point result?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web