I'm doing calculations on High decimal precision BigDecimal objects.
I'm using a third party library that requires the parameter in double. When I try to convert this to double i get the values in exponential format instead of decimals .
BigDecimal 0.000035000000000
Double 3.5E-5
BigDecimal bd;
BigDecimal(0.0000349999999995631583260546904057264328002929687500);
bd= bd.setScale(15,BigDecimal.ROUND_CEILING);
Log.i("bd","bd "+bd.toPlainString());
Log.i("bd","double"+bd.doubleValue());
I have found various ways of converting this 3.5E-5 value as correct decimal in points but in String format only . Whereas I need the value in double
Able to get without exponential in String object But not in double
DecimalFormat df = new DecimalFormat("#");
df.setMaximumFractionDigits(16);
String test=df.format(bd,doubleValue());
System.out.println("op2 "+test);
Double test1=Double.parseDouble(test);
System.out.println("op2 "+test1);
OUTPUT op2 .000035 op2 3.5E-5
I'm struggling since since days to find a solution as I have no control over 3rd party library that requires the value to be in double
Refferred Links
Format BigDecimal without scientific notation with full precission
Converting exponential value in java to a number format
Conversion from exponential form to decimal in Java
How to resolve a Java Rounding Double issue
Java BigDecimal without E
How to Avoid Scientific Notation in Double?
My question is different then these links, I do not want the double as string without exponential instead I want it in double format only.
EDIT
If the double value passed is in exponential format, the NDK based libary will further do calculations on this object, which will result inmore decimal points and larger Exponential value. So, I want to pass a simple double without E
You seem to be confusing a double, a 64 bit value where different bits have a different meaning, with its string representation.
Let's take a value of 0.015625. Internally, the double is represented as 64 bits (I don't know right now which combination of bits, but that is irrelevant anyway).
But the string representation depends on the format settings of the library you are using. Note that the representations 0.015625 and 1.5625E-2 represent the exact same double value. The double is not stored as a string, it does not contain a . or an E, just a number of bits. The combination of these bits form its real value, and it is the same, no matter how you represent it as a string. If you have a different format setting, the result can just as well be 1.56E-2. This just means that the code that converts the internal bit combination of the double to a string does some rounding.
So, to obtain a double from a BigDecimal, simply use bd.doubleValue(). There is no need to use an intermediate string representation, and it can even be detrimental to do so, because if the string representation performs some rounding, you don't get the best approximation of the value in the BigDecimal.
So again, bd.doubleValue() is the only correct way to do this. This does not return a specific format, it simply returns the double that is closest to the value in the BigDecimal.
And again, do not confuse the double type with how it is represented as a string. These are different things. A double is a double is a double, and that is not stored as a string, exponential or plain or rounded or whatever.
Actually, BigDecimal.toString() and BigDecimal.toPlainString() also return different string representations of the same BigDecimal. AFAIK, there is even a third string conversion function, toEngineeringString(), which gives you yet another string representation of the same BigDecimal. This is similar for double: different output routines with different arguments return different strings for the exact same value.
use this: amount=value to be converted to double from string
double dd = new BigDecimal(amount).doubleValue();
String val = String.format("%.4f", dd);
BigDecimal bd = BigDecimal.valueOf(Double.valueOf(val));
Double d=bd.doubleValue() ;
DecimalFormat formatter = new DecimalFormat("0.0000");
System.out.println("doubleValue= " + formatter .format(d));
Related
I have two pieces of code new BigDecimal("1.240472701") and new BigDecimal(1.240472701). Now if i use compareTo method of java on both the methods then i get that they are not equal.
When i printed the values using System.out.println() method of java. I get different results for both the values. For example
new BigDecimal("1.240472701") -> 1.240472701
new BigDecimal(1.240472701) -> 1.2404727010000000664291519569815136492252349853515625
So i want to understand what could be reason for this?
You can refer the Java doc of public BigDecimal(double val) for this:
public BigDecimal(double val)
Translates a double into a BigDecimal
which is the exact decimal representation of the double's binary
floating-point value. The scale of the returned BigDecimal is the
smallest value such that (10^scale × val) is an integer.
The results of this constructor can be somewhat unpredictable. One
might assume that writing new BigDecimal(0.1) in Java creates a
BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with
a scale of 1), but it is actually equal to
0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that
matter, as a binary fraction of any finite length). Thus, the value
that is being passed in to the constructor is not exactly equal to
0.1, appearances notwithstanding.
The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal("0.1") creates
a BigDecimal which is exactly equal to 0.1, as one would expect.
Therefore, it is generally recommended that the String constructor be
used in preference to this one.
When a double must be used as a source
for a BigDecimal, note that this constructor provides an exact
conversion; it does not give the same result as converting the double
to a String using the Double.toString(double) method and then using
the BigDecimal(String) constructor. To get that result, use the static
valueOf(double) method.
The string "1.240472701" is a textual representation of a decimal value. The BigDecimal code parses this and creates a BigDecimal with the exact value represented in the string.
But the double 1.240472701 is merely a (close) approximation of that exact decimal value. Double cannot represent all decimal values exactly, so the exact value stored in the double differs slightly. If you pass that to a BigDecimal, it takes that differing value and turns it into an exact BigDecimal. But the BigDecimal only has the inexact double to go by, it does not know the exact text representation. So it can only represent the value in the double, not the value of the source text.
In the first case:
String --> BigDecimal
Because BigDecimal is made to exactly represent decimal values, that conversion is exact.
In the second case:
1 2
Source code text --> double --> BigDecimal
In the second case, precision is lost in the first conversion (1). The second conversion (2) is exact, but the input -- the double -- is an inexact representation of the source code text 1.240472701 (in reality, it is 1.2404727010000000664291519569815136492252349853515625).
So: never initialize a BigDecimal with a double, if you can avoid it. Use a string instead.
That is why the first BigDecimal is exact and the second is not.
Since user thegauravmahawar provided the answer from docs. Yes, it is because of Scaling in BigDecimal case.
So the values might seem equal to You but internally java uses Scaling while storing the value of BigDecimal type.
Reason: Scaling.
Improvement:
You could call setScale to the same thing on the numbers you're comparing:
like this
new BigDecimal ("7.773").setScale(2).equals(new BigDecimal("7.774").setScale (2))
This will save you from making any mistake.
How do i print this in scientific notation:
BigDecimal r= (a.subtract(exact, MathContext.DECIMAL128)).divide(exact, MathContext.DECIMAL128).stripTrailingZeros();
DecimalFormat format = new DecimalFormat("0.###E0");
System.out.println(new BigDecimal(format.format(r));
where:
a = 1.111111111111111160454356650006957352161407470703125
exact = 0.11
returns:
r = 0.900010000000000004
any ideas? I've also tried calling EngineeringString() on the BigDecimal but this also didn't seem to work for me
You overdid the thing. What you only need is:
System.out.println(format.format(r));
The DecimalFormat object does indeed create a string, creating a BigDecimal instance again would just parse the number from string again - and the toString() method is called on the BigDecimal instance, produing the output you described...
Some clarification
BigDecimal, and other numeric formats (and dates too!) are stored in binary formats in the memory, abstracted from how us, humans think of them. BigDecimal for example stores the decimal digits, and where the decimal point is. Floating point numbers are even more sophisticated. Date stores the seconds from The Epoch. You need to format them to be readable. Formatting means to create a String (or semantically similar) object, that represents the value of the given object in the desired format. This doesn't involve changing the original object in any way.
The default formatting, toString() provides one generic format. To get your output the way you'd like does not mean to change the value to be formatted right with toString(), but to transform the unchanged value into the right String. Nice example is Double.toString() (using sun.mic.FloatingDecimal): it does exponential notation when the number is large or small enough, but in between, it prints in plain decimal format...
I have on question regarding double precision.When a float value is passed into double then I get some different result. For e.g.
float f= 54.23f;
double d1 = f;
System.out.println(d1);
The output is 54.22999954223633. Can someone explain the reason behind this behaviour. Is it like double defaults to 14 places of decimal precision.
The same value is printed differently for float and double because the Java specification requires printing as many digits as needed to distinguish the value from adjacent representable values in the same type (per my answer here, and see the linked documentation for more precision in the definition).
Since float has fewer bits to represent values, and hence fewer values, they are spaced more widely apart, and you do not need as many digits to distinguish them. When you put the value into a double and print it, the Java rules require that more digits be printed so that the value is distinguished from nearby double values. The println function does not know that the value originally came from a float and does not contain as much information as can fit into a double.
54.23f is exactly 54.229999542236328125 (in hexadecimal, 0x1.b1d70ap+5). The float values just below and just above this are 54.2299957275390625 (0x1.b1d708p+5) and 54.23000335693359375 (0x1.b1d70cp+5). As you can see, printing “54.229999” would distinguish the value from 54.229995… and from 54.23…. However, the double values just below and just above 54.23f are 54.22999954223632101957264239899814128875732421875 and 54.22999954223633523042735760100185871124267578125. To distinguish the value, you need “54.22999954223633”.
This is because the float hides the extra decimals and double shows them. The double will represent the actual number quite precisely and shows more digits.
Try this:
System.out.println(f.doubleValue()); (need to make it a Float first ofcourse)
So as you can see, the information is there, it is just rounded.
Hope this helps
This is due to the Internal Representation.
Floating-point numbers are typically packed into a computer datum as the sign bit, the exponent field, and the significand (mantissa), from left to right.
This is called as Accuracy Problems.
The fact that floating-point numbers cannot precisely represent all real numbers, and that floating-point operations cannot precisely represent true arithmetic operations, leads to many surprising situations. This is related to the finite precision with which computers generally represent numbers.
It is not a problem. It is how double works. You do not have to handle it and care about it. The precision of double is enough. Think, the difference between you number and the expected result is in the 14 position after decimal point.
If you need arbitrarily good precision, use the java.math.BigDecimal class.
Or if you still want to use double. Do like this:
double d = 5.5451521841;
NumberFormat nf = new DecimalFormat("##.###");
System.out.println(nf.format(d));
Please let me know in case of any doubt.
Actually this is only about different visual representation or converting float / double to String. Let's take a look at internal binary representation
float f = 0.23f;
double d = f;
System.out.println(Integer.toBinaryString(Float.floatToIntBits(f)));
System.out.println(Long.toBinaryString(Double.doubleToLongBits(d)));
output
111110011010111000010100011111
11111111001101011100001010001111100000000000000000000000000000
it means that f was converted to d1 without any distortion, significant digits are the same
double and float represent numbers in different formats.
Because of this you are bound to find certain numbers that store perfectly in one format but not in the other. You happen to have found one that correctly fits in a float but does not fit exactly in a `double.
This problem can also show itself when two different formatters are used.
Using the standard Java Double class to parse a floating point number with mantissa seems to omit the + sign from the exponent.
For example:
Double.parseDouble("1258124354E-28") returns 1.258124354E-19, but
Double.parseDouble("1243544322E+24") returns 1.243544322E33 (not E+33)
Is there any way to get the + sign using Double, without string post-processing?
The BigDecimal class does a better job, e.g.
new BigDecimal("1243544322E+24").toString() does return 1.243544322E+33
but it is generally slower than Double, which shows in intensive processing.
You need to differentiate between the value stored in a double and its string representation.
A double doesn't store a textual representation at all. 1.243544322E33 is 1.243544322E+33. They're the same value.
Now if you want to work on how you format a double value back to a String, that's a different matter - but the parsing you're doing is fine. You're not losing any information.
Jon is correct as above, its representing it correctly in memory. If you want it to display with the + on the mantissa then you are talking about string formatting the double.
Long winded official formatter reference
import java.util.Formatter;
double myDouble = Double.parseDouble("1243544322E+24");
Formatter formatter = new Formatter();
formatter.format("%+E", myDouble); //This should return with what you want, though with an extra + infront of the number
I haven't ran this code so I'm not 100% sure it will do the job. The + in the format specifier forces it to place a + or - sign for any number... I believe that extends to the mantissa.
I'm trying to convert a double to a string without notation, and tried this:
f= Double.valueOf(c.getString(c.getColumnIndex(NotesDbAdapter.KEY_VALUE)));
NumberFormat formatter = new DecimalFormat("###.##############");
However, the value of 7^3^7 is returning as: 558546000000000000 opposed to 558545864083284007. As always help would be greatly appreciated.
You already had the value as a String. Why convert it to double at all?
You can't get precision out of a double that it cannot hold. 558545864083284007 has 18 decimal digits. A double has 53 bits of binary precision, which is about 15.9 decimal digits. Google for 'What every computer scientist should know about floating-point'.
###.############## is not a suitable formatting mask for 558545864083284007.
If you already have the huge decimal number in string format, try using the BigDecimal class, something like this:
BigDecimal bigDecimalValue = new BigDecimal("1234567890123456789012345678901234567890.54321");
LOGGER.info("bigDecimalValue: {}", bigDecimalValue.toPlainString());
You should get back the original value with no precision loss:
bigDecimalValue: 1234567890123456789012345678901234567890.54321