posted 2 years ago

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.

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.

posted 2 years ago

Sure. No problem...

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

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

posted 2 years ago

I think the confusion arose from the fact that a primitive

Edit: darn, too slow

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

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

posted 2 years ago

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

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

posted 2 years ago

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

Since both IEEE754 numbers and two's complement numbers are deterministic, that has probably been done. But I don't fancy repeating the process.Piet Souris wrote: . . . Did anyone ever made some investigations on the mapping of longs to floats? . . .

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

posted 2 years ago

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):

Kind regards,

Roel

- 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

`-9223372036854776000,000000 -> 274877906945`

-9223370387587334100,000000 -> 549755813887

-9223369837831520300,000000 -> 549755813889

-9223371487098961900,000000 -> 549755813887

-9223370937343148000,000000 -> 549755813889

-9223368188564078600,000000 -> 393441985536

-9223369288075706400,000000 -> 549755813887

-9223368738319892500,000000 -> 549755813889

-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

Marshal

Posts: 56600

172

posted 2 years ago

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 …

Bob's your uncle

I have thought again about this.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 …

Bob's your uncle

Campbell Ritchie

Marshal

Posts: 56600

172

posted 2 years ago

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) .

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

Marshal

Posts: 56600

172

posted 2 years ago

Please always tell us where such quotes come from, so we can be sure there isn't a copyright problem.