This week's book giveaways are in the AI and JavaScript forums.
We're giving away four copies each of GANs in Action and WebAssembly in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of GANs in ActionE this week in the AI forum
or WebAssembly in Action in the JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Do the Java Specs Allow a Quotient that is off in the least significant Digit?

 
Ranch Hand
Posts: 224
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wrote a little piece of code like so:

When I run this it prints out "0.07692307692307693". Is that an error? Rounded correctly it should be "0.07692307692307692", shouldn't it? The repeating series is "076923". Do the Java specs allow a value returned that's off in the least significant digit?

Kevin S
 
Kevin Simonson
Ranch Hand
Posts: 224
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Kevin Simonson wrote:I wrote a little piece of code like so:

When I run this it prints out "0.07692307692307693". Is that an error? Rounded correctly it should be "0.07692307692307692", shouldn't it? The repeating series is "076923". Do the Java specs allow a value returned that's off in the least significant digit?

Kevin S


Furthermore, if I make it more general:

and run it with "java Rec 7", I get "1.0 / 7.0 == 0.14285714285714285". This time it didn't round up, but it should have, since the next digit would have been '7'. What's the deal here?

Kevin S
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Floating-point numbers (float and double) are in general much less accurate than what you got in your example. You're lucky that 1.0 / 13.0 gave such an accurate answer.

Java uses the ubiquituous IEEE floating point formats for the types float and double. (Most modern CPUs have hardware support for these formats). They store floating-point numbers as binary fractions. Some decimal numbers, for example 0.1, cannot be stored with full precision in these types.
 
Kevin Simonson
Ranch Hand
Posts: 224
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jesper de Jong wrote:Floating-point numbers (float and double) are in general much less accurate than what you got in your example. You're lucky that 1.0 / 13.0 gave such an accurate answer.

Java uses the ubiquituous IEEE floating point formats for the types float and double. (Most modern CPUs have hardware support for these formats). They store floating-point numbers as binary fractions. Some decimal numbers, for example 0.1, cannot be stored with full precision in these types.


So you're saying that Java does the division of 1.0 by 13.0, stores the quotient in binary format, losing a little precision as it does that, and then with the {println()} command converts it to decimal, losing a little more precision as it does that, and results in a decimal number that's off from what it should be in its least significant digit? And that's okay?

Kevin S
 
Rancher
Posts: 43011
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Read #20 in the https://coderanch.com/how-to/java/JavaBeginnersFaq.
 
Marshal
Posts: 67390
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are asking about the Java Specs, have you read them? It does actually tell you there, so yes.
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Kevin Simonson wrote:So you're saying that Java does the division of 1.0 by 13.0, stores the quotient in binary format, losing a little precision as it does that, and then with the {println()} command converts it to decimal, losing a little more precision as it does that, and results in a decimal number that's off from what it should be in its least significant digit? And that's okay?


It's not a question about whether it is "okay" or not, it's just how floating-point numbers work in Java and most other programming languages. float and double are not infinitely precise. If you think about it, they simply cannot be infinitely precise in principle, since they have a finite memory size (32 bits or 64 bits). To be able to store any arbitrary floating-point number with exact precision, you would need need an unlimited amount of memory.

If you need really precise numbers, use java.math.BigDecimal.
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This video explains it very clearly:

 
Danger, 10,000 volts, very electic .... tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!