A workaround, to avert 2X slowdown in purely double precision programs, is to delete Advanpix from Matlab Path permanently.
To check which BLAS and LAPACK are loaded,
at Matlab command prompt enter:
For those who are designing a machine (hardware) specifically to exceed Matlab's bench() function, they need to know that merely having Advanpix in Matlab Path causes 2X slowdown in R2023a. Solution is to take Advanpix out of Path while building.
ADVANPIX NOT IN MATLAB PATH
ADVANPIX IN MATLAB PATH
There is a second 2X slowdown caused by using Intel (Matlab R2023a default) BLAS and LAPACK on an AMD CPU.
Solution is to install AOCL from AMD: amd.com/en/developer/aocl.html
Then, in Windows Environment:_______________________________________add to Path: C:\Program Files\AMD\AOCL-Windows\amd-blis\lib\ILP64 add System Variable: BLAS_VERSION = AOCL-LibBlis-Win-MT-dll.dlladd to Path: C:\Program Files\AMD\AOCL-Windows\amd-libflame\lib\ILP64add System Variable: LAPACK_VERSION = AOCL-LibFLAME-Win-MT-dll.dll
("I" in front of "LP64" identifies 64-bit OS.)
You will know if you did it right when first time invoking bench() echoes AMD BLAS and LAPACK load.
Yes, true. But that method is not super quick. It requires more coding.
Presently, mp.Digits(34) is a special case that instructs MCT to use hardware microinstructions.
Why cannot mp.Digits(16) be similarly reserved to invoke double precision hardware microinstructions?
Presently, mp.Digits(16) is more precise than double precision. But the same is not true for mp.Digits(34); i.e, had you not invoked hardware microinstructions in that case, then mp.Digits(34) would be more precise than it is now (but slower).
In summary, I think mp.Digits(16) should invoke hardware microinstructions just as mp.Digits(34) does.
We are not suggesting mixed precision.
My original query concerns only passing number-of-digits precision to a subroutine.
User-written subroutines do not respect precision of the arguments;
i.e, the subroutine defaults to 34 digits regardless of input argument precision.
But consider the example on this page:
>> x = mp.rand(100,100);
>> tic; ifft(fft(x)); toc;
Elapsed time is 0.839798 seconds.
The fft() respects input precision of the arguments.This leads to an expectation of consistency; i.e, a subroutine (user-written or otherwise) should always be executed in precision of the arguments. But that is not the case.
Pavel, where is the treatment of subroutine execution precision disclosed in the documentation? I cannot find it.
Pavel, on your webpage
there is reference to Matlab's nchoosek().
I posted matlab code for linking to its complete (negative argument) binomial coefficient definition here:
Here is LaTeX output:
Change .txt to .mat in above; i.e,
A = rand(3,3,4,'mp');
B = mp.read('mpmatrix.mat');
Error using mp (line 1331)Error: uneven number of elements in the rows.Error in mp.read (line 1017) A = mp(['[',s,']']);
This .mat file format is read/writable to both Mathematica and Matlab.
Multiprecision Toolbox already understands .mat; e.g, mp.read() and mp.write().
But it coughs on import of multidimensional arrays. Should it not, if not textual?
This makes communication inelegant, by file transfer with Mathematica.
Previous versions need to be online to test for version-dependent anomalies and to rebuild a computer.
With Verve you can keep a thousand previous versions.
Customer support service by UserEcho