Develop Reference

How to convert BigInteger to scientific notation [duplicate]

I want to convert BigInteger number into a small scientific notation like 1.86e+6 and again reconvert that scientific notation into BigInteger number in Java. Please help.

The easiest way is to use a BigDecimal to parse or output the scientific notation string.
You can can do something like:
BigDecimal bd = new BigDecimal("1.86E+6");
BigInteger bi = bd.toBigInteger();
and reverse:
bd = new BigDecimal(bi);
String s = bd.toString();
Update
If you need more user-defined output, then you can use NumberFormatter. Don't forget to set the Locale to something like Locale.ROOT, so you won't get, say a comma as the decimal separator (which is what I got first, in the German locale). Example:
// Create a large, ugly number.
BigInteger bi = BigInteger.valueOf(1001).pow(345);
// Convert to scientific notation using invariant Locale.ROOT
NumberFormat formatter = new DecimalFormat("0.######E0", DecimalFormatSymbols.getInstance(Locale.ROOT));
String str = formatter.format(bi);
System.out.println(bi);
System.out.println();
System.out.println(str);
// No need for a formatter here.
BigDecimal bd = new BigDecimal(str);
BigInteger output = bd.toBigInteger();
System.out.println();
System.out.println(output);
The output of this is:
1411746534642247386926682895653605505594156007645319584856454985824576909030651172402258145880680847831210464829918490010166811079002972726937057623073994129575640372154237767652434547101885830188958723868572869883365738143353635151476880747344348010706072986535185748982964423793694140085891791220972791882178323235649877119554541663599295787824745711388310165587991341807160511741076029768404282877856115942906536866189181255514197337418597936644390730217525723115231014147849887446040444969336884906158293521291748134217314005889949484320602720371789914893639795254884800520873191697159041280591046403928290350948505388703036712226506136642305960716764124836947362932720418554290195995002114233675196543233402547357577387336805972842986766416381431727078044233139876612983206051371851773391882427929601311695575660371227105236375213782469513349953017524299926322617324052803634576283153878896093739315873095260971811967828941219651149370566639839402498088185721432957408746669159107050035686712174548658001777149571278954599340345001
1.411747E1035
1411747000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(Yes, BigIntegers can be unwieldy).
I don't know how big your values are, but the above works well on my Mac. Of course, using scientific notation with only a few decimal digits will lose a lot of precision.

BigDecimal methods send formatted numbers

I'm trying to round my big BigDecimals off to three decimal places. For instance, let's say I have some
BigDecimal X = 1362.59633
I wanna get:
1362.596
Here is what I'm doing:
BigDecimal Y = X.round(new MathContext(3));
But I keep getting this: 1.36E+3.
What should I do in this case?
Thanks

You actually don't have to round but you have to set the scale of your BigDecimal:
BigDecimal X = new BigDecimal("1362.59633");
X = X.setScale(3, BigDecimal.ROUND_HALF_UP);
System.out.println(X.doubleValue());
This will print out 1362.596.
Note that setScale returns a new BigDecimal so you have to assign it like I did in my example.
edit: there are several kinds of rounding strategies. Check the BigDecimal class for reference. I edited my answer to use BigDecimal.ROUND_HALF_UP.

BigDecimal X = new BigDecimal(1362.59633);
X = X.setScale(3,RoundingMode.HALF_EVEN);
System.out.println(X); //1362.596
Note that since BigDecimal objects are immutable, calls of this method
do not result in the original object being modified, contrary to the
usual convention of having methods named setX mutate field X. Instead,
setScale returns an object with the proper scale; the returned object
may or may not be newly allocated.

BigDecimal y= x.round(new MathContext(7, RoundingMode.HALF_EVEN));
This should work for you.

If you use only double you can do
double d = 1362.59633;
double d2 = Math.round(d * 1e3) / 1e3;
System.out.println(d2);
prints
1362.596
Note: this doesn't create any objects to perform the rounding.

We can use DecimalFormat class to define the format of the double data. You can define like new DecimalFormat("####.000")
we can call format method the value you want.
Example
DecimalFormat format = new DecimalFormat("####.000");
format.format("1362.59633");

First set the scale to 3 using setScale with RoundingMode.DOWN as the rounding mode to truncate
Then call toPlainString to guarantee the return of a String representation without an exponent field
Calling toString on a BigDecimal does not guarantee the return of a String without an exponent. It returns the string representation using scientific notation if an exponent is needed
An example based on your question:
BigDecimal x = BigDecimal.valueOf( 1362.59633 );
System.out.println( x.setScale( 3, RoundingMode.DOWN ).toPlainString( ) );

Equivalent to bcdiv from php in java

What is the equivalent of bcdiv(string, string [, int]) in java
the function divides two arbitrary precision numbers
I would like for instance to use:
bcdiv(10000,100, 2) results in 100.00
or
bcdiv(10000,100, 3) result in 100.000
I am more interested in the precision it gives.
I would like its equivalent in java
link to the php manual

The BigDecimal class allows arbritary precision math. In particular see the divide method.
BigDecimal a = new BigDecimal(10000);//Can take int
BigDecimal b = new BigDecimal("100");//Or string
BigDecimal answer = a.divide(b);

The number has defined structure, but you can format String produced from this number:
String.format("%.2f",10000/100f);

Move decimal point in double

I have this code:
Long dval = new Long((new Date()).getTime());
System.out.println("ogval:"+dval);
Double dd = (double)dval;
System.out.println("dval:"+dd);
Here is the output:
ogval:1381490769636
dval:1.381490769636E12
When I convert the value to Double, it adds a decimal point. Can I do the typecasting and get the value in double as it is?
The desired output would be:
ogval:1381490769636
dval:1381490769636
I have a function whose argument accepts only double value. When I try to pass a timestamp, it passes the decimal value inside the method.
I can't edit the function because its an inbuilt function of some package.

Simple answer is no.
Floating types can contain integer up to some arbitrary value, given by the way floats are stored. If the number is too big, it gets converted to decimal.
If you need to work with big integer values use BigInteger class.
Great tool to examine those imperfections is this float converter.
Try 123456789 in the float converter, it won't be stored exactly.

Use DecimalFormat, like:
Long dval = new Long((new Date()).getTime());
System.out.println("ogval:" + dval);
Double dd = (double) dval;
DecimalFormat format=new DecimalFormat("##########");
System.out.println("dval:" + format.format(dd));

Your problem is not with the type that you are using, but with the format that you are applying to it. Currently, the default format is used, because string + double implicitly calls Double.toString, which converts your specific double to a String using scientific notation. You can force a different format if you wish by using printf or any other formatting method that Java makes available to you:
System.out.printf("dval: %12.0f", dd);
(demo)

as an alternative you can try using bigdecimal
Long dval = new Long((new Date()).getTime());
System.out.println("ogval:"+dval);
Double dd = (double)dval;
System.out.println("dval:"+dd);
BigDecimal bd = new BigDecimal(dval);
System.out.println("bdval:"+bd.toPlainString());

Converting numeric value with currency symbol back to Decimal with NumberFormat

I would like to convert a possibly Decimal value prefixed with currency symbol into only numeric value.
For example -
The value can be like any of the following
String s1 = "£32,847,676.65";
String s2 = "£3,456.00";
String s3 = "£831,209";
I would like the result after conversion to be like - 32847676.65, 3456.00 and 831209.
I tried using the parse() method of the NumberFormat in this way -
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.UK);
numberFormat.setMinimumFractionDigits(2);
Number num = nf.parse(s1);
double dd = num.doubleValue();
BigDecimal gg = new BigDecimal(dd);
System.out.println(gg);
But the result is - 32847676.649999998509883880615234375 which is not quite exactly the correct one.
I need it to be numeric so that may be I can perform some kind of calculation.
Can you guys guide me with what else can I try

You already parse the value correctly. The problem is this:
BigDecimal gg = new BigDecimal(dd);
You covnert the value to BigDecimal, and the rounding problems of doubles account for the decimal places after the dot. Use:
BigDecimal gg = new BigDecimal(dd).setScale(2);
or
BigDecimal gg = new BigDecimal(dd).setScale(2,RoundingMode.HALF_UP);

When playing with BigDecimal, the appropriate constructor is BigDecimal(String val)
NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.UK);
BigDecimal gg = new BigDecimal(nf.parse(s1).toString());
System.out.println(gg);
BigDecimal(double val) does construct an exact decimal representation of the double value, which is not the human readable value you expected.
"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.
[...]
Therefore, it is generally recommended that the String constructor be used in preference to this one"
Source : BigDecimal javadoc

You can try the following without BigDecimal or NumberFormat. ;)
String s1 = "£32,847,676.65";
// remove the £ and ,
String s2 = s1.replaceAll("[£,]", "");
// then turn into a double
double d = Double.parseDouble(s2);
// and round up to two decimal places.
double value = (long) (d * 100 + 0.5) / 100.0;
System.out.printf("%.2f%n", value);
prints
32847676.65
If youw ant to avoid rounding error in your calculations but don't want the heavy weight BigDecimal you can use long cents.
// value in cents as an integer.
long value = (long) (d * 100 + 0.5);
// perform some calculations on value here
System.out.printf("%.2f%n", value / 100.0);

It is not guaranteed to work, but according to the NumberFormat API documentation, its getXyzInstance methods will return a DecimalFormat instance for "the vast majority of locales". This can probably be interpreted as "for all locales, unless proprietary locale service providers are installed".
If you can cast your NumberFormat to DecimalFormat, you can tell it to parse to a BigDecimal directly, reducing your code to:
DecimalFormat nf = (DecimalFormat) NumberFormat.getCurrencyInstance(Locale.UK);
nf.setParseBigDecimal(true);
BigDecimal gg = (BigDecimal) nf.parse(s1);
System.out.println(gg);
In this case, you will have no problem with the inaccuracy of binary floating point numbers.