"dpb" <email@example.com> wrote in message news:firstname.lastname@example.org... > On 3/21/2014 10:40 AM, dpb wrote: >> On 3/21/2014 8:46 AM, Steven Lord wrote: > ... > >>> I wouldn't use this approach; I'd instead select the elements to keep. >>> It avoids the IF and ELSEIF statements at the expense of a call to MIN: >>> >>> minRows = min(x, y); >>> a = a(1:minRows, :); >>> b = b(1:minRows, :); >>> >> ... >> >> It then also has the cost of the selection on both where one is already >> ok that the if...elseif avoids which is why I went that route. > ... > > I'm presuming the ML JIT optimization can't tell the above copy doesn't > need to happen, of course. Is the runtime code generation that smart, > Steven?
I really don't want to discuss the internal guts of the JIT for several reasons, among them: it WILL change from release to release; it gets really complicated really fast; and I hope that eventually/soon we get to a point where MATLAB is good enough at doing what it does that you guys _don't care_ (aside perhaps from curiosity) what we do internally to execute the code. [Yeah, I know that last one'll never happen. I can hope, can't I?]
My suggestion: don't write your code in some awkward way tailored to the current implementation of the underlying "guts" of MATLAB. Program your code in a way that makes sense, and if it's not working as quickly or as efficiently as you think let us know so we can improve MATLAB (or so we can offer suggestions as to how to modify your code so it still makes sense but also works more quickly or efficiently.)