--- Comment #3 from Don <> 2011-03-23 03:42:32 PDT ---
OK, although I don't think that the case with Ackermann code is so bad. It's
basically giving you a compile-time warning that the function blows up very,
very easily. Having seen this, it becomes obvious that the m=4 case will blow
up for n>2, and therefore that the m=5 will blow up for n>0, and the m>=6 will
blow up for any n. Since this only leaves a total of 4 cases, A(4,0) = 13,
A(4,1) = A(5,0) = 65533, and A(4,2), why not continue the optimization, and
eliminate the recursion entirely? So I think it encourages you to write better
quality code. I think it's quite bizarre to stop at m=3, so I don't find this
example convincing.

The thing I'm really worried about is this:
BigInt a, b, c;

a = (a ^^ b) % c;
This is an attempt to do modular exponentiation, which comes up frequently in
cryptography. The code is mathematically correct, but completely wrong in
So I would rather give an informative static assert for the BigInt ^^ BigInt
(Definitely, it shouldn't just fail the way it does now).

> How do I perform the equivalent of str(ackermann(4, 2)) with BigInt?

format("%d", ackermann(4,2))

>The bottom of this page shows a duplication to me:

You're right. A new ddoc bug.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to