Re: [classlib][java.math] optimization of BigInteger.modInverse
It should be fixed now. Thanks Daniel On 11/8/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel I've tried the patch you suggested. It causes failure of org.apache.harmony.tests.java.math.BigDecimalArithmeticTest Could you please take a look? Thanks, Mikhail 2006/11/8, Daniel Fridlender [EMAIL PROTECTED]: Hi, In http://issues.apache.org/jira/browse/HARMONY-2091 there is an optimization for modInverse. The issue includes a patch and two html files showing the performance of the method before and after the patch. In order to obtain this optimized version algorithms from the articles The Montgomery Modular Inverse - Revisited (by Savas, E; Koc, C) and New Algorithm for Classical Modular Inverse (by Lórencz, R) were implemented. Also some ad-hoc combination of arithmetic operations were introduced in order to avoid unnecessary creation of intermediate data. Thanks, Daniel
[classlib][java.math] optimization of BigInteger.modInverse
Hi, In http://issues.apache.org/jira/browse/HARMONY-2091 there is an optimization for modInverse. The issue includes a patch and two html files showing the performance of the method before and after the patch. In order to obtain this optimized version algorithms from the articles The Montgomery Modular Inverse - Revisited (by Savas, E; Koc, C) and New Algorithm for Classical Modular Inverse (by Lórencz, R) were implemented. Also some ad-hoc combination of arithmetic operations were introduced in order to avoid unnecessary creation of intermediate data. Thanks, Daniel
Re: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow
Hi Alexey, yes we often tested the speed in our several attempts to improve performance. Comparing modPow before and after this new patch gave us the following figures: size before after 16 5.636e+05 6.351e+05 32 9.727e+04 1.293e+05 48 3.225e+04 4.623e+04 64 1.436e+04 2.148e+04 128 19413114 192590 970 256252 420 384 75127 512 32 55 where the first column shows the size of the arguments in bytes and the other two the number of modPow operations per 100 seconds before and after the patch. The method modPow is used in cryptography, we tested several cryptographic algorithms obtaining in all cases figures in favor of the optimized version (the one in the patch). For instance, for RSA key generation we obtained: size before after 5123,00 2,06 102420,1713,58 2048 280,38 149,48 where the first column shows the length of the key in bits and the other two the time in seconds taken to perform 30 iterations of the key generation algorithm before and after the patch. Thanks, Daniel On 11/3/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Hi, Daniel. Great job! Have you made any performance testing to understand how much the patch increases the speed of the methods? SY, Alexey 2006/11/3, Daniel Fridlender [EMAIL PROTECTED]: Hi, We have submitted in http://issues.apache.org/jira/browse/HARMONY-1981 an optimization of BigInteger methods modPow and pow. The optimization in modPow was achieved by introducing sliding windows instead of the square-and-multiply method. Some gain was obtained also from an optimized Montgomery multiplication used for computing squares. The method pow was optimized accordingly by improving the computation of squares. Thanks Daniel
[classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow
Hi, We have submitted in http://issues.apache.org/jira/browse/HARMONY-1981 an optimization of BigInteger methods modPow and pow. The optimization in modPow was achieved by introducing sliding windows instead of the square-and-multiply method. Some gain was obtained also from an optimized Montgomery multiplication used for computing squares. The method pow was optimized accordingly by improving the computation of squares. Thanks Daniel
Re: [classlib][math]BigInteger bitwise operations
Hi Tatyana, thank you for reporting this bug. We have submitted a patch now to fix it. Thanks, Daniel On 10/29/06, tatyana doubtsova [EMAIL PROTECTED] wrote: Hello, I've filed http://issues.apache.org/jira/browse/HARMONY-1996 regarding bitwise operations on negative values. Could anybody, please, have a look at it. Thanks, Tanya
Re: [classlib][math] one more non-bug diff ? ([jira] (HARMONY-1499) BigDecimal((BigInteger)null, MathContext) throws NPE on Harmony and ArithmeticException on RI
On 9/20/06, Tony Wu [EMAIL PROTECTED] wrote:
RI disobeys spec because all constructors of BigDecimal do not throw any NPE
when encounter a null parameter.
I incline to follow spec and mark this issue as an non-bug difference.
I agree.
We should keep the current behavior of Harmony implementation since it
obeys the spec.
Daniel
On 9/20/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
As pointed in the HARMONY-1499 constructors BigDecimal((BigInteger)null,
new
MathContext(precision=14 roundingMode=UNNECESSARY)) and
BigDecimal(BigInteger unscaledVal, int scale, MathContext mc) throws NPE
on
Harmony and ArithmeticException on RI.
The spec requires NPE and BEA throws NPE in this case also as Harmony. I
suggest following the spec in this case.
Any objection?
thanks, Vladimir
-- Forwarded message --
From: Vladimir Ivanov (JIRA) [EMAIL PROTECTED]
Date: Sep 20, 2006 2:05 PM
Subject: [jira] Created: (HARMONY-1499) [classlib][math]
BigDecimal((BigInteger)null, MathContext) throws NPE on Harmony and
ArithmeticException on RI
To: [EMAIL PROTECTED]
[classlib][math] BigDecimal((BigInteger)null, MathContext) throws NPE on
Harmony and ArithmeticException on RI
--
Key: HARMONY-1499
URL: http://issues.apache.org/jira/browse/HARMONY-1499
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
Priority: Minor
The constructors BigDecimal((BigInteger)null, new
MathContext(precision=14
roundingMode=UNNECESSARY)) and
BigDecimal(BigInteger unscaledVal, int scale, MathContext mc) throws NPE
on
Harmony and ArithmeticException on RI.
The spec says for BigDecimal class: All methods and constructors for this
class throw NullPointerException when passed a null object reference for
any
input parameter and for the thes constructors: Throws:
ArithmeticException
- if the result is inexact but the rounding mode is UNNECESSARY.
Seems, that the RI does not check input for 'null' values. While BEA
throws
NPE in this case and RI behavior contradicts to the spec it may be
'non-bug
diff'.
== test.java =
import java.math.*;
public class test {
public static void main(String[] args) {
try {
System.out.println(res = + new BigDecimal((BigInteger)null,
new MathContext(precision=14 roundingMode=DOWN)));
} catch (Exception e) {
e.printStackTrace();
}
try {
System.out.println(res = + new BigDecimal((BigInteger)null,
new MathContext(precision=14 roundingMode=UNNECESSARY)));
} catch (Exception e) {
e.printStackTrace();
}
try {
System.out.println(res = + new BigDecimal((BigInteger)null,
1, new MathContext(precision=14 roundingMode=UNNECESSARY)));
} catch (Exception e) {
e.printStackTrace();
}
}
}
==
Output:
---
C:\tmp\tmp17C:\jdk1.5.0_08\bin\java.exe -cp . -showversion test
java version 1.5.0_08
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode)
res = -9.2233720368547E+18
java.lang.ArithmeticException: Rounding necessary
at java.math.BigDecimal.divide(BigDecimal.java:1346)
at java.math.BigDecimal.dropDigits(BigDecimal.java:3463)
at java.math.BigDecimal.doRound(BigDecimal.java:3433)
at java.math.BigDecimal.roundThis(BigDecimal.java:3399)
at java.math.BigDecimal.init(BigDecimal.java:811)
at test.main(test.java:11)
java.lang.ArithmeticException: Rounding necessary
at java.math.BigDecimal.divide(BigDecimal.java:1346)
at java.math.BigDecimal.dropDigits(BigDecimal.java:3463)
at java.math.BigDecimal.doRound(BigDecimal.java:3433)
at java.math.BigDecimal.roundThis(BigDecimal.java:3399)
at java.math.BigDecimal.init(BigDecimal.java:851)
at test.main(test.java:16)
---
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp .
-showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75,
GC: System optimized over throughput (initial strategy singleparpar))
java.lang.NullPointerException
at java.math.BigDecimal.doRound(BigDecimal.java:3066)
at java.math.BigDecimal.roundThis(BigDecimal.java:3042)
at java.math.BigDecimal.init(BigDecimal.java:751)
at test.main(test.java:6)
java.lang.NullPointerException
at java.math.BigDecimal.doRound(BigDecimal.java:3066)
at java.math.BigDecimal.roundThis(BigDecimal.java:3042)
at
Re: [jira] Assigned: (HARMONY-1208) Bug fixing and cosmetics for Harmony 935
Hi Mikhail, On 8/25/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel 2006/8/25, Daniel Fridlender [EMAIL PROTECTED]: On 8/23/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, I've tried the patch. 4 math tests failed. Could you please take a look? Thanks, Mikhail Hi Mikhail, You are right. Two of these four tests are due to typos in the exception messages: 1)org.apache.harmony.tests.java.math.BigDecimalConstructorsTest.testConstrStringExponentIntegerMin( BigDecimalConstructorsTest.java:497) expectedScale out of range. but was Scale out of range 2)org.apache.harmony.tests.java.math.BigDecimalScaleOperationsTest.testMovePointRightException( BigDecimalScaleOperationsTest.java:335) expectedUnderflow but was UnderFlow We corrected them (and a similar problem with Overflow) with a new patch typos.diff.zip´ in H1208. The other two failing tests require some discussion. 3)org.apache.harmony.tests.java.math.BigDecimalConstructorsTest.testConstrBI(BigDecimalConstructorsTest.java:75) I believe the test is wrong in this case since according to the API specification the NullPointerException will actually be thrown before the try block. The test incorrectly expects it to be thrown in the block. The RI also fails this test. I've just rerun it on RI and it passed. What RI version do you use? I got the argument about the spec. It in a class description, right? Right. The description of the class BigDecimal contains the statement All methods and constructors for this class throw NullPointerException when passed a null object reference for any input parameter. Thus, there is a bug in the 1.5.0 version of the RI when invoking the constructor BigDecimal(BigInteger val) with a null argument since it does not throw NPE. This bug is fixed in version 1.5.0_08 (and also in 1.6). I have just seen in H784 that Vladimir Ivanov discovered this for version 1.5.0_06. 4)org.apache.harmony.tests.java.math.BigDecimalArithmeticTest.testDivideByZero(BigDecimalArithmeticTest.java:492) expected BigInteger divide by zero but was Division by zero This is not just a typo. Both exception messages are used by the RI in different BigDecimal.divide methods when dividing by BigDecimal.ZERO. There is at least a third message: / by zero. Some methods seem to use different messages depending on the size of the dividend. So, I see two possibilities here: a) use everywhere the message Division by zero. b) try to find out when RI uses each of the different messages. I would suggest a) rather than b) since from the point of view of the programmer it is reasonable to obtain the same message when dividing by BigDecimal.ZERO regardless the size (or internal representation) of the dividend and the method invoked for the division. In general if a programmer use only one method in their implementation where RI throws BigInteger divide by zero, then they are not aware of other exception messages and they might hard code that BigInteger divide by zero one. It is a bit more complicated than that. From the tests we have run we can naturally guess that there are two groups of BigDecimal.divide methods in RI: i) those which check if the divisor is BigDecimal.ZERO in which case they throw the exception with the message Division by zero. ii) those which do not check (forget to check?) and attempt to divide anyhow: they will use the BigInteger divide by zero or / by zero depending on where the problem happens. That is, depending on whether the dividend is large (and the division takes place in BigInteger) or small (and the division takes place in a primitive type). So I'd prefer to keep it look like RI as it is now. BUT, if this change implies an undesirable design change then I'm OK with discrepancy in exception messages Keeping it look like RI for methods of group ii) would imply trying to determine the exact border between messages BigInteger divide by zero and / by zero. Thanks Daniel Thanks, Mikhail In addition, doing b) may imply inspecting the behavior of RI a bit too far. I am reluctant to do this since different messages may reveal when the unscaled value is implemented as a BigInteger and when as a primitive integral value. We submitted a new patch tests.diff.zip to H1208 correcting the test mentioned in 3) and replacing the test in 4) by another invocation to divide with the Division by zero message. Both RI and our implementation pass the tests. I think both patches should be applied. In the meantime we may discuss if the approach b) is preferred. Regards, Daniel 2006/8/22, Daniel Fridlender [EMAIL PROTECTED]: Hi Mikhail, On 8/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, Please resubmit the patch with license granted to ASF done. Seems like the patch was generated against original H-935 contribution and does not take into account later changes. Could
Re: [jira] Assigned: (HARMONY-1208) Bug fixing and cosmetics for Harmony 935
On 8/23/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, I've tried the patch. 4 math tests failed. Could you please take a look? Thanks, Mikhail Hi Mikhail, You are right. Two of these four tests are due to typos in the exception messages: 1)org.apache.harmony.tests.java.math.BigDecimalConstructorsTest.testConstrStringExponentIntegerMin( BigDecimalConstructorsTest.java:497) expectedScale out of range. but was Scale out of range 2)org.apache.harmony.tests.java.math.BigDecimalScaleOperationsTest.testMovePointRightException( BigDecimalScaleOperationsTest.java:335) expectedUnderflow but was UnderFlow We corrected them (and a similar problem with Overflow) with a new patch typos.diff.zip´ in H1208. The other two failing tests require some discussion. 3)org.apache.harmony.tests.java.math.BigDecimalConstructorsTest.testConstrBI(BigDecimalConstructorsTest.java:75) I believe the test is wrong in this case since according to the API specification the NullPointerException will actually be thrown before the try block. The test incorrectly expects it to be thrown in the block. The RI also fails this test. 4)org.apache.harmony.tests.java.math.BigDecimalArithmeticTest.testDivideByZero(BigDecimalArithmeticTest.java:492) expected BigInteger divide by zero but was Division by zero This is not just a typo. Both exception messages are used by the RI in different BigDecimal.divide methods when dividing by BigDecimal.ZERO. There is at least a third message: / by zero. Some methods seem to use different messages depending on the size of the dividend. So, I see two possibilities here: a) use everywhere the message Division by zero. b) try to find out when RI uses each of the different messages. I would suggest a) rather than b) since from the point of view of the programmer it is reasonable to obtain the same message when dividing by BigDecimal.ZERO regardless the size (or internal representation) of the dividend and the method invoked for the division. In addition, doing b) may imply inspecting the behavior of RI a bit too far. I am reluctant to do this since different messages may reveal when the unscaled value is implemented as a BigInteger and when as a primitive integral value. We submitted a new patch tests.diff.zip to H1208 correcting the test mentioned in 3) and replacing the test in 4) by another invocation to divide with the Division by zero message. Both RI and our implementation pass the tests. I think both patches should be applied. In the meantime we may discuss if the approach b) is preferred. Regards, Daniel 2006/8/22, Daniel Fridlender [EMAIL PROTECTED]: Hi Mikhail, On 8/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, Please resubmit the patch with license granted to ASF done. Seems like the patch was generated against original H-935 contribution and does not take into account later changes. Could you please regenerate the patch? The new patch should be applied to the version of java.math currently in the svn repository. It includes performance update from Vladimir (with bugs fixed) and other similar optimizations. We tried to respect spacing and line breaking from the version of the repository (it often disagrees with the original H935). Thanks, Daniel Thanks, Mikhail 2006/8/17, Mikhail Loenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1208?page=all ] Mikhail Loenko reassigned HARMONY-1208: --- Assignee: Mikhail Loenko Bug fixing and cosmetics for Harmony 935 Key: HARMONY-1208 URL: http://issues.apache.org/jira/browse/HARMONY-1208 Project: Harmony Issue Type: Improvement Reporter: Daniel Fridlender Assigned To: Mikhail Loenko Priority: Minor Attachments: MathDiff.diff.zip A patch to fix some bugs in Harmony 935, turn serialization compatible with RI and some cosmetics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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] - Terms of use : http
Re: [jira] Assigned: (HARMONY-1208) Bug fixing and cosmetics for Harmony 935
Hi Mikhail, On 8/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, Please resubmit the patch with license granted to ASF done. Seems like the patch was generated against original H-935 contribution and does not take into account later changes. Could you please regenerate the patch? The new patch should be applied to the version of java.math currently in the svn repository. It includes performance update from Vladimir (with bugs fixed) and other similar optimizations. We tried to respect spacing and line breaking from the version of the repository (it often disagrees with the original H935). Thanks, Daniel Thanks, Mikhail 2006/8/17, Mikhail Loenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-1208?page=all ] Mikhail Loenko reassigned HARMONY-1208: --- Assignee: Mikhail Loenko Bug fixing and cosmetics for Harmony 935 Key: HARMONY-1208 URL: http://issues.apache.org/jira/browse/HARMONY-1208 Project: Harmony Issue Type: Improvement Reporter: Daniel Fridlender Assigned To: Mikhail Loenko Priority: Minor Attachments: MathDiff.diff.zip A patch to fix some bugs in Harmony 935, turn serialization compatible with RI and some cosmetics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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]
Re: [classlib][java.math] combination of math packages
Vladimir, thank you very much for reviewing H-935 and improving it. It shows significantly better performance for BigDecimal that fit in 64 bits with no harm for the remaining cases. I agree with the changes you have made and are willing to continue improving our common math from now on. Thanks a lot! Daniel On 8/1/06, Vladimir Strigun [EMAIL PROTECTED] wrote: Daniel, Thank you for the new optimized version. We've analyzed your version and found it's very good. We can accept you version as default for Harmony but we'd like to add some improvements. :) I've updated H-935 and attach diffs for your code. We added optimization for small BigDecimal's objects. Our patch doesn't break your design covers the following issues: - reduce amount of object created during initialization of BigDecimal. In our version we don't use BigInteger during BigDecimal creation for small values. - cached values for powers of tens and for powers of five were added. - additional branches in all calculation methods for supporting small value calculations as well. - toDecimalScaledString method was added to Conversion class. The method is intended only for processing 32-bits numbers. I've attached small micro bench that shows boost for BigDecimal that fits to 64 bits. I should mention that we can't see any degradation in all other performance tests with our patch. Daniel, could you please review our patch? If you agree with suggested changes, I believe we all will vote +1 for our common math :) Thanks, Vladimir. -- Vladimir Strigun, Intel Middleware Product Division On 7/21/06, Daniel Fridlender [EMAIL PROTECTED] 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resolution of rmi/math/crypto duplication?
On 7/21/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: While it's not a critical thing, this seems like something we want to put to bed. Tim tried taking a run at this for one of these last week, and I'd like to try again. Would some number of days of discussion (like 3) plus a vote be an acceptable way to get this resolved? Yes. IMHO there is better value in performing a quick comparison and choosing one to work on and improve, compared to spending a long time evaluating the two/three impls. In the case of java.math I think we should pick the new implementation (H-935 which combines H-380 and H-199 and some of H-551) to improve from now on. Regards, Daniel It's a good problem to have though. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - 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]
Re: [classlib] resolution of rmi/math/crypto duplication?
On 7/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Daniel Fridlender wrote: On 7/21/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: While it's not a critical thing, this seems like something we want to put to bed. Tim tried taking a run at this for one of these last week, and I'd like to try again. Would some number of days of discussion (like 3) plus a vote be an acceptable way to get this resolved? Yes. IMHO there is better value in performing a quick comparison and choosing one to work on and improve, compared to spending a long time evaluating the two/three impls. In the case of java.math I think we should pick the new implementation (H-935 which combines H-380 and H-199 and some of H-551) to improve from now on. It doesn't surprise me that you'd say that :) What is your opinion for RMI? I am the wrong Daniel to answer that. I don't know enough about rmi to compare the two implementations. Daniel geir - 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]
[classlib][java.math] combination of math packages
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]
Re: [classlib][java.math]performance improvement for java.math package
Hi Vladimir, thank you very much for this new optimization of math from, as you said, enterprise-level applications point of view. Of course we are considering this optimization (H551) as well for the combination of the different math implementations into a new and more efficient one. In fact we are already working on a new version combining H39+380 with H199 and are introducing some of H551 optimizations as well. On the other hand, we are for the moment postponing some other of your optimizations for a future version since introducing them now would break, in my opinion prematurely, a nice design property we have so far: BigDecimal depends only on public features of BigInteger. So, we are following this plan: 1) integration of H39+H380 with H199 and with part of H551 2) optimization of this with more advanced algorithms 3) introducing remaining optimization from H551 For the point 2) above I would still like to have independence between BigDecimal and BigInteger. I hope you agree with this plan. I would also be grateful if you could be more specific when you mention enterprise-level applications. We are looking for realistic applications of math in order to be able to get an idea of how the implementations will work in practice. So far we had only found a few applications in cryptography and in number factorization (actually, they are applications of BigInteger only). Could you point me to the applications you had in mind so that we can add them to our (so far) small collection of applications? Are those applications for which float or double are not enough? Thanks again, Daniel On 6/2/06, Vladimir Strigun [EMAIL PROTECTED] wrote: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one. === Ops/sec for toString() method of BigDecimal Number Current fixed one of digits version 2 11215354 4 774 7514 8 615 6748 12 743 5543 16 623 4494 24 389 4895 32 306 3496 48 232 5815 64 224 3761 128 91 87 Ops/sec for divide method of BigInteger Number Current fixed one of digits version 2 52476315 4 46236497 8 55607491 12 838 838 16 25332063 24 16891717 32 23972494 48 21432131 64 613 525 128 13991418 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may
towards a new implementation of java.math
Hi, After a discussion we had a few weeks ago in this forum on the different implementations of java.math donated to Harmony (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for the task of integrating them into a single implementation which would benefit from the best features of Harmony-39, 380 and 199. We will consider comparing on a method-by-method level but also on ideas level so that the new implementation will probably require re-programming good ideas from the existing implementations. In the case of BigInteger we will also compare the benefits of the different internal representations. Right now we are analysing the two implementations. Once we are done with this analysis we will make it public and propose a way to proceed towards an integration. BTW, we had problems patching Harmony-380 over Harmony-39, it attempts to erase non-existing lines. Did we miss something? Is there any other intermediate patch that we have missed? Regards, Daniel Fridlender ITC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: towards a new implementation of java.math
Hi Mark, On 5/17/06, Daniel Gandara [EMAIL PROTECTED] wrote: Mark Hindess wrote: It would be quite trivial to do the same for the math implementations (and crypto I suppose). If we were to do this, perhaps the process of analysis and creation of a combined implementation could be done within the project? In public and with more potential contributions. What do you think? looks like a good and easy solution to handle packages with multiple contributions; I'll let Daniel (Fridlender) to answer since he is the one leading math :) I agree. Would you create a new jira with this for math? Then I would upload there a document with the result of our comparison and a proposal for a combination of the two implementations. Thanks Daniel Fridlender ITC Regards, Mark. Thanks, Daniel Gandara BTW: we are a bunch of Daniels here at Cordoba :))) On 17 May 2006 at 11:19, Daniel Fridlender [EMAIL PROTECTED] wrote: Hi, After a discussion we had a few weeks ago in this forum on the different implementations of java.math donated to Harmony (Harmony-(39+380) and Harmony-199) we (ITC) decided to voluteer for the task of integrating them into a single implementation which would benefit from the best features of Harmony-39, 380 and 199. We will consider comparing on a method-by-method level but also on ideas level so that the new implementation will probably require re-programming good ideas from the existing implementations. In the case of BigInteger we will also compare the benefits of the different internal representations. Right now we are analysing the two implementations. Once we are done with this analysis we will make it public and propose a way to proceed towards an integration. BTW, we had problems patching Harmony-380 over Harmony-39, it attempts to erase non-existing lines. Did we miss something? Is there any other intermediate patch that we have missed? Regards, Daniel Fridlender ITC - 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] - 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]
Re: ITC's java.math package contribution
Hi Geir, The 1.5 spec includes an Enum which is used in BigDecimal. But we surely can compile to 1.4 bytecode the part of the implementation that corresponds to the 1.4 API. Regards, Daniel Fridlender On 4/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Daniel Fridlender wrote: Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Nice! Performance is good! Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Great - can we compile down to 1.4 bytecode? geir - 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]
Re: ITC's java.math package contribution
Hi Geir, We implemented BigDecimal using only public features of BigInteger, so that our implementation of BigDecimal can be combined with any other implementation of BigInteger. On the other hand, having different internal representations would make it hard to combine both implementations of BigInteger into a single one. But we would be very happy to include into our implementation everything from HARMONY-39 that would enhance its performance. We are willing to continue optimizing our implementation further. Regards, Daniel Fridlender On 4/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This is great stuff. It will be fun to integrate all of this together to get the best of both. Now, with that happy and positive yet blatantly naive statement out there... How monolithic are these implementations? Will it even be possible to integrate, or do the internals reflect enough difference in approach that it will be one or the other? geir Semukhina, Elena V wrote: Hi Daniel, I've taken a look at ITC's implementation of java.math (original Harmony-199 donation) and tried to compare it to one donated by Harmony-39 on the method-by-method base. For example, I've tested about 30 BigInteger's methods and the result is the following: - 10 ITC's methods are slower, - 5 methods are approximately the same in both implementations, - 14 ITC's methods are faster. This is determined either by internal representation (which is different in both implementations) or algorithmically. On the other hand, I must admit that ITC's BigDecimal arithmetic is faster while, for example, toString() is slower for the values I've randomly chosen. I agree with you that real performance advantages should be demonstrated by real applications. On the whole, the package is well designed and the code quality is good. The disadvantage I've noticed is unimplemented serialization but this could be easily eliminated. Regards, Elena Semukhina Intel Middleware Products Division -Original Message- From: Daniel Fridlender [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 2:52 AM To: harmony-dev@incubator.apache.org Subject: ITC's java.math package contribution Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Some more information about our development can be found at http://www.fitc.unc.edu.ar/javadev/math/ Daniel Fridlender - 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ITC's java.math package contribution
Hi Stefano, I would be really surprised if a change in the VM has a significative impact on the relative performance of the two implementations. The difference in performance is due to the internal representation and to the implemented algorithms. But sure, it would be interesting to compare them on other VMs, thanks! Regards, Daniel Fridlender On 4/21/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Daniel Fridlender wrote: Hi Vladimir, Yes, I can make our results public of course. We have tested both implementations for RSA key generation, which is a mix of random prime generation and modular arithmetic (such as multiplicative inverse calculation). The testing platform was: CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz Cache size: 512 KB Total Mem: 1035492 KB OS: Linux kernel 2.6.11-6mdk #1 JDK: SUN Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) JCE Provider: Bouncy Castle release 1.30 We obtained the following results for keys of length 512, 1024 and 2048 bits. The figures are the average of 20, 15 and 5 iterations respectively. HARMONY-39 512 bits: 231.22 ms 1024 bits: 3361.98 ms 2048 bits: 37620.38 ms HARMONY-199 512 bits: 149.05 ms 1024 bits: 1245.45 ms 2048 bits: 16826.24 ms We also tested encrytping and decrypting, but in that case there were no significative differences between the implementations. have you tried on other JVMs? (I wouldn't want the optimizations to be tied to the way Sun's hotspot does things) -- Stefano. - 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]
Re: ITC's java.math package contribution
Hi Vladimir, We implemented BigDecimal using only public features of BigInteger, so that we can certainly combine our implementation of BigDecimal with HARMONY-39 (or any other) implementation of BigInteger. But I agree with you that there seems to be no easy way of combining both implementations of BigInteger due to their different internal representation. The only way would be to re-implement good ideas from one implementation into the other one. We want to further optimize our implementation, so we would be happy to do that. I also agree with you that it would be really nice to have a representative collection of realistic applications of the functionality of java.math. RSA key generation is definitely one of them. We should find more. That would also help us identifying methods that are critical for the performance in practice, thus methods that are worth optimizing further. Regards, Daniel Fridlender On 4/21/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Hi Geir, Unfortunately both implementations have different internal representation. Therefore all algorithms have been implemented in accordance with them. I see no way to integrate them. I'd also like to note it's insufficiently to measure the performance using only one of the real applications and one of VMs. We know some of methods for HARMONY-39 contribution have better performance in comparing with HARMONY-199. It means (in my opinion) it's not a fact that other applications will not show worse performance for one or other implementation. Clearly, that we should make a choice once. What will we do if there are 50% of voices against 50%? For any of the forthcoming contributions but not only for ones discussed in this thread. Thanks, Vladimir Gorr Intel Middleware Products Division. On 4/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This is great stuff. It will be fun to integrate all of this together to get the best of both. Now, with that happy and positive yet blatantly naive statement out there... How monolithic are these implementations? Will it even be possible to integrate, or do the internals reflect enough difference in approach that it will be one or the other? geir Semukhina, Elena V wrote: Hi Daniel, I've taken a look at ITC's implementation of java.math (original Harmony-199 donation) and tried to compare it to one donated by Harmony-39 on the method-by-method base. For example, I've tested about 30 BigInteger's methods and the result is the following: - 10 ITC's methods are slower, - 5 methods are approximately the same in both implementations, - 14 ITC's methods are faster. This is determined either by internal representation (which is different in both implementations) or algorithmically. On the other hand, I must admit that ITC's BigDecimal arithmetic is faster while, for example, toString() is slower for the values I've randomly chosen. I agree with you that real performance advantages should be demonstrated by real applications. On the whole, the package is well designed and the code quality is good. The disadvantage I've noticed is unimplemented serialization but this could be easily eliminated. Regards, Elena Semukhina Intel Middleware Products Division -Original Message- From: Daniel Fridlender [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 2:52 AM To: harmony-dev@incubator.apache.org Subject: ITC's java.math package contribution Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Some more information about our development can be found at http://www.fitc.unc.edu.ar/javadev/math/ Daniel Fridlender - Terms of use : http://incubator.apache.org/harmony/mailing.html
Re: ITC's java.math package contribution
Hi Vladimir, Yes, I can make our results public of course. We have tested both implementations for RSA key generation, which is a mix of random prime generation and modular arithmetic (such as multiplicative inverse calculation). The testing platform was: CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz Cache size: 512 KB Total Mem: 1035492 KB OS: Linux kernel 2.6.11-6mdk #1 JDK: SUN Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) JCE Provider: Bouncy Castle release 1.30 We obtained the following results for keys of length 512, 1024 and 2048 bits. The figures are the average of 20, 15 and 5 iterations respectively. HARMONY-39 512 bits: 231.22 ms 1024 bits: 3361.98 ms 2048 bits: 37620.38 ms HARMONY-199 512 bits: 149.05 ms 1024 bits: 1245.45 ms 2048 bits: 16826.24 ms We also tested encrytping and decrypting, but in that case there were no significative differences between the implementations. Regards, Daniel Fridlender On 4/20/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Hi Daniel, indeed it makes sense to compare the performance both implementations of java.math package using the real applications. If you have any results could you plase to make them public? I want to look at them. Besides I'd pefer to slightly correct you about the SVN repository already contains full implemenation of the java.math package for Java 1.5 (please look at the HARMONY-380 issue for details). Thanks, Vladimir Gorr Intel Middleware Products Division. On 4/21/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Some more information about our development can be found at http://www.fitc.unc.edu.ar/javadev/math/ Daniel Fridlender - 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]
Re: ITC's java.math package contribution
Hi Elena, thank you very much for having a look at our contribution and reporting the results of your tests. We have also done some method-by-method comparisons, our results were similar to yours. I agree with you that the difference in performance in methods of BigInteger is due to the internal representation and to the implemented algorithms. Regards, Daniel Fridlender On 4/21/06, Semukhina, Elena V [EMAIL PROTECTED] wrote: Hi Daniel, I've taken a look at ITC's implementation of java.math (original Harmony-199 donation) and tried to compare it to one donated by Harmony-39 on the method-by-method base. For example, I've tested about 30 BigInteger's methods and the result is the following: - 10 ITC's methods are slower, - 5 methods are approximately the same in both implementations, - 14 ITC's methods are faster. This is determined either by internal representation (which is different in both implementations) or algorithmically. On the other hand, I must admit that ITC's BigDecimal arithmetic is faster while, for example, toString() is slower for the values I've randomly chosen. I agree with you that real performance advantages should be demonstrated by real applications. On the whole, the package is well designed and the code quality is good. The disadvantage I've noticed is unimplemented serialization but this could be easily eliminated. Regards, Elena Semukhina Intel Middleware Products Division -Original Message- From: Daniel Fridlender [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 2:52 AM To: harmony-dev@incubator.apache.org Subject: ITC's java.math package contribution Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Some more information about our development can be found at http://www.fitc.unc.edu.ar/javadev/math/ Daniel Fridlender - 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]
ITC's java.math package contribution
Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Some more information about our development can be found at http://www.fitc.unc.edu.ar/javadev/math/ Daniel Fridlender - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
