Uw opmerkingen

Just a perfect, Pavel!!! Thanks...:)
Final request: Please add a description of the mp.RandState function to the Web function reference as a basic MCT functions info source.

Thanks again ...

This is a hard question, because for a regular MCT user like me, it is not clear how difficult it is to create fully functional mp.ResetRandom function as an full-precision alternative to the "rng" function. Moreover, full-precision random generators (rand(n) + rng ... 'mp' functions) are so specific, that it is not clear how important these functions really are for other MCT users in general.


From my point of view, is the new "mp.ResetRandom" function optimal solution, I just prefer better name: like "mp.rng" (if is it possible, of course, due to the mentioned overloading problem), to be close to standard MATLAB as possible. I am working now on the full-precision random sampling, where is this topic crucial, including the 'mp' alternative of "rng" to get full control over random generation process.

Especially for me, it is important to have full control over random number generation.

Could you add some clear and simple example how "rng" works with rand(x,'mp') now? Or better, could you describe this specific behavior at function reference WWW page?

And finally, what about rng('default') and rng('shuffle'), these two options are extremely useful? 

The "rng" still not working with rand(1,'mp'):

>> mp.Digits(100)

ans =

300

>> rng(1)
rmp = rand(1,'mp')
rng(1)
rmp = rand(1,'mp')

rmp =

0.1019434353836572895054626158415646843010934355718609316510899011279499964199600542084573004435709827


rmp =

0.7686462842760086723268602992488197377426292102713405281965513370345202336516897460693092237330618525

From my point of view, the following two commands are now fully equivalent: mp(rand(1)) and rand(1,'mp') and final random number is effectively the same, and in double precision.

So I think, that rand(1,'mp') should represent random number in full precision defined by mp.Digits(100) by default, and be equivalent to your experimental function mprand(n).

But in the 'mp' (full precision) case should be possible to control random generator by rng command, too.


So, the suggested way is elimination of mprand(n) at all, and use the rand(1,'mp') at full precision
regime.

I just found that the mprand is not connected with rng, so there is no way how to control random number generator mprand(n)? How to setup user defined seed for mprand(n)?

@dattorro Thanks for answer and additional insight info. But my primary question was oriented on MCT developers. Pavel 6 years ago announced here, that "fmincon" is already implemented as part of MCT beta-version (see Pavel's answer: "fmincon is in our todo list and actually we have beta version of fmincon (not included in toolbox yet)"). So, I am just asking Pavel if this function will be available in the near future or not, because in MCT documentation is still not mentioned.

Currently, supported optimization functions:

fminsearchFind minimum of unconstrained multivariable function (Nelder-Mead)
fzeroFind root of continuous function of one variable
fsolveSolve system of nonlinear equations
lsqnonnegSolve nonnegative linear least-squares problem
optimsetCreate or edit optimization options structure
optimgetOptimization options values

6 years ago you mentioned possible implementation of "fmincon". What is the actual state of the art of optimization methods supported by MCT.

OK, this solution works for now well... !!!

OK, my final observations are as follows:

1. Without MTC 4.8.6 Build 14636 at the PATH commands eps('like',y) and eps("like",y) works both identically and well on R2022a
2. With MTC 4.8.6 Build 14636 at the PATH works only eps("like",y), the eps('like', y) produce above mentioned error on R2022a

3. R2021b used eps(class(y)) instead of R2022a, which is using esp('like',y) at nthroot.m


R2021b ... function eps does not support two arguments call 
R2022a ... function eps support two arguments call (!!!), but presence of MTC at PATH introduce some problem with single quote argument used at ntroot.m  

From my point of view, the current problem with R2022a is introduced by MTC