“A deep dive into how silently casting a long to float or double in Java can cause unexpected rounding — even when it looks like everything's working fine.”
While I was experimenting with Java's primitive data types, I stumbled across a strange behavior when casting a long
value to a float
. Initially, everything looked fine — until I tried a slightly different number. Let's dive into what I found!
🧪 The Case: Casting long
to float
Here’s a small Java snippet that caught my attention:
class Example {
public static void main(String args[]) {
long original = Long.MAX_VALUE; // 9223372036854775807
float x = original;
long y = (long)x;
System.out.println("Original : " + original);
System.out.println("After storing the long value as float : " + x);
System.out.println("Stored in float and cast back : " + y);
System.out.println("Same? " + (original == y));
}
}
Original : 9223372036854775807
After storing the long value as float : 9.223372E18
Stored in float and cast back : 9223372036854775807
Same? true
Looks good, right? Now let’s subtract just 1 from that original value:
class Example {
public static void main(String args[]) {
long original = Long.MAX_VALUE - 1; // 9223372036854775806
float x = original;
long y = (long)x;
System.out.println("Original : " + original);
System.out.println("After storing the long value as float : " + x);
System.out.println("Stored in float and cast back : " + y);
System.out.println("Same? " + (original == y));
}
}
Original : 9223372036854775806
After storing the long value as float : 9.223372E18
Stored in float and cast back : 9223372036854775807
Same? false
🤔 What Just Happened?
float in Java is a 32-bit IEEE 754 floating-point number — it simply can’t hold the full precision of a 64-bit long (which has a 53-bit mantissa in double-precision, and only ~24 bits in single-precision).
So when you convert a long to float, you lose precision — and in some edge cases, this causes rounding to the nearest representable float, which might increase the number unexpectedly.
In our second example, 9223372036854775806L was rounded up to the same float representation as Long.MAX_VALUE — so when cast back to long, it became greater than it originally was.
🔍 Key Takeaways
✅ float cannot safely store large long values without precision loss.
⚠️ Be careful when comparing values after type casting.
💡 Use double or BigDecimal if you need more precise conversions or arithmetic.
🎯 Real-World Impact
Such subtle bugs can appear in:
- Financial applications dealing with large monetary values
- Timestamps or IDs stored as long
- Scientific calculations where precision matters Always know your data types and limits before relying on direct conversions.
💬 Final Thoughts
This tiny experiment reminded me why understanding the limits of data types is crucial, even in the simplest programs. Java makes type casting easy — but sometimes too easy!
Have you encountered similar surprises in Java (or other languages)? I’d love to hear your thoughts in the comments.
Let’s keep learning, one line at a time! ✨
📣 Follow me on LinkedIn and GitHub for more Java insights and development experiments.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.