My focus is at the moment on the colt-derived code. I'll report in when I get that far.
On Tue, Dec 15, 2009 at 10:10 AM, Sean Owen <[email protected]> wrote: > 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. >
