I would add that arithmetic mixing floating points (e.g. Double) with fixed points aka decimals (e.g. BigDecimal) strongly smells like a broken design.
Decimals are only precise if your numbers don’t have more digits than your BigDecimal is configured to handle. For example, BigDecimal is imprecise for one third (0.3333…) and, with default precision, for (1e50 + 1).
Decimals are much more expensive than Doubles. Doubles are 8 bytes big and operations are hardware-supported simple atomic transactions, i.e. very fast. Decimals are user-level objects some dozens of bytes large, and every operation is complex and user-defined, i.e. very slow.
Doubles work excellent for most science, engineering and applied math use cases when used properly. If you ever find that Doubles are not precise enough, then almost always one of the following three is true:
(1) You have a pure math problem requiring many digits, like calculating the first million digits of pi, or finding the next biggest known prime number. In that case, neither Double nor BigDecimal will save you, and you will need your own custom types. (Ok, maybe BigDecimal may somehow work, but only if used very cleverly)
(2) You have some financial or legal use case that calls for decimals. For example, calculating an account balance, or appointing seats in parliament according to election results. In this case, BigDecimal will work, but only after you have made sure the rounding (MathContext) is exactly according to the rules.
(3) You are using the wrong algorithm. Ask yourself whether the end result will critically change if some numbers are slightly altered. If yes, your algorithm will not work. In particular, testing for equality is almost always an error. Testing for ordering is only fine if you can tolerate an unexpected ordering of numbers that end up close to each other.
For example, to get a Range of Doubles, a valid algorithm would be to first calculate the first and last number and number of intervals and then calculate all numbers from Int indices. On the other hand, repeatedly adding and comparing to some boundary is probably not useful.