Float problem

Quote:

---

Originally Posted by citizen

float x = 4;
double y = 4;

Nothing wrong with promotion (as long as it is compatible). But when you convert to a lesser data type, you might lose your data.

>> And exactly what is wrong with [rounding]?
>> what point it is your are trying to make?

It is completely reasonable to avoid possible loss of data.

---

Again not too clear.
Anyway, for starters, having looked up the matter in my (rather old I might add) book on
C it states that division is never performed on a float, at least not without converting it
to a double first so putting an f there would seem to be a waste of yours, and possible
the compilers time.
And even if it did do the division on floats why go for a less accurate result?

Because again, you're cramming the result into a smaller variable with a great deal less precision. There is only so much rounding you can do until the value is just completely wrong. It depends what's important, etc.

I mean if you think the compiler cares you assign something really precise, you're wrong:

Code:

---

#include <stdio.h>

/** my calculators answer for pi: much larger than any float or double **/
#define PI_DB 3.1415926535897932384626433832795
#define PI_FL 3.1415926535897932384626433832795f

int main ()
{
    double pi = PI_FL;
    printf( "PI_FL          = &#37;1.6f\n", PI_FL );
    printf( "PI_DB          = %1.15g\n", PI_DB );
    printf( "pi (promoted): = %1.10g\n", pi );
    return 0;
}

---

Rounding obviously happened (out of necessity in this case) but you shouldn't make it a complete surprise: you might decide, for a time, to treat doubles like floats, and floats like doubles, and all that rounding takes it's toll on the overall precision of your final answer [/Regis]. You can't just extend pricision back to what it once was after you've messed with it.

And evidently it's not easy to keep track of: Plenty of people aren't aware that point-anything is double by the compiler. That's why people can be finicky about decimal numbers, because they have to be when it matters. Fortunately, you don't see much of these issues creeping into financial software, though it might be easy for accountants to lay blame. :D

Quote:

---

And never in a million years (I hope) would I write

Code:
float x = 4.0f;
double y = 4.0;

---

And yet this is correct and all of the examples you (esbo) have shown are incorrect. Why do you think it is wrong to specify floats as 1.0f and doubles as 1.0? Second, where did you learn this as being right:

Code:

---

float x = 4;
double y = 4;

---

And how does that differ from:

Code:

---

int x = 4;
unsigned int x = 4
unsigned long x = 4;
__int64 x = 4;

---

The last example shows integral data types being assigned integral values. The first two examples show floating point data types (float and double) being assigned integral values. Sure the compiler will convert but this will bite you someday if you continue to rely on the compiler for the conversion. It not only obfuscates the code, forces a conversion where perhaps none is needed if all vars are already using the same type, but also shows a bit of a lack of understanding about floating point data types. Take this sample:

Sample 1

Code:

---

float x = 4;
float y = 6;

float total = x + y;

---

Sample 2

Code:

---

float x = 4.0;
float y = 6;

float total = x + y;

---

Sample 3

Code:

---

float x = 4.0f;
float y = 6.0f;

float total = x + y;

---

Sample 4

Code:

---

double x = 4.0;
double y = 6.0;

double total = x + y;

---

Samples 1 and 2 are sloppy and inconsistent. There are times when variable types are not identical and casting is necessary but forcing a cast where none is needed is a bad practice.

If you write any type of modern 3D graphics code using OpenGL or Direct3D and you do all your calculations in double precision and then stuff that into a float.....what you get on screen will be very different from what you expect. If you fail to maintain your data types or toss them around sloppily your code will certainly crash and bring down the entire app. It only takes several matrix multiplies to accumulate a large floating point error even when data types are consistent much less when a lot of casting is taking place.

I tend to specify floats using 1.f for example. Do people even know that is also valid syntax?

Quote:

---

I tend to specify floats using 1.f for example. Do people even know that is also valid syntax?

---

Nope. Interesting. I don't think I'll switch though.

Well aside from all the other stuff in this thread I can honestly say I can never
even recall seeing the 'f' notation used apart from on this site.
Is it a relatively new 'development'?

Maybe I just got out whilst the going, was good so to speak :)

Or at least slightly better anyway.....

Quote:

---

Well aside from all the other stuff in this thread I can honestly say I can never
even recall seeing the 'f' notation used apart from on this site.
Is it a relatively new 'development'?

---

No, it's pretty old.

Quote:

---

Originally Posted by laserlight

No, it's pretty old.

---

Well I don't think I will ever use it, I have never had a problem with floats so far
and I can't see me ever having to use it in the future, it is surplus to requirements
as far as I am concerned.
I think it might have been introduced in ANSI C, those standards commities loved
introducing loads of stuff you never needed to use. Bit like the RS232 connector,
25 pins for serial communications - what a joke, I doubt anyone every used more then
5.

Well, you aren't forced to use floats, but if you do, use .f and even if you don't use it, even if you just give advance to someone, tell them to use .f of they use floats.