------_=_NextPart_000_01BF3C26.61BE21DC
Content-Type: text/plain


> -----Original Message-----
> From:	David N. Smith (IBM) [SMTP:dnsmith at watson.ibm.com]
> Sent:	Tuesday, November 30, 1999 6:44 PM
> To:	squeak at cs.uiuc.edu
> Subject:	RE: Intervals
> 
	<snip!>
> There is no way to compare floats 
> for equality that does not fail because of base conversion or 
> computational error problems.
> 
> It's one of the basic rules of nature:
> 
>     Never compare two floats for equality.
> 
> It right up there with "Don't tug on Superman's cape".
> 
> 
> Some languages have introduced the concept of ~fuzz~ for comparisons, 
> but that IMHO is simply a way to encourage people to use floats 
> without understanding them.
> 
> Besides, how big is the ~fuzz~? Would it allow intervals like this to
> work?
> 
>     (1.0e-200 to: 5.0e-200 by: 0.5e-200)
> 
> or would a ~fuzz~ of 1.0e-15 overwhelm the #to: value in the 
> interval? Would it solve problems when the exponents are huge:
> 
>     (1.0e200 to: 5.0e200 by 0.5e200)
> 
> In comparison to 1.0e200, a fixed fuzz value of 1.0e-15 or whatever 
> makes no difference at all.
> 
> Floats have a wide range for exponents on purpose; they do get used. 
> If you want the diameter of an electron in centimeters you don't do 
> it without very small exponents. If you want the diameter of the 
> universe in meters you don't do it without very large exponents.
> 
I think we're in agreement here.  After pondering about it overnight I now
think that the solution we've been discussing (a one-size-fits-all hack to
Interval) is not the right approach.  As I mentioned yesterday, the
class-side methods in Interval indicate that Intervals are supposed to have
Integers for the start, stop, and step values.  Given that, I think that
hacking Interval to support Float values is...well, it's a hack.  (Not that
there's anything wrong with hacks - some of my best friends are hacks...
:-).  I think that what's needed is a subclass of Interval intended to
handle non-integer start, stop, and step values, with provision for
appropriate fuzzy comparisons.  The change set to add FuzzyIntervals to
Squeak is attached.  Note that there's no attempt in FuzzyInterval to scale
the fuzz value by the step, as suggested by Peter Crowther.  Since
FuzzyInterval provides the user with the ability to set the fuzz factor I
think it's fair to hold the user responsible for choosing an appropriately
fuzzy value.  I also changed the class comment in Interval to state that it
expects integers for its start, stop, and step values, modified the names of
a couple parameters in Interval methods to clearly indicate they expect
integers, and added appropriate methods to Number to simplify the creation
of FuzzyIntervals.  

> Note that FORTRAN, the most widely used scientific and engineering 
> programming language (80% or more of the market) does not have 
> ~fuzz~. There is no reason why Smalltalk needs it either.
> 
But FORTRAN has no concept of encapsulation, so fuzz factors get sprinkled
willy-nilly through the code.  With FuzzyIntervals I'm attempting to
encapsulate the fuzz (lint trap? :-), at least as far as Intervals go.  

Also note that I'm still not calling this either a fix or an enhancement
because I haven't given it extensive testing, nor have I (yet) gone through
the 300+ senders of #includes: to see if anything might break.  I'd
appreciate any feedback anyone cares to offer.

Bob Jarvis
Compuware @ Timken

>  <<Interval changes.1Dece1251pm.cs>> 

------_=_NextPart_000_01BF3C26.61BE21DC
Content-Type: text/plain; name="Interval changes.1Dece1251pm.cs"
 ; x-mac-type="65417070"
 ; x-mac-creator="43534F6D"
Content-Disposition: attachment; filename="Interval changes.1Dece1251pm.cs"
Content-Transfer-Encoding: imap_stub

0,1885,2,5896,0,

------_=_NextPart_000_01BF3C26.61BE21DC--