MATLAB Central Newsreader - How can you enlarge a matrix by adding zeroes

How can you enlarge a matrix by adding zeroes

Ellen — Fri, 15 Jun 2012 21:43:06 +0000

Okay. Clearly that doesn't make sense worded like that. Let's say I have a matrix
[1;2;3;4;5]
But I want to to have dimensions 1x10. How could I fill the matrix up so that it is now
[1;2;3;4;5;0;0;0;0;0]
if I didn't know that the matrix originally had a dimension of 1x5. I only knew it had a dimension somewhere between 1x1 and 1x10.
If that is even possible. Or if that even makes sense. Thanks!

Re: How can you enlarge a matrix by adding zeroes

dpb — Fri, 15 Jun 2012 21:48:10 +0000

On 6/15/2012 4:43 PM, Ellen wrote:
> Okay. Clearly that doesn't make sense worded like that. Let's say I have
> a matrix
> [1;2;3;4;5] But I want to to have dimensions 1x10. How could I fill the
> matrix up so that it is now
> [1;2;3;4;5;0;0;0;0;0] if I didn't know that the matrix originally had a
> dimension of 1x5. I only knew it had a dimension somewhere between 1x1
> and 1x10.
> If that is even possible. Or if that even makes sense. Thanks!

If it exists in Matlab, it has a determinable dimension in each direction.

Surprisingly enough, the function to determine this is size() :)

doc size

To add from a given size to some other simply calculate what you need...

x=[1:5]';
x=[x; zeros(10-length(x),1)]; % another useful function here...
size(x)

--

Re: How can you enlarge a matrix by adding zeroes

Greg Heath — Sat, 16 Jun 2012 03:53:24 +0000

On Jun 15, 5:43

Re: How can you enlarge a matrix by adding zeroes

Nasser M. Abbasi — Sat, 16 Jun 2012 05:25:12 +0000

On 6/15/2012 10:53 PM, Greg Heath wrote:

>
> Therefore the dimensions are 10x1 and 5x1. Use dpb's syntax: [1:5]',
> etc
>

This syntax is not recommended. The better syntax is (1:5)'.

The [] are not necessary. That is what Code analyzer would report.

(edit->tools->Code analyze)

--Nasser

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 06:31:13 +0000

On 6/16/2012 12:25 AM, Nasser M. Abbasi wrote:
> On 6/15/2012 10:53 PM, Greg Heath wrote:
>
>>
>> Therefore the dimensions are 10x1 and 5x1. Use dpb's syntax: [1:5]',
>> etc
>>
>
> This syntax is not recommended. The better syntax is (1:5)'.
>
> The [] are not necessary. That is what Code analyzer would report.
>
> (edit->tools->Code analyze)
...

Well, if one starts following that advice, one will soon get more than a
little confused as to when/why parens vis a vis brackets are even there...

Extend it just a little and it breaks the other way...try writing

(1:5 ; 3:7)'

and see what it says about _that_.

--

Re: How can you enlarge a matrix by adding zeroes

Nasser M. Abbasi — Sat, 16 Jun 2012 06:47:26 +0000

On 6/16/2012 1:31 AM, dpb wrote:
> On 6/16/2012 12:25 AM, Nasser M. Abbasi wrote:
>> On 6/15/2012 10:53 PM, Greg Heath wrote:
>>
>>>
>>> Therefore the dimensions are 10x1 and 5x1. Use dpb's syntax: [1:5]',
>>> etc
>>>
>>
>> This syntax is not recommended. The better syntax is (1:5)'.
>>
>> The [] are not necessary. That is what Code analyzer would report.
>>
>> (edit->tools->Code analyze)
> ...
>
> Well, if one starts following that advice, one will soon get more than a
> little confused as to when/why parens vis a vis brackets are even there...
>
> Extend it just a little and it breaks the other way...try writing
>
> (1:5 ; 3:7)'
>
> and see what it says about _that_.
>

The above gives invalid syntax right in the editor. The editor shows
little red markers where the syntax errors are. Hence I do not see
how one can get confused by this vs. (1:5)' which does not give
syntax error.

I always run the code analyzer after I write something and
follow its advice and make the changes it recommends. (exceptions
is when I do not put ";" at end of a statement because I want to
see the output, but code analyzer flags these out as well).

But you are free not to follow its advice and write the code any
way you want.

--Nasser

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 12:17:14 +0000

On 6/16/2012 1:47 AM, Nasser M. Abbasi wrote:
> On 6/16/2012 1:31 AM, dpb wrote:
>> On 6/16/2012 12:25 AM, Nasser M. Abbasi wrote:
>>> On 6/15/2012 10:53 PM, Greg Heath wrote:
>>>
>>>>
>>>> Therefore the dimensions are 10x1 and 5x1. Use dpb's syntax: [1:5]',
>>>> etc
>>>>
>>>
>>> This syntax is not recommended. The better syntax is (1:5)'.
>>>
...

>> Well, if one starts following that advice, one will soon get more than a
>> little confused as to when/why parens vis a vis brackets are even
>> there...
>>
>> Extend it just a little and it breaks the other way...try writing
>>
>> (1:5 ; 3:7)'
>>
>> and see what it says about _that_.
>>
>
> The above gives invalid syntax right in the editor. The editor shows
> little red markers where the syntax errors are. Hence I do not see
> how one can get confused by this vs. (1:5)' which does not give
> syntax error.

Only if you have a release of Matlab that does that (which I don't and
never will unless the big contract falls from the sky which isn't likely...)

Meanwhile, if you try to train yourself to use () instead of [] in the
restricted cases in which it makes sense while building a matrix you've
then the pita of fixing all those red marks instead of making them int
he first place.

> I always run the code analyzer after I write something and
> follow its advice and make the changes it recommends. (exceptions
> is when I do not put ";" at end of a statement because I want to
> see the output, but code analyzer flags these out as well).
>
> But you are free not to follow its advice and write the code any
> way you want.

Well, there's blind adherence and then there's reasonable use of the
code analyzer's input. I see absolutely no reason for the "suggestion"
to not use [] when building a matrix whether 1D or not--it's consistency
in syntax that leads to productivity not trying to do some special-rule
thingie. The specific usage was not as array subscript vector even in
though in that case it works; it just makes no sense at all to switch
just because it is possible.

--

Re: How can you enlarge a matrix by adding zeroes

Greg Heath — Sat, 16 Jun 2012 15:03:09 +0000

dpb <none@non.net> wrote in message <jrhtga$4ij$1@speranza.aioe.org>...
> On 6/16/2012 1:47 AM, Nasser M. Abbasi wrote:
> > On 6/16/2012 1:31 AM, dpb wrote:
> >> On 6/16/2012 12:25 AM, Nasser M. Abbasi wrote:
> >>> On 6/15/2012 10:53 PM, Greg Heath wrote:
> >>>
> >>>>
> >>>> Therefore the dimensions are 10x1 and 5x1. Use dpb's syntax: [1:5]',
> >>>> etc
> >>>>
> >>>
> >>> This syntax is not recommended. The better syntax is (1:5)'.
> >>>
> ...
>
> >> Well, if one starts following that advice, one will soon get more than a
> >> little confused as to when/why parens vis a vis brackets are even
> >> there...
> >>
> >> Extend it just a little and it breaks the other way...try writing
> >>
> >> (1:5 ; 3:7)'
> >>
> >> and see what it says about _that_.
> >>
> >
> > The above gives invalid syntax right in the editor. The editor shows
> > little red markers where the syntax errors are. Hence I do not see
> > how one can get confused by this vs. (1:5)' which does not give
> > syntax error.
>
> Only if you have a release of Matlab that does that (which I don't and
> never will unless the big contract falls from the sky which isn't likely...)
>
> Meanwhile, if you try to train yourself to use () instead of [] in the
> restricted cases in which it makes sense while building a matrix you've
> then the pita of fixing all those red marks instead of making them int
> he first place.
>
> > I always run the code analyzer after I write something and
> > follow its advice and make the changes it recommends. (exceptions
> > is when I do not put ";" at end of a statement because I want to
> > see the output, but code analyzer flags these out as well).
> >
> > But you are free not to follow its advice and write the code any
> > way you want.
>
> Well, there's blind adherence and then there's reasonable use of the
> code analyzer's input. I see absolutely no reason for the "suggestion"
> to not use [] when building a matrix whether 1D or not--it's consistency
> in syntax that leads to productivity not trying to do some special-rule
> thingie. The specific usage was not as array subscript vector even in
> though in that case it works; it just makes no sense at all to switch
> just because it is possible.

I agree.

However, the point I was trying to make was to use the " ' " instead of
the plethora of internal " ; "s.

Of course that has to change to " .' " with complex elements.

Hope this helps.

Greg

Re: How can you enlarge a matrix by adding zeroes

Bruno Luong — Sat, 16 Jun 2012 15:50:07 +0000

dpb <none@non.net> wrote in message <jrhtga$4ij$1@speranza.aioe.org>...
> On 6/16/2012 1:47 AM, Nasser M. Abbasi wrote:

>
> Well, there's blind adherence and then there's reasonable use of the
> code analyzer's input. I see absolutely no reason for the "suggestion"
> to not use [] when building a matrix whether 1D or not--it's consistency
> in syntax that leads to productivity not trying to do some special-rule
> thingie. The specific usage was not as array subscript vector even in
> though in that case it works; it just makes no sense at all to switch
> just because it is possible.

Something about this warning that always bugs me.

I believe warning tells something like [1:5] is less efficient than (1:5). But if it can detect what it can't correct it automatically when the code is parsed?

May be it warns when the code would be run on older MATLAB version?

At the time where I was aware about this warning, I prefer to use [] rather than () for clarity of coding, since parenthesis can be used for a lot of other circumstances (function, expression), whereas bracket is used exclusively for array.

Just my $.02

Bruno

Re: How can you enlarge a matrix by adding zeroes

Nasser M. Abbasi — Sat, 16 Jun 2012 16:16:54 +0000

On 6/16/2012 7:17 AM, dpb wrote:

>
> Well, there's blind adherence and then there's reasonable use of the
> code analyzer's input. I see absolutely no reason for the "suggestion"
> to not use [] when building a matrix whether 1D or not

Just because you see no reason really means nothing.

Matlab is closed source. We do not know how Matlab handles () vs. []
in this case. You have no access to the Matlab parser and the interpreter
source code to see, and no one else has unless they work inside Mathworks.

We as users, we have to assume the Matlab engineers who added this
message to the code analyzer had a good reason to do it. They did
not add it just for for the fun of it.

You are free to second guess it and not follow the advice, but I
prefer not to.

--Nasser

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 17:02:21 +0000

On 6/16/2012 11:16 AM, Nasser M. Abbasi wrote:
> On 6/16/2012 7:17 AM, dpb wrote:
>
>>
>> Well, there's blind adherence and then there's reasonable use of the
>> code analyzer's input. I see absolutely no reason for the "suggestion"
>> to not use [] when building a matrix whether 1D or not
>
> Just because you see no reason really means nothing.

Just as your adherence... :)

> Matlab is closed source. We do not know how Matlab handles () vs. []
> in this case. You have no access to the Matlab parser and the interpreter
> source code to see, and no one else has unless they work inside Mathworks.

There's always the profiler. Show it makes a difference in a real case
and I'll change my opinion.

> We as users, we have to assume the Matlab engineers who added this
> message to the code analyzer had a good reason to do it. They did
> not add it just for for the fun of it.

Well, we can also assume that perhaps the code analyzer is just
excessively over-zealous in its pursuit of code purity which in this
case I'd expect has a pretty high chance of being the problem or that
even if there is a theoretical difference that it would be rare it could
be shown to actually make a measurable difference of significance.

> You are free to second guess it and not follow the advice, but I
> prefer not to.

Indeed, you can spend your development time as you see fit in making
inconsequential changes; I'll keep to the use of a symmetric syntax w/o
special rules to remember as much as possible and thereby be done coding
quicker and in the absolutely rare one in a billion or so case where it
actually makes a difference worry about fixing it then. :)

--

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 17:06:12 +0000

On 6/16/2012 10:03 AM, Greg Heath wrote:
> dpb <none@non.net> wrote in message <jrhtga$4ij$1@speranza.aioe.org>...
...
>> Well, there's blind adherence and then there's reasonable use of the
>> code analyzer's input. I see absolutely no reason for the "suggestion"
>> to not use [] when building a matrix whether 1D or not--it's
>> consistency in syntax that leads to productivity ...
>
> I agree.
> However, the point I was trying to make was to use the " ' " instead of
> the plethora of internal " ; "s.
...

Indeed, that was also one of the points trying to make in my initial
response; I was simply commenting above on Nasser's kneejerk reaction to
an essentially meaningless warning/suggestion...

--

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 18:02:23 +0000

On 6/16/2012 11:16 AM, Nasser M. Abbasi wrote:
...

> We as users, we have to assume the Matlab engineers who added this
> message to the code analyzer had a good reason to do it. They did
> not add it just for for the fun of it.
...

OK, I've done an extensive perusal of the online doc's for the last
release and I can find no hints of TMW suggesting to write matrices w/o
the brackets for performance in any situation.

The links to parentheses and brackets have essentially identical
documentation as I have here--it says 'help paren' has more info on
parentheses but I can't do that except locally.

I suppose it's possible that there's where the guidance is hidden but I
seriously doubt it says anything of the sort there, either.

So, I think the recommendation is simply an artifact of the code
analyzer nobody has ever questioned seriously as to the validity/reason
for it. Otherwise one has to presume there's a real reason for
special-casing the specific case and if so it's a significant oversight
in the documentation that it isn't discussed.

$0.025, imo, ymmv, etc., etc., etc., ...

Maybe S Lord will stumble upon the argu^h^h^h^hdiscussion and can
comment on the validity/significance of the analyzer and what
applications it is intended to address.

--

--

Re: How can you enlarge a matrix by adding zeroes

Bruno Luong — Sat, 16 Jun 2012 19:13:09 +0000

dpb <none@non.net> wrote in message <jrihne$ncn$1@speranza.aioe.org>...
thing of the sort there, either.
>
> So, I think the recommendation is simply an artifact of the code
> analyzer nobody has ever questioned seriously as to the validity/reason
> for it.

Yes me. I did the test, and don't see any notable speed difference between [1:5] and (1:5). Win-64 2012A.

tic
for i=1:1000000
a = [1:5];
end
toc % Elapsed time is 0.127151 seconds.

tic
for i=1:1000000
a = (1:5);
end
toc % Elapsed time is 0.124224 seconds.

Both are enclosed inside a function.

What is the mlint message about???

Bruno

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 19:32:02 +0000

On 6/16/2012 2:13 PM, Bruno Luong wrote:
> dpb <none@non.net> wrote in message <jrihne$ncn$1@speranza.aioe.org>...
> thing of the sort there, either.
>>
>> So, I think the recommendation is simply an artifact of the code
>> analyzer nobody has ever questioned seriously as to the
>> validity/reason for it.
>
> Yes me. I did the test, and don't see any notable speed difference
> between [1:5] and (1:5). Win-64 2012A.
...

> What is the mlint message about???
>
> Bruno

Bruno, I don't have a recent release...what does 'help paren' in you
release say? It doesn't have any such hint of any such usage does it?

As noted, I looked thru the online doc's fairly thoroughly and find
nothing; the one thing I can't do is the above for current/recent release.

--

Re: How can you enlarge a matrix by adding zeroes

Bruno Luong — Sat, 16 Jun 2012 19:57:07 +0000

dpb <none@non.net> wrote in message <jrimvi$4u1$1@speranza.aioe.org>...

>
> Bruno, I don't have a recent release...what does 'help paren' in you
> release say? It doesn't have any such hint of any such usage does it?

I did not see anything concerning the usage in the help.

Bruno

Re: How can you enlarge a matrix by adding zeroes

dpb — Sat, 16 Jun 2012 20:16:48 +0000

On 6/16/2012 2:57 PM, Bruno Luong wrote:
> dpb <none@non.net> wrote in message <jrimvi$4u1$1@speranza.aioe.org>...
>
>>
>> Bruno, I don't have a recent release...what does 'help paren' in you
>> release say? It doesn't have any such hint of any such usage does it?
>
> I did not see anything concerning the usage in the help.

What I expected... :)

I think it's a fig-newton of a remnant consequence of an implementation
algorithm w/ an unintended consequence, meself...iow, a bug. :)

--

Re: How can you enlarge a matrix by adding zeroes

Steven_Lord — Mon, 18 Jun 2012 14:21:01 +0000

"dpb" <none@non.net> wrote in message news:jrihne$ncn$1@speranza.aioe.org...
> On 6/16/2012 11:16 AM, Nasser M. Abbasi wrote:
> ...
>
>> We as users, we have to assume the Matlab engineers who added this
>> message to the code analyzer had a good reason to do it. They did
>> not add it just for for the fun of it.
> ...
>
> OK, I've done an extensive perusal of the online doc's for the last
> release and I can find no hints of TMW suggesting to write matrices w/o
> the brackets for performance in any situation.

Try this little experiment in the Command Window. You will receive warnings
from the DBSTOP calls, but that's to be expected.

http://www.mathworks.com/help/techdoc/ref/dbstop.html

"If file is not a MATLAB code file (for instance, it is a built-in or
MDL-file), then MATLAB issues a warning. MATLAB cannot stop in the file, so
it pauses before executing the file."

dbstop in horzcat
dbstop in vertcat
a = [5]

Note that MATLAB DOES call the built-in concatenation routine here, since
you're using []. Whether or not it calls the built-in concatenation routines
in a function file depends on how old a version of MATLAB you're using, I
think. The parser may be smart enough in later releases to avoid the
unnecessary call to the built-in concatenation routine since it can tell
that the built-in routine will be called. Code Analyzer does _static_
analysis of the code; the parser is not limited to static analysis when
running the code.

Granted, the concatenation routine doesn't have to DO much or anything in
this case, so it may not seem like a big deal. But consider doing this
inside a loop that iterates millions of times; the tiny overhead of calling
the built-in function may add up.

> The links to parentheses and brackets have essentially identical
> documentation as I have here--it says 'help paren' has more info on
> parentheses but I can't do that except locally.
>
> I suppose it's possible that there's where the guidance is hidden but I
> seriously doubt it says anything of the sort there, either.
>
> So, I think the recommendation is simply an artifact of the code analyzer
> nobody has ever questioned seriously as to the validity/reason for it.
> Otherwise one has to presume there's a real reason for special-casing the
> specific case and if so it's a significant oversight in the documentation
> that it isn't discussed.
>
> $0.025, imo, ymmv, etc., etc., etc., ...
>
> Maybe S Lord will stumble upon the argu^h^h^h^hdiscussion and can comment
> on the validity/significance of the analyzer and what applications it is
> intended to address.

If the parser has gotten smart enough, perhaps the particular message that
you and Bruno have been "discussing" is no longer necessary for functions or
classdef files. I'll ask the Code Analyzer developers to investigate and
determine if that message can be removed.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Re: How can you enlarge a matrix by adding zeroes

dpb — Mon, 18 Jun 2012 14:59:15 +0000

On 6/18/2012 9:21 AM, Steven_Lord wrote:
...

> Try this little experiment in the Command Window. You will receive
> warnings from the DBSTOP calls, but that's to be expected.
>
> http://www.mathworks.com/help/techdoc/ref/dbstop.html
>
> "If file is not a MATLAB code file (for instance, it is a built-in or
> MDL-file), then MATLAB issues a warning. MATLAB cannot stop in the file,
> so it pauses before executing the file."
>
> dbstop in horzcat
> dbstop in vertcat
> a = [5]
>
> Note that MATLAB DOES call the built-in concatenation routine here,
> since you're using [].

What am I supposed to see, Steve?

I see no difference between [] or ()...

>> dbstop in horzcat;dbstop in vertcat;a=[5]
??? Error using ==> dbstop
DBSTOP or DBCLEAR in a built-in function is not possible.

>> dbstop in horzcat;dbstop in vertcat;a=(5)
??? Error using ==> dbstop
DBSTOP or DBCLEAR in a built-in function is not possible.

>

It appears it stops either way...

> ... Whether or not it calls the built-in
> concatenation routines in a function file depends on how old a version
> of MATLAB you're using, I think. The parser may be smart enough in later
> releases to avoid the unnecessary call to the built-in concatenation
> routine since it can tell that the built-in routine will be called. Code
> Analyzer does _static_ analysis of the code; the parser is not limited
> to static analysis when running the code.
>
> Granted, the concatenation routine doesn't have to DO much or anything
> in this case, so it may not seem like a big deal. But consider doing
> this inside a loop that iterates millions of times; the tiny overhead of
> calling the built-in function may add up.

I can't see how the actual code executed by either path can be
significantly different for the limited cases in which the [] can be
replaced by () is where I was coming from, though, Steve. Bruno's test
was the type of test you outline above.

>> The links to parentheses and brackets have essentially identical
>> documentation as I have here--it says 'help paren' has more info on
>> parentheses but I can't do that except locally.
>>
>> I suppose it's possible that there's where the guidance is hidden but
>> I seriously doubt it says anything of the sort there, either.
...

>> Maybe S Lord will stumble upon the argu^h^h^h^hdiscussion and can
>> comment on the validity/significance of the analyzer and what
>> applications it is intended to address.
>
> If the parser has gotten smart enough, perhaps the particular message
> that you and Bruno have been "discussing" is no longer necessary for
> functions or classdef files. I'll ask the Code Analyzer developers to
> investigate and determine if that message can be removed.

If this is really a real issue and TMW can demonstrate to themselves
there's a realistic chance that anybody could ever tell the difference,
then I repeat that it definitely needs to go into the documentation
somewhere visible as a coding practice.

Until then, I still think the user will have more productive time in
maintaining a consistent coding style rather than trying to remember to
special case it or spending time fixing up warnings over it--I just
doubt he'll ever recoup that effort (at least until the profiler shows a
bottleneck and I'm thinking the chances of that are somewhere between
slim and none and Slim left town... :) )

It seems to me the kind of micro-optimizing that folks try to do to
smooge code into supposedly faster code by doing things like manual loop
unrolling, etc., on the assumption the compiler isn't as smart. These
days, most of the time the compiler optimizer is probably more capable
than the programmer who just writes clear, straightforward code (and
even Matlab keeps going farther that way w/ JIT and as you point out,
pretty smart parsing).

It's a nit, granted, but...

--

Re: How can you enlarge a matrix by adding zeroes

Steven_Lord — Tue, 19 Jun 2012 14:26:36 +0000

"dpb" <none@non.net> wrote in message news:jrnfo5$ujj$1@speranza.aioe.org...
> On 6/18/2012 9:21 AM, Steven_Lord wrote:
> ...
>
>> Try this little experiment in the Command Window. You will receive
>> warnings from the DBSTOP calls, but that's to be expected.
>>
>> http://www.mathworks.com/help/techdoc/ref/dbstop.html
>>
>> "If file is not a MATLAB code file (for instance, it is a built-in or
>> MDL-file), then MATLAB issues a warning. MATLAB cannot stop in the file,
>> so it pauses before executing the file."
>>
>> dbstop in horzcat
>> dbstop in vertcat
>> a = [5]
>>
>> Note that MATLAB DOES call the built-in concatenation routine here,
>> since you're using [].
>
>
> What am I supposed to see, Steve?

A behavior that it appears was introduced in a later version than the one
you're using, sorry. :(

> I see no difference between [] or ()...
>
> >> dbstop in horzcat;dbstop in vertcat;a=[5]
> ??? Error using ==> dbstop
> DBSTOP or DBCLEAR in a built-in function is not possible.
>
> >> dbstop in horzcat;dbstop in vertcat;a=(5)
> ??? Error using ==> dbstop
> DBSTOP or DBCLEAR in a built-in function is not possible.
>
> >
>
> It appears it stops either way...

In release R2012a, the first of those codes enters debug mode when the "a =
[5]" line was executed. The second does not.

*snip*

>> If the parser has gotten smart enough, perhaps the particular message
>> that you and Bruno have been "discussing" is no longer necessary for
>> functions or classdef files. I'll ask the Code Analyzer developers to
>> investigate and determine if that message can be removed.
>
> If this is really a real issue and TMW can demonstrate to themselves
> there's a realistic chance that anybody could ever tell the difference,
> then I repeat that it definitely needs to go into the documentation
> somewhere visible as a coding practice.

This particular Code Analyzer message may be warning about something that's
no longer be an issue (even if it may have been in the past) and that's why
I asked the Code Analyzer developers to investigate and consider removing
the message if appropriate. If there is a reason for this message to stick
around and it's not something extremely esoteric I'll ask that it be
included in the documentation.

> Until then, I still think the user will have more productive time in
> maintaining a consistent coding style rather than trying to remember to
> special case it or spending time fixing up warnings over it--I just doubt
> he'll ever recoup that effort (at least until the profiler shows a
> bottleneck and I'm thinking the chances of that are somewhere between slim
> and none and Slim left town... :) )

It's a fair point. As we've seen in CSSM, people will sometimes go to
extreme lengths to get what they believe to be a 1% increase in performance
... even before their code is fully finished.

> It seems to me the kind of micro-optimizing that folks try to do to smooge
> code into supposedly faster code by doing things like manual loop
> unrolling, etc., on the assumption the compiler isn't as smart. These
> days, most of the time the compiler optimizer is probably more capable
> than the programmer who just writes clear, straightforward code (and even
> Matlab keeps going farther that way w/ JIT and as you point out, pretty
> smart parsing).
>
> It's a nit, granted, but...

Agreed. That's one reason why we removed the column in the Profiler that
talked about whether a line was processed by the JIT -- ideally we want you
to write clear, clean code and let us (MathWorks) worry about making it
fast.
If some clear, clean code is not running fast enough THEN post to CSSM, ask
on MATLAB Answers, or ask Technical Support for how to modify the code to
improve the speed (or request of Technical Support that we investigate if
there's a way to make that clean code faster.)

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Re: How can you enlarge a matrix by adding zeroes

dpb — Tue, 19 Jun 2012 16:22:00 +0000

On 6/19/2012 9:26 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:jrnfo5$ujj$1@speranza.aioe.org...

...[big snip]...

>> ...I still think the user will have more productive time in
>> maintaining a consistent coding style rather than trying to remember
>> to special case it or spending time fixing up warnings over it--I just
>> doubt he'll ever recoup that effort (at least until the profiler shows
>> a bottleneck and I'm thinking the chances of that are somewhere
>> between slim and none and Slim left town... :) )
>
> It's a fair point. As we've seen in CSSM, people will sometimes go to
> extreme lengths to get what they believe to be a 1% increase in
> performance .... even before their code is fully finished.
...
> If some clear, clean code is not running fast enough THEN post to CSSM,
> ask on MATLAB Answers, or ask Technical Support for how to modify the
> code to improve the speed (or request of Technical Support that we
> investigate if there's a way to make that clean code faster.)
>

OK, thanks, Steven...I think/agree the review is worthy way to proceed.

--