Teie kommentaarid
10 aastat tagasi
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;
Hello Michael,
Thank you for the reports.
This is a bug and it has been fixed, please download updated version from our website - 3.7.1.7229.
(The reason - in matrix power function "^" we didn't fall back to coefficient-wise power operator ".^" when both arguments are scalars. Instead we were using the generic "pow" function limited in functionality. Not it has been fixed.)
Now I am investigating "bessely". Bessel functions have mature implementation for real arguments and preliminary support for complex arguments. Will update you asap.
Thank you for the reports.
This is a bug and it has been fixed, please download updated version from our website - 3.7.1.7229.
(The reason - in matrix power function "^" we didn't fall back to coefficient-wise power operator ".^" when both arguments are scalars. Instead we were using the generic "pow" function limited in functionality. Not it has been fixed.)
Now I am investigating "bessely". Bessel functions have mature implementation for real arguments and preliminary support for complex arguments. Will update you asap.
Customer support service by UserEcho
