Open dilabbiog opened 2 years ago
May also be a memory issue. For example, the following works: load('badtrain.mat'); tic; trn1 = train(b); toc; clear all; load('badtrain.mat'); tic; trn2 = train(b); toc;
I checked that this bug is also present on Linux with CLang and GCC compilers. Interesting! I wonder what persists between calls. I would have thought that even any global variables used by trains
would be reset. Not totally clear if this is a trains
or a Matlab issue.
I pushed a proposed fix to the develop
branch. It's because of the crazy, surprising fact that Matlab remembers globals in a C++ file. Hence, the braid you were trying was decreasing tolerance, then the next function call started with a tolerance that was too low. Or something. But basically you're dealing with braids that are close to causing trains
to hang.
On the Windows compilation, two (or more) consecutive applications of the train() subroutine can hang. For example, in the provided dataset, there is a databraid "b". When executing the script below, the first line completes rather quickly, but the second hangs. The behaviour is strange given that we are doing the exact same thing twice in this case. tic; trn1 = train(b); toc; tic; trn2 = train(b); toc;
The problem was initially observed in a script, where the train() subroutine was being used on a randomly generated databraid in each iteration of a for loop. I wonder if it is a problem with the supplied braid or if it is specific to the Windows compilation. Does the problem exist on Linux as well?
Part of this issue is that when MATLAB is executing a MEX subroutine (like train), we cannot use ctrl+c to stop it. So we have to force quit MATLAB (at least on Windows). Some kind of interrupt could be useful here (e.g., https://undocumentedmatlab.com/articles/mex-ctrl-c-interrupt).
badtrain.zip