Re: [q-lang-users] Bug?

[Albert G. <Dr....@t-...>]

Hi Eddie,

the difference between your two definitions is that the first one
involves if-then-else (syntactic sugar for cond::ifelse), a special form
which has to evaluate its unevaluated arguments. The evaluation of those
arguments (the third one is the culprit here) is done by recursive
invokations of the interpreter's eval() function in qm.c. Those
recursive invokations need "real" C stack space, and apparently the C
runtime runs out of this much earlier than the Q machine exhausts its
own "virtual" stack space. (It's strange that this doesn't happen on
Cygwin but maybe it doesn't detect the hardware stack overflow there.)

You can verify this by reducing the Q stack size. Instead of the
segfault you then also get a Q stack overflow with the first definition:

==> stacksize 2000

==> fact 0.2
! Stack overflow
>>> fact 0.2
            ^

Note that your second definition doesn't involve a special form, hence
there are no recursive invokations of qm.c:eval() and the C stack
overflow doesn't happen.

I agree that this is in fact a bug, but to really fix that I'd have to
rewrite qm.c:eval() (which is actually a mutually recursive collection
of C functions) as a non-recursive function. I might be tempted to try
this some day, but I have to be in a really masochistic mood to even
think about it. ;-)

Instead I could also try to work on the stack overflow detection
heuristic in eval() (line 3515 in qm.c), but AFAIK there is *no*
portable way to reliably detect an imminent C stack overflow beforehand.
Or can anyone here prove me wrong and show me such a trick?

Cheers,
Albert

Eddie Rucker wrote:
> I made a mistake of using a real number .2 to a factorial function
> defined as
> 
> fact N = if N = 0 then 1 else N * fact (N-1);
> 
> and it gives a segment fault (on debian Linux). However, a factorial
> function defined as
> 
> fact 0 = 1;
> fact N = N * fact (N-1);
> 
> stack overflows which is what I would expect. Why the difference?

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag