Ticket #280 (closed RFC: fixed)

Opened 6 years ago

Last modified 6 years ago

BigNum PMC

Reported by: whiteknight Owned by: rurban
Priority: minor Milestone: 1.0
Component: core Version:
Severity: low Keywords:
Cc: Language:
Patch status: new Platform: all

Description

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.

Attachments

tt280-bignum-pmc.patch Download (56.7 KB) - added by rurban 6 years ago.

Change History

Changed 6 years ago by rurban

  • owner changed from whiteknight to rurban
  • status changed from new to assigned
  • patch set to new

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.

Changed 6 years ago by 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.

Changed 6 years ago by 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.

Changed 6 years ago by rurban

Changed 6 years ago by rurban

  • status changed from assigned to closed
  • resolution set to fixed

Applied this as r36765

  • bugs: stringification leaves the _mp_size at 3
  • todo:
    • overflow tests
    • bigint inheritence
    • more tests
    • op integration
Note: See TracTickets for help on using tickets.