Intervals behaviour for negative numbers, normal or bug ?
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers. I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour. (-100 to: 1) on the other hand work as expected. Any thoughts on this issue ?
Hi Kilon, On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
yes I know, I was just wondering if that was normal behaviour because it looks quite confusing to me. On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
Hi Kilon,
On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
On May 18, 2014, at 7:59 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I know, I was just wondering if that was normal behaviour because it looks quite confusing to me.
Personally I find it a natural way of expressing an empty interval. to: is syntactic sugar for to:by:, and so the default of 1 for the step (the by: arg) is expected. I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity positive (or 1 to: Float inf, ugh). Eliot (phone)
On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Kilon,
On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
On 18 May 2014, at 18:50, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On May 18, 2014, at 7:59 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I know, I was just wondering if that was normal behaviour because it looks quite confusing to me.
Personally I find it a natural way of expressing an empty interval. to: is syntactic sugar for to:by:, and so the default of 1 for the step (the by: arg) is expected.
I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity positive (or 1 to: Float inf, ugh).
Since there is Character>>#to: you can actually write $A to: $Z although it returns an Array instead of a String, but that can be solved with ($a to: $z) as: String or String withAll: ($a to: $z)
Eliot (phone)
On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Kilon,
On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 18 May 2014, at 18:50, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On May 18, 2014, at 7:59 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I know, I was just wondering if that was normal behaviour because it looks quite confusing to me.
Personally I find it a natural way of expressing an empty interval. to: is syntactic sugar for to:by:, and so the default of 1 for the step (the by: arg) is expected.
I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity positive (or 1 to: Float inf, ugh).
Since there is Character>>#to: you can actually write $A to: $Z although it returns an Array instead of a String, but that can be solved with
($a to: $z) as: String
or
String withAll: ($a to: $z)
Ugh, that's really bad. So if I want to construct an interval over the Unicode characters this hack instantiates a large string. The whole point about an Interval is to compute a set of values, not construct a collection. If I want to construct a collection I can. I would add a subclass of Interval, say NonArithmeticInterval, that sent successor: step or predecessor: step so that e.g. Character>>successor: n ^Character value: self asInteger + n
Eliot (phone)
On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Kilon,
On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
-- best, Eliot
2014-05-18 19:19 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 18 May 2014, at 18:50, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On May 18, 2014, at 7:59 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I know, I was just wondering if that was normal behaviour because it looks quite confusing to me.
Personally I find it a natural way of expressing an empty interval. to: is syntactic sugar for to:by:, and so the default of 1 for the step (the by: arg) is expected.
I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity positive (or 1 to: Float inf, ugh).
It should be coupled to some lazy protocol (like Xtreams) otherwise any selector is going to loop infinitely.
Since there is Character>>#to: you can actually write $A to: $Z although
it returns an Array instead of a String, but that can be solved with
($a to: $z) as: String
or
String withAll: ($a to: $z)
Not that it answers a String in Squeak, because this seemed a more natural recipient than OrderedCollection to me (OrderedCollection it previously was).
Ugh, that's really bad. So if I want to construct an interval over the Unicode characters this hack instantiates a large string. The whole point about an Interval is to compute a set of values, not construct a collection. If I want to construct a collection I can.
I would add a subclass of Interval, say NonArithmeticInterval, that sent successor: step or predecessor: step so that e.g. Character>>successor: n ^Character value: self asInteger + n
Oh yes, that's coming directly from ASCII era when it did not matter. ... but then also to:do: and inlined variants will have to be hacked. Wouldn't the cost be a bit prohibitive?
Eliot (phone)
On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda < eliot.miranda@gmail.com> wrote: Hi Kilon,
On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
-- best, Eliot
On Sun, May 18, 2014 at 11:55 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-05-18 19:19 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Sun, May 18, 2014 at 10:04 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
On 18 May 2014, at 18:50, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On May 18, 2014, at 7:59 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I know, I was just wondering if that was normal behaviour because it looks quite confusing to me.
Personally I find it a natural way of expressing an empty interval. to: is syntactic sugar for to:by:, and so the default of 1 for the step (the by: arg) is expected.
I'm dissatisfied however that I can't write $A to: $Z, or 1 to: Infinity positive (or 1 to: Float inf, ugh).
It should be coupled to some lazy protocol (like Xtreams) otherwise any selector is going to loop infinitely.
Of course it should. But there are other things. For examp,le, Smalltalk-80 had an InfiniteForm and it always bugged me that InfiniteForm>>extent answered SmallInteger maxVal@SmallInteger maxVal. If one changed that to answer Infinity positive@Infinity positive it was Interval code that broke. So (at least in my image) I fixed the Interval code. Intervals are really useful for modelling things, not just iterating.
Since there is Character>>#to: you can actually write $A to: $Z
although it returns an Array instead of a String, but that can be solved with
($a to: $z) as: String
or
String withAll: ($a to: $z)
Not that it answers a String in Squeak, because this seemed a more natural recipient than OrderedCollection to me (OrderedCollection it previously was).
Ugh, that's really bad. So if I want to construct an interval over the Unicode characters this hack instantiates a large string. The whole point about an Interval is to compute a set of values, not construct a collection. If I want to construct a collection I can.
I would add a subclass of Interval, say NonArithmeticInterval, that sent successor: step or predecessor: step so that e.g. Character>>successor: n ^Character value: self asInteger + n
Oh yes, that's coming directly from ASCII era when it did not matter. ... but then also to:do: and inlined variants will have to be hacked. Wouldn't the cost be a bit prohibitive?
The inlined versions need only to work with integers. to:by:do: is a different animal to to:by:. Once we have a good adaptive optimizer the answer can be different, but for now...
Eliot (phone)
On Sun, May 18, 2014 at 4:49 PM, Eliot Miranda < eliot.miranda@gmail.com> wrote: Hi Kilon,
On May 18, 2014, at 6:32 AM, kilon alios <kilon.alios@gmail.com> wrote:
while I was recording my Interval video tutorial I observed that Interval does not behave as I would expect . Even though (1 to: 100) works as I expect, (1 to: -100) does not. In case of ( 1 to: -100) it created the interval object but it does not populate it with the numbers.
You have to say 1 to: -100 by: -1
I would expect it to populate the interval with the numbers or at least fail with an error. This does not look to me like normal behaviour.
(-100 to: 1) on the other hand work as expected.
Any thoughts on this issue ?
-- best, Eliot
-- best, Eliot
participants (4)
-
Eliot Miranda -
kilon alios -
Nicolas Cellier -
Sven Van Caekenberghe