I have just released new toolbox version (5.3.5.15874) with new function mp.RandState. It allows precise control of the random generator state. Its usage syntax and semantic is the same as for built-in 'rng', e.g.: 

mp.RandState(seed)
mp.RandState('default')
mp.RandState('shuffle')
mp.RandState(seed,'twister')
mp.RandState(state)

The mp.RandState returns full state of the generator, therefore it is exactly reproducible.

Simple example can be found here: https://www.advanpix.com/documentation/version-history/  

Well, here is update after few hours of trying to monitor/overload 'rng' function calls in MATLAB.

As it turns out, there is no such a way :(

 If, say, 'rng' is overloaded, then it is impossible to call the native MATLAB's function 'rng' anymore (from the overloaded). Which basically prevents us from monitoring each call to 'rng' = impossible to track each call to 'rng' to handle the case when seed is the same.

So there are two ways possible (please decide what you like better):

1. Same as now. Toolbox relies on the seed from 'rng', but resets state only iff the seed is different (see previous comment for details).

2. New, special function is introduced to reset the state of random number generator in toolbox. Say mp.ResetRandom.
Then it can be used as: 

mp.ResetRandom(seed)
mp.ResetRandom('default')
mp.ResetRandom('shuffle')

So that user needs to use mp.ResetRandom if he/she wants to reset the full-precision rand/randn(...,'mp').

Let me know what you prefer.

I think mp.ResetRandom is the way to go, if we want a full control.

Current situation. If user sets new seed with 'rng' (using rng(seed), rng('default') or rng('shuffle')) - then toolbox resets the state of its random number generator to this new seed. The 'new seed' means different seed from what was previously set.

In your example, first call rng(1) resets the state of generator. The second call rng(1) doesn't trigger reset because the seed is the same. This is the bug and needs to be fixed (working on this). 

Here is generator reset when seeds are different:

>> rng(0);
>> randn(2,1,'mp')
ans = 
        0.1868724736939647133172833335569502
        0.8829593750178176873331742398432483
 
>> rng(1);
>> randn(2,1,'mp')
ans = 
        -0.06238805020702318459649989108952415
        -0.51254018310017212737352467081772230
 
>> rng(0);
>> randn(2,1,'mp')
ans = 
        0.1868724736939647133172833335569502    
        0.8829593750178176873331742398432483    
 
>> rng(1);
>> randn(2,1,'mp')
ans = 
        -0.06238805020702318459649989108952415
        -0.51254018310017212737352467081772230

In the next version, the toolbox will work with the rng the same as built-in rand/randn (call to rng with the same seed will trigger the generator reset).

Good catch!. It is not working only if the seed is the same. Now toolbox is monitoring the case when seed is changing. This is kind of light approach - without deep intrusions to MATLAB core.

To reset the sequence for the same seed would require full-blown hook over 'rng' and actually monitoring its calls. This will make it slow(er). 

I have just released new version with this feature - 5.3.4.15817. Please update your toolbox.

Thank you very much for sharing your opinion. Yes, this is the way. This only difficulty is how to monitor when user calls "rng" to set the new seed. The easiest way would be to overload the 'rng' and make it part of toolbox. Or keep track of the 'rng' state internally in toolbox.... In any case, will include this into next toolbox version.

Agree, this is lack of documentation. The mprand(n) was an experimental name, I just left it for the time being.

Please suggest other name, unambiguous enough. Thank you.

The rand(...,'mp') generates numbers in double precision and then converts them to mp. Hence digits are not filled up to the 1034th digit. We do this in order to produce the same random numbers as built-in MATLAB's rand function (for reproducibility).

If you want random numbers to the full precision (all 1034 digits are filled), please use mprand/mprandn.

>> mp.Digits(100);
>> randn(1,'mp')
ans = 
0.8621733203681205548463140075909905135631561279296875

>> mprandn(1,'mp')
ans = 
0.1868724737876430395187949415904261118721051078748075419355524734700877850288747581541290481709356331

Thank you very much for the bug report!

Since R2023b the 'validateFinDiffRelStep' has been updated to accept 4 arguments instead of 3 (as it was before).

Indeed this incompatibility has slipped through our tests.

The toolbox has been updated with the incompatibility fixed. Please re-download & update the toolbox.

We haven't changed the toolbox version number (it is still 5.2.8.15537) but relevant files have been replaced and updated.

We still have the same beta version of fmincon (can send it by email for tests).

The fmincon is the part of the optimization toolbox, and its M-code depends heavily on the Mathworks compiled dll/so libraries (hardcoded to double precision). This makes it difficult to port to "mp" and include all the special cases and plethora of  functionality it provides.

What many of our users do - is they implement exactly the algorithm they need for particular problem.
This is what original topic starter did (we helped her along the way).