BigNum PMC

[whiteknight]

I've been idly tinkering with creating a BigNum PMC. Due to a series of naming conflicts I'm going to have to delete src/bignum.c and bignum.h before I can really start testing it and maybe commit it.

I mentioned this on IRC yesterday, and chromatic said that it was redundant to have both a BigNum PMC and a BigInt PMC. If there is redundancy between them and we only wanted one, I say we should have a BigNum because it's more general, and we can ditch BigInt.

So here's the question: Is it worthwhile to write a BigNum PMC? If so, do we want to keep both BigNum and BigInt types separate? Input appreciated.

[rurban]

There are several totally unneeded bignum methods, probably copy & paste from bigint, like shl, shr, mod, fdiv. I disabled that.

This does not work yet!

It would be good to accept bigint PMC args for several methods. Like bignum = add(bignum,bigint), not only int, float and bignum.

[rurban]

Is it worthwhile to write a BigNum PMC?

• Sure. Having precise floating point arithmetics is a completely different goal to having precise exact numbers. With exact numbers (bigint) you can never represent ratios for example.

A defined extended precision representation for 1/3 or sin(3)/2 is impossible without BigNum.

[rurban]

Attached is a new patch which makes bignum work basically.

It accepts also bigint and long double arguments. (untested)

There are still two issues with stringification and overflows which I marked as TODO in the tests. Will add tickets for these if required.

Please comment the interface.

[rurban]

Applied this as r36765

• bugs: stringification leaves the _mp_size at 3
• todo:
  • overflow tests
  • bigint inheritence
  • more tests
  • op integration