Re: Why equal(x[n], x[n..n])=0 ?

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu