Topic: FloatArray incorrect documentation; Memory initialization or not

The resize() function in floatarray currently works as sort of "resizeWithValues". It will keep the old stuff, and set zero values on the new portion. This code is a bit convoluted, since we also allow for "allocChunk" (which is actually ignroed if the old size is enough for the new size (excluding extra allocation).

Now, the documentation says the memory has to be zeroed first, which isn't true (well, if you increase the size, the old values are preserved). Most of the times, code in OOFEM doesn't (and often it can't) rely on the fact that the vector is zeroed, so it calls zero() again.
Nearly no code wants to actually keep the old vector values after a resize.

Short version: I want to make FloatArray::resize() not zero values, and not copy old values.

Alternative option, always zero memory when resizing, and not copy the old values (possible introduce "resizeWithValues()" is this is really needed.
I would have the DEBUG code will initialize everything to NaN so it's easy to spot whenever you forgot to zero() the vector.

Re: FloatArray incorrect documentation; Memory initialization or not

I have now correct a bit of code that didn't properly zero the values after a resize. I also introduced resizeWithValues() which is just used rarely.
Currently, resize() simply calls resizeWithValues(), but i think it should either:

1. Always zero data when calling resize() (even when no new memory is allocated).
2. Do not initialize memory at all.

Pretty much all code will zero the vector after a resize, so it'll simplify things code overall if we just do it with resize automatically. We definitely don't need to copy over the old values (we keep that function separate), since that's almost never needed.

Occasionally, zero'ing the matrix isn't necessary, so option 1 could have a slight performance drawback. (one should also consider that resize is called internally, by functions like beProductOf, which will overwrite all memory anyway, so zero'ing wouldn't be necessary).

I've fixed so that all the tests currently work without keeping old values and without zero'ing the new part of the array.

Re: FloatArray incorrect documentation; Memory initialization or not

I've been optimizing some of the FloatMatrix functions with BLAS and it is turning out nicely. For higher order elements I would highly recommend that one compiles with LAPACK-support (which brings in blas functions as well). OpenBLAS is an excellent choice, and in my tests, it has been up to twice as fast compared to the default FloatMatrix implementation.

I also wanted to wrap this issue up and decide on something already.
I propose we go for alternative 1, i.e. always zero the memory after a resize. None of the old data is preserved, no uninitialized memory, no need to call zero().
resizeWithValues exists in those cases where you really need to extend the vector.
A lot of x->zero() calls would then unnecessary.

Re: FloatArray incorrect documentation; Memory initialization or not

What about keeping resize as it is and introduce resizeAndZero?

Re: FloatArray incorrect documentation; Memory initialization or not

resize used to be basically "resizeWithValues" which almost none of the code actually wants.
Almost all code wants to zero the vector/matrix so I would like to have resize do that.

If anything, one can add a resizeUninitialized() for the relatively few cases where you don't need it zeroed, but I think the uses for that is quite small.

Re: FloatArray incorrect documentation; Memory initialization or not

Here is my plan:
resizeWithValues  <-- Keeps the old values, zeros new content
resize <-- Zeros all memory

and it should be the same behavior for IntArray, FloatArray, FloatMatrix.

(although, IntArray::resizeWithValues would be nearly pointless, since IntArray::followedBy(..) pretty much takes care of that).