[Maxima] stack size?

Thomas Widlar twidlar at yahoo.com
Fri Sep 5 14:15:50 CDT 2008


I sent my friend your answer about  enlarging the stack size, that stack 
size nor mally isn't the problem, that the problem is often elsewhere.

He sent me this.

> Tom,
>
> I ran the program for some hours and made some test output. The 
> program does not hang but proceeds very slowly because the expressions 
> to be calculated/simplified are really huge. I use the combination for 
> simplifying:
>
>  
>
> trigsimp(factor(ratsimp(f)))
>
>  
>
> Mainly there are 2 repeated error messages:
>
>  
>
> Maxima encountered a Lisp error:
>
>  
>
>  Error in MACSYMA-TOP-LEVEL [or a callee]: The storage for STREAM is 
> exhausted.
>
> Currently, 222 pages are allocated.
>
> Use ALLOCATE to expand the space.
>
>  
>
>  
>
> Maxima encountered a Lisp error:
>
>  
>
>  Error in PROGN [or a callee]: The storage for CONS is exhausted.
>
> Currently, 16881 pages are allocated.
>
> Use ALLOCATE to expand the space.
>
>  
>
>  
>
> The version I use is
>
> -------------------------------------------------------------
>
> Maxima version: 5.16.3
>
> Maxima build date: 22:48 8/24/2008
>
> host type: i686-pc-mingw32
>
> lisp-implementation-type: GNU Common Lisp (GCL)
>
> lisp-implementation-version: GCL 2.6.8
>
>  
>
I've asked him to isolate the code (20-40 line) causing his problem. He 
said it would try to do that but it would be easy.

Do these messages give us any clue as to what to look for?

Tom Widlar.

> From: Stavros Macrakis <macrakis at alum.mit.edu> 
> <mailto:macrakis at alum.mit.edu>
>
> The symptom you describe, running for a long time (perhaps an infinite 
> time?), is not a symptom of a stack overflow, so increasing the size 
> of the stack won't help.
>
> It could be that the calculation is intrinsically computationally 
> expensive, or that the algorithm being used is not efficient, or that 
> the algorithm is incorrect and is in an infinite loop, or that there 
> is a gross inefficiency or bug in some Maxima routine. There is no way 
> to know without actually seeing the problem.
>
> Without enough information to reproduce the problem, it is very hard 
> to give any useful advice. It often turns out that the problem is not 
> at all what the user thinks it is.  A good problem report includes the 
> following information:
>
>     * A clear procedure for reproducing the problem. Please verify
>       that your procedure actually re-creates the problem in a fresh
>       Maxima. If you can't reproduce it, still send it along, but try
>       to include as much information about what you did before. The
>       simpler and shorter the procedure, the better. It's always
>       appreciated when the discoverer of a bug narrows it down to a
>       simple case. Differentials are always good, too -- that is,
>       cases which are almost the same but DO work.
>     * The exact version number you're running under, as shown by
>       bug_report().
>
> In particular, the type of Lisp being used is very important for some 
> issues (e.g. behavior on stack overflow), but the CPU speed and memory 
> size are not usually relevant.
>
>              -s
>
> On Sun, Aug 31, 2008 at 5:26 PM, Thomas Widlar <twidlar at yahoo.com 
> <mailto:twidlar at yahoo.com>> wrote:
>
> A friend of mine asked this question.
>
>  If I remember right, the stack size is fixed and determined by the 
> Lisp subsystem. I have the problem that I cannot compute some 
> complicated metrics because Maxima hangs and eats up 99% of CPU time. 
> Probably the stack size is exhausted. Is a way to increase the stack? 
> Maybe by recompilation with a higher stack size?
>
> His setup is
>
>   Maxima 5.16.3, Windows distribution
>   running on Windows XP, SP 3
>   CPU: Pentium 4, 2.66 GHz  
>   Memory: 1 GB
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.math.utexas.edu/pipermail/maxima/attachments/20080905/23db0ebb/attachment-0001.htm 


More information about the Maxima mailing list