There are other solutions that aren't too expensive like maintaining a bit set of entries that are valid (which is fast since it initializes to all false/0). I've got a fast implementation in the code already. I'd prefer to not let the performance consideration convince us to not implement the semantics that seem correct -- if we agree that NaN is 'correct'.
On Tue, Dec 15, 2009 at 2:57 PM, Benson Margulies <[email protected]> wrote: > I had better be more clear. The problem is that Arrays.fill does use > some time. If you just say new double[1000], you've got 0. To get NaN, > you then need a fill. Last summer, when I was trying to get an E+M > procedure to run in reasonable time, and trying to initialize many > arrays with NaNs to detect various errors, I measured and found that > I was getting killed. Now, does that mean that at construction and > resize of these hash tables that we can't afford the fill? I won't > make that claim without a measurement.
