Meaning of Float>>closeTo:

Hi,

I would like to know what is the exact meaning of #closeTo:.

999999 closeTo: 999899.00011.             => true
999999 closeTo: 999899.0001.               => false

Is it a bug ? Is it a problem with how computer deal with floating
point numbers ?

--
Damien Cassou

On Mar 2, 2007, at 12:55 , Damien Cassou wrote:

> Hi,
>
> I would like to know what is the exact meaning of #closeTo:.
>
> 999999 closeTo: 999899.00011.             => true
> 999999 closeTo: 999899.0001.               => false
>
> Is it a bug ? Is it a problem with how computer deal with floating
> point numbers ?

No, one is just closer than the other. One is below the threshold and  
one above.

- Bert -

2007/3/2, Bert Freudenberg <[hidden email]>:
> On Mar 2, 2007, at 12:55 , Damien Cassou wrote:
> > 999999 closeTo: 999899.00011.             => true
> > 999999 closeTo: 999899.0001.               => false
> >
> > Is it a bug ? Is it a problem with how computer deal with floating
> > point numbers ?
>
> No, one is just closer than the other. One is below the threshold and
> one above.

I don't understand. We are talking about 2 numbers close to 1 million.
I don't see how adding 0.00001 to one number can totally change the
result.

--
Damien Cassou

On Mar 2, 2007, at 13:56 , Damien Cassou wrote:

Huh? Should it answer "maybe"? There is a threshold, and you chose  
your numbers right at that threshold.

- Bert -

2007/3/2, Bert Freudenberg <[hidden email]>:
> On Mar 2, 2007, at 13:56 , Damien Cassou wrote:
> > 2007/3/2, Bert Freudenberg <[hidden email]>:
> >> On Mar 2, 2007, at 12:55 , Damien Cassou wrote:
> >> > 999999 closeTo: 999899.00011.             => true
> >> > 999999 closeTo: 999899.0001.               => false
> >> >
> Huh? Should it answer "maybe"? There is a threshold, and you chose
> your numbers right at that threshold.

I think the answer should be the same. Look at the differences:

999999 - 999899.00011.                          => 99.9998899999773
999999 - 999899.0001.                            => 99.9999000000535

It's nearly a hundred in both cases.

999999 closeTo: 999899.00011.            => true (with a difference of
nearly 100)
2 closeTo: 1                                               => false
(with a difference of 1)

So, what is the threshold ?

--
Damien Cassou

"Damien Cassou" <[hidden email]> wrote:

0.0001? ( According to Float>>closeTo: )

frank

2007/3/2, Frank Shearar <[hidden email]>:
Ok, so if two numbers have nearly 100 of difference, #closeTo:
shouldn't answer true. Right ?

--
Damien Cassou

"Damien Cassou" <[hidden email]> wrote:

Ah, but #closeTo: (on closer reading) doesn't just do |a - b| < threshold.
The idea of "close to" depends on the magnitudes of the numbers involved:
99999 and 999899.00011 are close to each other because their difference
(99.9998899999773) is less than a thousandth of the magnitude of the larger
number (which is 100).

What confused me the first time is that the threshold value (in the sense of
|a-b| < threshold) is the same as the threshold value in the sense of |a-b|
< max(a, b)*threshold.

frank

On Fri, 2 Mar 2007 15:06:03 +0100, "Damien Cassou"
<[hidden email]> wrote:

> Ok, so if two numbers have nearly 100 of difference, #closeTo:
> shouldn't answer true. Right ?

If you look at the routine, it basically says two numbers that are within
0.01% of each other. Large numbers don't have to be as close as small
numbers.

For the first example:

999999.0 closeTo: 999899.00011
999999.0 closeTo: 999899.0001

You've found the exact threshold where it rolls over from being < 0.01% to
> 0.01%.

Whether it *should* work this way is another question, but it certainly
seems consistent...

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

2007/3/2, Jon Hylands <[hidden email]>:
> Whether it *should* work this way is another question, but it certainly
> seems consistent...

Sure, the result is consistent with the implementation :-) But do we
really want that meaning ?

--
Damien Cassou

On Mar 2, 2007, at 15:57 , Damien Cassou wrote:

> 2007/3/2, Jon Hylands <[hidden email]>:
>> Whether it *should* work this way is another question, but it  
>> certainly
>> seems consistent...
>
> Sure, the result is consistent with the implementation :-) But do we
> really want that meaning ?

It's a very sensible definition of "close to":

{
1.1 closeTo: 1.0.
10.1 closeTo: 10.0.
100.1 closeTo: 100.0.
1000.1 closeTo: 1000.0.
}

#(false false false true)

- Bert -

On Fri, 02 Mar 2007 07:58:02 -0800, Bert Freudenberg  
<[hidden email]> wrote:

> It's a very sensible definition of "close to":
>
> {
> 1.1 closeTo: 1.0.
> 10.1 closeTo: 10.0.
> 100.1 closeTo: 100.0.
> 1000.1 closeTo: 1000.0.
> }

If it be an issue then why not extend:

1.1 closeTo: 1.0 within: 0.01  "...so 1%, which would be false here..."
10.1 closeTo: 10.0 within: 0.01 "...true, assuming <=..."

?

I'd say that depends on what you're using it for,
on the precision and context of expected values.

1.1 is very close to 1 for some situations
(if you expect the range of the value to be (-infinity, infinity),
or if you're working with very rough numbers of only a digit's worth  
of precision,
then 1.1 is very close to 1)

1000.1 is not really very close to 1000 in others
(if you're working to full precision, 0.0001 is a pretty big epsilon.)

Float  'closeTo:' meaning within 1/1000th of,
seems to me like being a bit too casual about putting
a fairly specialized test  that someone found useful once or twice
into the general platform as if it were a general utility.

Imagine it were more horribly, but accurately, named
        x withinOneTenthOfOnePercentOf: y,

clearly that's going to be useful sometimes, but it hasn't
the false aura of general utility that comes with the -name- 'closeTo:'

I don't think the long-named version would be taken as a
sensible candidate for inclusion in the platform,
and not just because of the name...

-brad

Hi All,

Maybe #closeTo: has a financial background as 0.01% is 1 basis point. A
basis point is used to denote the change in a financial instrument
(http://en.wikipedia.org/wiki/Basis_points).

- Zulq.


Jon Hylands wrote:

> You've found the exact threshold where it rolls over from being < 0.01% to
>> 0.01%.
>
> Whether it *should* work this way is another question, but it certainly
> seems consistent...

Zulq Alam a écrit :
Hi,

I would have conjectured it was used in Screen coordinates transform.
Since Screen have not more than a few thousands pixels...

But browsing senders, they are not so many in base image
- MethodFinder
- Float>>reduce
- Player>>setHeading:

The first, i didn't understand the power yet. Anyway MethodFinder
implementation is not in the lightweight category, so my instinct tells
me to keep away...

The last is highly arguable, since the message is very general.
Fortunately there is hardly no user of reduce in Squeak (Argh i used
reduce in Smallapack getting a 1e-4 accuracy when i try to reach 1e-15,
but since i have other problems i don't care yet)

Player setHeading: is OK. As long as we do not throw players in
intergalactic missions, such an accuracy is well enough.
Except if headings were accidentally provided as Fraction, which would
mean no approximation, but i guess they aren't.


Nicolas

By the way, while watching Player's code what a usefull comment!
setHeading: newHeading
        "Set the heading as indicated"
One should better explain me expected unit and other conventions (0
upscreen ? positive clockwise ? )
Something not really indicated.

Inquiring Morph>>heading is helpless
heading
        "Return the receiver's heading (in eToy terms)"

If i browse Morph comments, nothing.
I then click TransformMorph link and there i get
"Rotation and scaling are relative to the local origin, (0@0)."


Fortunately Kedama is more explicit, and win a Medals
heading
        "Answer my heading in degrees."

Also senders of #setHeading: will provide informations.

Still i know nothing about zero and clockwise but for that i can reverse
engineer the code...
And #setHeadingTheta: tells me there is another convention lying in the
system, but nothing more...

Well easy to criticize, but i think we are all responsible of providing
better comments.
- not paraphrasing the code or the method name
- not to long (better give a reference to a document, tutorial or whatever)
- clues about limitations, non trivial implementation choices...

Or maybe like pair programming, programmer should not write the comment.

Nicolas

So, what should I do ?

--
Damien Cassou

On Mar 5, 2007, at 10:33 , Damien Cassou wrote:

> So, what should I do ?

Document the behavior in the comment?

- Bert -