bigDecimal.doubleValue() + bigDecimal2.doubleValue()
just because Java does not have operator overloading and using methods instead of familiar operators was ugly.
Anyway, BigDecimal has an add() method (overloaded for rounding behaviour)
bdResult = bd1.add( bd2 )
Using it for formulas makes for wonderful code.
Try
y = (5x^3 - 3x^2 + 7x + 1)/(3x^2 - 7x)
Side note: the notation we have is not that old; but as soon as people actually started working with polynomials, they invented notation that makes it sane.
That's to say, Java's .add() is so 1400's.
There are languages that allow for a cleaner way to express mathematical statements, this is valid Julia:
julia> p(x) = (5x^3 - 3x^2 + 7x + 1)/(3x^2 - 7x)
p (generic function with 1 method)
julia> p(1 + 2im)
2.4 + 0.2imLet us compare:
> bigDecimal.doubleValue() + bigDecimal2.doubleValue()
vs.
> bdResult = bd1.add( bd2 )
The first code is longer (two methods calls, which each do a conversion, one addition, and probably omitted some conversion back to BigDecimal). The second one is just one simple method call. I would strongly argue that the second, right way is much easier than the wrong way.
The primitive types in Java and their operators have always been a hack for performance in the object-oriented type system of Java. So if such code exists in the program, there can be very good reason (in particular performance), but it always has "code smell". So it always should be commented properly.
> if the developers are unaware of the implications
You do not do such a conversation if you have not read into the implications.
bdP = bdA / pow((1 + bdr / bdm), (bdm - bdt));
bdP = bdA.divide((ONE.add(bdr.divide(bdm))).pow(bdm.subtract(bdt)));
Obviously the first is more transparent than the second and this isn't a particularly complicated equation. Mind you that this can be mostly mitigated by splitting up the equation but that can sometimes make solutions quite opaque comparatively.