Perhaps all present and past users of MCT should be notified (by direct email) that intrinsic behavior of random functions has changed with regard to: 1) Matlab `clear all' command, 2) extension from 55 digits to arbitrary precision, and 3) whether MCT randomization function algorithms now differ from Matlab.

Option (3): MCT reads/writes current state/seed from/to disk whenever  rand(n,m,'mp')  or  randn(n,m,'mp) is called.

Rationale: Spinning rust disk drives are obsolete.  

High-end Samsung PRO NVMe M.2 drives can reach on the order of 500,000 to 1,000,000 random write IOPS (4 KB) in burst conditions.  In contrast, even the fastest 15,000 rpm HGST enterprise hard disks typically peak around 300 to 400 random write IOPS.  In other words, the Samsung PRO M.2 SSD’s best-case random burst write performance is roughly three orders of magnitude higher than that of the best rotating magnetic media.

Advantage:  mp.RandState remains useful but no longer compulsory.

Matlab’s built-in random number generator never treats “clear all” as a command to reset or reseed its generator.  That behavior has also been integral to all prior MCT versions, which aligns with user expectations and ensures backward compatibility.  This sudden unexpected change without advance notice, making “clear all” reinitialize the MCT random seed, wields significant deleterious impact:

1. Breaks Established Code: Existing scripts rely on “clear all”, merely to remove variables and free memory, with the understanding that random seeds remain untouched.  Altering that assumption invalidates all results that previously depended on dynamic seeds.

2. Conflicts with Matlab Conventions: Users familiar with Matlab expect “clear all” to leave the random seed alone. Departure from that convention forces MCT users to incorporate extra & unexpected steps (like manually restoring the seed) whenever “clear all” appears in a script.

3. Impacts Reproducibility: Research code often depends on a fixed seed for reproducible Monte Carlo or simulation results. Changing that seed unintentionally, simply because “clear all” appears for housekeeping, undermines reproducibility and can lead to subtle or undetectable failures, erroneous or repetitive results, and false conclusions..

4. `Cause Unknown': Even experienced users will not know to remove "clear all" or to invoke the new mp.RandState function. Hours of needless debug time per user inevitably ensue.

While mp.RandState offers a manual workaround, it introduces overhead and potential for confusion.  Restoring the original MCT policy —so that MCT behaves like Matlab in not resetting the random generator after “clear all”— keeps MCT code compatible, predictable, and consistent with core Matlab behavior.

clear all

clc

mp_angle = 2*rand(1,'mp') - 1

dp_angle = 2*rand(1) - 1

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Run this program multiple times.

mp_angle is always the same.

dp_angle is always different.

Cause of bad mp_angle is `clear all' statement.

Despite Mathworks' recommendation against `clear all' usage, 

there are circumstances where it becomes necessary.

MCT must continue to work exactly the same as Matlab does.

Otherwise, every MCT program ever written with `clear all' is broken.

mp.Digits(1034);
nchoosek(mp('76'), mp('32'))

Warning: Result may not be exact. 

Coefficient has a maximum relative error of 7.9936e-15, corresponding to absolute error 21547503.
> In nchoosek (line 121)

      ans = 2 695 592 391 875 732 963 328  % incorrect

Correct answer is: 2 695 592 391 875 730 827 550

Accuracy (precision) of solution is not in question.  To say that two different multiprecision solutions are equivalent, because they fall within some calculable error tolerance, does not address the reproducibility problem at issue.  Mathworks certainly hasn't asserted that a small neighborhood of linear system solutions are equivalent.  One could indeed ask: Where does Matlab documentation state that linear system solution by mldivide() is NOT bit by bit deterministic?  The fact that double precision solution (of an overdetermined rank deficient linear system) is reproducible leads to an expectation of multiprecision reproducibility for MCT.

MCT can indeed produce an identical result (for the overdetermined rank deficient system in my seminal post) on a subsequent run for the very same problem:

ans = 3.312601991721914126549721394248086e-06    % different results

ans = 0                                                                              % identical results

This means that every neighborhood of equivalent solutions must include {0}.  "...multi-threading, flow of divide-and-conquer/bulge chasing computations" implies that MCT may have inadvertently introduced stochastics into the mldivide algorithm.  Nondeterministic MCT behavior implies departure from Matlab algorithms.  

MATLAB’s mldivide is expected deterministic; reproducible in floating point computations under identical conditions.  Repeated runs of the same problem in the same environment will yield the same bitwise result unless something in the environment changes; e.g, CPU type, number of threads, BLAS/LAPACK library, or MATLAB release:

mldivide (backslash)

https://www.mathworks.com/help/matlab/ref/mldivide.html

(From “Algorithms” and “Tips” sections):

“The mldivide function [...] performs a least-squares solution if A is rectangular. [...] The results of mldivide are sensitive to the condition of A. However, the same inputs on the same architecture produce the same outputs.”

Although MathWorks does not explicitly say “bitwise identical” in that reference, it emphasizes (under the same hardware and same MATLAB version) that mldivide provides reproducible results; i.e, the same result each time.

• MATLAB’s deterministic algorithms, including linear algebra operations via LAPACK/BLAS, will generate consistent results across repeated runs when run under the same environment.
• Floating-point arithmetic is subject to round-off error but, in absence of changes such as multithreading differences or CPU differences, you’ll get identical results bit by bit.

Floating Point Results Between Computers

https://www.mathworks.com/support/tech-notes/1100/1108.html

• This tech note covers in detail why floating-point results may differ when hardware, compiler optimizations, or operating system changes, but not for repeat runs under the exact same conditions.
• The takeaway is that if none of those external factors changes, MATLAB’s solver routines produce the same outputs for the same inputs.

Moore-Penrose Pseudoinverse (pinv)

https://www.mathworks.com/help/matlab/ref/pinv.html

• When mldivide solves rank deficient or rectangular problems, it uses LAPACK routines that effectively compute the Moore-Penrose pseudoinverse (or a variant thereof) under the hood.
• The pinv documentation states it returns a specific deterministic matrix A† so repeated calls with the same A are consistent.

Determinism

• Same Environment: If you run x = A\b; for the same matrix A and vector b, on the same hardware, with the same version of MATLAB, and the same parallelization/threading settings, the results are bit for bit identical each time.
• Potential Sources of Variation: Changes in CPU architecture, changes to number of threads or parallelization settings, or updating to a new MATLAB release (which might switch to a newer version of BLAS/LAPACK) can alter order of floating point operations and thus yield slight numerical differences.

As long as all conditions remain fixed, the backslash operator is deterministic for the same input problem—even in the overdetermined rank deficient case—and will yield the exact same solution for each call.

mprand() and mprandn() appear nowhere in the documentation nor on the Advanpix site;

Google search is empty: mprandn site:advanpix.com

Syntactically, function calls to mprandn(n) are expected equivalent to randn(n,'mp').

Sure looks like a bug to me.

Michal,

Matlab's fmincon() provides choice of algorithm: interior point, SQP, trust region.

Interior point algorithms were never designed for accuracy, providing only a few decimal digits precision on easier problems.

SQP is more accurate, disclosed in an excellent textbook by Nocedal & Wright:

https://www.convexoptimization.com/TOOLS/nocedal.pdf

Still, Matlab's SQP implementation would benefit greatly from quadruple precision because it is sensitive to quantization noise of double precision floating point; even on low-dimensional problems.

It is best not to begin with Optimization source code developed at Mathworks.

I speculate that the authors of fmincon() are not specialists in mathematical Optimization. 

It would be better to port original source code developed by mathematicians themselves: Philip Gill, Walter Murray, Michael Saunders, Margaret Wright, Gene Golub, Stephen Wright, Stephen Boyd, Lieven Vandenberghe, Nick Higham, Yinyu Ye, Jan de Leeuw, Henry Wolkowicz, Mar Hershenson, Michael Grant, Jos Sturm, David Donoho, Emmanuel Candes, Monique Laurent, Joakim Jalden, Benjamin Recht, Pablo A. Parrilo, Angelia Nedić.

I know that two of these authors certainly want to see their code translated into Matlab source.

Jon Dattorro

Is an MCT compatible version of Matlab's fmincon() nonlinear optimization available for SQP algorithm?

>>mp.Digits(1)

returns 34.

mp.Digits with argument (.) is a command, not a query.

Why the latency on a command?