I think it should be possible to combine on ideas level, not just the code.
You may want to look at your counterpart's code from the following perspective: which ideas, tips, algorithms would you take to your code? Once we figured that out I think it would be easier to define next steps. Thanks, Mikhail 2006/4/23, Daniel Fridlender <[EMAIL PROTECTED]>: > 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 > > > > > > > >> 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]
