Your comments

A workaround, to avert 2X slowdown in purely double precision programs, is to delete Advanpix from Matlab Path permanently.

In programs requiring Advanpix MCT, lead off with Matlab command:
   addpath('C:\Program Files\Advanpix');
which remains valid for current session.

For purely double precision programs, lead off with Matlab commands:
   warning('off', 'MATLAB:rmpath:DirNotFound');
   rmpath('C:\Program Files\Advanpix');

Jon Dattorro

To check which BLAS and LAPACK are loaded, 

at Matlab command prompt enter:

version -blas

version -lapack

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

Image 44

                                                         ADVANPIX IN MATLAB PATH

Image 43


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:

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.dll

add to Path:
   C:\Program Files\AMD\AOCL-Windows\amd-libflame\lib\ILP64
add System Variable:


("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.

Jon Dattorro

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:

>> mp.Digits(100);
>> x = mp.rand(100,100);
>> norm(x-ifft(fft(x)),1)
>> 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, 

Matlab input:

A = rand(3,3,4,'mp');

mp.write(A, 'mpmatrix.mat');

B ='mpmatrix.mat');

Matlab output:

Error using mp (line 1331)
Error: uneven number of elements in the rows.
Error in (line 1017)
A = mp(['[',s,']']);

This .mat file format is read/writable to both Mathematica and Matlab.

Multiprecision Toolbox already understands .mat; e.g, 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.

100GB storage.

unlimited bandwidth.

$181 USD/year

Hi Pavel

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.