As in python:

str="Hello"

[i]     :  -5 -4 -3 -2 -1 0 1 2 3 4
str[i]  :   H  E  L  L  0 H E L L O

of course not only for strings, for all arrays.

This is a good idea, but it has a significant runtime cost for every array access.

"vb" <none@nil.com> wrote in message news:Xns9297BBCA6B999whatisthis@63.105.9.61...
> As in python:
>
> str="Hello"
>
> [i]     :  -5 -4 -3 -2 -1 0 1 2 3 4
> str[i]  :   H  E  L  L  0 H E L L O
>
> of course not only for strings, for all arrays.

But that cost should be less than any other way of doing the equivalent negative indexing.

There are other languages, such as J (think of APL using ASCII, then add steroids), where negative indexing makes the implementation of many algorithms far more "natural".  My most recent example was performing some image manipulation using 3x3 convolution matrices.  There is always the "edge problem" which in most languages requires lots of special code.  For the particular problem I was solving, having negative indices "reflect" back into the matrix provided exactly the solution I needed.

The neat thing about J in this context is that it "knows" about matrices, and I didn't even have to write a loop.  After defining my matrices, the actual "code" to do the entire operation was a single line.

If you are going to *really* use arrays, then negative indexing is a great help.  The alternative is often tons and tons of special-case code, or klugey things like the following (in C):

  char c = (i >= 0) ? str[i] : str[strlen(str) + i];

Which would become a macro, probably called SIGNED_INDEX().  Which is something D doesn't really want to have.  And this is something the compiler does better anyhow.


-BobC


Walter wrote:

> This is a good idea, but it has a significant runtime cost for every array access.
>
> "vb" <none@nil.com> wrote in message news:Xns9297BBCA6B999whatisthis@63.105.9.61...
> > As in python:
> >
> > str="Hello"
> >
> > [i]     :  -5 -4 -3 -2 -1 0 1 2 3 4
> > str[i]  :   H  E  L  L  0 H E L L O
> >
> > of course not only for strings, for all arrays.

I also like negative indexing.  Icon supports it too.

I encountered the "edge problem" in my image processing work and negative indices help a lot in many algorithm domains.

Mark

vb wrote:

> As in python:
>
> str="Hello"
>
> [i]     :  -5 -4 -3 -2 -1 0 1 2 3 4
> str[i]  :   H  E  L  L  0 H E L L O
>
> of course not only for strings, for all arrays.

*IF* (that's a big if) the optimizer was smart enough, you could use the
syntax:
    str.reverse[n]
to access the n'th element from the end.  So your characters would be:

reverse[4]    H
reverse[3]    E
reverse[2]    L
reverse[1]    L
reverse[0]    O
[0]    H
[1]    E
[2]    L
[3]    L
[4]    O

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

I also like the python, perl way of allowing -ve array offset to mean "from
the end"
BUT this changes the points at which you get an "out of bounds" exception
from
index < 0  and index >= array.length to  index < -array.length and index >=
array.length
meaning that if there was a bug in your code you would get junk data instead
of a exception

I would prefer a syntax like
array:wrap[idx]  (-ve is from end, +ve as usual : bounds checked)
and
array:ring[idx]  (idx % array.length so never throws an exception)

Mike.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:an52r2$2jnd$1@digitaldaemon.com...
> I also like negative indexing.  Icon supports it too.
>
> I encountered the "edge problem" in my image processing work and negative indices help a lot in many algorithm domains.
>
> Mark
>
>

I don't follow you.  Negative indices have boundaries too, and if the positive equivalent throws an exception, then so should the negative.

I like the idea of a ring index -- and will do it one better.  In image processing one often likes to mirror the edges to achive smoothness.  An out-of-bounds index reflects back into the original array.  The alternative of zero-padding introduces a severe discontinuity.

I'm not sure which, if any, of our combined features actually belong in the core language, but negative indexing does.  That makes all the other things easier to implement.

Mark

Negative indexing will require an extra test for every array reference. That will put it behind in any efficiency comparisons with C++.


>The alternative is often tons and tons of special-case code, or klugey
> things like the following (in C):
>
>   char c = (i >= 0) ? str[i] : str[strlen(str) + i];

In D it would be:

   char c = (i >= 0) ? str[i] : str[str.length + i];

You could do it with an inline function:

    char index(str, int i)
    {
       return (i >= 0) ? str[i] : str[str.length + i];
    }

Don't give in, Walter.  Negative indices are nifty and all, but definitely not worth the performance loss.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:an66dr$jok$1@digitaldaemon.com...
> Negative indexing will require an extra test for every array reference.
That
> will put it behind in any efficiency comparisons with C++.

I agree. Fundamental Performance is crucial to D or people will not upgrade from C++.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:an6ad2$q8c$1@digitaldaemon.com...
> Don't give in, Walter.  Negative indices are nifty and all, but definitely not worth the performance loss.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:an66dr$jok$1@digitaldaemon.com...
> > Negative indexing will require an extra test for every array reference.
> That
> > will put it behind in any efficiency comparisons with C++.
>
>