rng('default') unreliable

Question

broken_arrow 2022-6-13

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/1739580-rng-default-unreliable

评论： broken_arrow 2022-6-17

I have some lengthy code (too long to post here) which executes some sampling based computations. At the beginning of the code, I set

rng('default')

to ensure reproducibility of results for debugging purposes (afaik, this means a Mersenne twister with seed 0). This is the only place in the code where rng is invoked. During program execution, some quantities are sampled using normrnd, which are subsequently used as inputs for the computations. The thing is, I've noticed on multiple occasions now that running the exact same code several times does NOT always yield the exact same results.

I always have one instance of Matlab running in GUI mode. Alternatively, I can also run the code in batch mode in the background, which I do most of the time. Although I change absolutely nothing in the code, the sample values occasionally (not always) differ from run to run. I can't figure out what's going on, but since my input does not change, it must have something to do with the rng. Has someone experienced the same problem? Could it be some kind of crossfire between GUI and batch mode? Or does rng('default') involve time or some other "random" variable?

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Jan 2022-6-13

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/1739580-rng-default-unreliable#answer_984850

编辑：Jan 2022-6-13

在 MATLAB Online 中打开

rng('default') sets the random number generator to the initial state. This is a reliable procedure.

If your code replies different results for the random numbers, it must contain another source of randomness. If this effect occurs only sometimes, it does not seem to be a problem related to the value of the current time. This would be something like:

% Not likely to be the problem:
itime = now;
while now - itime < 5
    a = rand; 
end

Such dependencies on the time should be observable in all runs.

Another problem can be using different inputs relying ob the path "D:" : This is the last folder used on the disk D and can be influenced by external software. Brrr, such evil.

I assume, you have to check the code and search for the source of the problem. While the RNG is known not to create magical output, you either process different inputs (without knowing it) or there is another source of entropy.

8 个评论
显示 6更早的评论隐藏 6更早的评论

Jan 2022-6-14

[MOVED from sectio for answers:] broken_arrow wrote:

Hi Jan,

thanks for your answer. I'd really like to figure this one out. Here are my thoughts:

Looking at a multitude of results, it seems time can be ruled out as a factor (as you said, rng('default') should not involve time)
I do invoke some inputs from path "F:\some_folder\..." (which I dead certain never changed during my tests). My code is also stored there. "F:" is my last local drive (I also have a "D:" drive). Could that be part of the problem (i. e. have an influence on rng)?
Could it be that running a job in batch mode makes a difference (different rng behaviour)?
What other sources of entropy could there possibly be? Resetting rng and then drawing the same random numbers over and over should leave no room for entropy (at least not user induced). Or are there commands other than rng which introduce a random component?

I am certain the problem is not input related because I do nothing else than running a job, looking at the results, then running the exact same job again and looking at the results again. I could just accept it as randomness (the sample values always lie in the specified range), but unexpected behaviour is a red light for me, so I'd really like to know the cause.

Jan 2022-6-14

@broken_arrow: Distinguish "D-Drive", "D:" and "D:\". The first is a drive letter, the last ist the path to the root folder on the disk D and "D:" is the last used folder on drive D, which is very volatile and therefore it should be avoided strictly. If you code contains a line like: cd('F:') you cannot be sure, where you get, while cd('F:\') is stable.

Relying on the current folder is a bad programming pattern, because a callback of a timer or GUI can change the current folder. So use absolute paths for all files in general.

But it is unlikely that your code creates a wrong output if the current folder is changed unexpectedly. A crash is more likely.

The most frequent cause of entropy is using orphaned pointers or uninitialized variables in C-Mex functions. Do you call C-mex functions?

In Matlab R2009a, the sum() command was implemented using multithreading above the limit of 88999 elements. Then the partial results were added in the temporal order. This could cause different results between repeated calls, see https://www.mathworks.com/support/bugreports/532399 . Maybe you are using another function, which has an equivalent bug.

It would be useful to narrow down the code, which causes the difference.

Steven Lord 2022-6-15

Or you could sort the output of fieldnames before deciding which field gets which random vector if you don't need or want to reorder the struct array itself.

broken_arrow 2022-6-17

That is one possibilitiy. It still seems strange that dynamic properties apparently are not created in the specified order (even in GUI mode) and in batch mode the order even appears to be random (c. f. below). Maybe that should be changed (just my opinion).

请先登录，再进行评论。

Answer 2

broken_arrow 2022-6-15

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/1739580-rng-default-unreliable#answer_986230

编辑：broken_arrow 2022-6-15

在 MATLAB Online 中打开

Ok, it seems we have to go one step further. I think it's actually a problem with dynamicprops objects. Let me give a code example. Take this function file:

function fieldnametest
myobj = dynpropobj;
myobj.afield = "these";
myobj.bfield = "are";
myobj.cfield = "exemplary";
myobj.dfield = "attributes";
myfields = fieldnames(myobj);
disp(myfields)
end

with an additional classdef file:

classdef dynpropobj < dynamicprops
    
    methods
        function obj = dynpropobj % constructor
            obj.addprop('afield');
            obj.addprop('bfield');
            obj.addprop('cfield');
            obj.addprop('dfield');
        end
    end
end

If i run fieldnametest in GUI mode, the fields are (as observed so far) always created in the same sequence. But if I create a batch file

cmd /k ^

matlab -batch -wait ""cd('F:\testfolder')"; "fieldnametest""

(where cmd /k ^ is to keep cmd open after execution and 'F:\testfolder' is the directory where the aforementioned files are located) and run it, the field name order seems to get shuffled randomly (at least that is what I observe on my computer).

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

rng('default') unreliable

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

回答（2 个）

8 个评论
显示 6更早的评论隐藏 6更早的评论

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

另请参阅

类别

标签

产品

版本

Community Treasure Hunt

rng('default') unreliable

0 个评论 显示 -2更早的评论隐藏 -2更早的评论

回答（2 个）

8 个评论 显示 6更早的评论隐藏 6更早的评论

0 个评论 显示 -2更早的评论隐藏 -2更早的评论

另请参阅

类别

标签

产品

版本

Community Treasure Hunt

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

8 个评论
显示 6更早的评论隐藏 6更早的评论

0 个评论
显示 -2更早的评论隐藏 -2更早的评论