Le 03/11/2013 14:43, Gilles a écrit : > On Sun, 3 Nov 2013 10:30:40 +0000, Sean Owen wrote: >> On Sun, Nov 3, 2013 at 4:17 AM, Ted Dunning <ted.dunn...@gmail.com> >> wrote: >>> Does this actually matter after the JIT takes hold? And if the JIT >>> doesn't >>> care to optimize this away, does it even matter? >> >> Unclear. There aren't hard guarantees about what the JIT does, but >> transformations like this should be easy and local. Doesn't optimize >> != doesn't matter though. The 2D load/store is harder to match, and >> there's one place it matters a bit in EigenDecomposition. I always >> figure it helps to write an increment/decrement as what it is -- all >> the better that it can't hurt speed. >> >> These are all fairly trivial. The motivation was more from consistency >> in most cases, with an occasional small runtime benefit. I was more >> wondering if, it were just a matter of pressing a button, it would be >> desirable to zap a lot like this. I think the right approach is indeed >> to propose a couple targeted changes and move on. > > Standardization is the key concept. A worthy goal even it brings zero > performance improvement. > >> >> Others that might be of interest, as food for thought: >> - Standardizing literals? like saying "0.3" instead of ".3" or ".3d", > > If the number is like 0.3, it probably has to be declared as a > "private static final" field with a telling name. > > A case that occurs often is "zero" (as "double"). > I prefer "0d".
I really don't like the d suffix. It reminds me nightmares about Fortran. 0.0 is reasonably readable by everyone even without knowing Java syntax, so go for it. > >> and writing "2L" not "2l" since the latter looks like "21" > > Same here. > For zero as long, I'm for "0L". Sure. best regards, Luc > >> - Using log1p() for computing log(1+p) with a tiny bit more accuracy >> in a few places > > Certainly. > > > Best, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
