My UArr code looks like it's reading uninitialized memory?

[pumpkingod@…]

I'm parsing in a reasonably large data file (I've included a smaller one that still exhibits the problem) in CSV format, replacing all NaNs? with 0, and then proceeding to calculate a sliding window mean over the columns of the data. The data has no NaNs? in it, so there's no reason for any of the means to be NaN/e308, and definitely no reason to see changes between runs of the program (unless I'm doing something very wrong!).

I compile with ghc -O2 --make -o minimal minimal.hs and run with ./minimal. The data files used are in data, and the program relies on current path so run it from the parent folder of data.

See the two_runs file for an example of what I get from two successive runs of the program, with nothing else in between. The data files don't ever change.

I'm compiling on GHC 6.10.1 (the 32-bit package from haskell.org) on Mac OS 10.5.

My code and data are at http://pumpkinpat.ch/uvector_bug.tbz .

[pumpkingod@…]

I tracked this down to issues in my understanding of zipU and friends, where zipU happily reads past the end of the second array if the first is longer. lengthU on the resulting array will catch this is the safe flag is on. It seems like reasonable behavior, it just needs to be outlined in the documentation (which I'm doing).