There is nothing you can do to repair an "out of memory" situation if your program needs to allocate more memory than you have on your system.
It sounds as if you are not expecting that your program uses that much memory. You need to figure out which line of code is triggering the error, and you need to examine the sizes of the expressions and work out the size of the output that the operators would produce.
Common mistakes include:
- The * operator is algebraic matrix multiplication. For multiplying an n x m matrix by an m x p matrix, it produces an n x p matrix. In particular if you accidentally use * to multiply a column vector by a row vector then the result is going to be length(column) by length(row)
- The / operator is matrix divison, A/B being similar to A*pinv(B) . This produces an output with as many columns as there were rows in the denominator. That might not trigger an immediate error, but it gives you a row vector where you probably expected a column vector, and if you happened to * that... see first point about sizes for * operator.
- If you pass a vector to rand() or zeros() or ones() then the produce arrays with as many dimensions as the length of the array. For example, people sometimes do zeros(1:50) expecting to produce a vector of length 50 that is initialized to 0, but this instead creates a 50 dimensional array that is 1 x 2 x 3 x 4 x 5 x 6 .... x 50 . Which you totally do not have enough memory for.
- Since R2016b, most of the binary operations act as if there was a bxsfun() coded. If you happen to have coded a row vector in a binary operation with a column vector then you get a result which is length() of the row by length() of the column instead of an error like you would have gotten previously. For example, (10:10:90).' + (0:8) now gives a 9 x 9 array instead of an error. It is not uncommon for people to forget which vectors are which row vectors and which are column vectors and try to do a binary operation on them thinking they are going to get element-by-element arithmetic in a vector.
