# long primitive fits in float. Why?

bairava surya
Ranch Hand
Posts: 134

how long can be stored in float as size of long is greater than float?

Roel De Nijs
Sheriff
Posts: 10662
144
bairava surya wrote:how long can be stored in float as size of long is greater than float?

Very good question!

You'll find a great answer (with explanation & example code) in this post.

Brian Brumpton
Ranch Hand
Posts: 40
1
I know Roel already posted a link where you'll find the answer. I hope you don't mind me replying but I wanted to take a stab at explaining it to test my knowledge and understanding.

how long can be stored in float as size of long is greater than float?

Java implicitly casts a smaller size primitive type to the larger size primitive type, there is no need to write the explicit cast in your code.

Henry Wong
author
Marshal
Posts: 22089
88
Brian Brumpton wrote:I know Roel already posted a link where you'll find the answer. I hope you don't mind me replying but I wanted to take a stab at explaining it to test my knowledge and understanding.

Sure. No problem...

Brian Brumpton wrote:
Java implicitly casts a smaller size primitive type to the larger size primitive type, there is no need to write the explicit cast in your code.

The basis of the confusion has to do with the size (in terms of the number of bits). A long is 64 bits in size. A float is 32 bits in size. So, how can a long implicitly cast to a float?

Of course, the reason is that memory size has nothing to do with it. It is the range that matters. Even though a float value is contained in 32 bits, its range is larger than that of a long -- and fully encompasses the range of a long. Hence, a long can be implicitly cast to a float.

Henry

Jelle Klap
Bartender
Posts: 1952
7
Brian Brumpton wrote:I know Roel already posted a link where you'll find the answer. I hope you don't mind me replying but I wanted to take a stab at explaining it to test my knowledge and understanding.
...
Java implicitly casts a smaller size primitive type to the larger size primitive type, there is no need to write the explicit cast in your code.

I think the confusion arose from the fact that a primitive float is a 32-bit data type, while a primitive long is a 64-bit data type, so at first glance it seems reasonable that a long could hold a value that couldn't be represented by a float, and that makes the implicit widening conversion seem odd. You might expect to need an explicit cast as is the case when assigning a long value to an int; also a 32-bit data type.

Edit: darn, too slow

Piet Souris
Rancher
Posts: 1516
32
And it gets even more interesting. Since we have 2 ^ 64 different longs, and 2 ^ 32 different floats,
and assuming that every long can be cast to a float, it means that on average, 2 ^ 32 different longs
are mapped onto the same float. It is even worse than that, since 0F is probably the only image of
0L, and, since the range of floats is bigger than the range of longs, not all floats will be the image
of a long.

Did anyone ever made some investigations on the mapping of longs to floats?

Greetz,
Piet

Guillermo Ishi
Ranch Hand
Posts: 789
It hasn't been explained well. Bits, range, etc. Bottom line is there is 32 bits of information vs 64 bits. 64 bits of information cannot be contained by 32 bits. Except maybe in Java

Campbell Ritchie
Sheriff
Posts: 51344
86
Piet Souris wrote: . . . Did anyone ever made some investigations on the mapping of longs to floats? . . .
Since both IEEE754 numbers and two's complement numbers are deterministic, that has probably been done. But I don't fancy repeating the process.
You can pass both longs and floats to BigDecimal constructors and then count whether the two are exactly the same with the compareTo method. That might work if you have a few weeks's processor time going spare

Roel De Nijs
Sheriff
Posts: 10662
144
Brian Brumpton wrote:I know Roel already posted a link where you'll find the answer. I hope you don't mind me replying but I wanted to take a stab at explaining it to test my knowledge and understanding.

Don't mind at all! That's what these forums are all about.

Roel De Nijs
Sheriff
Posts: 10662
144
• 1
Piet Souris wrote:Did anyone ever made some investigations on the mapping of longs to floats?

Just for fun I did a little experiment. I created this little application:Output of the last invocation of print (after running 10-11 hours):
-9223372036854776000,000000 -> 274877906945
-9223370387587334100,000000 -> 549755813887
-9223369837831520300,000000 -> 549755813889
-9223371487098961900,000000 -> 549755813887
-9223370937343148000,000000 -> 549755813889
-9223368188564078600,000000 -> 393441985536
-9223369288075706400,000000 -> 549755813887
-9223368738319892500,000000 -> 549755813889

Kind regards,
Roel

Campbell Ritchie
Sheriff
Posts: 51344
86
Piet Souris wrote: . . .
Did anyone ever made some investigations on the mapping of longs to floats?
. . .
A float has 23 mantissa bits, so when the exponent after biasing is not more than 24 you can fit every integer under 2²⁴.
Then you can fit in every other integer under 2²⁵. That means another 2²³.
Then every fourth integer under 2²⁶. That means another 2²³. (etc etc)
So you keep adding 2²³ at a time until you get to 2⁶³.
Then you double your total to allow for negative numbers.
Then you subtract 1 because you now have +0 and −0. Then you subtract 1 again because you have both 2⁶³ and -2⁶³.

And …

Campbell Ritchie
Sheriff
Posts: 51344
86
Somebody check please: did I write 2²³ when it should have been 2²⁴?

joey parkker
Greenhorn
Posts: 4
Widening primitive conversions do not lose information about the overall magnitude of a numeric value. Indeed, conversions widening from an integral type to another integral type do not lose any information at all; the numeric value is preserved exactly. Conversions widening from float to double in strictfp expressions also preserve the numeric value exactly; however, such conversions that are not strictfp may lose information about the overall magnitude of the converted value.

Conversion of an int or a long value to float, or of a long value to double, may result in loss of precision-that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode (ยง4.2.4) .

Campbell Ritchie
Sheriff
Posts: 51344
86
Please always tell us where such quotes come from, so we can be sure there isn't a copyright problem.