Re: indexing improvements - advice wanted

[John W. Eaton]

On 29-Oct-2008, Jaroslav Hajek wrote:

| If you're trying more corner cases, perhaps you could add them to the
| test suite? It was a big help when I was doing this.

I'm just running some code that I have and that was written by others.
It is not a systematic test.  But so far I haven't noticed any obvious
failures, like an index expression or assignment returning an object
of the wrong size or orientation, which would likely generate an error
message.

| I'm not sure - I guess it depends on how far off 3.2.0 is. I wanted to
| also look at Sparse<T> (see my previous reply to David), so this patch
| has only gone "halfway", and if 3.2.0 is released, e.g., next week, I
| may not make it to finish the rest. But I really can't tell whether
| this is enough of a reason.

I think it will be at least a couple of months until 3.2.0.  As long
as your patch doesn't break sparse indexing, I don't see it as a
problem that you've only updated the dense indexing code.

| The single-subscript specialization are necessary, because single
| subscripts behave differently enough. I created two-subscripts
| specializations for several reasons:
| 1. It is the most common case.
| 2. The old code did so.
| 3. They avoid the rec_index_helper class machinery and recursive calls
| in favor of a single index reduction and a simple loop, so I hoped it
| would save bits of performance.
| 
| I don't think any of them is particularly strong, but together, they
| justified the thing for me. I guess the performance advantage will be
| barely visible, but I can test it.
| Simply comparing speed of a(i,j) vs. a(i,j,1) should actually do the trick.

I just wanted to know whether it would be possible to eliminate them.
I don't have a strong objection to keeping them.

| Good idea. I guess we can simply overload the () operators to do that.
| I'm not sure, however, whether an analogical thing can easily be
| achieved to support indexed assignment (we would need to return some
| kind of indexed proxy).
| If not, then maybe it is not such a good idea, because if b = a(i)
| works, people will IMHO tend to assume that a(i) = b works as well.

OK.  We can do this later if it seems useful enough.  I don't think
this extra complexity should be mixed in with the current patch.

Thanks,

jwe