Excellent. Maybe we can put this "dual math" thing to bed? Daniel Fridlender wrote: > Dear all, > > On behalf of ITC, I have submitted as H-935 a new implementation of > java.math combining previously donated implementations. It includes > what we think are the best features of H-380 (donated by Intel) and > the best features of H-199 (donated by ITC). We have also fixed some > bugs from both implementations and done some further optimizations on > methods from both of them. > > We have also included a few optimizations from H-551, we expect to > include the remaining optimizations soon. We have also improved the > performance test suite from H-551 and included further tests, among > them realistic applications from cryptography. Check the README file > included in the package mathPerformanceTestsUpdate.zip (H-935) for > some more details about the new features of the test suite. > > A sample of the output obtained with the performance test suite can be > found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html > > A comparative analysis on a method-by-method basis between H-380 and > H-199 can be found at > http://www.fitc.unc.edu.ar/javadev/math/docs.html > > We will include further documentation soon. In the meantime, a brief > description of the main issues follows: > > Internal representation of BigInteger: taken from H-380 > (Sign-magnitude representation). > Design: taken from H-199 (well-defined static libraries grouped by > functionality). > Serialization: taken from H-380 (it was not implemented in H-199). > > Most methods and constructors were taken from one of the previous > donations and then tuned for consistency with the internal > representation, for bug removal and for further optimizations. Very > often large parts were reprogrammed (e.g.: shiftRight, bitLength, > bitCount, not, setTrueCoded, modInverse, and many more). > > Nevertheless we can roughly say that the new version started by taking: > > 1) Methods of BigDecimal: most of them from H-199 because of efficiency. > 2) Representation-dependent methods of BigInteger: most of them from H-380. > 3) Representation-independent methods of BigInteger: most of them from > H-199 for efficiency. > 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, > BigDecimal.valueOf, etc. We also took their performance test suite, > improve it and added further benchmarks. > > We plan to introduce remaining optimizations from H-551 and to > optimize other methods (modPow, modInverse, nextProbablePrime, etc.) > in order to bridge the gap in efficiency with the RI. > > Best regards, > > Daniel Fridlender > ITC > > http://issues.apache.org/jira/browse/HARMONY-935 > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]