| Re: [cdt-dev] Bug ID 403404 |
|
I think you need to look at the implementation of BigInteger before claiming it's not a performance problem. At the very least, it's really big.
It's easy to imagine a much more performant and small implementation if you know how many bits you're trying to handle. For example, with 128-bits, you can use double word algorithms are as old as I am and maximize performance.
Doug.
From: <Oberhuber>, Martin <Martin.Oberhuber@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Date: Friday, 5 April, 2013 8:51 AM To: David Wang <kuoweiwang@xxxxxxxxx>, "CDT General developers list." <cdt-dev@xxxxxxxxxxx>, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> Subject: Re: [cdt-dev] Bug ID 403404 StackOverflow recommends BigInteger and doesn’t talk about inefficiency. Starting with BigInteger now, it should be fairly straightforward to refactor into a different class with the same API later (ie simple search &
replace on the name BigInteger and the import statements for its package). That is, only if performance measurement shows that it’s in fact a problem. Or are you concerned that the API of BigInteger is already inefficient ? – Are you concerned about memory size or performance ? Thanks, Martin -- Martin Oberhuber, SMTS / Product Architect – Development
Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of David Wang I would hope we can simply use the BigInteger for now even though its inefficient. But at least this stuff would work. At the same time we can look into a more solid solution. Thanks From: Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> Good opportunity for somebody to contribute one. -sergey
On Tue, Apr 2, 2013 at 4:15 PM, David Wang <kuoweiwang@xxxxxxxxx> wrote: Not that I am aware of. From: Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> Cc: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Oh, I see. I didn't notice the bug number in the subject. Do you know of an open source Java implementation of 128-bit integers with EPL-compatible license? I'd like to
avoid BigInteger since it's too heavy and inefficient. -sergey
On Tue, Apr 2, 2013 at 4:02 PM, David Wang <kuoweiwang@xxxxxxxxx> wrote: Thanks. I already filed a bug and the ID on the subject. Do you want me to create another one? I wonder what is the outlook for the bug, my code needs this thing to work. Thanks again From: Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> This is most likely caused by the fact that ULONG_MAX cannot be represented by a Java long. Could you please file a bug. -sergey
On Tue, Apr 2, 2013 at 3:42 PM, David Wang <kuoweiwang@xxxxxxxxx> wrote: Hi I discussed some potential eclipse indexing error at It seems to be a bug in eclipse. I created a bug last month. Can someone please help and confirm if this is an eclipse bug? and/or will it be fixed shortly?
Thanks a lot, my code heavily relies on this to be working correctly... David
|