Take the 2-minute tour ×

Is there a generally accepted way to get Euler's number in BigDecimal?

I basically want to do Math.exp(double a) and I basically want the same function but calculated using BigDecimal to prevent precision loss with other calculations.

I thought of just doing,


But not sure if that's the right way to approach the problem.

share|improve this question
Your current approach is definitely not gonna give you more than about 16 digits of accuracy. You're gonna need to actually compute e to whatever your target precision is. –  Mysticial Aug 7 '12 at 23:57
@Mysticial Just read your post on branch predictors, you're awesome. So in this case, regardless of however precise other numbers are in future calculations, such as if I do the above BD.(Math.E).pow(x), I'll at most get the precision of whatever the double value of e is correct? –  congalong Aug 8 '12 at 0:03
For the most part, yes. To oversimplify things a bit: Outputs are only going to be as accurate as the least accurate input. So if your input is e accurate to a double (~16 digits), your output isn't gonna be any better than 16 digits. In your particular case, you seem to want a fully generic exp() function. You can just use the taylor series of exp(x). No need to compute e. No need to power anything. Raising things to non-integral powers is not easy to implement. –  Mysticial Aug 8 '12 at 0:08
@Mysticial Thanks makes sense. I'm just a junior developer that's been tasked with porting this code over to a new application. I wanted to write a few test cases to prove that writing the application using BigDecimal instead of Double is more accurate in the long run in edge cases. :) –  congalong Aug 8 '12 at 0:11
Depending on what that application is, BigDecimal might not even be necessary. (especially if it becomes a performance bottleneck) exp(x) is the easiest of non-trivial functions to implement because of that taylor series. Stuff like log(x), and the trig functions are - well... don't even try unless you want to get messy. sin() and cos(x) also have trivial series expansions, but they have horrific numerical stability if used naively. –  Mysticial Aug 8 '12 at 0:16

3 Answers 3

up vote 2 down vote accepted

The problem is that Euler's number is irrational; in BigDecimal, you'd have to have infinite memory to hold it. The reason there's no previously-stored value is that however many decimal places you needed, you wouldn't have the right number for your current application.

You're going to have to determine how many decimals you want, then construct the BigDecimal representation using the String constructor (new BigDecimal("2.71828...")).

share|improve this answer
yep. you can get more precision, but ultimately you can't prevent precision loss - you need infinite memory to do that –  Bohemian Aug 8 '12 at 0:00
Assuming the OP doesn't know the values beforehand, he could also approximate it to whatever using its Taylor series expansion. –  Dennis Meng Aug 8 '12 at 0:00

Well, Math.E is a double. If you want a higher precision representation of Euler's number, you can create it with some arbitrary precision of decimal places, or there are BigDecimal math libraries with a really high precision version of E.

You could approximate one yourself with something like this: Better approximation of e with Java

share|improve this answer

While the double Math.E should be accurate enough for most calculations, there is a way to calculate e to greater accuracy.

If you want to get e that has more accuracy that double can contain, you calculate it by adding up the sum of 1/0!, 1/1!, 1/2!, 1/3!...

Where ! means factorial. Just add up the reciprocal of all the factorials starting from zero. The more terms you add up, the more precise you will get. Of course since e is irrational, you can never get the real value, but you can get pretty darn close.

share|improve this answer

Your Answer


