1. Why equal(x[n], x[n..n])=0 ?
Hi All,
I was debugging a function when I noticed that a slice with equal indexes is
different from an access with one index. x[n] is different from x[n..n] where n
is a valid index.
According to the manual, a slice always result in a sequence (also when x[n] is
an atom). But, in particular, when we have something like x[n..n], the result is
x[n] with the its depth incremented by 1. In other words, the structure of the
element depends on the access form (subscription or slicing). For me, this is a
surprising fact.
This kind of implementation affects some algorithms, because we have to test
when the indexes are equal in order to not use slice.
So, why equal(x[n], x[n..n])=0 ?
Regards,
Fernando
2. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Hi All,
>
> I was debugging a function when I noticed that a slice with equal indexes is
> different from an access with one index. x[n] is different from x[n..n] where
> n is a valid index.
> According to the manual, a slice always result in a sequence (also when x[n]
> is an atom). But, in particular, when we have something like x[n..n], the
> result
> is x[n] with the its depth incremented by 1. In other words, the structure of
> the element depends on the access form (subscription or slicing). For me, this
> is a surprising fact.
> This kind of implementation affects some algorithms, because we have to test
> when the indexes are equal in order to not use slice.
> So, why equal(x[n], x[n..n])=0 ?
>
Hmmm.
What we currently have is this:
sequence s
s={1,3,5,7,11}
s[2..4]={3,5,7}
s[2..3]={3,5}
s[2..2]={3}
s[2..1]={}
and what you seem to be saying is that you are surprised it is not:
s[2..3]={3,5}
s[2..2]=3
s[2..1]={}
I think that would cause far more shock and surprise. What algorithms does this
affect anyway?
Of course if you always compare slices with slices, and subscripts with
sunscripts, then no such issue ever arises.
Regards,
Pete
3. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Hi All,
>
> I was debugging a function when I noticed that a slice with equal indexes is
> different from an access with one index. x[n] is different from x[n..n] where
> n is a valid index.
> According to the manual, a slice always result in a sequence (also when x[n]
> is an atom). But, in particular, when we have something like x[n..n], the
> result
> is x[n] with the its depth incremented by 1. In other words, the structure of
> the element depends on the access form (subscription or slicing). For me, this
> is a surprising fact.
> This kind of implementation affects some algorithms, because we have to test
> when the indexes are equal in order to not use slice.
> So, why equal(x[n], x[n..n])=0 ?
Because the syntax [n..m] is a slice which is a sequence - always. And the
syntax [n] is a element reference whose value depends in what is at location 'n'.
Specifically, the syntax [n..n] is a sequence which has a length of one.
Given the sequence (string) s = "qwerty", then s[3..3] is the string "e" and
s[3] is the character 'e'. And characters are not strings.
Another way to look at is this ...
s[3 .. 4] is "er"
s[3 .. 3] is "e"
s[3 .. 2] is ""
so making s[3..3] ("e") mean the same as s[3] ('e') is inconsistent.
And yet another look ...
Given that
s = {"one", "two", "three", "four"}
it means that s is a list of strings.
Thus s[3 ..4] is a list of two strings {"three", "four"} and
s[3 .. 3] is a list of one string {"three"} but
s[3] is not a list, but the element at location 3, which happens to be a string
in this case.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
4. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Hi All,
>
> I was debugging a function when I noticed that a slice with equal indexes is
> different from an access with one index. x[n] is different from x[n..n] where
> n is a valid index.
> According to the manual, a slice always result in a sequence (also when x[n]
> is an atom). But, in particular, when we have something like x[n..n], the
> result
> is x[n] with the its depth incremented by 1. In other words, the structure of
> the element depends on the access form (subscription or slicing). For me, this
> is a surprising fact.
> This kind of implementation affects some algorithms, because we have to test
> when the indexes are equal in order to not use slice.
> So, why equal(x[n], x[n..n])=0 ?
>
> Regards,
> Fernando
At a rough guess I'd say x[n] is an atom, the n'th item in the sequence,
(assuming a sequence of atoms), whereas x[n..n] is a one-element sequence.
So you're comparing an atom and a sequence. Essentially the first is an item
from the sequence, the second is a sequence containing the item.
Andy
5. Re: Why equal(x[n], x[n..n])=0 ?
- Posted by Fernando Bauer <fmbauer at hotmail??om>
Sep 24, 2007
-
Last edited Sep 25, 2007
Hi Derek! Thanks for your reply.
Derek Parnell wrote:
>
> Fernando Bauer wrote:
> >
> > Hi All,
> >
> > I was debugging a function when I noticed that a slice with equal indexes is
> > different from an access with one index. x[n] is different from x[n..n]
> > where
> > n is a valid index.
> > According to the manual, a slice always result in a sequence (also when x[n]
> > is an atom). But, in particular, when we have something like x[n..n], the
> > result
> > is x[n] with the its depth incremented by 1. In other words, the structure
> > of
> > the element depends on the access form (subscription or slicing). For me,
> > this
> > is a surprising fact.
> > This kind of implementation affects some algorithms, because we have to test
> > when the indexes are equal in order to not use slice.
> > So, why equal(x[n], x[n..n])=0 ?
>
> Because the syntax [n..m] is a slice which is a sequence - always. And the
> syntax
> [n] is a element reference whose value depends in what is at location 'n'.
> Specifically,
> the syntax [n..n] is a sequence which has a length of one.
>
> Given the sequence (string) s = "qwerty", then s[3..3] is the string "e" and
> s[3] is the character 'e'. And characters are not strings.
>
> Another way to look at is this ...
>
> s[3 .. 4] is "er"
> s[3 .. 3] is "e"
Ok. But why s[3..3] is not 'e'? Why the original 'e' is transformed in "e" ?
> s[3 .. 2] is ""
>
> so making s[3..3] ("e") mean the same as s[3] ('e') is inconsistent.
Why do you think this is inconsistent? I could think the opposite. Why does the
slice s[3..3] change the type of s[3]?
>
> And yet another look ...
>
> Given that
> s = {"one", "two", "three", "four"}
> it means that s is a list of strings.
> Thus s[3 ..4] is a list of two strings {"three", "four"} and
> s[3 .. 3] is a list of one string {"three"} but
> s[3] is not a list, but the element at location 3, which happens to be a
> string
> in this case.
Yes. The manual is also very clear about this. However, the meaning of my
question is another:
Why does Euphoria (the manual) define slices like x[n..n] and x[n] differently?
Why is an atom transformed in a sequence by using a slice?
An analogy:
Suppose you have a set of enumerated objects and the following rules:
a)You can hold only one at a time. (subscription)
b)If you need more objects you can use a container. (slicing)
Then, if someone asks you to collect the objects 2 to 4?
- Because the number of objects is 3, you need to use the container (rule 2).
Now, if someone asks you to collect the objects 2 to 2?
- Because the number of objects is 1, you *don't* need to use the container,
you can catch it directly (rule 1). Besides, if you use the container (sequence),
you will have to discard it to catch the object (an unnecessary procedure).
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
Regards,
Fernando
6. Re: Why equal(x[n], x[n..n])=0 ?
- Posted by Fernando Bauer <fmbauer at ?o?mail.com>
Sep 24, 2007
-
Last edited Sep 25, 2007
Hi Andy! Thanks for your reply.
Andy Drummond wrote:
>
> Fernando Bauer wrote:
> >
> > Hi All,
> >
> > I was debugging a function when I noticed that a slice with equal indexes is
> > different from an access with one index. x[n] is different from x[n..n]
> > where
> > n is a valid index.
> > According to the manual, a slice always result in a sequence (also when x[n]
> > is an atom). But, in particular, when we have something like x[n..n], the
> > result
> > is x[n] with the its depth incremented by 1. In other words, the structure
> > of
> > the element depends on the access form (subscription or slicing). For me,
> > this
> > is a surprising fact.
> > This kind of implementation affects some algorithms, because we have to test
> > when the indexes are equal in order to not use slice.
> > So, why equal(x[n], x[n..n])=0 ?
> >
> > Regards,
> > Fernando
>
> At a rough guess I'd say x[n] is an atom, the n'th item in the sequence,
> (assuming a sequence of atoms), whereas x[n..n] is a one-element sequence.
> So you're comparing an atom and a sequence. Essentially the first is an item
> from the sequence, the second is a sequence containing the item.
>
> Andy
Ok. But my question, using your example, is: why the second is a sequence? Why
not an atom?
I know that slice is defined that way, but my question is why?
Please, look at my reply to Derek.
Regards,
Fernando
7. Re: Why equal(x[n], x[n..n])=0 ?
- Posted by Jason Gade <jaygade at yaho?.?om>
Sep 24, 2007
-
Last edited Sep 25, 2007
Fernando Bauer wrote:
>
> Hi Derek! Thanks for your reply.
>
> Derek Parnell wrote:
> >
> > Fernando Bauer wrote:
> > >
> > > Hi All,
> > >
> > > I was debugging a function when I noticed that a slice with equal indexes
> > > is
> > > different from an access with one index. x[n] is different from x[n..n]
> > > where
> > > n is a valid index.
> > > According to the manual, a slice always result in a sequence (also when
> > > x[n]
> > > is an atom). But, in particular, when we have something like x[n..n], the
> > > result
> > > is x[n] with the its depth incremented by 1. In other words, the structure
> > > of
> > > the element depends on the access form (subscription or slicing). For me,
> > > this
> > > is a surprising fact.
> > > This kind of implementation affects some algorithms, because we have to
> > > test
> > > when the indexes are equal in order to not use slice.
> > > So, why equal(x[n], x[n..n])=0 ?
> >
> > Because the syntax [n..m] is a slice which is a sequence - always. And the
> > syntax
> > [n] is a element reference whose value depends in what is at location 'n'.
> > Specifically,
> > the syntax [n..n] is a sequence which has a length of one.
> >
> > Given the sequence (string) s = "qwerty", then s[3..3] is the string "e" and
> > s[3] is the character 'e'. And characters are not strings.
> >
> > Another way to look at is this ...
> >
> > s[3 .. 4] is "er"
> > s[3 .. 3] is "e"
> Ok. But why s[3..3] is not 'e'? Why the original 'e' is transformed in "e" ?
>
> > s[3 .. 2] is ""
> >
> > so making s[3..3] ("e") mean the same as s[3] ('e') is inconsistent.
> Why do you think this is inconsistent? I could think the opposite. Why does
> the slice s[3..3] change the type of s[3]?
I thought that it was already adequately explained, but let me try again.
s[3..3] is *not* the same as s[3]. s[3] is an element of a sequence, which may
be a sequence or an atom. s[3..3] is a sequence with the elements from index 3 to
index 3 (which happen to be the same index).
A slice is *always* a sequence. See http://www.rapideuphoria.com/refman_2.htm#1
section 2.2.6. With your idea, how would s[3..2] work? What is it supposed to
return? Currently it returns the empty sequence.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
8. Re: Why equal(x[n], x[n..n])=0 ?
- Posted by Jason Gade <jaygade at yahoo.co?>
Sep 24, 2007
-
Last edited Sep 25, 2007
Sorry, I missed the second part of the post.
Fernando Bauer wrote:
>
> Yes. The manual is also very clear about this. However, the meaning of my
> question
> is another:
> Why does Euphoria (the manual) define slices like x[n..n] and x[n]
> differently?
> Why is an atom transformed in a sequence by using a slice?
>
> An analogy:
> Suppose you have a set of enumerated objects and the following rules:
> a)You can hold only one at a time. (subscription)
> b)If you need more objects you can use a container. (slicing)
> Then, if someone asks you to collect the objects 2 to 4?
> - Because the number of objects is 3, you need to use the container (rule 2).
> Now, if someone asks you to collect the objects 2 to 2?
> - Because the number of objects is 1, you *don't* need to use the container,
> you can catch it directly (rule 1). Besides, if you use the container
> (sequence),
> you will have to discard it to catch the object (an unnecessary procedure).
> Regards,
> Fernando
Because when you say s[3..3] you are saying, "bring me one item in a bucket".
It's not mutually exclusive. You can carry one thing with or without the bucket.
You can always take the item out of the bucket after it is brought to you.
Does that make sense?
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
9. Re: Why equal(x[n], x[n..n])=0 ?
Jason Gade wrote:
> Because when you say s[3..3] you are saying, "bring me one item in a bucket".
> It's not mutually exclusive. You can carry one thing with or without the
> bucket.
> You can always take the item out of the bucket after it is brought to you.
>
I like that analogy. A slice asks for a bucket with n items in it. You've always
got the bucket, whether it has 97, 4, 1, or 0 things in it.
And a thing in a bucket is not the same as said thing not in a bucket.
Regards,
Pete
10. Re: Why equal(x[n], x[n..n])=0 ?
Hi Jason. Thanks for your reply.
Jason Gade wrote:
>
> Sorry, I missed the second part of the post.
>
> Fernando Bauer wrote:
> >
> > Yes. The manual is also very clear about this. However, the meaning of my
> > question
> > is another:
> > Why does Euphoria (the manual) define slices like x[n..n] and x[n]
> > differently?
> > Why is an atom transformed in a sequence by using a slice?
> >
> > An analogy:
> > Suppose you have a set of enumerated objects and the following rules:
> > a)You can hold only one at a time. (subscription)
> > b)If you need more objects you can use a container. (slicing)
> > Then, if someone asks you to collect the objects 2 to 4?
> > - Because the number of objects is 3, you need to use the container (rule
> > 2).
> > Now, if someone asks you to collect the objects 2 to 2?
> > - Because the number of objects is 1, you *don't* need to use the
> > container,
> > you can catch it directly (rule 1). Besides, if you use the container
> > (sequence),
> > you will have to discard it to catch the object (an unnecessary procedure).
> > Regards,
> > Fernando
>
> Because when you say s[3..3] you are saying, "bring me one item in a bucket".
This is how slices are currently implemented in Euphoria, but it doesn't have to
be. Why do you need the bucket? Why don't you catch the item directly?
> It's not mutually exclusive. You can carry one thing with or without the
> bucket.
> You can always take the item out of the bucket after it is brought to you.
Yes, but taking the item out of the bucket consumes more time and energy!
>
> Does that make sense?
Definitely yes.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
Regards,
Fernando
11. Re: Why equal(x[n], x[n..n])=0 ?
Hi Pete,
Pete Lomax wrote:
>
> Jason Gade wrote:
> > Because when you say s[3..3] you are saying, "bring me one item in a
> > bucket".
> > It's not mutually exclusive. You can carry one thing with or without the
> > bucket.
> > You can always take the item out of the bucket after it is brought to you.
> >
> I like that analogy. A slice asks for a bucket with n items in it. You've
> always
> got the bucket, whether it has 97, 4, 1, or 0 things in it.
> And a thing in a bucket is not the same as said thing not in a bucket.
And that is the problem! Sometimes you expect a thing out of the bucket and you
receive within the bucket.
>
> Regards,
> Pete
Regards,
Fernando
12. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Hi Pete,
>
> Pete Lomax wrote:
> >
> > Jason Gade wrote:
> > > Because when you say s[3..3] you are saying, "bring me one item in a
> > > bucket".
> > > It's not mutually exclusive. You can carry one thing with or without the
> > > bucket.
> > > You can always take the item out of the bucket after it is brought to you.
> > >
> > I like that analogy. A slice asks for a bucket with n items in it. You've
> > always
> > got the bucket, whether it has 97, 4, 1, or 0 things in it.
> > And a thing in a bucket is not the same as said thing not in a bucket.
> And that is the problem! Sometimes you expect a thing out of the bucket and
> you receive within the bucket.
>
> >
> > Regards,
> > Pete
> Regards,
> Fernando
I understand what you are saying, and after a certain point the answer becomes
"because that's the way it is!" Which is rarely satisfying to give or receive,
but...
I still think it adheres to the "principle of least surprise" anyway, unlike a
few other aspects of the language.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
13. Re: Why equal(x[n], x[n..n])=0 ?
Maybe you could post an algorithm/code sample where you think returning an atom
would make more sense?
s[constant...constant] is never used; slices are usually used in a loop or with
one or two variables. The expression following almost invariably expects a
sequence--returning either a sequence or an atom would require extra checking.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
14. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
> > Another way to look at is this ...
> >
> > s[3 .. 4] is "er"
> > s[3 .. 3] is "e"
> Ok. But why s[3..3] is not 'e'? Why the original 'e' is transformed in "e" ?
It seems that you are not thinking things through clearly. The character 'e' has
not been transformed.
The bucket analogy is an excellent one.
If you have a bucket of fruit, and you want to create a NEW bucket of fruit
using one piece of fruit from the initial one, the syntax to do that is
newBucket = oldBucket[n..n]
If you have a bucket of fruit, and you want to look at one piece of fruit that
is in it, the syntax to do that is
theFruit = oldBucket[n]
As you can see, the syntax you actually use depends on what you want to achieve.
The slice syntax [x..y] gives you a new sequence/container/bucket, and the
element reference syntax [z] gives you one element from a container.
> Yes. The manual is also very clear about this. However,
> the meaning of my question is another:
> Why does Euphoria (the manual) define slices
> like x[n..n] and x[n] differently?
You misunderstand, it seems.
[n..n] IS a slice, and [n] IS NOT a slice.
[n..n] IS NOT an element reference, and [n] IS an element reference.
> Why is an atom transformed in a sequence by using a slice?
There is no transformation. If one has a sequence (which a slice always is), one
can insert an atom into it. The atom is not transformed.
> An analogy:
> Suppose you have a set of enumerated objects and the following rules:
> a)You can hold only one at a time. (subscription)
Hold the object in what? A container maybe?
> b)If you need more objects you can use a container. (slicing)
> Then, if someone asks you to collect the objects 2 to 4?
> - Because the number of objects is 3, you need to use
> the container (rule 2).
Why? That is only one option. Another is to hold the VALUES in a set of objects.
object a,b,c
a = bucket[2]
b = bucket[3]
c = bucket[4]
This is why I was saying that the way you want to see the data dictates the
method used to store the data.
> Now, if someone asks you to collect the objects 2 to 2?
> - Because the number of objects is 1, you *don't* need
> to use the container, you can catch it directly (rule 1).
So you acknowledge this is optional. That is, you can have the single object as
an entity itself or you can has it as the contents of a container. It's your
choice. So to tell Euphoria which method you have chosen, you use the appropriate
syntax. If you want the just the object use bucket[2], however if you want it in
a container then use bucket[2..2]. It's your choice.
> Besides, if you use the container (sequence),you will
> have to discard it to catch the object (an unnecessary procedure).
Why? It depends on what you want to do with it. It's your choice.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
15. Re: Why equal(x[n], x[n..n])=0 ?
Jason Gade wrote:
>
> Maybe you could post an algorithm/code sample where you think returning an
> atom
> would make more sense?
>
> s[constant...constant] is never used; slices are usually used in a loop or
> with
> one or two variables. The expression following almost invariably expects a
> sequence--returning
> either a sequence or an atom would require extra checking.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
I have some code that normalises a sequence of numbers and pairs of numbers to
make the whole stuff non overlapping and increasing. I remember having run in
this sort of trouble, where I have a lower and upper limit, and the idea is:
return element of sequence if lower=upper, and keep working on a smaller slice
else. And I got hit precisely by the fact that s[lower..upper] has a bucket
around it. I can dig the code up when I'm back home tonight (ie 10-12h from now).
While it is indeed annoying at times, I think it is better that slices always be
sequence, because not doing so would make quite more code more complex. But I do
agree that this is sometimes a nuisance.
CChris
16. Re: Why equal(x[n], x[n..n])=0 ?
Hi Fernando.
Maybe the point is that x[1..5] as well as x[3..3] are slices (two indexes
separated by two periods), while x[5] (a single index) is not a slice.
The simplest case: assume all elements of x are atoms. Then x[i] is an atom, and
x[i..j] is a sequence of atoms.
Assume also that you have this loop (code not tested):
x = repeat(4, 10)
for i = 10 to 1 by -1 do
foo(x[1..i])
end for
The foo() procedure gets sequences with diminishing length, and processes them.
It expects it has to deal with a sequence.
But, oh surprise!, when you get to i = 1 (if x[n] where the same as x[n..n], as
you propose), it would get an atom!, and probably fail.
So, foo() should test if its argument is a sequence or an atom before
proceeding.
Don't you think this way things would be more complex?
Best regards.
PD: Hi Fernando.
I am from Buenos Aires, Argentina. I recall you are from Porto Alegre, Brazil,
true?
I understand enough Portuguese. You can contact me at ricardoforno at
tutopia.com in Portuguese if you like.
Ah! And I plan to take my holydays in the south of Brazil next January, with my
wife. Maybe we can meet then.
17. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Hi All,
>
> I was debugging a function when I noticed that a slice with equal indexes is
> different from an access with one index. x[n] is different from x[n..n] where
> n is a valid index.
> According to the manual, a slice always result in a sequence (also when x[n]
> is an atom). But, in particular, when we have something like x[n..n], the
> result
> is x[n] with the its depth incremented by 1. In other words, the structure of
> the element depends on the access form (subscription or slicing). For me, this
> is a surprising fact.
> This kind of implementation affects some algorithms, because we have to test
> when the indexes are equal in order to not use slice.
> So, why equal(x[n], x[n..n])=0 ?
Imagine please a sausage, it has the sausage-meat and the sausage-shell.
Then imagine a slice of that sausage.
This slice again consists of meat and shell, see?
Same with sequences, slice of a sequence has its meat (say, atom) and
shell ({}). 
But if without jokes, if you want x[n] to be equal x[n..n],
then you'll need to do {x[n..n]}, if you want a sequence, when x[n]
is an atom.
And now, x[n] may be an atom, but x[n..n] is always sequence.
I think, we have good rules in Euphoria now.
Regards,
Igor Kachan
kinz at peterlink.ru
18. Re: Why equal(x[n], x[n..n])=0 ?
Derek Parnell wrote:
>
> Fernando Bauer wrote:
>
> > > Another way to look at is this ...
> > >
> > > s[3 .. 4] is "er"
> > > s[3 .. 3] is "e"
> > Ok. But why s[3..3] is not 'e'? Why the original 'e' is transformed in "e" ?
>
> It seems that you are not thinking things through clearly. The character 'e'
> has not been transformed.
Let me see the dictionary:
transform = "To change markedly the form or appearance of"
change = "To cause to be different".
Now, we have originally an atom 'e' (form A). After slicing we have a sequence
"e" (form B). Clearly, form A != form B (even in computer memory), so slicing
changes the form A to form B, and this is the definition of "transform" above. So
I conclude that that slice transforms 'e' into "e".
>
> The bucket analogy is an excellent one.
>
> If you have a bucket of fruit, and you want to create a NEW bucket of fruit
> using one piece of fruit from the initial one, the syntax to do that is
>
> newBucket = oldBucket[n..n]
>
> If you have a bucket of fruit, and you want to look at one piece of fruit that
> is in it, the syntax to do that is
>
> theFruit = oldBucket[n]
>
> As you can see, the syntax you actually use depends on what you want to
> achieve.
> The slice syntax [x..y] gives you a new sequence/container/bucket, and the
> element
> reference syntax [z] gives you one element from a container.
>
> > Yes. The manual is also very clear about this. However,
> > the meaning of my question is another:
> > Why does Euphoria (the manual) define slices
> > like x[n..n] and x[n] differently?
>
> You misunderstand, it seems.
I dont't think so. Probably my question is not precise. Let me try again:
Why does Euphoria (the manual) define slice x[n..n] different from subscription
x[n]?
>
> [n..n] IS a slice, and [n] IS NOT a slice.
I know this! This is the syntax definition of slice. This is clear in the
manual! My question is: why doesn't the interpreter transform the slice into a
subscript when the indexes are equal?
> [n..n] IS NOT an element reference, and [n] IS an element reference.
Ok. But why [n..n] can't be an element reference? Why aren't they synonyms?
>
> > Why is an atom transformed in a sequence by using a slice?
>
> There is no transformation. If one has a sequence (which a slice always is),
> one can insert an atom into it. The atom is not transformed.
See above why I think we can say that there is a transformation.
>
> > An analogy:
> > Suppose you have a set of enumerated objects and the following rules:
> > a)You can hold only one at a time. (subscription)
>
> Hold the object in what? A container maybe?
For a concrete example, in your hand.
>
> > b)If you need more objects you can use a container. (slicing)
> > Then, if someone asks you to collect the objects 2 to 4?
> > - Because the number of objects is 3, you need to use
> > the container (rule 2).
>
> Why? That is only one option. Another is to hold the VALUES in a set of
> objects.
>
> object a,b,c
> a = bucket[2]
> b = bucket[3]
> c = bucket[4]
You can't hold more than either one object or a container in your hand.
(I mean "either a or b" = a xor b)
>
> This is why I was saying that the way you want to see the data dictates the
> method used to store the data.
>
> > Now, if someone asks you to collect the objects 2 to 2?
> > - Because the number of objects is 1, you *don't* need
> > to use the container, you can catch it directly (rule 1).
>
> So you acknowledge this is optional. That is, you can have the single object
> as an entity itself or you can has it as the contents of a container. It's
> your
> choice. So to tell Euphoria which method you have chosen, you use the
> appropriate
> syntax. If you want the just the object use bucket[2], however if you want it
> in a container then use bucket[2..2]. It's your choice.
Ok. But sometimes you want to use slice, and then you have to test the length of
the slice or the values of the indexes. This probably adds lines of code and
processing time.
>
> > Besides, if you use the container (sequence),you will
> > have to discard it to catch the object (an unnecessary procedure).
>
> Why? It depends on what you want to do with it. It's your choice.
Ok. But normally you want to catch (access) the object, or in other words, you
normally want to subscript the sequence (x[n]), which is the discard procedure.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
Regards,
Fernando
19. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
> Ok. But sometimes you want to use slice, and then you have to test the length
> of the slice or the values of the indexes. This probably adds lines of code
> and processing time.
Ah, but depending on the algorithm, sometimes when you expect a slice to return
a sequence then checking for an atom or "one sequence down" will probably add
lines of code or processing time.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
20. Re: Why equal(x[n], x[n..n])=0 ?
Hi Ricardo. Thanks for your reply.
Ricardo Forno wrote:
>
> Hi Fernando.
> Maybe the point is that x[1..5] as well as x[3..3] are slices (two indexes
> separated
> by two periods), while x[5] (a single index) is not a slice.
> The simplest case: assume all elements of x are atoms. Then x[i] is an atom,
> and x[i..j] is a sequence of atoms.
> Assume also that you have this loop (code not tested):
>
> x = repeat(4, 10)
>
> for i = 10 to 1 by -1 do
> foo(x[1..i])
> end for
>
> The foo() procedure gets sequences with diminishing length, and processes
> them.
> It expects it has to deal with a sequence.
Yes. For functions expecting a sequence, only the current definition of slice
works, and probably this is the cause of that slice definition. But then I ask,
why not define a similar but more generic function which accepts object?
> But, oh surprise!, when you get to i = 1 (if x[n] where the same as x[n..n],
> as you propose), it would get an atom!, and probably fail.
> So, foo() should test if its argument is a sequence or an atom before
> proceeding.
Yes. I think this is a common procedure in all functions that receive objects.
> Don't you think this way things would be more complex?
For now, I don't know. I think that I'd have to have much more experience with
Euphoria to correctly answer this.
I'm learning with all of you with these discussions.
>
> Best regards.
>
> PD: Hi Fernando.
> I am from Buenos Aires, Argentina. I recall you are from Porto Alegre, Brazil,
> true?
Yes. And I know a few things about you thanks to the Euforum.
> I understand enough Portuguese. You can contact me at ricardoforno at
> tutopia.com
> in Portuguese if you like.
> Ah! And I plan to take my holydays in the south of Brazil next January, with
> my wife. Maybe we can meet then.
Ok. Maybe.
Best Regards,
Fernando
21. Re: Why equal(x[n], x[n..n])=0 ?
[tag]
I've stayed out of this for as long as I could resist, but now it's my
turn.
Fernando Bauer wrote:
>
> Let me see the dictionary:
> transform = "To change markedly the form or appearance of"
> change = "To cause to be different".
> Now, we have originally an atom 'e' (form A). After slicing we have a sequence
> "e" (form B). Clearly, form A != form B (even in computer memory), so slicing
> changes the form A to form B, and this is the definition of "transform" above.
> So I conclude that that slice transforms 'e' into "e".
No. A slice just gives you a portion (or possibly all of) the sequence
upon which it is operating. It transforms "xxerxx" into "e".
> I dont't think so. Probably my question is not precise. Let me try again:
> Why does Euphoria (the manual) define slice x[n..n] different from
> subscription
> x[n]?
Well, I'll pretend that I'm Raymond Chen, and ask, "What would it mean to
have x[n..n] = x[n]?" And the answer is, a world gone mad. Ok, maybe not,
but certainly you'd have something that doesn't make a lot of sense. You've
taken a sequence operation, and created a special case. Now, everytime we
slice (unless we're using two literal values, we'll have to check them,
and adjust.
I think the burden is upon the person who wishes to see this special case
created. It's defined this way because it's the obvious and most simple
interpretation. To me, your question is equivalent to:
Why doesn't "n + n" mean the same as "n * n".
> >
> > [n..n] IS a slice, and [n] IS NOT a slice.
>
> I know this! This is the syntax definition of slice. This is clear in the
> manual!
> My question is: why doesn't the interpreter transform the slice into a
> subscript
> when the indexes are equal?
Because while euphoria may have some surprising quirks here and there
that surprise many programers (like equal() vs = with sequences), this
isn't one of them. Listen to what you're asking:
"Why do these two different operations return different values?"
> > [n..n] IS NOT an element reference, and [n] IS an element reference.
> Ok. But why [n..n] can't be an element reference? Why aren't they synonyms?
Because that would be wrong. Please let this thread die....
> Ok. But sometimes you want to use slice, and then you have to test the length
> of the slice or the values of the indexes. This probably adds lines of code
> and processing time.
Not as many as we would if we changed the definition of [n..n]. Remember,
this could arise practically anywhere, including [n..$]. If you don't
want the overhead of a slice, then don't use a slice. If you want to
just pull the element out, use the fine subscript operation. It works
really well...of course, you'll have to check to make sure you've not
subscripted outside of the bounds of the sequence. This probably adds
lines of code and processing time.
> >
> > > Besides, if you use the container (sequence),you will
> > > have to discard it to catch the object (an unnecessary procedure).
> >
> > Why? It depends on what you want to do with it. It's your choice.
>
> Ok. But normally you want to catch (access) the object, or in other words, you
> normally want to subscript the sequence (x[n]), which is the discard
> procedure.
If you want to subscript a sequence, then just use the freaking subscript
operation! It's really pretty simple. Right tool for the right job, and
all that.
Please, either re-read all of the responses until you understand them, or
stop trolling this forum.
Matt
22. Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Derek Parnell wrote:
> >
> > Fernando Bauer wrote:
> >
> > > > Another way to look at is this ...
> > > >
> > > > s[3 .. 4] is "er"
> > > > s[3 .. 3] is "e"
> > > Ok. But why s[3..3] is not 'e'? Why the original 'e' is transformed in "e"
> > > ?
> >
> > It seems that you are not thinking things through clearly. The character 'e'
> > has not been transformed.
> Let me see the dictionary:
> transform = "To change markedly the form or appearance of"
> change = "To cause to be different".
> Now, we have originally an atom 'e' (form A). After slicing we have a sequence
> "e" (form B). Clearly, form A != form B (even in computer memory), so slicing
> changes the form A to form B, and this is the definition of "transform" above.
> So I conclude that that slice transforms 'e' into "e".
I'm starting to feel sorry for you.
I have an apple. I put the apple into a bucket. Is the apple transformed? I
don't think so. It's still the same apple. No change (markedly or otherwise) in
either form or appearance.
I have an atom. I put the atom into a sequence. Is the atom transformed? I don't
think so.
>
> >
> > The bucket analogy is an excellent one.
> >
> > If you have a bucket of fruit, and you want to create a NEW bucket of fruit
> > using one piece of fruit from the initial one, the syntax to do that is
> >
> > newBucket = oldBucket[n..n]
> >
> > If you have a bucket of fruit, and you want to look at one piece of fruit
> > that
> > is in it, the syntax to do that is
> >
> > theFruit = oldBucket[n]
> >
> > As you can see, the syntax you actually use depends on what you want to
> > achieve.
> > The slice syntax [x..y] gives you a new sequence/container/bucket, and the
> > element
> > reference syntax [z] gives you one element from a container.
> >
> > > Yes. The manual is also very clear about this. However,
> > > the meaning of my question is another:
> > > Why does Euphoria (the manual) define slices
> > > like x[n..n] and x[n] differently?
> >
> > You misunderstand, it seems.
> I dont't think so. Probably my question is not precise. Let me try again:
> Why does Euphoria (the manual) define slice x[n..n] different from
> subscription
> x[n]?
Maybe it's because they are different things?
How plainly do we all have to say the same thing over and over and over and over
and over ... again before you get it. A slice is not a subscription! This is
really not rocket surgery, you know.
>
> >
> > [n..n] IS a slice, and [n] IS NOT a slice.
> I know this! This is the syntax definition of slice. This is clear in the
> manual!
> My question is: why doesn't the interpreter transform the slice into a
> subscript
> when the indexes are equal?
I could say "Because that would be dumb", but that would be rude. So let's try
another (yes, yet another simple example that refuse to understand).
If we had it your way, we would have ...
s[n .. n + 2] is a sequence
s[n .. n + 1] is a sequence
s[n .. n + 0] is not a sequence
s[n .. n + -1] is a sequence
Now that is just not cool. That would force us to always check for this
"special" case in our code. And that is really a bad idea, no?
You seem to be saying that whenever we reference a sequence that happens to
contain exactly one element, that the element should be the value of the
expression rather than the sequence. Honestly? That is really stupid.
I'm sorry that you can't see that.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
23. Re: Why equal(x[n], x[n..n])=0 ?
Derek Parnell wrote:
>
> This is really not rocket surgery, you know.
That sounds pretty dangerous.
Matt
24. Re: Why equal(x[n], x[n..n])=0 ?
Hi Matt.
Matt Lewis wrote:
[snipped]
> > > [n..n] IS NOT an element reference, and [n] IS an element reference.
> > Ok. But why [n..n] can't be an element reference? Why aren't they synonyms?
>
> Because that would be wrong. Please let this thread die....
Ok. Sorry for all the discussion.
[snipped]
>
>
> Please, either re-read all of the responses until you understand them, or
> stop trolling this forum.
>
> Matt
Ok. It was not my intention to waste time of anyone. And sorry for my stupidity.
Best regards to all,
Fernando
