Initializing constants

[Richard Heathfield]

Re: Initializing constants

Keith Thompson said:

richard@cogsci. ed.ac.uk (Richard Tobin) writes:

>In article <lnu03pevh1.fsf @nuthaus.mib.or g>,
>Keith Thompson <kst-u@mib.orgwrote:
>>

>>>#define PI (355.0 / 155) /* to 7 sig. digits */

>>

>>>Sure, if by "7" you mean "1".

>>
>Um, 0 actually. 355/155 is about 2.3.

>
Pedant!

If he were a pedant, he'd have said: 355/155 is 2

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

Re: Initializing constants

Richard Heathfield wrote:

Keith Thompson said:
>

>richard@cogsci. ed.ac.uk (Richard Tobin) writes:

>>In article <lnu03pevh1.fsf @nuthaus.mib.or g>,
>>Keith Thompson <kst-u@mib.orgwrote:
>>>
>>>>#define PI (355.0 / 155) /* to 7 sig. digits */
>>>Sure, if by "7" you mean "1".
>>Um, 0 actually. 355/155 is about 2.3.

>Pedant!

>
If he were a pedant, he'd have said: 355/155 is 2

Which does not make him incorrect since he only said "about" and 23
could be considered to be about 2
int about(double d)
{
return d;
}
--
Flash Gordon.

[Richard Heathfield]

Re: Initializing constants

Flash Gordon said:

Richard Heathfield wrote:

>Keith Thompson said:
>>

>>richard@cogsci. ed.ac.uk (Richard Tobin) writes:

<snip>

>>>355/155 is about 2.3.
>>Pedant!

>>
>If he were a pedant, he'd have said: 355/155 is 2

>
Which does not make him incorrect since he only said "about" and 23
could be considered to be about 2

I suppose we could consider 23 to be about 2, if we're prepared to ignore an
order of magnitude. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

Re: Initializing constants

Richard Heathfield wrote:

Flash Gordon said:
>

>Richard Heathfield wrote:

>>Keith Thompson said:
>>>
>>>richard@cogsci. ed.ac.uk (Richard Tobin) writes:

>
<snip>
>

>>>>355/155 is about 2.3.
>>>Pedant!
>>If he were a pedant, he'd have said: 355/155 is 2

>Which does not make him incorrect since he only said "about" and 23
>could be considered to be about 2

>
I suppose we could consider 23 to be about 2, if we're prepared to ignore an
order of magnitude. :-)

OK, which one of you stole my decimal point? :-)
--
Flash Gordon

[newsposter0123]

Re: Initializing constants

The peccant 155/113 cacophony momentarily obscured the discussion. To
which I add that the difference is 42, not 23, although it is in the
same order of magnitude, but the decimal point is still lost. Perhaps a
matter of improper reference position?

Skarmander wrote:

I should have made clear that we were still talking about
objects with static storage duration, hence the need for the initializer
to be a constant expression. (I was exactly discussing the confusion
between constant expressions and const-qualified objects.)

The following is C99/May 2005?

Point well taken. By using a const-qualified floating point object, the
constants value/precision is limited by the most restrictive of the
run-time environments implementation or the translation environment's
evaluation, even if the hardware, either during translation or
execution, provides a greater precision. Because of this limitation,
any expression involving conversion may never result in a "most
accurate floating point constant". This rules out base 10 floating
point numbers, and probably hexadecimal floating point numbers.

A "most accurate const-qualified floating point type" could be
initialized using a normalized binary float number representation.
Provided the exponent was within range, it could be loaded directly
into the target representation of the const-qualified floating point
type, without alteration. Any least significant excess bits of the
fractional part would just be truncated. If this is already available,
an example would be nice.

However, in order to ensure that "most accurate floating point
constant" was used during the evaluation of an expression , a keyword
identifier would have to be added, similar to __func__, that, when
evaluated, evaluates to the most accurate representation of the
floating point constant available.

BEGIN SPECIFIC MSVC++ 32BIT EXAMPLE

The MSVC++ 32 bit compilers define floating point type double and
floating point type long double. Both are the same size,64bits, with
the same precision, which is less than the maximum evaluable if using a
387 coprocessor, which provides 80bits. Under the theory that constants
should interfere with the precision of an expression during evaluation
as little as possible, the more accurate the constant, the better.

long double a, b=113.0, c=LDBL_PI, d;
a = LDBL_PI/b;
d = c / b;

may produce different results depending on the value of b. When
evaluating the "a" expression, the 80bit value is used for pi, but when
evaluation the "d" expression, only 64bits are used. By default, when
using the 387, all floating points, within the coprocessor, are 80bits.

END SPECIFIC MSVC++ 32BIT EXAMPLE

BEGIN GCC/i386 32BIT EXAMPLE
For the SYSV i386 ABI implementations (GCC), the full 80bits is used
for long double, so both the "a" and "d" expressions should evaluate to
equal results.

However, the statements:
float a, b=113.0, c=LDBL_PI;
a = LDBL_PI/b;
a = c / b;

may produce different results, depending on the value of b and how the
translation environment converts a long double to float.
END GCC/i386 32BIT EXAMPLE

I guess two-cents just ain't worth what it used to be, and is now worth
non-cents.