java.math.MutableBigInteger
is only available from inside the package. It inherits from java.lang.Object
and there is only one subclass (SignedMutableBigInteger
) which is only available from inside the package.

- 12,717
- 29
- 108
- 202
3 Answers
/**
* A class used to represent multiprecision integers that makes efficient
* use of allocated space by allowing a number to occupy only part of
* an array so that the arrays do not have to be reallocated as often.
* When performing an operation with many iterations the array used to
* hold a number is only reallocated when necessary and does not have to
* be the same size as the number it represents. A mutable number allows
* calculations to occur on the same number without having to create
* a new number for every step of the calculation as occurs with
* BigIntegers.
*
* @see BigInteger
* @version 1.12, 12/19/03
* @author Michael McCloskey
* @since 1.3
*/
I'd guess MutableBigInteger is used internally for BigInteger heavy calculations that are slowed down by frequent reallocations. I'm not sure why its not exported as part of java.math. Perhaps some distaste for mutable value classes?
To clarify "mutable":
Standard BigInteger has one value for its entire lifetime, given two BigInteger references "a" & "b", "a+b" will always yield a new BigInteger with the same value. Let's say that value is 4.
With MutableBigInteger, "a+b" could yield 4 initially, yet yield 8, 16, 32, or any other number at some point in the future due to OTHER code changing the values (aka. mutating) of the objects referenced by "a" & "b". Accordingly, most (perhaps all) of the value types (Character, Short, Long, Integer, BigInteger, BigDecimal, Float, Double, even String) in Java are immutable.

- 22,191
- 9
- 88
- 137
-
Thanks for answering. Maybe the questions should be: "Why it is no public class?". I think the such a class could be very usefull, especially for loop variables. – May 21 '09 at 01:41
-
I've expanded my answer a bit accordingly. Basically, its probably not mutable because other value types are also not mutable. Its a convention, really. – Kevin Montrose May 21 '09 at 01:45
The issue with BigInteger is that it's immutable: in other words, once you have a BigInteger object, you can't change the value of the object itself, you can only replace it with a new object.
Now this is normally a fine thing, since it prevents aliasing and so on (you don't want your "2 + 3" somewhere to suddenly turn into "2 + 5" because a user of that "3" somewhere else in your program changed it into a "5"). However, internally the BigInteger uses an array to hold the components of this value. For a large number, this array can be quite large; a BigInteger representing a bazillion might need an array of, oh, a thousand elements, say.
So what happens when I want to add one to this BigInteger? Well, we create a new BigInteger, which in turn will create a new array internal to it of a thousand elements, copy all of the elements of the old BigInteger's internal array to the new BigInteger's internal array, excepting the last one, and put in a new version of that last element incremented by one. (Or it might need to update the last two.) If you then don't need the old value, it frees up that old BigInteger, which frees up the array.
This is obviously pretty inefficient if you are just getting rid of the old values anyway. So if you have operations like this, you can instead use a MutableBigInteger, which can be incremented by simply changing the last element in the internal array of the existing MutableBigInteger. This is far faster! However, it does destroy the old value, which can be problematic, as I pointed out above. If someone gives you the int "3", you can expect that to stay the same. If someone gives you a MutableBigInteger, don't expect it to be the same number later on!

- 25,752
- 9
- 89
- 101
-
Thanks for answering. You described the way the class works very well. But you missed one thing: The class is not public (declared without or with the default modifier). So it is not availible from outside the package java.math . – May 21 '09 at 01:43
-
@c0d3x and Curt, there is certainly nothing wrong with creating an immutable constructor flag in an otherwise immutable class, or vice versa. That would certainly protect your "3". I'm more than a little annoyed frankly that there is no mutable LongLong and similar for the BigInteger variants. I feel that this immutable business is a clumsy bit of pedantry and violates the law of least surprise, both when using it and reading code using it. Seriously, have any of you seen a page of it? It's just gross. – Jul 21 '16 at 16:41
-
2I've seen tens of thousands of lines of code with almost no immutability at all. It's called Haskell, and it's wonderful. :-) Honestly, making the majority of your data immutable almost always makes for easier programming. However, it is often true that, in systems heavily reliant on mutability throughout the system, trying to introduce immutability can get awkward. That's not really a problem with the concept; it's a problem with it not being applied well. – cjs Jul 22 '16 at 10:37
-
1The issue with encapsulation often tends to break down into one of two mindsets when it comes to numbers. 1. Are we abstracting out the storage of immediates, or 2. Are we abstracting out the immediate itself. IMO, having immutable numbers is of very little help, so I tend to default to the first mindset. If we need both the storage of the number _and_ the (immutable) immediate, then there certainly is no problem with the following idiom (not currently valid): `BigInteger fiveBI = new BigInteger(5, BigInteger.IMMUTABLE);` – Jul 22 '16 at 20:40
-
1Keep in mind, what are common for the storage of numbers to begin with? We like to increment them. `bigI.inc()` is not possible. We like to add _to_ them. `bigI.add(17)` is not possible. (etc.) I really think that there are times when we let the academics run amok when designing libraries. – Jul 22 '16 at 20:46
-
You are certainly correct that `3.inc()` and `3.add(17)` are not possible. I would further add that they're not even sensible. – cjs Jul 25 '16 at 13:38
-
You clearly didn't understand what I wrote. Of course (immediate)`.inc()` isn't possible. But the abstraction should be for the _storage_ of the numbers not the (immutable) numbers themselves. Tell me: Of what use would this be in the case of primitives? Would you advocate that `i` in the case of `int i=3;` be immutable? Of course not. Stop insisting that the `3` is immutable. That's of no use whatsoever. The `i` is not. – Jul 25 '16 at 15:39
-
It's perfectly reasonable to want the _i_ to be immutable: when I call _doSomething(i)_, often I really don't want to worry about whether, by design or error, _doSomething_ mutates my _i_. The core issue in these comments is that you're clearly used to living in a world of mutability (as shown by your incorrect assumption that "we like to increment numbers through mutation"--you may, but I certainly do not) and so you don't really see the massive problems that brings along--the fish not noticing the water.This is not the place for a detailed discussion of that, however. – cjs Jul 26 '16 at 22:35
-
If you want to further discuss immutability in general, rather than `MutableBigInteger` specifically, do feel free to contact me via e-mail. My address is on my profile page. – cjs Jul 26 '16 at 22:40
-
I have no wish to debate immutability "in general" because my entire focus here is on numbers what it means to abstract their storage instead of their value. Why bring up a generalized discussion anyway? Some means of deflection? – Jul 30 '16 at 02:37
-
Fine. The entire focus of `BigInteger` not being mutable, and having a mutable version available only as an internal interface for efficiency, is that in general you want to abstract their values, not their storage. If you disagree with that, you disagree with a primary design characteristic of `BigInteger` and you should take it up with the authors. – cjs Aug 01 '16 at 04:50
-
I'm sorry, but that's simply absurd. Apparently you think that every opinion about a language failing can be waved away with "take it up with the authors." The argument I'm now having is with your rationale, which was missing what I was saying. YES, as I outlined originally, this has to do with a difference in methodology: abstracting storage vs. the value. Your position is clear. But it's not made with things like `3.inc()`. I wonder what you store your `BigInteger`s in? A _mutable variable_ holding a reference to it!!! That variable can be reassigned. Goodbye to your pedantry. Adios. – Aug 01 '16 at 21:37
-
As I explained earlier, I store things like numbers in immutable variables, so that I can use them just like, and with just as much safety, as I use "3". This sort of thing is "pedantry" only to those who do not understand the value of broad use of immutable variables (which, yes, is probably the vast majority of programmers). – cjs Aug 05 '16 at 03:37
MutableBigInteger is referenced in the java.math library. If you have a JDK installed check out the contents of src.zip in your jdk directory.
You will see BigInteger uses it:
public BigInteger divide(BigInteger val) { MutableBigInteger q = new MutableBigInteger(), r = new MutableBigInteger(), a = new MutableBigInteger(this.mag), b = new MutableBigInteger(val.mag); a.divide(b, q, r); return new BigInteger(q, this.signum * val.signum); }
MutableBigInteger is an encapsulation of the mathematical algorithms used by BigInteger.

- 1,944
- 17
- 17