> It's just one more funny thing one must realize, > when comparing real numbers with some exact > real constants. After this, I will try to never > compare doubles directly, but using tricks like > above. Because, in this digital world > 1 + 0.4 - 0.4 <> 1.
In binary that is 00000001 + 0.0110011001100.... - 0.0110011001100.... because we hit recurring decimals a lot more in binary than decimal. I wonder why we don't have a standard format (maybe we do?) that factors in the remainder as part of the number also? 4 bits with recurring fraction ("decimal") debugging power could do some good. Maybe it's just too messy and slows FP operations even more. Would think that 0000 for recurring length too big, 0001 for no recurring, and 0010-1111 (2-15) would be length of recurring bits from lsb. Not sure if one would be able to detect longer easily. That would be able to cover 4 decimal digits of repeating bits. 0.0110011001100 (was 4/10) + 0.0110011001100 (was 4/10) + 0.0011001100110 (was 2/10) = 0.1111111111111 (was 10/10) (0.0000000000001 short) With the above, they all repeat on 4 bits: 1100 1100 0110 =11110 - this would translate to a series of 1s if recurred. Would here be able to surmise that we need to add the 0001 that is short. because the recursion has been undone. It would probably lead to a pile of new problems but, that's another story. Stephen *----------------------------------------------------------------------- This E-Mail may contain confidential and/or privileged information. It is only intended for the use of the addressee indicated in this message. If you are not an intended addressee of this email (or responsible for delivery of the message to such person), the disclosure, copying or delivering of the contents of this email to anyone else is strictly prohibited and may be unlawful. If you receive this e-mail by mistake destroy the message and please notify us immediately by e-mail, [EMAIL PROTECTED] Information or opinions in this message that do not relate to the business of ELCB Information Services shall be treated as neither given or endorsed by it. *----------------------------------------------------------------------- _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal