Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.c
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Equality failure in <=.
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Barry Schwarz  
View profile  
 More options Mar 25 2010, 11:35 pm
Newsgroups: comp.lang.c
From: Barry Schwarz <schwa...@dqel.com>
Date: Thu, 25 Mar 2010 20:35:21 -0700
Local: Thurs, Mar 25 2010 11:35 pm
Subject: Re: Equality failure in <=.
Print | View thread | Show original | Report this message | Find messages by this author
On Thu, 25 Mar 2010 01:39:50 -0700, "Robbie Hatley"

<see.my.signat...@for.my.contact.info> wrote:

>"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
>where the numbers are increasing in increments of at least
>0.001 (100 times larger), I've "fuzzed-out" (or "overloaded",
>in C++ lingo) the meaning of operator "<=" to mean
>"less-than OR approximately-equal-to-give-or-take-0.00001",
>which cures the problem in the most-direct and simplist way.

Only by the unfortunate accident that all the values in question had
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.

>This "fuzz zone" approach can work well with much less code bloat
>than the "convert-to-integers" method, PROVIDED that you can find
>a fuzz value that is at least an 2 magnitude smaller than the
>"granularity" of the numbers involved, and 4 orders of magnitude
>larger than the floating-point errors involved.  In some cases,
>that can't be done, and you have to use "convert-to-integers".
>But In the case of my temp conversion programs, a suitable
>fuzz value was very easy to find, because the granularity is
>known.

>(So why was I even asking about this here, if I already know
>these two methods?  Simple: I was wondering if anyone knew
>any *OTHER* methods I hadn't considered.)

>> with no understanding of what the real issue still is!

>I understand the problem

Not if you believe what you wrote above.  My system has built in
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
hold.

snip

>But as for 0.2, I'm not sure why it can't be exactly represented.
>Perhaps you can enlighten?

One procedure for converting a decimal fraction to binary is to
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
1.  0.5 * 2 = 1.0; keep the 1 and stop.  The binary representation of
0.375 is 0.011.

Now try it with 0.2 and let me know when the process terminates.

--
Remove del for email


 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google