Chris Gray wrote:
On Sunday 23 April 2006 02:07, Daniel Fridlender wrote:
I also agree with [Vladimir] 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 m
Vladimir Gorr [mailto:[EMAIL PROTECTED]
> >Sent: Sunday, April 23, 2006 7:28 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: ITC's java.math package contribution
> >
> >If we will combine on ideas level new implementaion of java.math should
> >appear
lena
>-Original Message-
>From: Vladimir Gorr [mailto:[EMAIL PROTECTED]
>Sent: Sunday, April 23, 2006 7:28 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: ITC's java.math package contribution
>
>If we will combine on ideas level new implementaion of java.math sh
If we will combine on ideas level new implementaion of java.math should
appear.
Both implementations use the D. Knuth's algorithms and nothing new. Yes, we
can take
the Big Decimal from HARMONY-199 and Big Integer from HARMONY-39 (or vice
versa)
and measure the performance. Other approach is to imp
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,
On Sunday 23 April 2006 02:07, Daniel Fridlender wrote:
> I also agree with [Vladimir] 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 woul
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
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 the
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 Big
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:
> > De
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
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)
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
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
C
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 diff
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 w
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 ar
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 contain
18 matches
Mail list logo
