I have demonstrated through experiments that at least on MacOS and Linux, if you allocate an array using zeros(), that it does not ask the operating system for all of that memory at that time. However as soon as you store even one thing into the array, it then needs to ask the operating system for all of the memory, and as a result you can get an "out of memory" error. For example,
With this online facility, 2.72e9 would give out of memory at the zeros; I have shown in the past that sometimes it would be the assignment into A(1) that would trigger the out of memory.
I did not test on MS Windows.
However, this is specifically an "out of memory" error that is generated, not an "array is too large" error.
The MATLAB model is that any array that is created and is not sparse, has all of its memory allocated at the time of creation. But that turns out not to be the case when zeros() specifically is used, as long as the array stays just 0.
If
is generating an array too big error, that most often implies that Δ is a vector or array and that the inner-product operator * needs size(S,1) * size(Delta,2) memory locations for the result. So if you accidentally * a column vector and a row vector, you can be asking for a much larger result than you expect. If
is generating an array too big error, that most often implies that implicit expansion is being done. If you accidentally .* a column vector and a row vector, you could be asking for a much larger result than you expect. So... recheck whether you are using the * (inner product) or .* (element-by-element) operator, and recheck size() of the arrays to see whether implicit expansion might be happening.