On 05/01/2017 5:50 PM, Era Scarecrow wrote:
Well re-watched a video regarding the Ackermann function which is a heavily recursive code which may or may not ever give a result in our lifetimes. However relying on the power of memoize I quickly find that when the program dies (from 5 minutes or so) nearly instantly (and only using 9Mb of memory).long ack(long m, long n) { long ans; if (m == 0) ans = n + 1; else if (n==0) ans = ack(m-1, 1); // else ans = ack(m-1, ack(m, n-1)); // original else ans = memoize!ack(m-1, memoize!ack(m, n-1)); return ans; } This is only due to the limited stackframe space. Doing a search I find that the amount of stack space is decided on when the EXE is being compiled and in the EXE header but I'm not sure which one needs to be update (supposedly it's either 250k or 1Mb is the default), although neither help in this case, nor do the other binary tools as they don't recognize the binary format of D's exe output files) Alternatively if there's a way to tell the compiler a hint (either in D or in the compiling/linking flags) or the specific offset of which 32bit entry is the stack reserved space, I could continue my little unimportant side experiments. Suggestions? Comments?
Well, you could create a fiber[0]. Fibers allow you to set the stack size at runtime. [0] http://dlang.org/phobos/core_thread.html#.Fiber.this
