The concern over performance is valid but:

- Unsigned integers require no test at all, so a different object code gen subroutine could be invoked for them

- The kind of performance worry under consideration is one of those that matters only to serious numerical analysts and database engineers, who are working with fairly large data sets, not everyday programming; even with the extra test, my bet is that performance won't suffer more than 5%-10% in typical algorithms

- The gains are huge with negative indices in algorithm design, and most
software managers glady sacrifice performance to "get the job done";
that is where D must really shine, not inner loop performance;
I've *never* had a manager complement me on inner loop performance,
but they *always* want to know "when will the project be done" and
D must convince managers of its usefulness in answering that question

- A #pragma-like directive or compiler switch is always possible to scope sections of code that should assume positive indices only

- One of the great features of C++, with which D must compete, is STL; and STL offers backward iterators

- One of the great features of script languages (including MATLAB, IDL, and
Mathematica along with Icon/Perl/Python families) is their facility with
manipulating data in ways that C/C++ cannot, and the more of those features
are available in D, the better; I do not view C/C++ as any kind of model
language in terms of data manipulation, and that by itself has driven many
people away from C++ even though performance is lower; again, the
"get it done" factor outweighs inner loop performance almost every time,
and when inner loop performance becomes a concern, it will merit its own
engineering effort

- Negative indices have a direct influence on the design of circular buffers which were mentioned in a previous post

- Thanks everyone for an interesting discussion and to Walter

Mark


In article <an66dr$jok$1@digitaldaemon.com>, Walter says...
>
>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];
>    }
>

Whats wrong with using

str[(i + str.length) mod str.length];

or if you want more that one wrap of negative indexing use

str[(i + (x * str.length)) mod str.length];

where x denotes how many times round negative you need to go.

I think this it is only going to be off use to a minority of people and should be coded when they need it. Also if you are doing convolution as has been sugested it would realy slow the perfomance very severly, at least 100%.  I definatly would not use it because of that and the fact that its little (if not none) use in audio dsp.

chris


"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.

Chris,

This whole area of array manipulation is one of the huge, gaping holes in C/C++ that any replacement language should strive to fix.  I categorically disagree that array (and by extension, string) manipulation is some kind of obscure backwater.

If you focus attention on numerical routines like convolution then you can probably isolate cases where negative indices cause a real performance hit.  So what.  My experience teaches that coding correctly and quickly is vastly more important.  Performance issues always take a back seat.  I say to you about extreme performance just what you say to me about negative indexing: it's only helpful to a small minority who should be hand-coding anyway.

I've written literally dozens of convolution routines (1D and 2D) using C and also using script languages.  The first thing I did was to construct a "negative index" system to facilitate the convolution algorithms.  In some languages that was not necessary because it was already built-in.  Guess which languages I preferred?  I would have been in heaven if my C compiler had supported negative indices.

I've also used negative indexing extensively in Icon string processing and  it is a real blessing.  (Consider right-to-left languages, among other things.)  I swear, one of these days I am going to port Icon to C, just so I can have its string processing power in C.

I am beginning to wonder how D will become "a better C++" if nobody wants non-C++ features in the language!

Mark


In article <an88kh$2nc1$1@digitaldaemon.com>, chris jones says...
>
>Whats wrong with using
>
>str[(i + str.length) mod str.length];
>
>or if you want more that one wrap of negative indexing use
>
>str[(i + (x * str.length)) mod str.length];
>
>where x denotes how many times round negative you need to go.
>
>I think this it is only going to be off use to a minority of people and should be coded when they need it. Also if you are doing convolution as has been sugested it would realy slow the perfomance very severly, at least 100%.  I definatly would not use it because of that and the fact that its little (if not none) use in audio dsp.
>
>chris
>
>
>"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.
>
>

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:an7uj7$2dpn$1@digitaldaemon.com...
> The concern over performance is valid but:
>
> - Unsigned integers require no test at all, so a different object code gen subroutine could be invoked for them

Yes, that could work, but couldn't the subtly different behavior be pretty confusing?

> - The kind of performance worry under consideration is one of those that matters only to serious numerical analysts and database engineers, who are working with fairly large data sets, not everyday programming; even with the extra test, my bet is that performance won't suffer more than 5%-10% in typical algorithms

5-10% is probably accurate, but it doesn't take too many of those to kill the performance. Nobody expects Icon or Python to execute fast, but people will expect D to.

> - The gains are huge with negative indices in algorithm design, and most
> software managers glady sacrifice performance to "get the job done";
> that is where D must really shine, not inner loop performance;
> I've *never* had a manager complement me on inner loop performance,
> but they *always* want to know "when will the project be done" and
> D must convince managers of its usefulness in answering that question

I write a lot of system code, and I have had acceptance held up until that last 10% of speed was achieved. I've seen a lot of (inaccurate) dissing of C++ as being slower than C; the last thing D needs is the convenient excuse for not using it because it is irredeemably slower than C++.

> - A #pragma-like directive or compiler switch is always possible to scope sections of code that should assume positive indices only

That will work, but forgive me, down that path lies madness <g>.

> - One of the great features of C++, with which D must compete, is STL; and STL offers backward iterators

The STL iterator issue is important, and I have some ideas for addressing it.

> - One of the great features of script languages (including MATLAB, IDL,
and
> Mathematica along with Icon/Perl/Python families) is their facility with manipulating data in ways that C/C++ cannot, and the more of those
features
> are available in D, the better; I do not view C/C++ as any kind of model
> language in terms of data manipulation, and that by itself has driven many
> people away from C++ even though performance is lower; again, the
> "get it done" factor outweighs inner loop performance almost every time,
> and when inner loop performance becomes a concern, it will merit its own
> engineering effort

But the people D needs to attract are those people who want performance in their language.

> - Negative indices have a direct influence on the design of circular
buffers
> which were mentioned in a previous post

Yes. But you can always make it work by designing an inline function.

> - Thanks everyone for an interesting discussion and to Walter

Yes, it is a great discussion and your ideas are valuable. I do especially appreciate reading your well thought out arguments for them.

"Walter" <walter@digitalmars.com> wrote in message news:an4pt6$2b0o$1@digitaldaemon.com...
> 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.
>

That kind of runtime cost is not affordable.
BUT:

What if this "symmetric" indexing is done through a separate property? The [] operator remains the same, and you invent a new property such as:

char a = str.at(i);

This new property would do symmetric indexing, and ... well ... upper bounds
checking?
I think this combination would result in maximum runtime performance.
If we don't have the opportunity to build own dynamic array types (lack of
[] operator overload),
then the built-in array type should be feature-rich.

Yours,
Sandor

"vb" <none@nil.com> ha scritto nel messaggio 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.

In C/C++ you can do it easily:

 char str[] = "Hello";
 char * str_end = str + strlen(str);

i         str_end[i]
0            \0
-1          o
-2          l
-3          l
-4          e
-5         H

Is this still possible in D?

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:an96cn$lci$1@digitaldaemon.com...
> "vb" <none@nil.com> ha scritto nel messaggio 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.
>
> In C/C++ you can do it easily:
>
>  char str[] = "Hello";
>  char * str_end = str + strlen(str);
>
> i         str_end[i]
> 0            \0
> -1          o
> -2          l
> -3          l
> -4          e
> -5         H
>
> Is this still possible in D?
>
> Ciao

Pointers are discouraged. IMHO, a similar D-ish solution would be *reverse slices*.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:an8chi$2qp4$1@digitaldaemon.com...
> Chris,
>
> This whole area of array manipulation is one of the huge, gaping holes in
C/C++
> that any replacement language should strive to fix.  I categorically
disagree
> that array (and by extension, string) manipulation is some kind of obscure
> backwater.

I can see why it is desirable but i have only needed it a couple of times in the last few so i guese its of little importance to me.

> If you focus attention on numerical routines like convolution then you can probably isolate cases where negative indices cause a real performance
hit.  So
> what.  My experience teaches that coding correctly and quickly is vastly
more
> important.  Performance issues always take a back seat.  I say to you
about
> extreme performance just what you say to me about negative indexing: it's
only
> helpful to a small minority who should be hand-coding anyway.

It would cause a severe performance hit in every instance of convolution. If every array index now takes twice as long that is unaceptable for most dsp programers i know, the same people who probably would benefit from negative indexing would also be very unhapy with the performance hit.

Also if it was built into the language it would have to be more robust and would be even slower you couldn't asume a minumun negative wrap round and hence it would take more than the extra 3 arithmetic ops, mabey even a jmp, arrgh. I get a significant perfomance increase when i turn the bounds checking of in delphi so i guese negative indexing would be the same, if not more, i think its 4 ops for bounds checking in delphi.

Actualy what i would like - and negative indexing could be an extension to this idea - is to be able to specify when accesing the array whether you want bounds checking. Nagative indexing could be an option but i do not want to be forced to use it. I dont know what good syntax would be, definatly not like this but the idea is....

str[i]    bounds checked no negative indexing
str![i]    no bounds checking
str-[i]     negative indexed


> I've written literally dozens of convolution routines (1D and 2D) using C
and
> also using script languages.  The first thing I did was to construct a
"negative
> index" system to facilitate the convolution algorithms.  In some languages
that
> was not necessary because it was already built-in.  Guess which languages
I
> preferred?  I would have been in heaven if my C compiler had supported
negative
> indices.

What is so hard about the method i sugested?

> I've also used negative indexing extensively in Icon string processing and
it
> is a real blessing.  (Consider right-to-left languages, among other
things.)  I
> swear, one of these days I am going to port Icon to C, just so I can have
its
> string processing power in C.
>
> I am beginning to wonder how D will become "a better C++" if nobody wants non-C++ features in the language!

I though part of the idea was to keep a small feature set to ovoid the Bloat++. Actualy i think D is shapping up to be an exelent language but in that it cant also be all things to all people.

chris

In article <an59h5$2ptq$1@digitaldaemon.com>, Mike Wynn says...
>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.

And a hearty second for that!  The performance problem with allowing negative indices on unadorned arrays is that you take the performance hit on every array index, even for arrays that you know are never going to be negatively indexed. I really like the wrap/ring idea, because it lets normal arrays be accessed at full speed, and special case arrays be treated as special case arrays.

Dunno about the syntax.  Works well enough for me, but I could also see "building it in" to arrays, kind of like reverse():

array.wrap()[idx]
array.ring()[idx]

or
array.wrap(idx)
array.ring(idx)

I have to admit that I prefer your syntax over mine, but thought I'd throw it out there in case it had any consistency or parsing benefits that might outweigh the aesthetic problems...

Mac

In article <an66dr$jok$1@digitaldaemon.com>, Walter says...
>
>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];
>    }

And since arrays know their length at all times, D's str.length is 'length' times faster than C's strlen(str), which had to do a linear traversal looking for the NULL.  That makes the D version not just a syntactic difference, but a very real performance improvement.

Mac