Ваші коментарі
Dear Jason,
Toolbox already overloads all element-wise operations. Moreover, the error message is perfectly valid, as arrays have incompatible dimensions - in fact, all MATLABs up to 2016a return the same error message for this operation.
However a year ago (starting from R2016b), MATLAB developers added "implicit arithmetic expansion" to make this kind of operations valid [1].
IMHO the feature is questionable, as it could break old code (e.g. see [2]) and it makes new code incompatible with older MATLABs.
This feature is not implemented in toolbox for the time being, please use classic MATLAB's techniques.
For example, A = bsxfun(@times,x,y) does exactly this.
[1] https://blogs.mathworks.com/loren/2016/10/24/matlab-arithmetic-expands-in-r2016b/
[2] http://undocumentedmatlab.com/blog/afterthoughts-on-implicit-expansion
Dear Iuliia,
Thank you for the question.
Yes, indeed, fmincon is in our todo list and actually we have beta version of fmincon (not included in toolbox yet).
What optimization algorithm do you use in fmincon? So far our code supports "trust-region-reflective" and "active-set".
I will send you the code by email in a minute.
I am afraid, quality extended-precision library for GPU is non-existent.
Toolbox provides state-of-the-art performance on CPU. Special GPU version of toolbox is under development, but there is no strict plans on its release.
Dear Abhranil,
Thank you for your question.
At the moment, toolbox doesn't support computations on GPU.
The quote you mention, refers to possible merits of implementing quadruple precision computations on GPU.
But this has not been done yet.
SVD decomposition in toolbox is well optimized for parallel execution. Its performance scales almost linearly with number of CPU cores. Try using CPU with more cores. On my six-core I have got 51 seconds:
>> A = rand(1000,'mp');
>> tic; [U,S,V] = svd(A); toc;
Elapsed time is 50.972569 seconds.
What is your target usage pattern of SVD (compute just once or many times)?
Please check this section in our User Manual:
https://www.advanpix.com/documentation/users-manual/#More_on_Existing_Code_Porting
It shows few examples of difference between precision & accuracy.
And, of course, I would also suggest to use powerful computer with multi-core CPU, etc.
Laptops are not usable for any serious computations (if you happen to use the one).
It depends on situation. In general it is better to compute everything as 'mp' from the onset.
But in some cases, e.g. ill-conditioning is localized only in one operation or your data came from real world measurements (and thus in low-precision) - then 'mp' can be applied only at some particular place.
Knowing nothing about your problem, I would suggest to try both ways and see the difference.
If you use octuple precision most of the times, you can put the mp.Digits(71) into mpstartup.m.
This will make it the default precision for every MATLAB/toolbox session.
Служба підтримки клієнтів працює на UserEcho
Hi Michal,
There is no bug in GNU Linux version of toolbox.
The difference in performance is because we have better development tools for Windows.
We have full stack of Intel development tools on Windows: Intel Compiler (ICC), Intel Profiler (VTune), etc.
This allows us to reach much better performance on Windows compared to other platforms.
We are non-for-profit company and we cannot afford full stack of Intel development tools for ALL platforms - Intel gives us no discounts despite our multiple requests.
Thus we are using GCC on GNU Linux and MacOSX. GCC stack of tools is good but it is light years behind the Intel compiler. In fact, we maintain our own version of GCC to make it of acceptable quality.
Hopefully we will be able to use Intel tools on all platforms in future