Interval protocol

>> and i always hitting the wall with my head again and again.. because
>> there's no such protocol
>> and instead (after opening browser and looking at class, i figuring
>> that i should use #first/#last, but it is completely unintuitive to
>> me)..
>
> Me too, when I was using what I knew would only ever need to be,
> simply, an Interval.
>
> Later the complexity increased and it would be either a Interval or
> Array of numbers.  It was a transparent / painless improvement.  After
> gaining that appreciation, now I think of Intervals as just "efficient
> Arrays" and think naturally to use #first / #last.
>

> On 15 December 2012 23:45, Chris Muller <[hidden email]> wrote:
>>> and i always hitting the wall with my head again and again.. because
>>> there's no such protocol
>>> and instead (after opening browser and looking at class, i figuring
>>> that i should use #first/#last, but it is completely unintuitive to
>>> me)..
>>
>> Me too, when I was using what I knew would only ever need to be,
>> simply, an Interval.
>>
>> Later the complexity increased and it would be either a Interval or
>> Array of numbers.  It was a transparent / painless improvement.  After
>> gaining that appreciation, now I think of Intervals as just "efficient
>> Arrays" and think naturally to use #first / #last.
>>
>
> Well, my math background prevents me from thinking this way.
> Since in math, intervals are defined on sets of numbers.
> (like Real set).. you cannot treat it as array , simply because there
> is an infinite number
> of values inside any non-empty interval, and you cannot enumerate them.

> On 16 December 2012 01:06, Igor Stasenko <[hidden email]> wrote:
>> On 15 December 2012 23:45, Chris Muller <[hidden email]> wrote:
>>>> and i always hitting the wall with my head again and again.. because
>>>> there's no such protocol
>>>> and instead (after opening browser and looking at class, i figuring
>>>> that i should use #first/#last, but it is completely unintuitive to
>>>> me)..
>>>
>>> Me too, when I was using what I knew would only ever need to be,
>>> simply, an Interval.
>>>
>>> Later the complexity increased and it would be either a Interval or
>>> Array of numbers.  It was a transparent / painless improvement.  After
>>> gaining that appreciation, now I think of Intervals as just "efficient
>>> Arrays" and think naturally to use #first / #last.
>>>
>>
>> Well, my math background prevents me from thinking this way.
>> Since in math, intervals are defined on sets of numbers.
>> (like Real set).. you cannot treat it as array , simply because there
>> is an infinite number
>> of values inside any non-empty interval, and you cannot enumerate them.
>
> But it's a subset of the integers, not the reals!
>

> On 16 December 2012 09:26, Frank Shearar <[hidden email]> wrote:
>> On 16 December 2012 01:06, Igor Stasenko <[hidden email]> wrote:
>>> On 15 December 2012 23:45, Chris Muller <[hidden email]> wrote:
>>>>> and i always hitting the wall with my head again and again.. because
>>>>> there's no such protocol
>>>>> and instead (after opening browser and looking at class, i figuring
>>>>> that i should use #first/#last, but it is completely unintuitive to
>>>>> me)..
>>>>
>>>> Me too, when I was using what I knew would only ever need to be,
>>>> simply, an Interval.
>>>>
>>>> Later the complexity increased and it would be either a Interval or
>>>> Array of numbers.  It was a transparent / painless improvement.  After
>>>> gaining that appreciation, now I think of Intervals as just "efficient
>>>> Arrays" and think naturally to use #first / #last.
>>>>
>>>
>>> Well, my math background prevents me from thinking this way.
>>> Since in math, intervals are defined on sets of numbers.
>>> (like Real set).. you cannot treat it as array , simply because there
>>> is an infinite number
>>> of values inside any non-empty interval, and you cannot enumerate them.
>>
>> But it's a subset of the integers, not the reals!
>>
> what?
> then how you explain this:
>
> (1.5 to: 1.6 by: 0.01) collect: [:i | i ]
>
>> frank
>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

> hi,
>
> i am alone with this problem (or just mentally ill?), why every time i
> use #start and #end protocol for Interval, e.g.:
>
> start := (1 to: 100) start.
> end := (1 to: 100) end.
>
> why i expecting that something called 'interval' should answer its
> start and end (or begin & end, if you like)?
>
> and i always hitting the wall with my head again and again.. because
> there's no such protocol
> and instead (after opening browser and looking at class, i figuring
> that i should use #first/#last, but it is completely unintuitive to
> me)..
>
> So, i am alone with this? Or maybe intervals deserving to have start and end?
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

> On Dec 15, 2012, at 5:30 PM, Igor Stasenko wrote:
>
>> hi,
>>
>> i am alone with this problem (or just mentally ill?), why every time i
>> use #start and #end protocol for Interval, e.g.:
>>
>> start := (1 to: 100) start.
>> end := (1 to: 100) end.
>>
>> why i expecting that something called 'interval' should answer its
>> start and end (or begin & end, if you like)?
>>
>> and i always hitting the wall with my head again and again.. because
>> there's no such protocol
>> and instead (after opening browser and looking at class, i figuring
>> that i should use #first/#last, but it is completely unintuitive to
>> me)..
>>
>> So, i am alone with this? Or maybe intervals deserving to have start and end?
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>

>
> On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote:
>
>> 2012/12/16 Stéphane Ducasse <[hidden email]>:
>>> polymorphically they are a collection with a first and last :)
>>>
>>
>> No.
>>
>> (5 to: 4) is different than (3 to: 2) because they specify a different
>> cursor position.
>
> Ok that I understand
>
>> Viewed as collection, they have no first nor last, they're just empty
>>
>> Nicolas

> 2012/12/16 Stéphane Ducasse <[hidden email]>:
>>
>> On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote:
>>
>>> 2012/12/16 Stéphane Ducasse <[hidden email]>:
>>>> polymorphically they are a collection with a first and last :)
>>>>
>>>
>>> No.
>>>
>>> (5 to: 4) is different than (3 to: 2) because they specify a different
>>> cursor position.
>>
>> Ok that I understand
>>
>>> Viewed as collection, they have no first nor last, they're just empty
>>>
>>> Nicolas
>
> Currently:
>
> (3 to: 2) first -> 3.
> (3 to: 2) last -> 2.
>
> But:
> (2 to: 4 by: 3) last -> 2
>
> Try to guess the logic behind this...
>
>>
>> I see. But does it make sense to have (thinking aloud)?
>>         (3 to: 2) start -> 3
>>         (3 to: 2) end -> 2
>> probably?
>
> Yes, I did that refactoring in Squeak 3.9, but I was sure it would be
> rejected, too many methods were changed (TextMorph ParagraphEditor &
> co). See http://bugs.squeak.org/view.php?id=6454
>
> You also know that breaking the classes we use for browsing/debugging
> is a dangerous sport ;)
>
> The simplest thing would be to add a few message to TextLineInterval
> (first, last, ...) and move it somewhere else in hierarchy, because I
> don't think it shares that much with Interval.
> - I guess we don't use much of Collection protocol in TextLineInterval
> - it spoils first/last uniformity
> - it can't handle Interval step
> - ...
>
>>
>> So we should improve that.
>> If what I said is correct and you confirm it I will open a bug entry
>> Stef
>>
>>
>
> I found http://bugs.squeak.org/view.php?id=7002 indicating that most
> weirdness of Interval were corrected, but I'm quite sure it still has
> other reported or non reported bugs, except hash.
>
> I can still do an infinite loop with to:do: and Float,
> 2 - Float epsilon to: 2 by: Float epsilon/4 do: [:i | Transcript cr;
> show: i printString]
>
>  but Interval>>do: is correct: (well I warned you, some rounding occurs...)
> (2 - Float epsilon to: 2 by: Float epsilon/4) do: [:i | Transcript cr;
> show: i printString]
>
> For hash, I wonder if it would not be easier to just drop #(2 3) = (2
> to: 3) and let it answer false.
> We have hasSameElementsThan: or isSameSequenceThan: for that purpose.
>

> What Frank means is that Smalltalk Interval are countable (and most are finite).
>
> However, the original usage of Interval was for Text editing, and an
> Interval from 5 to: 4 means that the cursor is before (after?)
> position 5. That's why Interval is a strange beast, not exactly
> polymorphic to an Array of Number. Those two views have introduced a
> number of unconsistencies in the library...
>
> Last thing, I don't recommend using Interval of Float, (1.5 to: 1.6
> by: 0.01), rather use Integer or Fraction. You never know where the
> Float Interval really ends, it's progression is generally not
> constant, and to:do: used to behaved differently than do:
>
> Nicolas
>
> 2012/12/16 Igor Stasenko <[hidden email]>:
>> On 16 December 2012 09:26, Frank Shearar <[hidden email]> wrote:
>>> On 16 December 2012 01:06, Igor Stasenko <[hidden email]> wrote:
>>>> On 15 December 2012 23:45, Chris Muller <[hidden email]> wrote:
>>>>>> and i always hitting the wall with my head again and again.. because
>>>>>> there's no such protocol
>>>>>> and instead (after opening browser and looking at class, i figuring
>>>>>> that i should use #first/#last, but it is completely unintuitive to
>>>>>> me)..
>>>>>
>>>>> Me too, when I was using what I knew would only ever need to be,
>>>>> simply, an Interval.
>>>>>
>>>>> Later the complexity increased and it would be either a Interval or
>>>>> Array of numbers.  It was a transparent / painless improvement.  After
>>>>> gaining that appreciation, now I think of Intervals as just "efficient
>>>>> Arrays" and think naturally to use #first / #last.
>>>>>
>>>>
>>>> Well, my math background prevents me from thinking this way.
>>>> Since in math, intervals are defined on sets of numbers.
>>>> (like Real set).. you cannot treat it as array , simply because there
>>>> is an infinite number
>>>> of values inside any non-empty interval, and you cannot enumerate them.
>>>
>>> But it's a subset of the integers, not the reals!
>>>
>> what?
>> then how you explain this:
>>
>> (1.5 to: 1.6 by: 0.01) collect: [:i | i ]
>>
>>> frank
>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko.
>>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>

>
> Currently:
>
> (3 to: 2) first -> 3.
> (3 to: 2) last -> 2.
>
> But:
> (2 to: 4 by: 3) last -> 2
>
> Try to guess the logic behind this…

>
>>
>> I see. But does it make sense to have (thinking aloud)?
>>        (3 to: 2) start -> 3
>>        (3 to: 2) end -> 2
>> probably?
>
> Yes, I did that refactoring in Squeak 3.9, but I was sure it would be
> rejected, too many methods were changed (TextMorph ParagraphEditor &
> co). See http://bugs.squeak.org/view.php?id=6454
>
> You also know that breaking the classes we use for browsing/debugging
> is a dangerous sport ;)

> The simplest thing would be to add a few message to TextLineInterval
> (first, last, ...) and move it somewhere else in hierarchy, because I
> don't think it shares that much with Interval.
> - I guess we don't use much of Collection protocol in TextLineInterval
> - it spoils first/last uniformity
> - it can't handle Interval step
> - ...
>
>>
>> So we should improve that.
>> If what I said is correct and you confirm it I will open a bug entry
>> Stef
>>
>>
>
> I found http://bugs.squeak.org/view.php?id=7002 indicating that most
> weirdness of Interval were corrected, but I'm quite sure it still has
> other reported or non reported bugs, except hash.
>
> I can still do an infinite loop with to:do: and Float,
> 2 - Float epsilon to: 2 by: Float epsilon/4 do: [:i | Transcript cr;
> show: i printString]
>
> but Interval>>do: is correct: (well I warned you, some rounding occurs...)
> (2 - Float epsilon to: 2 by: Float epsilon/4) do: [:i | Transcript cr;
> show: i printString]
>
> For hash, I wonder if it would not be easier to just drop #(2 3) = (2
> to: 3) and let it answer false.
> We have hasSameElementsThan: or isSameSequenceThan: for that purpose.

>
>>> For hash, I wonder if it would not be easier to just drop #(2 3) = (2
>>> to: 3) and let it answer false.
>
> + 1
> to me there are not equal!
>
> Stef
>
>>> We have hasSameElementsThan: or isSameSequenceThan: for that purpose.
>>>
>> or we haven't (? can't remember), but should have.
>>
>>> Nicolas
>>>
>>>>
>>>>
>>
>
>

> I am probably stupid but this sounds crazy.
>
> Most people will have a pretty good idea of what an interval is from mathematics.
> Stating that it is a finite, countable progression from a start to a stop with a step is more precise and makes sense.
>
> Now, [a,b] with b<a will seem wrong from this perspective.
>
> It could well be that Interval is (ab)used somewhere with b<a but is that a reason to allow this ?
>
> IMO, the specific cursor usage should have its own data structure…

> So, to my sense a behavior of Interval is overloaded..
> it tries to be too many things at once:
> - be an interval in math sense (which is infinite set if used for Real numbers)
> - be a "collection" of numbers which you can enumerate (implies that
> it is finite).
>
> to me, i would be much happier if we could have two different and
> non-intersecting entities:
>
> - Enumeration. This one indeed can be used as a collection. i.e.
> "give me all integer numbers lying between values A and B, count each
> C-th number"
>   Like that,
>   (1 to: 1.5 by: 1) is enumeration which contains a single element.
> and #last should be = 1
>
> - Interval (Range). A pure interval in math sense:  defines a Set of
> numbers lying between numbers A and B, inclusive, where A <= B. Not
> enumerable, therefore no 'step' variable, instead what it could have,
> is flags to indicate whether interval endpoints included into interval
> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b].
>
> Not supporting enumeration (no #do: , no #add: no #at: etc). You can,
> however intersect, merge or diff two intervals etc.. same operations
> which you doing on sets (but that would require another entity -
> interval set). And of course, you can test whether some number lies
> within given interval or not.
>
> The reason i started this topic is because some code were using
> 'range' for variables which holding intervals..
> Now what you think is more appropriate protocol for something called
> 'range', this:
>
> x := range first
> y := range last
>
> or this:
>
> x := range start
> y := range end
>
>
> --
> Best regards,
> Igor Stasenko.
>