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.
You are not, I need to always recheck the Interval class to see what messages to use. -- Pavel On Sat, Dec 15, 2012 at 5:30 PM, Igor Stasenko <siguctua@gmail.com> 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.
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 <asqueaker@gmail.com> 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. -- Best regards, Igor Stasenko.
On 16 December 2012 01:06, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 December 2012 23:45, Chris Muller <asqueaker@gmail.com> 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! frank
-- Best regards, Igor Stasenko.
On 16 December 2012 09:26, Frank Shearar <frank.shearar@gmail.com> wrote:
On 16 December 2012 01:06, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 December 2012 23:45, Chris Muller <asqueaker@gmail.com> 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.
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 <siguctua@gmail.com>:
On 16 December 2012 09:26, Frank Shearar <frank.shearar@gmail.com> wrote:
On 16 December 2012 01:06, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 December 2012 23:45, Chris Muller <asqueaker@gmail.com> 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.
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⦠On 16 Dec 2012, at 11:04, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
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 <siguctua@gmail.com>:
On 16 December 2012 09:26, Frank Shearar <frank.shearar@gmail.com> wrote:
On 16 December 2012 01:06, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 December 2012 23:45, Chris Muller <asqueaker@gmail.com> 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.
On Dec 16, 2012, at 4:11 PM, Sven Van Caekenberghe wrote:
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â¦
Yes :) I'm as stupid as you :)
polymorphically they are a collection with a first and last :) 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.
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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. Viewed as collection, they have no first nor last, they're just empty Nicolas
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 <stephane.ducasse@inria.fr>:
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
I see. But does it make sense to have (thinking aloud)? (3 to: 2) start -> 3 (3 to: 2) end -> 2 probably? So we should improve that. If what I said is correct and you confirm it I will open a bug entry Stef
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote:
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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. Nicolas
2012/12/16 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote:
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
or we haven't (? can't remember), but should have.
Nicolas
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
Ah, i also forgot this feature: (2 to: 3) at: 1.5 -> 2.5 It's fun 2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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
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.
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class. Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap. Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image. Nicolas 2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class.
Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
On 16 December 2012 16:19, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap.
Certainly in Ruby a range is like a Smalltalk Interval: (1..10) is the same as 1 to: 10.
Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image.
Indeed, I think it's clear the confusion around this class is as Igor says: a mathematical interval, or a set of contiguous integers (or other countable things). frank
Nicolas
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class.
Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
On Dec 16, 2012, at 5:33 PM, Frank Shearar wrote:
On 16 December 2012 16:19, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap.
Certainly in Ruby a range is like a Smalltalk Interval: (1..10) is the same as 1 to: 10.
can they do not real intersection with ] [ and [ ] stef
Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image.
Indeed, I think it's clear the confusion around this class is as Igor says: a mathematical interval, or a set of contiguous integers (or other countable things).
frank
Nicolas
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class.
Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
Yes I started a proper mathematical interval implementation during an evening hack session: - open interval - closed intervals - compound intervals so you can properly distinguish ]0, 1[ [0, 1[ [0, 1] ]0, 1] and I think as well we should have Range vs Interval. And Range being just a sequence of numbers. For me that would simplify a lot. I uploaded the bare code here: http://smalltalkhub.com/mc/dh83/interval/main
Good. there is one in MathMorph too for years 2012/12/17 Camillo Bruni <camillobruni@gmail.com>:
Yes I started a proper mathematical interval implementation during an evening hack session: - open interval - closed intervals - compound intervals
so you can properly distinguish ]0, 1[ [0, 1[ [0, 1] ]0, 1]
and I think as well we should have Range vs Interval. And Range being just a sequence of numbers. For me that would simplify a lot.
I uploaded the bare code here: http://smalltalkhub.com/mc/dh83/interval/main
It's from pre-Monticello era, http://www.dm.uba.ar/MathMorphs/ If you follow the links, you'll have news from late 90s ;) 2012/12/17 Camillo Bruni <camillobruni@gmail.com>:
On 2012-12-17, at 15:23, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Good. there is one in MathMorph too for years
repository please? :)
Hmm, the problem with MathMorph is that there are several concurrent implementations... Here is one possible, apparently not the one used in AlgebraicNumber... Maybe there is a version in http://www.squeaksource.com/MathMorphsRevival/ Nicolas 2012/12/17 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
It's from pre-Monticello era, http://www.dm.uba.ar/MathMorphs/ If you follow the links, you'll have news from late 90s ;)
2012/12/17 Camillo Bruni <camillobruni@gmail.com>:
On 2012-12-17, at 15:23, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Good. there is one in MathMorph too for years
repository please? :)
Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap.
Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image.
Why not? Now it would be good to move. but what I know is that igor wanted to have range intersection for the new text model. Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? I do not think so. We can check what is around and **improve** our nice system Stef
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class.
Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
On 16 December 2012 16:51, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap.
Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image.
Why not? Now it would be good to move. but what I know is that igor wanted to have range intersection for the new text model. Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? I do not think so. We can check what is around and **improve** our nice system
If you use Ruby for any length of time (and ignore most of the syntax) you will quickly realise that Ruby _is_ Smalltalk in many fundamental ways. It's just a pity Matz based its syntax on Perl (or so it seems). Ruby = Smalltalk with rubbish syntax and awesome integration with basic programmer tools and decent infrastructure. frank
Stef
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class.
Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
On 17 December 2012 07:28, Frank Shearar <frank.shearar@gmail.com> wrote:
On 16 December 2012 16:51, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap.
Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image.
Why not? Now it would be good to move. but what I know is that igor wanted to have range intersection for the new text model. Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? I do not think so. We can check what is around and **improve** our nice system
If you use Ruby for any length of time (and ignore most of the syntax) you will quickly realise that Ruby _is_ Smalltalk in many fundamental ways. It's just a pity Matz based its syntax on Perl (or so it seems). Ruby = Smalltalk with rubbish syntax and awesome integration with basic programmer tools and decent infrastructure.
I should add: with that last clause I'm not trying to dismiss Pharo's and Squeak's massive improvement in infrastructure. It's just that it's nowhere near as slick as in Ruby. frank
frank
Stef
2012/12/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class.
Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote:
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.
If you use Ruby for any length of time (and ignore most of the syntax) you will quickly realise that Ruby _is_ Smalltalk in many fundamental ways. It's just a pity Matz based its syntax on Perl (or so it seems). Ruby = Smalltalk with rubbish syntax and awesome integration with basic programmer tools and decent infrastructure.
My point is that we should capture what is adapted for Pharo not just because in another language.
I should add: with that last clause I'm not trying to dismiss Pharo's and Squeak's massive improvement in infrastructure. It's just that it's nowhere near as slick as in Ruby.
How to improve?
O
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â¦
;D
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 ;)
oh yes like CharacterScanner and Event :)
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.
If you have changes that you want to propose for Pharo please go. I think that I will spend most of my charisma holidays fixing bugs :) Stef
participants (8)
-
Camillo Bruni -
Chris Muller -
Frank Shearar -
Igor Stasenko -
Nicolas Cellier -
Pavel Krivanek -
Stéphane Ducasse -
Sven Van Caekenberghe