[508] in java-interest
Re: BigInteger class out there?
daemon@ATHENA.MIT.EDU (Michael Lorton)
Mon Jun 26 20:28:48 1995
Date: Mon, 26 Jun 1995 16:53:19 -0700
From: Michael Lorton <mlorton@eshop.com>
To: java-interest@java.Eng.Sun.COM
In-Reply-To: Chuck McManis's message of Mon, 26 Jun 1995 13:23:29 -0700 <9506262023.AA15073@pepper.Eng.Sun.COM>
> Originally I had written VPI's to be immutable like strings, then I wrote
> some code that did a lot of math and discovered I was blasting the heap with
> lots of allocations and disposals. Sure, they get collected eventually, but
> if you do a lot of operations it can be useful (and more efficient) to be
> able to re-use the allocated buffers. The decsion to make those interfaces
> public is not cast in stone (especially since no code outside of mine yet
> uses them :-))
Well, I am agin' it. As I tried (clumsily) to point out, the current
makes buffer management into a global problem: Is any else using this
number-buffer? You would be reducing the complexity of the
implementation by increasing the complexity of the interface.
Maybe you should have internal mutable numbers and external immutable
ones. Would this solve (or reduce) your performance problem?
> Heres another random question, what about autogrowing integers? Right
> now add returns a boolean if there was a carry "out" of the result
> (ie result.maxBits() > Math.max(a.maxBits(), b.maxBits())) this appears
> to be the expected behaviour of most of the big number packages I've
> seen (except for the LISP ones). Which would you do, make it bigger or
> make it return status?
In the "immutable" style it isn't a problem. When you "create" a
number, you know how many bit it takes to represent it. When you add
(or multiply or, heaven protect us, exponentiate) a wholly new number
is created, with whatever number of bits.
I am very much against putting error codes (which is what the carry
is) in return values. It vastly increases the size of the client code
and make more likely that the error will go overlooked. Use exceptions
instead.
M.
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
