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.
On Tue, Dec 15, 2009 at 9:51 AM, Sean Owen <[email protected]> wrote: > NaN is my vote too from a correctness standpoint. Really, > Arrays.fill() is unnaturally slow to fill in NaN? this sounds odd. Is > it significant? > > On Tue, Dec 15, 2009 at 1:26 PM, Benson Margulies <[email protected]> > wrote: >> My first reaction was to be opposed to checking in generated output, >> but now I can't really think of a strong objection. A separate maven >> profile to enable the generator, and off we go. >> >> As to float and double, they may need to be special cases. Ask >> yourself: "What should get(k) return when containsKey(k) is false and >> the payload is double?" >> >> Answer 1: NaN. >> Answer 2: zero, like with the int types. >> >> Answer 1 feels more correct, but I've discovered that the JVM is very >> slow in filling an array with NaN values, whereas, of course, new >> delivers a supply of fresh, clean, zeros in a jiffy. >> >> >> On Tue, Dec 15, 2009 at 7:12 AM, Grant Ingersoll <[email protected]> wrote: >>> >>> On Dec 14, 2009, at 11:38 PM, Sean Owen wrote: >>> >>>> I think both are desirable. Check in the generator and also the >>>> generated code. It just keeps it simple. >>> >>> +1. This is what Lucene does w/ the QueryParser (JavaCC) and the Ant >>> script detects when the two are out of sync and then regenerates. >>> >>>> >>>> On Tue, Dec 15, 2009 at 1:43 AM, Benson Margulies <[email protected]> >>>> wrote: >>>>> The idea here is that the templates are checked in. The build process >>>>> goes template-to-java and then compiles the java. In other words, the >>>>> java classes are not checked in and editable. >>>>> >>>>> If this is not acceptable, I'll just manually create all the classes. >>>>> It's just easier to keep them in sync if there's one source instead of >>>>> 16 to edit. (The presumption here is that all of 16 classes >>>>> {Byte,Char,Int,Long}x{Byte,Int,Char,Long} are really identical except >>>>> for the data types). >>> >>> >>> >> >
