Many mathematical operations simply do not work on arbitrary precision numbers. For example, SQRT(2), in a world of infinite precision, would never finish. Thus, the API is going to end up as a clunky mess where every operation requires a context to explain exactly how precise the answer would have to be. BigDecimal is that kind of library and is hence rather clunky. It's also prone to throw exceptions (that's what it'll do if you for example try to divide 2.0 by 3.0, as the result cannot be stored as BD without putting a limit on precision somewhere).
Nevertheless, yes, BD doesn't nearly have everything one could be looking for. Fortunately I've never run into the need to have more than BD has. Isn't integration of BigDecimal and BigInteger a bit of a red herring? You can just use BigDecimal everywhere, the impact of using it instead of a BigInteger on memory/CPU is probably negligible (as in, usage of BD/BI over primitive math is already gigantic, I doubt the small difference between BD/BI is going to be noticeable). What kind of operations are you doing if you want both performance and more precision than double can give you? That's an awfully fine line to walk. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
