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


Groups > comp.lang.c++ > #84185

Re: C++ (and some C) quiz questions

Path csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.lang.c++
Subject Re: C++ (and some C) quiz questions
Date Thu, 19 May 2022 08:21:39 -0700
Organization A noiseless patient Spider
Lines 117
Message-ID <86y1yx1rb0.fsf@linuxsc.com> (permalink)
References <t5tc3s$164p$1@gioia.aioe.org> <t5u3kb$h0k$1@dont-email.me> <t5u6es$a95$1@dont-email.me> <t5u6uh$e6l$1@dont-email.me> <t5v928$1h9n$1@gioia.aioe.org> <87czgcqxgc.fsf@bsb.me.uk> <86o7zw2x55.fsf@linuxsc.com> <t61tbu$1dmq$1@gioia.aioe.org> <t62lbd$12vc$1@gioia.aioe.org> <8635h72bap.fsf@linuxsc.com> <t630am$4kh$1@dont-email.me>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Injection-Info reader02.eternal-september.org; posting-host="2a3388073214779a12c7a9c38773b260"; logging-data="13168"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/w2PsY8upvXMzjrc6fUR24S0NZJXWrOCA="
User-Agent Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock sha1:6mjX/kN7/6iUWCYETGp/D89UF6I= sha1:RM8/5hLrHbmA+G4TcjsX1aCHk10=
Xref csiph.com comp.lang.c++:84185

Show key headers only | View raw


Paavo Helde <eesnimi@osa.pri.ee> writes:

> 18.05.2022 16:57 Tim Rentsch kirjutas:
>
>> Manfred <noname@add.invalid> writes:
>>
>>> On 5/18/2022 6:40 AM, Juha Nieminen wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>
>>>>> But that doesn't change the problem of potential loss of
>>>>> precision, because the representation (and hence the particular
>>>>> value) of the constant 0.1 is chosen before that value is
>>>>> converted to long double.  The constant 0.1, being of type
>>>>> double, doesn't have to have less precision than 0.1L, but
>>>>> certainly it can.
>>>>
>>>> AFAIK no C/C++ compiler will second-guess the programmer and assume that
>>>> the literal was meant to be a long double literal.  If you specify a
>>>> literal of type double, the compiler will assume you meant it (and will
>>>> just convert it to double without adding any precision to the resulting
>>>> value.)
>>>>
>>>> With double vs. long double the loss in precision isn't extremely
>>>> drastic (although in some calculations it could accumulate to significant
>>>> proportions).  However, people often make the mistake when they are using
>>>> some third-party multiple-precision libraries that support floating point
>>>> values of arbitrary size.  If you are calculating with eg. 1024-bit
>>>> floating point, make sure you initialize them properly (ie. do not
>>>> initialize such a value with eg. the literal 0.1).
>>>
>>> I believe Tim was referring to the fact that the standard does not
>>> mandate for long double to have more precision than double.
>>
>> That is one possibility, but I didn't mean just that.
>>
>> Here is the original context:
>>
>>      long double value = 0.1;
>>
>> I'm not sure what C++ allows or doesn't allow for the value of
>> the literal 0.1.
>>
>> For C, my understanding is that the current C standard allows the
>> constant 0.1 to be represented in the format, and precision, of a
>> long double even though its type is double.  (The rules for
>> floating constants in C has changed over time so I'm not sure if
>> that allowance might be different for earlier C standards.)
>>
>> The next C standard apparently will be explicit on this point -
>> in the n2731 draft of the C standard, section 6.4.4.2 paragraph 6
>> says this in part:
>>
>>      The values of floating constants may be represented in
>>      greater range and precision than that required by the type
>>      (determined by the suffix);  the types are not changed
>>      thereby.
>
> Doesn't it just mean that in the program code, one can write the
> literal with more precision than needed, just in case the type may
> have more precision in another or future implementation?
>
> const double pi = 3.141592653589793238462643383279502884197;

The short answer to this question is no.  That seems obvious to
me, but let me try to give a more complete explanation.

When talking about floating point, the C standard uses the terms
range and precision in relation to aspects of elements in the
abstract machine.  (There are separate notions of "precision"
that pertain to integer types or to the *printf() functions, but
these uses do not concern us here.)

In contrast, a floating constant occurs in program source and is
just a sequence of characters.  A floating constant has a source
form but does not have a range or precision, as the C standard
uses those terms.

The word "type" is used both to mean a compile-time notion that
is manipulated during compilation and to describe an internal
format that occurs inside the abstract machine at run time.  In
many cases these two notions are used interchangeably, but they
aren't quite the same, and pointedly so in the case of floating
point.  For example, in n1570 (a C11 draft), 6.3.1.8 paragraph 2
says this:

    The values of floating operands and of the results of
    floating expressions may be represented in greater range and
    precision than that required by the type;  the types are not
    changed thereby.

This sentence illustrates the distinction between "type" as a
compile-time notion and a run-time internal format, which may
be different than the internal format of the compile-time type.

Floating constants have a compile-time type (which is determined
by their suffix, or lack thereof).  However the type does not
necessarily determine the internal format used to represent the
constant.  Again from n1570, 6.4.4.2 paragraph 5 says in its
last sentence:

    All floating constants of the same source form(75) shall
    convert to the same internal format with the same value.

The footnote numbered 75 gives clarifying examples:

    1.23, 1.230, 123e-2, 123e-02, and 1.23L are all different
    source forms and thus need not convert to the same internal
    format and value.

After reading the above explanation I hope it is clear that the
excerpt from n2731 refers to what internal format is used, and
does not refer to any aspect of the source form (except of course
indirectly because constants having the same source form must use
the same internal format and have the same value).

Does that make more sense now?

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

C++ (and some C) quiz questions Juha Nieminen <nospam@thanks.invalid> - 2022-05-16 11:21 +0000
  Re: C++ (and some C) quiz questions Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-16 17:35 +0300
    Re: C++ (and some C) quiz questions Juha Nieminen <nospam@thanks.invalid> - 2022-05-16 16:13 +0000
  Re: C++ (and some C) quiz questions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-16 10:49 -0700
  Re: C++ (and some C) quiz questions Christian Gollwitzer <auriocus@gmx.de> - 2022-05-16 20:02 +0200
    Re: C++ (and some C) quiz questions "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-16 20:51 +0200
      Re: C++ (and some C) quiz questions Christian Gollwitzer <auriocus@gmx.de> - 2022-05-16 20:59 +0200
        Re: C++ (and some C) quiz questions Manfred <noname@add.invalid> - 2022-05-16 21:55 +0200
          Re: C++ (and some C) quiz questions Christian Gollwitzer <auriocus@gmx.de> - 2022-05-16 22:09 +0200
            Re: C++ (and some C) quiz questions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-16 13:47 -0700
              Re: C++ (and some C) quiz questions Ben <ben.usenet@bsb.me.uk> - 2022-05-16 22:19 +0100
                Re: C++ (and some C) quiz questions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-16 14:52 -0700
                Re: C++ (and some C) quiz questions Ben <ben.usenet@bsb.me.uk> - 2022-05-16 22:57 +0100
            Re: C++ (and some C) quiz questions Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-17 00:54 +0300
              Re: C++ (and some C) quiz questions Ben <ben.usenet@bsb.me.uk> - 2022-05-17 00:34 +0100
                Re: C++ (and some C) quiz questions Christian Gollwitzer <auriocus@gmx.de> - 2022-05-17 08:24 +0200
                Re: C++ (and some C) quiz questions Juha Nieminen <nospam@thanks.invalid> - 2022-05-17 08:21 +0000
                Re: C++ (and some C) quiz questions Ben <ben.usenet@bsb.me.uk> - 2022-05-17 11:06 +0100
        Re: C++ (and some C) quiz questions Juha Nieminen <nospam@thanks.invalid> - 2022-05-17 04:41 +0000
          Re: C++ (and some C) quiz questions Ben <ben.usenet@bsb.me.uk> - 2022-05-17 11:12 +0100
            Re: C++ (and some C) quiz questions Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-17 14:37 +0300
              Re: C++ (and some C) quiz questions Ben <ben.usenet@bsb.me.uk> - 2022-05-17 14:31 +0100
            Re: C++ (and some C) quiz questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-17 04:53 -0700
              Re: C++ (and some C) quiz questions Juha Nieminen <nospam@thanks.invalid> - 2022-05-18 04:40 +0000
                Re: C++ (and some C) quiz questions Manfred <noname@add.invalid> - 2022-05-18 13:29 +0200
                Re: C++ (and some C) quiz questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-18 06:57 -0700
                Re: C++ (and some C) quiz questions Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-18 17:37 +0300
                Re: C++ (and some C) quiz questions Juha Nieminen <nospam@thanks.invalid> - 2022-05-19 14:43 +0000
                Re: C++ (and some C) quiz questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-19 08:21 -0700
                Re: C++ (and some C) quiz questions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-18 06:01 -0700

csiph-web