• 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

How to covert a String value to double without loosing the precision

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

How can I convert a String value "106.4000" to a double, without loosing the precisions after 4 ?

If I use,

double dbl = Double.parseDouble("106.4000");

I am getting 106.4 only.

But I need the exact string value as double.


So please help me to do this.

Thanks in advance...

regards,
Nishad P
 
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The simple answer is "you can't". A slightly longer answer is...

A "double" value is stored in binary. The idea of trailing decimal zeros, as in 106.4000, is meaningless in a "double" value.

A "double" value is also floating-point. This means it cannot store all decimal values (whole or fractions) with perfect accuracy. If you don't know about this stuff, Google for "floating point".
 
Marshal
Posts: 79054
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to JavaRanch

Your problem sounds like a job for . . . BigDecimal!
 
Ranch Hand
Posts: 242
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mathematically,



So you cannot keep the preceding zeros before the decimal and trailing zeros after the decimal.
 
Campbell Ritchie
Marshal
Posts: 79054
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Try this, and see what BigDecimal makes of leading and trailing zeroes:
 
Campbell Ritchie
Marshal
Posts: 79054
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Santhosh Kumar:
Mathematically,



So you cannot keep the preceding zeros before the decimal and trailing zeros after the decimal.

Actually, I agree with the behaviour of BigDecimal that 1.1 is not exactly equivalent to 1.1000. Change the last statement of my BigDecimalTest class which I posted a few minutes back to read like this, and try again.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Campbell Ritchie:
Actually, I agree with the behaviour of BigDecimal that 1.1 is not exactly equivalent to 1.1000.



But mathematically, it is, isn't it?
 
Campbell Ritchie
Marshal
Posts: 79054
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We're not here to do maths . . . BigDecimal does exactly what the original poster wants, retain the value and the original precision.
 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Campbell Ritchie:
We're not here to do maths . . . BigDecimal does exactly what the original poster wants, retain the value and the original precision.



Well, it really has nothing to do with precision but rather with presentation (they're not the same). If the OP wants to have 4 leading numbers then the obvious choice would be to use java.text.DecimalFormat with the pattern: "0.0000":

 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Campbell Ritchie:
We're not here to do maths . . .



It sounded to me like you were implying that the behavior of primitive doubles was somehow not fully correct. To that I would answer that it shows exactly the behavior a mathematician would expect.

I agree that if you need different behavior, you should use something different, and if that's BigDecimal in this case, fine.
 
Campbell Ritchie
Marshal
Posts: 79054
375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
It sounded to me like you were implying that the behavior of primitive doubles was somehow not fully correct. . .

More likely, expressing myself awkwardly. Sorry. We seem all to agree in the end however.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


But mathematically, it is, isn't it?


Yes, and no.
1.1 equals 1.100, but 1.100 has better precision than 1.1. This can be illustrated by this example: 1.100 rounded to two digits is 1.1, but so is 1.109, 1.14 etc.
So 1.1 really is only precise to say that it is a number N 1.15<N<=1.05, while with 1.100 is 1.150<N<=1.050.

But of course, this doesn't matter much to a computer.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic