On 01.09.2007 22:33, Kyle Schmitt wrote:
> On 8/31/07, Logan Capaldo <logancapaldo / gmail.com> wrote:
>> On 8/31/07, Kyle Schmitt <kyleaschmitt / gmail.com> wrote:
>>> On 8/30/07, doug meyer <doug.meyer / sigeps.org> wrote:
>>>> There is also a class called BigDecimal (or something like that) if
>>>> you want to have really accurate numbers and no floating-point errors.
>>> A warning on things like BigDecimal.
>>> Unless I'm mistaken it's still stored in twos compliment, which means
>>> you'll still end up with the same sort of floating point problems
>>> (albeit further down), and the same numbers that you can't express
>>> exactly with a normal float, can't be expressed exactly with a
>>> BigDecimal.
>>>
>> Um, 2's compliment is not a cause of floating point error. IEEE
>> floating point numbers do not use two's complement, they have a sign
>> bit. Two's complement is just a way of encoding the sign of a value.
> 
> Used the wrong term :P sue me.  I guess that's why I should lookup
> stuff before responding ;)
> Anyway it's all based on the fact that you can't store some numbers
> exactly as sum of different xes for 2**(-x).

BigDecimals do *not* use binary representation.  That's why they are 
called Big/Decimal/.

If you want to give a warning then it should be that for *any* 
representation (binary, decimal, hex, octal whatever) there are 
fractional numbers that cannot be represented properly with that 
representation.  You have to be aware of this for *all* representation 
types.  The reason people are surprised is typically because we enter 
float numbers in decimal but systems use binary representation (which is 
standardized btw.) internally and that has other numbers that it cannot 
properly represent.  BigDecimal helps because it uses the same 
representation internally that we are used to use for numbers - decimal 
digits.

Kind regards

	robert