BigInteger enhancing

[Dmitriy Melnik]

Hello again,

Standard BigInteger class lacks several useful methods used in
cryptography such as square rooting and square rooting modulo a prime.
Of course, it is possible to create static methods like this and use
them:

public class NewMethods {
public static BigInteger sqrt(BigInteger n) { ... }
public static BigInteger modSqrt(BigInteger n, BigInteger modulo)
{ ... }
}

But this solution does not look elegant.

How can I enhance BigInteger in the way that'll provide consistent
interface? I tried to write something like this:

public class BigIntegerExt extends BigInteger {
// constructors are omitted
public BigIntegerExt sqrt() { ... }
public BigIntegerExt modSqrt(BigInteger modulo) { ... }
}

But this still seems to be inconsistent. A lot of inherited methods
still return a BigInteger. So I end up with the mess of two classes
and constant casting. For example:

BigIntegerExt a = new BigIntegerExt("1");
BigIntegerExt b = new BigIntegerExt("2");
BigIntegerExt c = a.sqrt(); // Works
BigIntegerExt d = a.add(b); // Doesn't work; needs explicit casting
from BigInteger to BigIntegerExt which is unsafe

Is there another way to transparently add several methods to
BigInteger?

 

[Lew]

But this still seems to be inconsistent. A lot of inherited methods
still return a BigInteger. So I end up with the mess of two classes
and constant [?] casting.

Override those methods to return the subclass.

 

[Dmitriy Melnik]

But this still seems to be inconsistent. A lot of inherited methods
still return a BigInteger. So I end up with the mess of two classes
and constant [?] casting.

Override those methods to return the subclass.

I thought about it but hoped there were an easier way. Thanks!

P.S. "Constant" means "all the time" My English's not good at times.

 

[Arne Vajhøj]

Standard BigInteger class lacks several useful methods used in
cryptography such as square rooting and square rooting modulo a prime.
Of course, it is possible to create static methods like this and use
them:

public class NewMethods {
public static BigInteger sqrt(BigInteger n) { ... }
public static BigInteger modSqrt(BigInteger n, BigInteger modulo)
{ ... }
}

But this solution does not look elegant.

How can I enhance BigInteger in the way that'll provide consistent
interface? I tried to write something like this:

public class BigIntegerExt extends BigInteger {
// constructors are omitted
public BigIntegerExt sqrt() { ... }
public BigIntegerExt modSqrt(BigInteger modulo) { ... }
}

But this still seems to be inconsistent. A lot of inherited methods
still return a BigInteger. So I end up with the mess of two classes
and constant casting. For example:

BigIntegerExt a = new BigIntegerExt("1");
BigIntegerExt b = new BigIntegerExt("2");
BigIntegerExt c = a.sqrt(); // Works
BigIntegerExt d = a.add(b); // Doesn't work; needs explicit casting
from BigInteger to BigIntegerExt which is unsafe

Is there another way to transparently add several methods to
BigInteger?

Java does not support extension methods.

But do you really want it that way ?

I am assuming you are implementing something you have in Math.

You first construct combined with static import seems to much
better match Math syntax.

a.sqrt()
NewMethods.sqrt(a)
sqrt(a)

Arne

 

[Dmitriy Melnik]

Java does not support extension methods.

But do you really want it that way ?

I am assuming you are implementing something you have in Math.

You first construct combined with static import seems to much
better match Math syntax.

a.sqrt()
NewMethods.sqrt(a)
sqrt(a)

I tried to mimic native BigInteger interface. But now I can see the
required amount of work is not worth the result.

 

[Dmitriy Melnik]

Java does not support extension methods.

But do you really want it that way ?

I am assuming you are implementing something you have in Math.

You first construct combined with static import seems to much
better match Math syntax.

a.sqrt()
NewMethods.sqrt(a)
sqrt(a)

I tried to mimic native BigInteger interface. But now I can see the
required amount of work is not worth the result.

 

[Arne Vajh©ªj]

I tried to mimic native BigInteger interface. But now I can see the
required amount of work is not worth the result.

That interface/syntax is not very convenient.

You will be better off with static import.

Arne

 

[Dmitriy Melnik]

That interface/syntax is not very convenient.

You will be better off with static import.

Now I understood it too. Besides it will save me some time. Thanks!

 

[blue indigo]

Java does not support extension methods.

There was a big discussion about adding such support, a while back. I
didn't participate. No consensus emerged that I can recall.

 

[Tom Anderson]

Standard BigInteger class lacks several useful methods used in
cryptography such as square rooting and square rooting modulo a prime.

Another option could be to use a different bignum class that does have the
methods you need. I could have sworn that there was an IBM one that was
faster than Sun's, but i can't find it. The GMP package is very fast, and
has all sorts of methods useful for cryptography, but is written in C -
you'd have to write a wrapper using JNI, or else copy the java-GMP bridge
used in the Kaffe project.

tom

 

[Arne Vajh¸j]

There was a big discussion about adding such support, a while back. I
didn't participate. No consensus emerged that I can recall.

And even if there were consensus, then it would not help OP much - not
today and considering that to my best knowledge the people active
in JCP do not read this forum most likely not in the future either (*).

Arne

*) If they do then they are awfully quiet.

 

[Dmitriy Melnik]

Another option could be to use a different bignum class that does have the
methods you need. I could have sworn that there was an IBM one that was
faster than Sun's, but i can't find it. The GMP package is very fast, and
has all sorts of methods useful for cryptography, but is written in C -
you'd have to write a wrapper using JNI, or else copy the java-GMP bridge
used in the Kaffe project.

Thanks for GMP hint. I'm going to try it out.

 

[Lew]

Java does not support extension methods.

What do you mean by "extension methods"?

 

[Arne Vajhøj]

What do you mean by "extension methods"?

It is a C#/.NET feature where you can write
a class Y that adds methods to class X.

Arne

 

[Arne Vajhøj]

It is a C#/.NET feature where you can write
a class Y that adds methods to class X.

The code below outputs 9.

Arne

================================

using System;

namespace E
{
public class A
{
private int v;
public int V { get { return v; } set { v = value; }}
public A(int v)
{
this.v = v;
}
public void Add(int n)
{
v += n;
}
public override string ToString()
{
return v.ToString();
}
}
public static class B
{
public static void Mul(this A o, int n)
{
o.V *= n;
}
}
public class Program
{
public static void Main(string[] args)
{
A o = new A(2);
o.Add(1);
o.Mul(3);
Console.WriteLine(o);
Console.ReadKey();
}
}
}

 

[Lew]

You could always roll out your own class. Standard BigInteger happens
to be written in pure Java; source code is available through, for
instance, OpenJDK (and you can reuse it, provided that you comply
with the license, which is a kind of GPL-derivative). So you could
simple copy the BigInteger.java file, modify its package directive,
and alter it at will.

If the OP is not willing to override BigInteger's methods with covariant
methods in the subclass, it seems unlikely they'd go through the at least as
large effort of replacing the class outright.

If they were willing to go through that effort, they could also consider
wrapping BigInteger in a class that delegates to appropriate methods.

 

[Arne Vajhøj]

You could always roll out your own class. Standard BigInteger happens
to be written in pure Java; source code is available through, for
instance, OpenJDK (and you can reuse it, provided that you comply
with the license, which is a kind of GPL-derivative). So you could
simple copy the BigInteger.java file, modify its package directive,
and alter it at will.

True.

But I think it would be bad practice.

Future changes to SUN BigInteger would need to be retrofitted
into the forked code.

Arne

 

[Dmitriy Melnik]

If the OP is not willing to override BigInteger's methods with covariant
methods in the subclass, it seems unlikely they'd go through the at least as
large effort of replacing the class outright.

If they were willing to go through that effort, they could also consider
wrapping BigInteger in a class that delegates to appropriate methods.

I've already considered delegating. But my new BigInteger is to be
used heavily. So invoking two methods instead of one could decrease
the speed.

 

[Lothar Kimmeringer]

The GMP package is very fast, and
has all sorts of methods useful for cryptography, but is written in C -
you'd have to write a wrapper using JNI, or else copy the java-GMP bridge
used in the Kaffe project.

AFAIR GMP was also used with SUN's Java until it was replaced
with a pure Java implementation with Java 1.2. So getting the
sources of Java 1.1/1.0 should be possible as well if you
want to reestablish the use of a C-Library instead of letting
the Hotspot do its job.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lew]

I've already considered delegating. But my new BigInteger is to be
used heavily. So invoking two methods instead of one could decrease
the speed.

By how much, exactly?

What percentage of overall processing time would that be, exactly?