unmaintainable-code VS gmp-wasm

Two thoughts:

* This is ridiculous. Why would you do this? Which made think of this quote: "Which is ridiculous and unnecessary but when has that ever stopped programmers?" from one of my favorite Tom Scott videos: https://www.youtube.com/watch?v=gocwRvLhDf8

* How to Write Unmaintainable Code: https://github.com/Droogans/unmaintainable-code

How to Write Unmaintainable Code is basically a must-read for any programmer in my opinion, even so many years later.

Oh my the defines. What is language and semantics?

Very ugly, ill-defined, uncodified democracy. No one tells you when you vote, no one counts up the votes, there are no official results.

When you speak or communicate with someone else, you are voting with them. "I vote this word means X, for a poor/crude/coarse agreement of what X is the first place."

And this is propaganda at its finest. Evil doublespeak: say one thing, and it actually is another. Snuck in.

Fantastic.

Related: https://github.com/Droogans/unmaintainable-code

May I anti-recommend (i.e. suggest you read so as not to follow the advice of it) this wonderfully written guide here on unmainable code.

How To Write Unmaintainable Code

There are "bignum" implementations for every language. Though I never tested the performance impact on closed-form Fibonacci when a defined double precision >64bit is used.

https://gmplib.org/

Your code has an accidentally quadratic runtime (instead of linear). Since the array is appended to, the code regularly increases the memory region and has to move all the previous data over.

You could pre-allocate the memory as n is known ahead.

The GMP library is useful https://gmplib.org/

I recently released Malachite 0.3.2, which includes new support for small prime generation, primorials, and binomial coefficients. How many primes can be represented by a u32? The answer is 203,280,221, and on my machine it takes 6.13 seconds to generate and count them using an iterator created via Malachite's Primes trait: u32::primes().count(). Alternatively, I can get the answer even faster, in 3.85 seconds, using u32::primes_less_than_or_equal_to(&u32::MAX).count()). The first iterator keeps creating larger and larger prime sieves as it goes, whereas the second creates a prime sieve of the right size immediately. It's the same tradeoff as between Vec::new and Vec::with_capacity. As usual, I followed GMP's implementations for primorials and binomial coefficients. The binomial coefficient implementation is pretty elaborate, using 6 algorithms depending on the input size. Some of the variable names in the GMP code are in Esperanto, just to make life a little more difficult. I did not carry this quirk over to Malachite. The next Malachite version will be 0.4.0, and will finally include (initially very limited) support for arbitrary-precision floats! Don't expect much arithmetic yet; I am first focusing on conversion to and from other numeric types (with correct rounding), and on comparison. I am ensuring that all operations give the same results as those implemented by MPFR, by very thoroughly testing against rug::Float.

Because, depending on the architecture, your unsigned long might not be long enough to hold 19!. A 64-bit unsigned long would be sufficient, but a 32-bit would not be. You could try uint64_t instead (use #include ), or, if that isn't sufficient, use an arbitrary-precision library like GMP.

If you don't want to deal with doing things by yourself, you could try GMP. It has a C++ interface and being GNU you can count on Cygwin to provide a .dlll (cyggmpxx-version.dll is the name) if you don't want to build it yourself.

I definitely suggest implementing fixnums with pointer tagging. It's fun and useful. To begin with, just signal an error on overflow, and then move on to actually implementing bignums once the basics work. Unless you specifically want to have zero dependencies, I'd use gmp for bignums, as it can be pretty tricky to implement by hand.

In C, the GMP library (aka GNU MP Bignum library) is the most well-known library in the domain. It offers unparalleled performance for arithmetic, at the cost of being fairly big.