Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double)
jeffhain at rocketmail.com
Fri Jan 22 11:13:32 PST 2010
Dmitry, here is the link:
The non-wrong treatments could be mainly:
- round(double), floor(float), ceil(float), round(float),
- maybe hypot(double,double) (Math.hypot delegates to StrictMath.hypot,
which is very slow on my computer due to its use of StrictMath.sqrt
I think (same slowness reason than for Math.asin and Math.acos I think)),
- maybe also remainder(double,double) (but it's not the IEEE algorithm).
For Joe (or whoever wants to read it):
If benches get harder and harder as JVM's get smarter and smarter,
maybe some tools could be developped to help developpers with that,
instead of just having them warned about benches.
I know there is JConsole etc., but I think about something that could
work for libraries, and rate them for different contexts of use.
After all, developping is developping implemented algorithms, and
algorithms are rated according to their correctness (for which we have
JUnit), and their performance (for which we have (?)).
Or maybe that's just not possible, or would be way too complicated...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev