I agree that automatic conversion from string to double, esp. obvious in the case of “:”, causes some very unpleasant issues. People here are listening, though there is no immediate solution. Thanks for commenting.

–Loren

I would be thrilled to see implicit type conversion from char to double disappear in a future version of MATLAB. That has been a source of many bugs in my experience.

That’s just not part of indexing with MATLAB. The end has to be used directly in an expression so the context can be discerned. Though you can index with strings in MATLAB, sort of, the only string MATLAB really copes with is :. This has caused problems for some because double(‘:’) is 58 and that can cause some anomalies in code that I think of as strangely written (though others may disagree).

–Loren

idx={':','1:2:end'}
A(idx{:});

Maybe I’m doing something wrong but I get errors with this formulation.

In my work as a research student in image processing, I frequently have to deal with some sort of operation between two arrays of different number of dimensions (usually differing by one, but of the same size for the common dimensions) that seems natural enough to me to warrant having a simple way of implementing these operations, but currently either requiring a loop or the permute/reshape/repmat approach (that I originally learnt from Peter Acklam’s cool Matlab tips and tricks Guide).

I don’t know what the people over at MATLAB would think of this idea, or whether they’ve already considered something like this: introduce a special type of array that uses a special single-dimensional “modulus” index, e.g., if A is an array of this special type, of size m x n, then
A[x] and A[y] where x = rem(y-1, m*n)+1 refer to the same element. So if A is of size 3 x 4, for example, A[13] winds back to A[1], and so does A[25], etc.

Then operations between arrays of dimensions, for example, dim and dim-1, can be defined as operations between a “normal” array and the special array respectively.
So if I had M of size pxqxr and special array N of size pxq respectively (N being special), then P = M*N would matrix multiply each 2D slice of P with N, and P = M.*N would take the element-by-element product for each 2D slice of P with N, etc.

Admittedly I haven’t thought this through and my approach may be rubbish (the idea came to me just now, and I’m not really the sharpest knife in any drawer), but really the important thing for me is, I feel MATLAB really need to come up with a better way to handle operations between ND-arrays, and arrays of different numbers of dimension.

You have to permute the arrays to be truly 2-D to apply the operations (using permute, reshape, or squeeze perhaps).

–Loren

suppose there is a 3-dim ND array A of size n,3,2.
For each 1<=j<=n I interpret the “level” A(j,:,:) as a 3×2 matrix, but then matlab does perform computations for these “level-matrices”. In my particular case I aim at computing A(j,:,:)*A(j,:,:)’

I have a stack of 2D polygons. Can u suggest me a way to stack these polygons in 3D such that I get a 3D object out of these 2D polygons.

My solution is perhaps a bit ‘hackish’, but it works quite well. I wanted to be able to index an array called obj in the following ways (example is with obj being 2D):

obj(1:2:end, 1:2:end)
obj(1:2:end, 2:2:end)
obj(2:2:end, 1:2:end)
obj(2:2:end, 2:2:end)

For 3D it would be obj(1:2:end, 1:2:end, 1:2:end) etc. and there would be 2^3 combinations.

I used base-2 counting (via Matlab’s DEC2BIN) to enumerate the combinations and the actual indexing on obj was achieved by creating a string (e.g. ‘obj(1:2:end, 1:2:end)’) and then calling Matlab’s EVAL on that string.

The advantages of this method are:

one doesn’t have to learn a new syntax for indexing (I’ve been using Matlab for years and didn’t know of Loren’s cell array-based method, and it wouldn’t have occurred to me);

by generating strings, which are then evaluated, it’s easy to see exactly what would be computed (though actually the cell array method is equally transparent once you know about it).

I imagined the main disadvantage would be the performance hit of making Matlab to interpret code at run-time, however profiling on simple examples shows that there doesn’t appear to be a massive performance hit compared to some of the other Matlab functions I’m using (e.g. REGRESS, PADARRAY) in the code.

It would be interesting to know more about EVAL.