[503] in java-interest
Re: BigInteger class out there?
daemon@ATHENA.MIT.EDU (Chuck McManis)
Mon Jun 26 17:04:59 1995
Date: Mon, 26 Jun 1995 13:23:29 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: java-interest@java.Eng.Sun.COM
Cc: mlorton@eshop.com
Michael Lorton wrote ;
>Which brings us to my question: why no operator overloading in Java?
My understanding was that it was a value/complexity tradeoff but either
Arthur van Hoff or James Gosling can answer this question more completely.
>What does this mean? That the VPInteger pointed to by c is reset to
>a*b. If so, I think this is *bad*.
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 :-))
As for your test case:
>Consider:
>
> VPInteger five = new VPInteger(16);
> five.assign("5");
> VPInteger six = new VPInteger(16);
> six.assign("5");
>
> VPInteger product = five;
>
> six.mul(product, five);
>
> Sys.out.println(five); // prints out "30" !!
This would actually print out '25' but I see understand your point. But
this is just a code bug right? I mean how is six.mul(product, five); any
different than accidently coding five.assign(30); ? The expected thing
happens if you had coded it:
product = six.mul(five);
And if you had used the other syntax you presumably intended that the object
referenced by 'product' be turned into the value of the product.
Anyway, in the immutable case your test case would have the "unexpected"
result of replacing the ref in product to five to something else. Which
is the worse suprise?
>Better, I would think, to make VPIntegers immutable, like Strings.
>After all, you have garbage collection.
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?
--Chuck
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
