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
|
Not Categorized, Please Help
|
|
