Your comments
The bug is more interesting.
The issue repeats every 64 values (modulo 64).
Try for example:
a = (1:200)';
b=mp(a(1:100));
c=mp(a(101:200));
d = [b;c];
This "black magic" is definitely not related to toolbox :-).
The issue repeats every 64 values (modulo 64).
Try for example:
a = (1:200)';
b=mp(a(1:100));
c=mp(a(101:200));
d = [b;c];
This "black magic" is definitely not related to toolbox :-).
Confirmed. R2014a also has this issue.
The main issue here is that actually toolbox has no influence on variable editor functionality.
Looks like Matlab's bug. Will check further.
The main issue here is that actually toolbox has no influence on variable editor functionality.
Looks like Matlab's bug. Will check further.
Is there any possibility for vectorization?
A(1:n,1:m) = ...
A(1:n,1:m) = ...
Hello Michael,
This is a very good question!
At first, let me show results for 'vpa' matrices for the sake of completeness and fairness:
A=vpa(zeros(200,200));
tic
for ii =1:200
for jj = 1:200
A(ii,jj)=vpa('1.234');
end
end
toc
Elapsed time is 128.775 seconds.
tic
for ii =1:200
for jj = 1:200
A(ii,jj)=vpa('1.234');
end
end
toc
Elapsed time is 370.221 seconds.
Our computers are comparable in performance (as I see from your timings) - so that you should see approximately the same values on your system.
***
There are two natural questions:
1. Why we are faster (with or without pre-allocation)?
2. Why pre-allocation doesn't make any difference in our case?
Although MATLAB's language is simple to learn and great for computations, it was born as procedural, not object-oriented (which is needed to support custom types, like "mp", efficiently).
Recently TMW has been working on adding OOP features, but still MATLAB provides only limited OOP-capabilities.
In particular, it doesn't allow to overload the destructor and basic assignment operator "=" for custom types (e.g. in case of A = B).
As a result, third-party toolboxes are not able to manage its own data and have to rely on legacy MEX API, which is slow and heavily based on copying the data on every call (copy-overhead).
When it comes to basic array operations (e.g. indexing, assignment, etc.) MATLAB provides its own routines for that. Such routines are highly optimized for usual arrays of "double" numbers. But they are extremely slow for arrays of custom objects.
If we combine all of these imperfections - we will get the terrible performance. Good example is VPA - it is based on standard OOP capabilities of MATLAB and it is slower than "mp" by a large margin.
We do not think this is acceptable and we have been fighting with the situation since the beginning.
First, we are using undocumented MEX API to avoid the copy-overhead [1].
Secondly, we re-implemented all array manipulation operations from the scratch - in a specific way for "mp" objects [2].
Although this allows us to be much faster than VPA, still MEX/MATLAB overhead is of 70-80% of the total time!
Pre-allocation cannot provide predictable merit in these conditions too.
Next version of array manipulation engine is under development - it will introduce some new workarounds and hopefully it will be 5-10 times faster (at least for the simple case as you demonstrated). Pre-allocation will start to play an important role then.
Unfortunately most of the issues are related to restrictions in MATLAB itself. If they would allow more flexible plug-in architecture & OOP features - such operations won't take much longer than with built-in "double" precision arrays.
Sorry for such long e-mail, this is just ongoing PITA topic for us for a long time.
[1] http://goo.gl/6AvHfH
[2] http://goo.gl/AJGPg2
This is a very good question!
At first, let me show results for 'vpa' matrices for the sake of completeness and fairness:
A=vpa(zeros(200,200));
tic
for ii =1:200
for jj = 1:200
A(ii,jj)=vpa('1.234');
end
end
toc
Elapsed time is 128.775 seconds.
tic
for ii =1:200
for jj = 1:200
A(ii,jj)=vpa('1.234');
end
end
toc
Elapsed time is 370.221 seconds.
Our computers are comparable in performance (as I see from your timings) - so that you should see approximately the same values on your system.
***
There are two natural questions:
1. Why we are faster (with or without pre-allocation)?
2. Why pre-allocation doesn't make any difference in our case?
Although MATLAB's language is simple to learn and great for computations, it was born as procedural, not object-oriented (which is needed to support custom types, like "mp", efficiently).
Recently TMW has been working on adding OOP features, but still MATLAB provides only limited OOP-capabilities.
In particular, it doesn't allow to overload the destructor and basic assignment operator "=" for custom types (e.g. in case of A = B).
As a result, third-party toolboxes are not able to manage its own data and have to rely on legacy MEX API, which is slow and heavily based on copying the data on every call (copy-overhead).
When it comes to basic array operations (e.g. indexing, assignment, etc.) MATLAB provides its own routines for that. Such routines are highly optimized for usual arrays of "double" numbers. But they are extremely slow for arrays of custom objects.
If we combine all of these imperfections - we will get the terrible performance. Good example is VPA - it is based on standard OOP capabilities of MATLAB and it is slower than "mp" by a large margin.
We do not think this is acceptable and we have been fighting with the situation since the beginning.
First, we are using undocumented MEX API to avoid the copy-overhead [1].
Secondly, we re-implemented all array manipulation operations from the scratch - in a specific way for "mp" objects [2].
Although this allows us to be much faster than VPA, still MEX/MATLAB overhead is of 70-80% of the total time!
Pre-allocation cannot provide predictable merit in these conditions too.
Next version of array manipulation engine is under development - it will introduce some new workarounds and hopefully it will be 5-10 times faster (at least for the simple case as you demonstrated). Pre-allocation will start to play an important role then.
Unfortunately most of the issues are related to restrictions in MATLAB itself. If they would allow more flexible plug-in architecture & OOP features - such operations won't take much longer than with built-in "double" precision arrays.
Sorry for such long e-mail, this is just ongoing PITA topic for us for a long time.
[1] http://goo.gl/6AvHfH
[2] http://goo.gl/AJGPg2
The '1i' syntax is standard in MATLAB. It is strange that 'vpa' doesn't support it.
Please modify the mp2sym script as follow:
Please modify the mp2sym script as follow:
r = sym(zeros(size(s))); for n=1:numel(s), r(n) = sym(strrep(num2str(s(n)),'i','*i')); end;
Customer support service by UserEcho
We tap into some undocumented features to make MATLAB show the "mp" objects in variable editor.
Still, there is no control on how MATLAB does this in detail. MATLAB calls functions from toolbox to determine the dimensionality of "mp"-variable and its string representation (for display). All other "magic" is its responsibility.
The "mp" matrices and arrays clearly have correct dimensionality (nothing would work otherwise).
Conversion to string can be easily tested as well, by 'num2str' or 'display' functions.
That is why I conclude that bug is in MATLAB.
I believe they have some issues with handling custom types in variable editor (I see similar issues at many other places). Hope they will improve quickly.