4 ms·
Coincidentally I was just writing a bignum library from scratch two weeks ago. A few interesting things I learned: 1. Knuth volume 2 has an extensive discussi
by haberman 2y ago
Coincidentally I was just writing a bignum library from scratch two weeks ago.
A few interesting things I learned:
1. Knuth volume 2 has an extensive discussion of the problem space. I've only gotten a chance to skim it so far, but it looks interesting and approachable.
2. I need to support bitwise operations, which operate on a two's complement representation, so I figured it would be simpler to use two's complement internally, despite seeing that most (all?) bignum libraries use signed magnitude. I'm starting to regret this: two's complement introduces a lot of complexity.
The most fun thing about working on a bignum library is that it makes the algorithms you learned in grade school for add/subtract/multiply/divide relevant again. The basic ("classical") algorithms on bignum are basically exactly the same thing you learned in grade school, except on a much larger base than base-10.
- vintermann 2y agoKnuth has a "hugenum" scheme, TCALC, which is based on trees rather than byte arrays. There are many ways to do it, depending on which type of numbers you need most - for TCALC, it's numbers close to towers of exponents. Of course for every big number encoding that can beat an array of bytes for some numbers, it also has to lose to byte arrays for some numbers... But it's possible to bound this inefficiency, so that it's never more than twice as bad as byte arrays, but potentially exponentially more efficient for the favoured numbers.
- lysp 2y agoTwice as bad being a timeout and 2nd call?
- vintermann 2y agoI don't quite get what you mean. Computation time is also bounded with the size of the tree.