Excellent. Maybe we can put this "dual math" thing to bed?
Daniel Fridlender wrote:
> Dear all,
>
> On behalf of ITC, I have submitted as H935 a new implementation of
> java.math combining previously donated implementations. It includes
> what we think are the best features of H380 (donated by Intel) and
> the best features of H199 (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 H551, we expect to
> include the remaining optimizations soon. We have also improved the
> performance test suite from H551 and included further tests, among
> them realistic applications from cryptography. Check the README file
> included in the package mathPerformanceTestsUpdate.zip (H935) 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 methodbymethod basis between H380 and
> H199 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 H380
> (Signmagnitude representation).
> Design: taken from H199 (welldefined static libraries grouped by
> functionality).
> Serialization: taken from H380 (it was not implemented in H199).
>
> 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 H199 because of efficiency.
> 2) Representationdependent methods of BigInteger: most of them from H380.
> 3) Representationindependent methods of BigInteger: most of them from
> H199 for efficiency.
> 4) From H551: 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 H551 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/HARMONY935
>
> 
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, email: harmonydevunsubscribe@incubator.apache.org
> For additional commands, email: harmonydevhelp@incubator.apache.org
>
>
>

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, email: harmonydevunsubscribe@incubator.apache.org
For additional commands, email: harmonydevhelp@incubator.apache.org
