> The blog post states “BigDecimal is a class in Java used to represent floating-point numbers with arbitrary precision” > Which means that the order should no

> The blog post states “BigDecimal is a class in Java used to represent floating-point numbers with arbitrary precision” > Which means that the order should not semantically matter. Arbitrary precision in the sense that you can set an arbitrary precision on your BigDecimal which then gets carried through. 1/3 = 0, 1.0/3=0.3, 1.00/3=0.33 etc. > Any justification for == not comparing the represented value applies equally to compareTo (which someone else suggested?) No it doesn't. equals (not the same as == in Java) is meant to mean equivalent in the program, liskov-substitutable for. compareTo is meant to compare ordering. It's ok to have values that are nonequal but compare the same for ordering purposes. > If the actual intent of this type is “equals is an invalid way to compare values” the equals should throw when the values are the same but the representation is different. equals is valid, it just compares something different from the mathematical value. This is the normal behaviour in programming (equals does not understand the domain, if your program has multiple representations for things that are equivalent in the domain then those representations will should still compare unequal unless they have completely equivalent behaviour in your program)