Intervals

Stephan Rudlof sr at evolgo.de
Mon Dec 6 01:05:59 UTC 1999


Dear Squeakers!

"Andrew P. Black" wrote:
> As I indicated earlier, I believe that expecting Intervals to work
> for floats is misguided, so I agree with the philosophy of making a
> separate subclass for floats.

That's it!

After the long discussion it seems to be obvious for me that using
floats while constructing an object of class Interval and so mixing
mathematical and collection semantics leads to confusion and many
problems.

Suggestion:

- define/declare Interval as only responsible for integer intervals -
it is derived from SequencableCollection! -, integers for start, stop
and step;
- define a new MathInterval after the proposals of Andrew and Torsten,
which is responsible for testing if some number lays inside it or not;
- define a method asMathInterval in Interval.

Then testing for a real number in an (integer) Interval becomes:
        (Interval from: anInteger to: anInteger) asMathInterval
includes: aNumber
..
Advantage: there would be a _clear_ border between the mathematical and
collection semantics.

Computation with floats would look like - most people know that -:


| start stop steps step |
start = 0.1.
stop = 0.2.
steps = 10.

step = (stop - start) / steps.

0 "!" to: steps do: [:ix |
        num = start + (ix * step).
        "make something with num"
].


The loop will be performed 11 times in this case (but we go in 10 steps
from start to stop...)!

Advantages:
- works also with negative steps (start > stop),
- hits stop number as exactly as possible.

Greetings,

Stephan


P.S.: Interval creation method #from:to:by: assumes Integers as given
parameters:

from: startInteger to: stopInteger by: stepInteger 
	"Answer an instance of me, starting at startNumber, ending at  
	stopNumber, and with an interval increment of stepNumber."
	^ self new
		setFrom: startInteger
		to: stopInteger
		by: stepInteger




"Andrew P. Black" wrote:
> 
> Dan writes:
> 
> >Would you (or anyone else here -- volunteers?) be willing to examine the
> >senders
> >and change those that need it to rangeIncludes: before we do this?
> 
> Gosh, you guys work fast.  I'd be happy to look at some classes for calls
> to interval includes:, if they haven't all been inspected already.  But I
> don't want to re-do work that's already been done.
> 
> >I think the proper fix for the range interpretation is to replace the calls
> >that expect a range interpretation with, say, #rangeIncludes: or some better
> >choice that you might recommend.
> 
> I think that a better fix might be to introduce a new class that represents
> a range, which no step size expressed or implied, but with the ability to
> be open or closed at each end.  Something like
> 
>         x := Range closed: 3 closed: 7   => [ 3 .. 7 ]
>         y := Range open: 4 closed: 9     => ( 4 .. 9 ]
>         z := Range closed: 4 open: 2     => the empty range
>         x join: y                        => [ 3 .. 9 ]
>         x meet: y                        => ( 4 .. 7 ]
> 
> This sounds like an interesting student project, but I think it would be
> worth doing only if there is actually a use for it.   Ranges aren't
> collections (well, maybe they are infinite collections of reals?) and they
> aren't magnitudes (because they are only a partial order).
> 
> Would classes like these actually be useful in the graphic methods?  My
> assumption was that the new method for  interval|includes: had been written
> to speed up some code in  the windowing system, since without it
> interval|includes: uses the method in Collection which actually runs the do:
> 
>         Andrew




Torsten.Bergmann at phaidros.com wrote:
> 
> Some thought's about the Interval discussion:
> 
> Squeak and Smalltalk in general mixes mathematical
> intervals and numerical orders in the Interval class:
> 
> If we use
> 
> (1 to: 20)   we expect to get an interval with a beginning and
>              an end. We can ask this interval if it includes
>              a number. It should return true if this number is
>                  inside the interval.
>                  Example:
>                         (1 to: 20) includes: 0.9  -> false
>                         (1 to: 20) includes: 1    -> true
> 
>                         (1 to: 20) includes: 1.1  -> true
>                  The interval by itself is continuous. [----]
>              Maybe we should also think about open intervals with
>              infinite beginning or end. [--[
>                         (1 to: oo) includes: 100 factorial -> true
>                  oo stands for infinite sign.
> 
> (1 to: 20 by: 3) means we want to have a collection of numbers
>                      like the following: (1,4,7,...,19).
>                  The method Integer>>to:by: should therefore
>                  return an array, an instance of a new class
>                  called NumericalOrder or whatever. As mathematician
>                      we would'nt expect an interval as return value, would
> we.
> 
> As Smalltalker we would expect an Interval, because we know of
> the Integer>>to:by: implementation.
> 
> I've asked some non-smalltalkers about that with the result that
> people wouldn't expect an interval, because an interval has only a
> beginning and an end and is continuous. (They also expect the
> result of 3+4*7 as 31 ;)
> 
> The only reason for returning an interval is that Smalltalk
> can safe a lot of memory if it stores only the beginning, the end and
> an increment. So you can easily iterate through a huge collection of
> numbers.
> (1 to: 4000 by: 3) do: [...]
> 
> -Torsten





More information about the Squeak-dev mailing list