• Advertisement
Sign in to follow this  

float x = 1.33333333333333 why does it equal 1?

This topic is 4874 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I have made a float like so float x = 400/300 400/300 = 1.333333333333333333333333333333333 When i find out what value x is like so this.text = x.tostring(); text = 1 for some reason Do recurring numbers get rounded off if so, how can i keep it so x = 1.3333? Thanks for any info

Share this post


Link to post
Share on other sites
Advertisement
because you are doing an integer division.

float x = (float)400/300


That will do what you want.

Share this post


Link to post
Share on other sites
If both numbers on either side of a division are integers a ‘integer division’ is performed. This is basicly a division that is trunctuated to an integer (for the sake of speed). To solve this you can cast the values as floats or doubles.

Example:

Floats:
400.0f / 300.0f

Floats:
( float ) 400 / (float ) 300

Doubles:
400.0 / 300.0

Hope this helps,
Jackson Allan

Share this post


Link to post
Share on other sites
Quote:
Original post by Xetrov
because you are doing an integer division.

float x = (float)400/300




Casting literals is strange. Why not this?

    float x = 400.0f / 300.0f 

Share this post


Link to post
Share on other sites
Quote:

Casting literals is strange. Why not this?

    float x = 400.0f / 300.0f 


Fair enough, but that doesnt exactly work when you want to use variables instead ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by Xetrov
Fair enough, but that doesnt exactly work when you want to use variables instead ;)


(Kicking the man while he's down.)
C casts are evil (unless you're programimng in pure C).
Prefer static_cast<float>(a)/b.
That way it is obvious what the cast is applied to.
(does the cast in (float)a/b apply to a or to a/b ?)

[wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by Fruny
Prefer static_cast<float>(a)/b.
That way it is obvious what the cast is applied to.
(does the cast in (float)a/b apply to a or to a/b ?)

Although C-casts are ugly, I usually find this nice:
float(a)/b

Share this post


Link to post
Share on other sites
That's not a C cast, you're creating a temporary float from a. I guess in the end it's exactly the same, but I'm going to say they're different, so har!

Share this post


Link to post
Share on other sites
Quote:
Original post by dalleboy
Quote:
Original post by Fruny
Prefer static_cast<float>(a)/b.
That way it is obvious what the cast is applied to.
(does the cast in (float)a/b apply to a or to a/b ?)

Although C-casts are ugly, I usually find this nice:
float(a)/b


float x = (float)(a/b) is the way I did

Share this post


Link to post
Share on other sites
Quote:
Original post by Archi
float x = (float)(a/b) is the way I did
I don't think that'll work. The integer divide would happen before the float cast.

Share this post


Link to post
Share on other sites
I think the OP would have known why it was 1 if he was using integer variables (cause he seemed to already understand the fact that his type being float was important) ... so it seems he was only surprised by the fact that:

float f = 300/400;

is using an integer 300 and an integer 400 when the compiler could clearly see the result is float ...

I think the thing he (and many others) didn't know is that all literals are inheirently typed ... all the time - even in #define statements.

100 is always an integer, and (if memory serves) 100.0 is always a double (correct me if i'm wrong here).

Hence the reason you see:

100.0f (makes it be a float instead of a double)
100L (long instead of int)
100U (unsigned instead of int)

and also of course
0144 // 100 as an octal number
0x64 // 100 as a hex constand

Share this post


Link to post
Share on other sites
Quote:

I think the OP would have known why it was 1 if he was using integer variables (cause he seemed to already understand the fact that his type being float was important) ... so it seems he was only surprised by the fact that:

float f = 300/400;

is using an integer 300 and an integer 400 when the compiler could clearly see the result is float ...


but

float f = 25/5;

wouldn't be so obvious would it? hence the convention...

Share this post


Link to post
Share on other sites
what convention? I think there was a minor misunderstanding .. I know the reasons why the C / C++ compiler acts the way it does, and believe it makes complete sense. And here's the real reason - if the user WANTS this float to be initialize based on integral arithmatic, he/she needs that option.

All I was saying in my last post was: I think the OP and others like him need to be informed about the fact that all literals are typed (and therefore follow almost exactly the same rules as if they we're variables of their type), and how to select their type, more than about types, casts, and expression evaluation in general (most C/C++ people learn the basic expression evaluation fairly early).

Share this post


Link to post
Share on other sites
Quote:
Original post by dalleboy
Quote:
Original post by Fruny
Prefer static_cast<float>(a)/b.
That way it is obvious what the cast is applied to.
(does the cast in (float)a/b apply to a or to a/b ?)

Although C-casts are ugly, I usually find this nice:
float(a)/b

That's a function-style cast, which was added in C++.

Share this post


Link to post
Share on other sites
It's not a function, it's a constructor call (although it may be refered to as a function style cast) - it is only available on types which implement a constructor taking the single parameter of the appropriate type ...

Share this post


Link to post
Share on other sites
Quote:
Original post by Xai
It's not a function, it's a constructor call (although it may be refered to as a function style cast) - it is only available on types which implement a constructor taking the single parameter of the appropriate type ...

Hence more appropriate in generic programming.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement