• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

why can a long assigned to float without casting

 
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
functionTakesFloat(float f)
{
...
}
long l = 100000;
functionTakesFloat(l);
this compiles without explicit casting, long type is 64-bit and float is 32- bit, should not such assignment result in "possible loss of precision"?
Thanks.
Yan
 
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So... in a nutshell, you need to cast your conversion when there's a possible loss of precision (basically you're letting the Compiler know that you know that there's a risk doing the operation, and you take full responisiblity of whatever happens...
Check out what the JLS has to say about this:
(�5.1.2) Widening Primitive Conversion
(I extracted the most interesting parts)

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

Despite the fact that loss of precision may occur, widening conversions among primitive types never result in a run-time exception (�11).
Here is an example of a widening conversion that loses precision:

which prints:

thus indicating that information was lost during the conversion from type int to type float because values of type float are not precise to nine significant digits.
so basically... you're right -- there is a possible loss or precision when going from long --> float. But the JLS says not to throw a RunTimeException... so there isn't one. And because the compiler doesn't care that there's a possible loss of precision, you don't need to cast it!
Does that help?
[ October 22, 2003: Message edited by: Jessica Sant ]
 
Author
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I write about this JLS example at great length in "Java Rules". It was very upsetting for me the first time I realized that a "loss of precision" could mean a different whole number. The following three type conversions can result in a loss of precision:
int to float
long to float
long to double
The explanation why a loss of precision is not considered a narrowing (read "unsafe") type conversion is simply that the significand of a floating-point type is designed to be imprecise. That is what makes them useful to scientists who store very large and small numbers in the exponent field of a floating-point type.
More precisely, an important distinction is made between a loss of magnitude and a loss of precision in the floating-point types. Primitive type conversions from integral to floating-point types are categorized as widening primitive conversions (that is, safe) because there is no loss of magnitude. A loss of magnitude is defined as a change in the exponent as a result of the type conversion. When discussing floating-point types, always remember:
Magnitude is to the exponent what precision is to the significand.
There is no potential for a loss of magnitude in the three type conversions under consideration, only a loss of precision. When converting from int to float or from long to float or double, the highest power of two is always stored in the exponent. Specifically, the highest power of two in Integer.MAX_VALUE can be stored in the exponent of a float. Likewise, the highest power of two in Long.MAX_VALUE can be stored in the exponent of a float or double. In fact, the exponents of the floating-point types can store powers of two that are much greater than Integer.MAX_VALUE and Long.MAX_VALUE. A loss of precision always refers to the significand.
The conceptual difficulty here is that you cannot think of the floating point types as simply numbers that include a decimal point. They have very specific uses. If "exact" results are required, Java offers BigDecimal. Java may be the first programming language in which programmers routinely use a numeric class (instead of a primitive data type) for exact results. In the past various programming technics (such as rounding) have been used to compensate for the loss of precision in floating-point types. I could go on and on about this subject, but would refer you to "Java Rules" for a more detailed discussion.
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wrote an article for the JavaRanch Newsletter, titled "Working with Money" that deals with how numbers are actually stored in float. A not-far-from-the-truth quote from that article, "floating-point is designed to give you the wrong answer very quickly."
 
Yan Zhou
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, if the spec. says so, that is fine.
I just thought there is inconsistence as to when the compiler error "possible loss of precision" happens. Normally, I won't care it, either. But for the test, I just want to be sure.
Yan
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Yan Zhou:
OK, if the spec. says so, that is fine.
I just thought there is inconsistence as to when the compiler error "possible loss of precision" happens. Normally, I won't care it, either. But for the test, I just want to be sure.
Yan


There is no inconsistency. It all depends on your definistion of "precision".
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic