Comment by olliej | Hacker News Reader

Comment by olliej | Hacker News Reader

Parent Full thread

Why is it not?

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.

That said even if the order necessarily does matter (infinite precision be alas unavailable), does not justify equality of different representations of the same value being incorrect.

Any justification for == not comparing the represented value applies equally to compareTo (which someone else suggested?)

More over operations on this type, if they can give precise/arbitrary representation should not matter if the input values are represented differently. If I perform the same operations on the same values, and in intermediate values are all representable, then the output should always be the same value.

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.

> 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)

> The blog post states “BigDecimal is a class in Java used to represent floating-point numbers with arbitrary precision”

That doesn’t mean BigDecimal is used exclusively for that purpose… If you ask an engineer if 2.5 and 2.50 are the same, they will say no. It’s clear from the implementation that BigDecimal was meant for more than just representing arbitrary precision floating points, which is why there is a pitfall if that’s all you use it for.

Btw that’s the reason it’s got Decimal in the class name - it’s modeling base10 strings, not numbers. If the strings are different it shouldn’t be equal.

>If you ask an engineer if 2.5 and 2.50 are the same, they will say no They will say it depends on the context. If you don't look into the implementation, the class name and maybe a short summary provides that context and clearly misleads people

Right, but in this case the short summary being posted is poor. In the context of a language like Java, floating point is synonymous with IEEE base-2 floats. BigDecimal is not used to store arbitrary precision floats, but rather fixed precision decimals. Otherwise it would be called BigFloat.

Also the scale parameter really isn’t an implementation detail. Virtually every non-trivial method defined in the class requires you to understand the scale parameter in order to get the result you want.

Reply on news.ycombinator.com