'123'-'0' vs [1,2,3] and mtree

14 views (last 30 days)
Daniel Shub
Daniel Shub on 11 Mar 2012
Edited: Jan on 21 Sep 2014
This is a Cody inspired question. From what I understand, the odd looking
'123'-'0'
has fewer programming nodes in the parse tree than the straight forward
[1, 2, 3]
Not having a CS background, and not really understanding what a parse tree is, does this make sense? Is this a peculiarity of MATLAB? Is there any situation in which one might prefer the former over the latter?
The more general question might be, how can I use the functionality provided by mtree to improve my code (not Cody answers, but actual "real" code).

Answers (2)

Walter Roberson
Walter Roberson on 11 Mar 2012
It does make sense from a parsing standpoint. Using pseudo-language
start argument list
load STRING"123" on list
load STRING"0" on list
call minus on argument list
versus
start argument list
load DP_NUMBER"1" on list
load DP_NUMBER"2" on list
load DP_NUMBER'3" on list
call horzcat on argument list
One more node for this version.
This is not really MATLAB specific. Some languages might note that the expressions are all constants and might perform the calculation at compile time and then just load the result at run time, but the parsing work would occur before that optimization. This corresponds to the MATLAB situation that the JIT might optimize either or both expressions.

Jan
Jan on 11 Mar 2012
Edited: Jan on 21 Sep 2014
If you want to reduce the memory footprint of a function, '123'-'0' is better than [1, 2, 3] - if this assumption is correct: The P-coding performs a parsing and the result is stored in uncompressed form in the memory. Then the size of Matlab-6-P-coded files is a equivalent to the memory foot print.
This does not work for modern P-files anymore, which are extremly well compressed. They are even smaller than the LZMA compressed M-files!
Why is the CHAR method smaller? Internally '123'-'0' creates both strings in the memory and performs the conversion to double and the subtraction at runtime. Storing the string needs 2 bytes per character => 8 bytes. [1,2,3] converts the values to double format during parsing. Then 3*8=24 bytes are required.
But the header of the Matlab variables matter for such small array also: About 120 bytes per variable. Therefore I use the CHAR-format for larger arrays only, e.g. [32x32] icons.
Of course storing the data as char array mean, that the dynamic conversion needs some time. Therefore I avoid to use it for frequently accessed data. And finally it is very unlikely, that the memory consumption of the parsed code is relevant compared to the processing data. Therefore this is my opinion:
The mtree size is not useful to improve real-world code.
An excellent example for this claim: See Cody: Sum 1:2^n. Creating the vector 1:2^n and adding the elemnts is optimal when measured with the mtree-size. James Tursa's solution is much more efficient when the memory foot print and the speed matter.

Categories

Find more on Argument Definitions in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!