>BigDecimal has an add() method

Using it for formulas makes for wonderful code.

Try

    y = (5x^3 - 3x^2 + 7x + 1)/(3x^2 - 7x)

See how readable that is using methods like .add()

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 is no argument from me that a + b is more readable than a.add(b). Java founding fathers (Gosling?) decided against operator overloading sighting the mess it allowed to created in other languages. The mathematical notations for spelling out polynomials has been optimized over some time - Java being a general purpose programming language has other fish to fry.

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.2im

No, but the right way should at least be easier than the wrong way.

> No, but the right way should at least be easier than the wrong way.

Let 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.

It's possible that real world code that converts to double uses temporary variables and a more complicated expression involving other operators with different precedence. Converting all that to method invocations would require refactoring the expression and if the developers are unaware of the implications (because of a lack of education in numerical methods) they might think that switching to temporary variables and preserving the expression is the safest way to adapt the code to some library that suddenly deals with that funny new numeric type. After all, if all tests (if any exist) pass...

> It's possible that real world code that converts to double uses temporary variables and a more complicated expression involving other operators with different precedence.

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.

Now how about a more complex example?

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.