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 2 of 2 — ← Prev page 1 [2]

#5884

On 05/30/2011 09:30 PM, Ian Collins wrote:
>> 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?


somehow i knew that would have been the answer

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

#5869

On 2011-05-30 15:24:13 -1000, Ruben Safir said:

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

Actually, the "standard calculator" is lying to you. It didn't get 1.0, 
but it rounded the value to display it. Try subtracting 1.0 from that 
result.

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

#5835

On May 30, 6:17 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Juha Nieminen <nos...@thanks.invalid> wrote innews:4de3835d$0$2833$7b1e8fa0@news.nbl.fi:
>
>
>
>
>
> > 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.)
>
> 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.

My confusion is about the 5/10:
 The values of the floating operands and 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.

I read that the implementation may use double or long double under the
hood whereonly it wants in floating point arithmetics as long it
pretends that things still are "float" to the developer.

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

#5839

On 2011-05-30 08:39:59 -1000, Öö Tiib said:

> On May 30, 6:17 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> Juha Nieminen <nos...@thanks.invalid> wrote 
>> innews:4de3835d$0$2833$7b1e8fa0@news.nbl.fi:
>> 
>> 
>> 
>> 
>> 
>>> 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.)
>> 
>> 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.
> 
> My confusion is about the 5/10:
>  The values of the floating operands and 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.
> 
> I read that the implementation may use double or long double under the
> hood whereonly it wants in floating point arithmetics as long it
> pretends that things still are "float" to the developer.

That allows things like the Intel math processor, which does all 
floating-point  math with 80-bit values (unless you turn this off, 
which makes it much slower), then converts them to the target type 
(32-bit float, 64-bit double). But that affects the value of the result 
(down in the noise bits), not its type.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web