Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Corrected: Using type suffixes with floating point constants

0 views
Skip to first unread message

Ioannis Vranos

unread,
Mar 26, 2009, 12:56:44 PM3/26/09
to
ISO/IEC 9899:1990/1995 says (from K&R2):

“A6.4

When a less precise floating value is converted to an equally or more precise floating type, the value is
unchanged.

==> When a more precise floating value is converted to a less precise floating type, and the value is within
representable range, the result may be either the next higher or the next lower representable value.

If the result is out of range, the behavior is undefined”.


Question: Does the above mean that it is a good practice or *always* needed to use the appropriate type
suffixes with floating point constants?

An example of this:


#include <iostream>


int main(void)
{
using namespace std;

float f1 = 0.33439F;

float f2= 0.33439f;

cout<< "\nf1= "<< f1<<", f2= "<< f2<< endl;


double d1= 0.33439;

double d2= 0.33439;

cout<< "\nd1= "<< d1<<", d2= "<< d2<< endl;


// It doesn't work with MINGW, compiler is broken regarding
// long double.
long double ld1= 0.33439L;

long double ld2= 0.33439l; // 'l' is the lower case 'L'.

cout<< "\nld1= "<< ld1<<", ld2= "<< ld2<< endl;


return 0;
}

Victor Bazarov

unread,
Mar 26, 2009, 6:30:23 PM3/26/09
to
Ioannis Vranos wrote:
> ISO/IEC 9899:1990/1995 says (from K&R2):
>
> “A6.4
>
> When a less precise floating value is converted to an equally or more
> precise floating type, the value is unchanged.
>
> ==> When a more precise floating value is converted to a less precise
> floating type, and the value is within representable range, the result
> may be either the next higher or the next lower representable value.
>
> If the result is out of range, the behavior is undefined”.
>
>
> Question: Does the above mean that it is a good practice or *always*
> needed to use the appropriate type suffixes with floating point constants?

No, the above does not mean that. You need to look at the definition of
the FP literals. The suffix only says what type the literal has. The
suffix does not control potential precision. IOW

float Pi = 3.1415926;
float Pi_ = 3.1415926f;

will *likely* have the same value since the number of digits (8) in the
literals is greater than 'float' can represent (7), and both numbers
will be "fixed", only at different times, so to speak. The former will
be squeezed into a 'float' at the time of initialising of 'Pi' (formally
by your program), the other will be squeezed into a 'float' by the
compiler upon creating the literal. It is conceivable that the numbers
will be different *if* your compiler uses a different way of "fixing" of
the value to fit into a 'float' than your program (which can actually be
controlled in some cases by a flag in the CPU/FPU, IIRC).

> An example of this:

An example of *what* exactly? That it's a good idea to always use the
suffixes?

> #include <iostream>
>
>
> int main(void)
> {
> using namespace std;
>
> float f1 = 0.33439F;
>
> float f2= 0.33439f;
>
> cout<< "\nf1= "<< f1<<", f2= "<< f2<< endl;
>
>
> double d1= 0.33439;
>
> double d2= 0.33439;
>
> cout<< "\nd1= "<< d1<<", d2= "<< d2<< endl;
>
>
> // It doesn't work with MINGW, compiler is broken regarding
> // long double.
> long double ld1= 0.33439L;
>
> long double ld2= 0.33439l; // 'l' is the lower case 'L'.
>
> cout<< "\nld1= "<< ld1<<", ld2= "<< ld2<< endl;
>
>
> return 0;
> }

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

James Kanze

unread,
Mar 27, 2009, 5:12:39 AM3/27/09
to
On Mar 26, 11:30 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:

[...]


> No, the above does not mean that. You need to look at the
> definition of the FP literals. The suffix only says what type
> the literal has. The suffix does not control potential
> precision. IOW

> float Pi = 3.1415926;
> float Pi_ = 3.1415926f;

> will *likely* have the same value since the number of digits
> (8) in the literals is greater than 'float' can represent (7),
> and both numbers will be "fixed", only at different times, so
> to speak.

First, as you know, a float can have more than 8 decimal digits
of precision. I'll suppose that we're talking about the usual
IEEE float here.

> The former will be squeezed into a 'float' at the time of
> initialising of 'Pi' (formally by your program), the other
> will be squeezed into a 'float' by the compiler upon creating
> the literal. It is conceivable that the numbers will be
> different *if* your compiler uses a different way of "fixing"
> of the value to fit into a 'float' than your program (which
> can actually be controlled in some cases by a flag in the
> CPU/FPU, IIRC).

The big difference is that formally, the first involves two
roundings: decimal to double, then double to float. This
certainly could, in certain cases, result in a difference in the
LSB.

--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Ioannis Vranos

unread,
Mar 27, 2009, 8:48:19 AM3/27/09
to

The sizes differ:


#include <stdio.h>


int main(void)
{
printf("sizeof(0.33439F)= %lu, sizeof(0.33439)= %lu\n\n",
(unsigned long)sizeof(0.33439F), (unsigned long)sizeof(0.33439));

return 0;
}


john@ubuntu:~/Projects/anjuta/c/src$ ./foobar
sizeof(0.33439F)= 4, sizeof(0.33439)= 8

john@ubuntu:~/Projects/anjuta/c/src$

Ioannis Vranos

unread,
Mar 27, 2009, 8:52:29 AM3/27/09
to


The sizes differ in my system:


#include <iostream>


int main(void)
{
using namespace std;

cout<<"sizeof(0.33439F)= "<< sizeof(0.33439F)<< ", sizeof(0.33439)= "
<<sizeof(0.33439)<<endl<< endl;

return 0;
}


john@ubuntu:~/Projects/anjuta/cpp/src$ ./foobar
sizeof(0.33439F)= 4, sizeof(0.33439)= 8

john@ubuntu:~/Projects/anjuta/cpp/src$

Ioannis Vranos

unread,
Mar 27, 2009, 8:55:21 AM3/27/09
to
Forwarded:


Bart.van.In...@ict.nl said:

On Mar 26, 2:54 pm, Ioannis Vranos <ivra...@freemail.spam.not.gr>
wrote:


> > ISO/IEC 9899:1990/1995 says (from K&R2):
> >
> > “A6.4
> >
> > When a less precise floating value is converted to an equally or more

> > precise floating type, the value is unchanged. When a more precise


> > floating value is converted to a less precise floating type, and the
> > value is within representable range, the result may be either the next
> > higher or the next lower representable value. If the result is out of
> > range, the behavior is undefined”.
> >
> > Question: Does the above mean that it is a good practice or *always*
> > needed to use the appropriate type suffixes with floating point constants?
> >

I don't know about best practice---I don't use floating point often
enough for that---, but it certainly is not needed to always specify
the suffixes.

First of all, the majority of floating point constants are not exactly
representable in any of the floating point types, so you get the
conversion to the next higher or next lower representable value
anyway.
If float and double don't have the same range and precision, then a
compiler must be really perverse to get different results for the
expressions '(float)0.33439' and '0.33439F'.

The only suffix with more than documentary value is L (or l), if you
need the extra precision or range that long double might give you.

Bart v Ingen Schenau

Ioannis Vranos

unread,
Mar 27, 2009, 9:07:01 AM3/27/09
to


Yes I think there is a case for long doubles constants. If we use the default double constants we may loose
both in precision and value ranges, on assignment to a long double variable and at calculations.


However I think we also have a case for floats, for truncation and perhaps compiler range checks.

Victor Bazarov

unread,
Mar 27, 2009, 7:11:05 PM3/27/09
to

Ahem... If there weren't different, why would we have this
conversation, right? Of course they are different. But what does this
have to do with the issue at hand? You're asking about initialising a
'float' with either an explicit 'float' literal or with a 'double'
literal. I am saying that there would be most likely no difference *for
the resulting 'float'*.

Ioannis Vranos

unread,
Mar 31, 2009, 8:18:28 AM3/31/09
to
Because of the unavoidable mistakes, typos and other, and also to keep track how the proposal evolves, I have
created a web page for it:

http://www.cpp-software.net/documents/cpp_only_proposal.html


So please base your answers to that document.

Ioannis Vranos

unread,
Mar 31, 2009, 8:26:05 AM3/31/09
to


Wrong thread, sorry.

Victor Bazarov

unread,
Mar 31, 2009, 8:35:49 AM3/31/09
to

Please amend your proposal with the description of the problems you're
trying to solve. "Increase type safety" reads like hand waving, it's
too generic. Please don't repeat by stating what the mechanism would
do, I think by now we all get it. Explain *why* you want conversions to
be ignored in certain cases, and what prevents you from solving those
problems using the existing mechanisms in the language. Thanks!

0 new messages