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

Reply via email to