On Thu, 25 Mar 2010 01:39:50 -0700, "Robbie Hatley"
<see.my.signat...@for.my.contact.info> wrote:Only by the unfortunate accident that all the values in question had
>"Barry Schwarz" wrote:
>> "Robbie Hatley" wrote:
>> > The <= issue is also now fixed. I used a +0.0001 "fuzz zone".
>> It is not fixed.
>Oh, but it *is* fixed.
>> You have simply camouflaged it.
>No, I "fuzzed" it. Read on.
>> You have managed to obtain the output you want
>Precisely. By adding a "fuzz zone" of 0.00001 in a program
sufficiently few significant digits. Since a double is guaranteed to
have at least 10 significant digits, 40. + 0.00001 will always be
greater than 40. But on a system where float has only 6 significant
digits, 40.f + 0.00001f will be equal to 40.f. In this situation,
your "fuzz zone" will do nothing.
Not if you believe what you wrote above. My system has built in
>This "fuzz zone" approach can work well with much less code bloat
>(So why was I even asking about this here, if I already know
>> with no understanding of what the real issue still is!
>I understand the problem
decimal floating point and I don't need the fuzz at all if the
fraction does not exceed the number of significant digits a double can
>But as for 0.2, I'm not sure why it can't be exactly represented.One procedure for converting a decimal fraction to binary is to
>Perhaps you can enlighten?
multiply by two, use the integer portion, and repeat with the
fractional portion, stopping when the fraction is 0
For example, 0.375 * 2 = 0.75; keep the 0. 0.75 * 2 = 1.5; keep the
Now try it with 0.2 and let me know when the process terminates.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.