BigInteger enhancing

[Arne Vajhøj]

You evidently don't have the same keyboard as me!

The typing of code is usually an insignificant part of
a software project. The hard part is figuring out what
to type.

Arne

 

[Lew]

<file name="cli/big/MegaInteger.java">
package cli.big;

import java.math.BigInteger;

public class MegaInteger {

public static final MegaInteger ZERO = new MegaInteger();

or
public static final MegaInteger ZERO =
new MegaInteger( BigInteger.ZERO );

private final BigInteger value;

private MegaInteger() {
this.value = BigInteger.valueOf(0);

or
this.value = BigInteger.ZERO;

 

[John B. Matthews]

this.value = BigInteger.valueOf(0);

or
this.value = BigInteger.ZERO;[/QUOTE]

Yes, a good example of the clarity of a named constant in preference to
a "magic number".

In the particular exercise I was trying, an easier result may be
obtained by running the JScience benchmark:

java -jar jscience.jar perf

<adapted>
1024 bit BigInteger versus 1024 bit LargeInteger using StackContext
....
BigInteger addition: 8.304 us
BigInteger multiplication: 59.58 us
LargeInteger addition: 884.8 ns
LargeInteger multiplication: 42.62 us
....
</adapted>

For reference, the JScience maintainers kindly acknowledged a report of
the corrected spelling of Karatsuba's name, thanks to rossum.

 

[Tom Anderson]

this.value = BigInteger.valueOf(0);

or
this.value = BigInteger.ZERO;

Yes, a good example of the clarity of a named constant in preference to
a "magic number".[/QUOTE]

Well, not really, since in this case the number is 0, which i think is a
sufficiently well-known number that no clarity is gained by naming it.

I do prefer Lew's version, but because it's simpler: we load a field with
the value we want, rather than parsing a string.

tom

 

[Wojtek]

Tom Anderson wrote :

Well, not really, since in this case the number is 0, which i think is a
sufficiently well-known number that no clarity is gained by naming it.

Sure, that is what they all say. Then one day it bites you.

There is no run time overhead from using constants and huge benefits
for readability.

I am not saying that the value of zero will ever change, but you may
have another place where zero is used with a different meaning, which
one day does change. Now how do you determine which zero to change?
Other than going through the code line by line?

ie:

BigInteger.ZERO (== 0)
MyStuff.NO_VALUE (== 0 then changes to == -1 because 0 becaomes a valid
value)

 

[John B. Matthews]

Well, not really, since in this case the number is 0, which i think
is a sufficiently well-known number that no clarity is gained by
naming it.

[/QUOTE]

Certainly this is true when 0 is used is a familiar way, say as the
lowest index of a Java array or a "don't care" dimension in GridLayout.
In BigInteger, ZERO is already a named constant; in LargeInteger, ZERO
is the additive identity and a convenient coefficient in constructing

Sure, that is what they all say. Then one day it bites you.

There is no run time overhead from using constants and huge benefits
for readability.

Moreover, instances are immutable, so a single copy suffices. In
particular, a static factory method is not required to create
a new object each time it iss invoked.

I am not saying that the value of zero will ever change, but you may
have another place where zero is used with a different meaning, which
one day does change. Now how do you determine which zero to change?
Other than going through the code line by line?

ie:

BigInteger.ZERO (== 0)
MyStuff.NO_VALUE (== 0 then changes to == -1 because 0 becaomes a
valid value)

I wondered about that. One might explicitly initialize the value to null
in the private, no-argument constructor

private MegaInteger() {
this.value = null;
}

to get something like Double.NaN:

public static final MegaInteger NaN = new MegaInteger();

I'm sure if it would be useful, but the odd value reminds me of the
ternary logic used in databases:

<http://en.wikipedia.org/wiki/Ternary_logic>
<http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/fundament
als.htm>

But I digress.

 

[Lew]

One might explicitly initialize the value to null
in the private, no-argument constructor

private MegaInteger() {
    this.value = null;
}

to get something like Double.NaN:

public static final MegaInteger NaN = new MegaInteger();

I'm sure if it would be useful, but the odd value reminds me of the
ternary logic used in databases:

<http://en.wikipedia.org/wiki/Ternary_logic>
<http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/fundamentals.htm>

But I digress.

It's not really a digression in that it fits quite well in the context
of "enhancing" the value of 'BigInteger'. It's especially relevant to
Wojtek's suggestion of

MyStuff.NO_VALUE (== 0 then changes to == -1
because 0 becaomes a valid value)

because an out-of-band value like 'null' is more immune to that kind
of refactoring than in in-band value like '0' or '-1'. (It is also
better not to change static final constants because compiler
dependencies follow different rules where they're concerned.)

I like ternary logic with UNKNOWN (sometimes called "NULL" or 'null')
for its usefulness. (Learning of it completed a lesson started back
in undergraduate logic class, finally scratching a long-standing
mental itch.) It has raised questions from some correspondents about
other possible out-of-band values - "Is it unknown because you just
haven't found out yet, because you cannot find out, or because you
don't care what you find out?" I don't know that we need additional
values as I've heard some argue, though. Would a quaternary logic be
useful, one that includes both UNKNOWN and UNIMPORTANT?

 

[John B. Matthews]

It's not really a digression in that it fits quite well in the context
of "enhancing" the value of 'BigInteger'. It's especially relevant to
Wojtek's suggestion of


because an out-of-band value like 'null' is more immune to that kind
of refactoring than in in-band value like '0' or '-1'. (It is also
better not to change static final constants because compiler
dependencies follow different rules where they're concerned.)

I like ternary logic with UNKNOWN (sometimes called "NULL" or 'null')
for its usefulness. (Learning of it completed a lesson started back
in undergraduate logic class, finally scratching a long-standing
mental itch.) It has raised questions from some correspondents about
other possible out-of-band values - "Is it unknown because you just
haven't found out yet, because you cannot find out, or because you
don't care what you find out?" I don't know that we need additional
values as I've heard some argue, though. Would a quaternary logic be
useful, one that includes both UNKNOWN and UNIMPORTANT?

This is indeed a thorny problem. I would fear a combinatorial explosion
beyond ternary. The classic case is a radio group from which one (and
only one) response is to be selected. What is the default selection? A
hidden button is often advocated. Is null a permitted value? If so, all
queries must account for the possibility of null. If the value is null,
does it symbolize not answered? Never asked? Refused to answer? Forgot?
Never knew?

As a practical matter, I've used null to symbolize "never asked" and
have no other meaning. All other choices must be explicit: instead of
"smoker | non-smoker" one must have "refused-to-answer | never-smoked |
former-smoker | current-smoker" with "date-quit" and "packs-per-day" as
dependent attributes.

It's a minefield. I sense you've been there.

 

[John W Kennedy]

Would a quaternary logic be
useful, one that includes both UNKNOWN and UNIMPORTANT?

No. Something that is absolutely unimportant is, by definition, a
question that does not need to be asked in the first place. Something
that is relatively unimportant can be handled by recasting the rules.

But the need for nulls is one of the reasons Codd gave us SQL.... ;-)

 

[Tom Anderson]

It's not really a digression in that it fits quite well in the context
of "enhancing" the value of 'BigInteger'. It's especially relevant to
Wojtek's suggestion of


because an out-of-band value like 'null' is more immune to that kind
of refactoring than in in-band value like '0' or '-1'. (It is also
better not to change static final constants because compiler
dependencies follow different rules where they're concerned.)

I like ternary logic with UNKNOWN (sometimes called "NULL" or 'null')
for its usefulness. (Learning of it completed a lesson started back
in undergraduate logic class, finally scratching a long-standing
mental itch.) It has raised questions from some correspondents about
other possible out-of-band values - "Is it unknown because you just
haven't found out yet, because you cannot find out, or because you
don't care what you find out?" I don't know that we need additional
values as I've heard some argue, though. Would a quaternary logic be
useful, one that includes both UNKNOWN and UNIMPORTANT?

I am reminded of this:

http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx

!

tom

 

[John B. Matthews]

I am reminded of this:

http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx

!

Indeed, ternary logic has many dangers: <http://xkcd.com/246/>

 

[blue indigo]

Indeed, ternary logic has many dangers: <http://xkcd.com/246/>

In this newsgroup it's

public enum ResponseType {
YES;
NO;
JOKE;
SPELLING_TOPPOSTING_WRONG_NEWSGROUP_OR_OTHER_FLAME;
TROLL_FOOD;
ERROR_TIMEOUT;
ERROR_AIOE_DOWN_YET_AGAIN;
}

which would indicate that the dangers of ternary logic pale beside those
of septenary logic. (Or is that September logic?

The closest in the above to UNKNOWN being ERROR_TIMEOUT. All the rest can
be considered UNIMPORTANT, at least if you know how to use a real
newsreader and especially its score file. Well, except for
ERROR_AIOE_DOWN_YET_AGAIN. Which I treat like other things'
ERROR_TIMEOUT, wait a bit and retry.

Confused yet?

 

[Tom Anderson]

In this newsgroup it's

public enum ResponseType {
YES;
NO;
JOKE;
SPELLING_TOPPOSTING_WRONG_NEWSGROUP_OR_OTHER_FLAME;
TROLL_FOOD;
ERROR_TIMEOUT;
ERROR_AIOE_DOWN_YET_AGAIN;
}

No.

Oh god *dammit*!

tom