Re: indexing improvements - advice wanted

[Jaroslav Hajek]

On Wed, Oct 29, 2008 at 8:18 PM, John W. Eaton <address@hidden> wrote:
> 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.
>

It's no problem, then. OK to push?

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



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz