Subject: Re: wanted! Lisp

Date: Sat, 07 Sep 1996 05:52:43 GMT
From: jeeper@halcyon.com (Dennis Shinn)
Organization: Northwest Nexus Inc.
Newsgroups: comp.cad.autocad,
Message-ID: <50r2uo$3c2@news2.halcyon.com>
References: 1, 2, 3, 4,

paul.suleski@pc-aug.com (Paul Suleski) wrote:

> Aw, c'mon, Dennis - you never answered my LAST question about
>what recursive is in the first place.

> I got tired of waiting, so I looked it up. It refers to a
>routine that repeats itself until stopped, or until a predefined
>limit is reached.

Nuh-uh .....

Sorry for the delay but we had a Labor Day weekend that eclipses the camping trip you described in the PCGNet echoes .... more on that via PCGNet if you're interested.

Now back to our regularly scheduled programming.

Recursive does indeed imply repetition but with a catch: A recursive function "calls" itself rather than simply repeating itself. It calls itself from within the initial program call. Thus for each repitition there is another "call" to the original function.

Let's take a simple function like calculating the factorial of any number. Not that's "any" number, to be specified by the user at the first program call. Meaning, of course, the user must have the opportunity to enter any number she wishes to calculate.

(defun fact (n) (cond ((zerop n) 1) (T (* n (fact (1- n)))) ) )

We'll take each step at a time to explain how this works.

(defun fact (n)
~~~~~~~~~

This is the basic function definition within AutoLISP. Essentially it says "DEfine <the> FUNction "fact" to accept the symbol "n" which is enclosed in the parenthisese. This is a 'parameter' to the function. We can pass parameters to AutoLISP functions in that it is, after all a programming language. Script files are defined, of course, but must be called with another command, the SCRIPT command that tells AutoCAD to perform the steps outlined within the file. So far we're pretty neck & neck.

(cond ....
~~~~~~

A programming language, to be worth of the name must have 'decision making' powers. It must be able to examine a situation, symbol value, or user input and decide on some action to take. The action is, of course, more or less determined by the programmer but nevertheless, it opens up a pretty wide spectrum of options. I think this might nudge me ahead just a touch.

In our case, we examine the value held in the symbol 'n', the parameter to the function. We test the value to see if it's 0. (now before you or anyone calls me on this one, I realize that entering 0 returns 1 which is not possible. Factorial 0 doesn't count in this example! (g))

Since the first time through our journey, n is greater than 0, the first conditional test fails and we drop to the second:

(T (* n (fact (1- n))))
~~~~~~~~~~~~~

(T), the AutoLISP shorthand for 'True', always evaluates to True, of course so we take this another journey departing for a moment from our primary course. But what's this?? We make yet another decision since we meet ourselves coming around the corner. Here's our old friend (fact) again asking the question, is (1- n), that is the value of our symbol 'n' less 1, is this now 0? Given that we've entered a number greater than 1 (or 0 which doesn't count! hehehe) then (1- n) EVALUATES to non-nil when subjected to the (zerop n) function. As this test is conducted within another complete call to the (fact) function, it is said to "recurse" or call itself in it's entirety.

Now ... the function actually takes some real action as we return through the recursions back to the top level. You see, Paul, we've never left the original call to (fact). Each time it occurs within the initial call, it "recurses" one level for each increment of the parameter we've supplied. So a true recursive function must "back out" to make the return trip. On it's way back to the top level is when the real work is done.

You can see how this works by turning the (trace) function on before you run this little routine. At the Command: line in an AutoCAD session, enter:

	(trace <function_name>)

to trace recursion or otherwise de-bug AutoLISP routines. I realize you have little use for parenthises but humor me on this one. Enter:

	(trace fact)

Now clip the (fact) function into Notepad or something and save it as fact.lsp. At the command line, enter (load "d:\\<dir>\\fact")

where d: is the drive and <dir> is the dirctory of where you saved fact.lsp.

Now at the Command: line enter (fact 5), or any other number you wish. (be careful .... large numbers can and will exhaust the stack and cause an error).

What you will see is something similar to:

    
Command: (fact 5) Entering FACT: 5 Entering FACT: 4 Entering FACT: 3 Entering FACT: 2 Entering FACT: 1 Entering FACT: 0 Result: 1 Result: 1 Result: 2 Result: 6 Result: 24 Result: 120 120

So as this illustrates, recursion isn't something as simple as repetition, Paul. It involves three basic steps to compete a recursive journey:

Find out how to take a single step. We decided to find out if the function paramter was equal to 0. In our conditional test case, if it isn't 0 then -

Break the journey down into a yet smaller journey. We call (fact again only we use a smaller number, one less than the original parameter until -

Know when to stop. Which in the case at hand, we run out of numbers and n=0.

We could write the same thing another way to illustrate another advantage of a true programming language, itteration:

(defun fact2 (n) (SetQ x 1 y 1) (Repeat (1- n) (SetQ x (1+ x) y (* x y) ) ) )

First we define the function as in the first instance with the DEfine FUNction built in form. Next -

  (SetQ x 1  y 1)
~~~~~~~~~~

we initialize our symbols to insure that they are the correct value.

 (Repeat (1- n)
~~~~~~~~~~

We now repeat a set of steps for a specific number of times defined by the number entered as the PARAMETER to the function. Since the factorial operation involves the number of numbers to be multiplied less 1 we can perform this CALCULATION within our function.

(SetQ  x (1+ x) y (* x y))
~~~~~~~~~~~~~~~

Now we do the MATH. During each itteration of this statement, x becomes incrementally larger by a value of 1 and y is incremented as the product of itself and the next larger value of x etc., etc.

Note - in this case, without ERROR TRAPPING which is a nice feature of a programming language, both 0 and 1 are undefined since neither allow the itteration to happen; the repeat simply doesn't repeat. But for the purpose of illustrating the advantage(s) of using a true programing language to perform true recursion and itteration, the point is made.

> You can make a SCRIPT interactive by using the "pause for user
>entry" feature.

I will confess that on this point I've searched my docs and find nothing that references pausing for user input. By user input I mean something beyond a menu selection, coordinate point or osnap selection using the pointing device; rather something along the lines of :

(setq yourname (getstring "\nWhat is your name...? " t))

which woul allow the user to enter a string including a space between first and last names and hold that value in order to do something like

(Prompt (StrCat "Hi there " yourname))

But then STRING CONCATONATION isn't something easily done except in a true programming language.

> You can make it recursive by making the last line
>read "SCRIPT scriptname."

By now it should be fairly clear that repeating a script isn't quite the true definition of recursion. I don't expect you to accept that, of course but you might accept one small bit of advice and instead of calling the script by name again which isn't too efficient, just use the RSCRIPT statement instead. You see, Paul, I use scripts exctensively in my work as well. I have hordes of layer management and plotting scripts that I will go to the matt with anyone who argues against their use. But you asked me once to challenge you to do something in AutoLISP that you couldn't do by using script. Frankly I think this whole arguement is no less silly than the first time we got into it back in the echoes, but do this for me.

Given a list of numbers, any list in any form you chose, write a script that will return "T" if any one of the numbers is odd and "NIL" if none of them are odd. Just to prove it can be done in LISP:

(defun anyoddp (n) (Cond ((null n) nil) ((/= 0 (rem (car n) 2)) t) (T (anyoddp (cdr n)))))

Here is the results of two runs:

Command: (anyoddp '(2 4 6 8)) Entering ANYODDP: (2 4 6 8) Entering ANYODDP: (4 6 8) Entering ANYODDP: (6 8) Entering ANYODDP: (8) Entering ANYODDP: nil Result: nil Result: nil Result: nil Result: nil Result: nil nil

Command: (anyoddp '(2 4 6 8 9)) Entering ANYODDP: (2 4 6 8 9) Entering ANYODDP: (4 6 8 9) Entering ANYODDP: (6 8 9) Entering ANYODDP: (8 9) Entering ANYODDP: (9) Result: T Result: T Result: T Result: T Result: T T 

Peace, my friend.

Dennis Shinn
Seattle AutoCAD User Group
SAUG-BBS [206] 644-7115 [PCGNet]9:517/215
    Anatech Systems
    Construction Detailing
    3D modeling support for the construction industry
        http://www.halcyon.com/jeeper 
email: jeeper@halcyon.com

From fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!01-newsfeed.univie.ac.at!swidir.switch.ch!in2p3.fr!univ-lyon1.fr!howland.erols.net!cam-news-hub1.bbnplanet.com!www.nntp.primenet.com!nntp.primenet.com!uucp.primenet.com!aug!paul.suleski Wed Sep 11 10:56:45 1996 Path: fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!01-newsfeed.univie.ac.at!swidir.switch.ch!in2p3.fr!univ-lyon1.fr!howland.erols.net!cam-news-hub1.bbnplanet.com!www.nntp.primenet.com!nntp.primenet.com!uucp.primenet.com!aug!paul.suleski From: paul.suleski@pc-aug.com (Paul Suleski) Newsgroups: comp.cad.autocad Subject: Re: wanted! Lisp Date: Sat, 7 Sep 1996 14:02:00 GMT Message-ID: <96090709001212632@pc-aug.com> Organization: The Phoenix Chapter AutoCAD Users Group Distribution: world References: <50r2uo$3c2@news2.halcyon.com> <505c3f$oc8@news.halcyon.com> <4vt91o$qil@dfw-ix Lines: 412

Excellent tutorial, Dennis! I actually understand every word of it (thanks to your clear, precise writing) and think it's worth repeating, so I'm quoting its entirety below. I appreciate the patience and time you put into the effort.

You're right on with the recursive explanation, although I'd hesitate to call our original dialog a silly argument. It's more like the argument my wife and I had in the vein of "tell me what you can do that I can't." My smart-alec answer was, of course, "father a child."

My challenge, if I'd taken the thought to be precise, should have contstrained the "do" to "drawing automation," not just any old function. I don't know that I'd ever want to do any function as recursively as a factorial calculation, or odd/even determination.

My challenge was on the order of "make a drawing."

Your response is on the order of "make a drawing the way I do."

Maybe I do, maybe I don't - I say it this way, because I can point to where I do use a recursive routine. It's in my SCRIPT generator program, written in dBASE. Aha! you say - so you can't do it in SCRIPT. Well, yes, I can. I just wouldn't like doing it, for it would take much to long, and would break my Rule #2 for using computers: Make the computer to the dumb work.

I'm referring to the breakthrough I made several years ago in drawing helical shapes using REVSURF to generate a conveyor frame from a polyline cross-section, then usind PEDIT to MOVE the vertices into correct position along the z-axis. It was that the tech support people at Autodesk, CATIA, UNIGRAPHICS, and CADD said couldn't be done without "bringing down the house." Their problem was attempting to do the task as simultaneous radial/axial calculations with unrestrained resolution (attempting to generate a smooth curve) whereas my method takes a far simpler approach, producting acceptable results. The "recursive" part was selecting which vertex to move from an unpredictable number of vertices.

My comment regarding "user input pause" may be confusing DIESEL for menus with SCRIPT; but, I don't think it's worth looking up at this point. I think it's appropriate to concede LISP has functions absent from SCRIPT; however, I maintain, that the two are equivalent when it comes to producing drawing data. I wouldn't even try to argue which is more efficient at this point, except for the difference between inserting a predrawn block vs. generating one with a LISP routine (and while percentages may always favor the former, today's cpu speeds make the difference moot).

Years ago, I departed from the mainstream of AutoCAD application development because I wanted instant gratification to integrate AutoCAD with a database. At that time, the combination of SCRIPT and dBASE (could also have done it with Lotus123/QUATTRO PRO - my first professional career programming languages after Fortran IV, but that's another story). Now I do it that way so easily, it'll take much more than a crowbar to get me to change (yet, I did switch to Windows, eventually NT, didn't I?).

If ever I switch to using AutoLISP, there'll be one thing certain: It's all your fault.

8-)

BTW, I want to reply quickly, so I won't puzzle out your last challenge, but I can outline my solution method: CHEAT. It's how I solve all of my "missions impossible" - the ones everybody else has given up on (especially programmers). I would pass your list of numbers to a batch file in a shell command such as SH ODDEVEN 2 4 6 8 9 That would be the input to ODDEVEN.BAT which then evaluates 2, 4, 8, 8, 9 in turn as %1, %2, %3, etc. I'd use the SHIFT feature to move each number into %1 position to evaluate as a label (as in GOTO 2) target. The program would then go to :2 of the batch file and execute ECHO 2 IS EVEN>>EVAL.TXT.

When the batch file finishes its run, it returns to the next line of the script, which would import the file EVAL.TXT into the current drawing (or open a new, specific drawing for that purpose). The result would be:

    2 IS EVEN
    4 IS EVEN
    6 IS EVEN
    8 IS EVEN
    9 IS ODD

I could expand this to any size numbers, using the batch file in turn to call a QBASIC program which would parse a number of any size, evaluating only the last digit and appending the result to the EVAL.TXT file, etc.

In this manner, I would have a more general routine than simply calling all numbers ODD even if only one of them is. ;)

When problem solving, the GOAL is more important than the METHOD, and in some circumstances, the first solution is the right one, allowing you to progress to the next problem rather than waste time seeking the BEST solution (as "it's OK to pee in public to put out a small fire rather than wait for the firetruck while half the house goes up in flames.").

>From: jeeper@halcyon.com (Dennis Shinn)
>Subject: Re: wanted! Lisp >
>paul.suleski@pc-aug.com (Paul Suleski) wrote: >
>> Aw, c'mon, Dennis - you never answered my LAST question about
>>what recursive is in the first place. >

___ * UniQWK v4.2 * The Windows Mail Reader

From fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!news.ecrc.de!news.compuserve.com!chi-news.cic.net!news.math.psu.edu!news3.cac.psu.edu!howland.erols.net!newsxfer2.itd.umich.edu!netnews.worldnet.att.net!newsadm Wed Sep 11 10:58:08 1996 Path: fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!news.ecrc.de!news.compuserve.com!chi-news.cic.net!news.math.psu.edu!news3.cac.psu.edu!howland.erols.net!newsxfer2.itd.umich.edu!netnews.worldnet.att.net!newsadm From: "Tony Tanzillo" <tony.tanzillo@worldnet.att.net> Newsgroups: comp.cad.autocad Subject: Re: wanted! Lisp Date: 9 Sep 1996 04:20:09 GMT Organization: Design Automation Consulting Lines: 94 Message-ID: <01bb9e05$fb62c580$842d46c7@pentiumpro> References: <50r2uo$3c2@news2.halcyon.com> <505c3f$oc8@news.halcyon.com> <4vt91o$qil@dfw-ix <96090709001212632@pc-aug.com> NNTP-Posting-Host: 132.newark-2.nj.dial-access.att.net X-Newsreader: Microsoft Internet News 4.70.1155

Paul Suleski <paul.suleski@pc-aug.com> wrote in article <96090709001212632@pc-
>
> I'm referring to the breakthrough I made several years ago in
> drawing helical shapes using REVSURF to generate a conveyor frame
> from a polyline cross-section, then usind PEDIT to MOVE the
> vertices into correct position along the z-axis. It was that the
> tech support people at Autodesk, CATIA, UNIGRAPHICS, and CADD said
> couldn't be done without "bringing down the house."

I really don't understand this comment. "Breakthrough"? What is it that you did? I've written a number of AutoLISP programs that generate helical extrusions (as a series of one or more polyface or polygon mesh objects), and this was way back when AutoCAD was first capable of 3D objects.

I'm not sure what tech support people at Autodesk told you this can't be done, but I can tell you that the people I know at Autodesk who were doing tech support back then, certainly would not have told you this.

> was attempting to do the task as simultaneous radial/axial
> calculations with unrestrained resolution (attempting to
> generate a smooth curve) whereas my method takes a far simpler
> approach, producting acceptable results. The "recursive" part was
> selecting which vertex to move from an unpredictable number of vertices.

So, can we interpret this as implying that you invented the process of "tesselation" or faceting? I don't think your figuring out how to automate the creation of a helical construct in AutoCAD using a script file qualifies as a "breakthrough". Not even close.

> My comment regarding "user input pause" may be confusing DIESEL
> for menus with SCRIPT; but, I don't think it's worth looking up at
> this point. I think it's appropriate to concede LISP has functions
> absent from SCRIPT; however, I maintain, that the two are
> equivalent when it comes to producing drawing data.

This is pure horseshit. Any day, any where, any time, I will gladly demonstrate to how I can code circles around you with AutoLISP. With AutoLISP. I can easily make AutoCAD do things that you can never do by playing back keystrokes (E.G., scripts).

If you don't mind my saying, you are trying to defend the indefenceible.

> I wouldn't
> even try to argue which is more efficient at this point, except for
> the difference between inserting a predrawn block vs. generating
> one with a LISP routine (and while percentages may always favor the
> former, today's cpu speeds make the difference moot).

I don't understand what you mean by this. Blocks are statically- defined objects that cannot have variable parameters from one instance to the next. There is no analogy between parametriclly-driven objects and statically-defined blocks. The fact that parametrically-driven objects are created in the form of BLOCK insertions in AutoCAD is merely because that is the most-convenient way to do it.

> Years ago, I departed from the mainstream of AutoCAD
> application development because I wanted instant gratification to
> integrate AutoCAD with a database. At that time, the combination
> of SCRIPT and dBASE (could also have done it with Lotus123/QUATTRO
> PRO - my first professional career programming languages after
> Fortran IV, but that's another story). Now I do it that way so
> easily, it'll take much more than a crowbar to get me to change
> (yet, I did switch to Windows, eventually NT, didn't I?).

I've done much intergration of AutoCAD and databases, and I didn't have to depart from the "mainstream of AutoCAD application development" in order to do this.

Personally, I think you're hiding behind your lack of understanding of the AutoLISP language, or at least, that's the impression that I get by how many hoops you seem willing to jump through to achieve what would be considered childs play to the average AutoLISP hacker.

-TonyT.

-- 
/*******************************************************/ 
/*   Tony Tanzillo     Design Automation Consulting    */
/*    Expert AutoCAD Programming and Customization     */
/* --------------------------------------------------- */
/*      Co-Author of Maximizing AutoCAD R13 and        */
/*        Maximizing AutoLISP for AutoCAD R13          */
/* --------------------------------------------------- */
/*       Contributing Author  CADENCE Magazine         */
/* --------------------------------------------------- */
/*             71241.2067@compuserve.com               */
/*           tony.tanzillo@worldnet.att.net            */
/*   http://ourworld.compuserve.com/homepages/tonyt    */
/*******************************************************/

From fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!newsfeed.sunet.se!news01.sunet.se!sunic!surfnet.nl!howland.erols.net!newsfeed.internetmci.com!in1.uu.net!nwnews.wa.com!news2.halcyon.com!usenet Wed Sep 11 10:59:25 1996 Path: fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!newsfeed.sunet.se!news01.sunet.se!sunic!surfnet.nl!howland.erols.net!newsfeed.internetmci.com!in1.uu.net!nwnews.wa.com!news2.halcyon.com!usenet From: jeeper@halcyon.com (Dennis Shinn) Newsgroups: comp.cad.autocad Subject: Re: wanted! Lisp Date: Mon, 09 Sep 1996 07:37:26 GMT Organization: Northwest Nexus Inc. Lines: 125 Message-ID: <510hqr$8mo@news2.halcyon.com> References: <50r2uo$3c2@news2.halcyon.com> <505c3f$oc8@news.halcyon.com> <4vt91o$qil@dfw-ix <96090709001212632@pc-aug.com> NNTP-Posting-Host: blv-pm0-ip2.halcyon.com 

Thanks for taking it in the spirit in which it was offered, Paul. As you know, I'm every bit an advocate of whatever it takes to get the job done as you are. With respect to recursion, that little effort was in fact an excuse to get closer to the real meaning for myself as for anyone. This is, in fact, what I've always appreciated about the on line discussion. The more questions we answer or search to find the answers ourselves, the more we learn in return.

I suspect the only thing that separates those of us who make an effort to answer questions from those who ask them is perhaps knowing the right place to look for a solution.

paul.suleski@pc-aug.com (Paul Suleski) wrote:

>(thanks to your clear, precise writing)

Spelling errors and all? (grin) One of these days I'll learn to use the spell chucker in this news reader.

> ....., although I'd
>hesitate to call our original dialog a silly argument.

Silly insofar as we both let it get the best of us. This exchange has been, for me at least, far more fruitful.

> My challenge, if I'd taken the thought to be precise, should
>have contstrained the "do" to "drawing automation," not just any
>old function.

I'll take that into consideration in my next challenge! (grin)

> I don't know that I'd ever want to do any function
>as recursively as a factorial calculation, or odd/even determination.

I thought about using the fibonacci series to perform an infinte recursion but thought better about it. My reference for my research into this question, BTW was "LISP", A Gentle Introduction to Symbolic Computation by David S. Touretzky. While this book deals with common lisp as opposed to AutoLISP, the principles are the same. In fact, since AutoLISP has no built-in function as does common lisp for the form (oddp x) to determine the oddness of a number I had to actually devise my own recursive call using the (rem) function in AutoLISP in order to determine if a number was even (rem x)=0 or odd (rem x)/=0.

It was fun and I thank you for the opportunity to put on the old thinking cap again.

> Your response is on the order of "make a drawing the way I do."

I woudln't wish that on anyone.

> Aha! you say - so you can't
>do it in SCRIPT.

It really makes no difference, Paul. If we both get our work done in with the least amount of effort, and it's right when we're done, that's the main thing.

> Make the computer to the dumb work.

Amen!

> My comment regarding "user input pause" may be confusing DIESEL
>for menus with SCRIPT; but, I don't think it's worth looking up at
>this point.

If you do run across it I would seriously like to know how you go about it. In my scripts I've always relied on a companion AutoLISP function to handle user input and decision making. So in effect, I, too, use a hybrid system much like yourself. Whereas you use the coding aspect of dbase, I use AutoLISP.

I guess we're in a tie race after all! (g)

> I think it's appropriate to concede LISP has functions
>absent from SCRIPT; however, I maintain, that the two are
>equivalent when it comes to producing drawing data.

Ummmm welllllll ............

Nah - I'll save that for later (hehehe)

> I wouldn't
>even try to argue which is more efficient at this point, except for
>the difference between inserting a predrawn block vs. generating
>one with a LISP routine .....

We'll use this for another thread as well! (har-har)

> If ever I switch to using AutoLISP, there'll be one thing
>certain: It's all your fault.

That would take all the fun out of it!

> , but I can outline my solution method: CHEAT.

It's whatever it takes to get the job done. I could probably re-claim half the space on one of my drives here at home if I eliminated all the batch files but then I'd be stuck with a lot of manual dumb stuff and as you said, I'll leave that for the confuser to do. Writing batch files is quickly becoming a dieing art I'm afraid. How does it feel to be a dinasour? (grin)

> In this manner, I would have a more general routine than simply
>calling all numbers ODD even if only one of them is. ;)

All (anyoddp) was asked to do is report if one of the numbers in the list were odd. Since there was one, each result was T.

> When problem solving, the GOAL is more important than the
>METHOD, I.....

This is something that amazes me about some of the questions asked in this group. I mean we see questions asking for an AutoLISP routine to do something that can be done with basic Acad commands directly at the command line. I would have to agree that too often we put METHOD ahead of GOAL.

Dennis Shinn Seattle AutoCAD User Group SAUG-BBS [206] 644-7115 [PCGNet]9:517/215 Anatech Systems Construction Detailing 3D modeling support for the construction industry http://www.halcyon.com/jeeper email: jeeper@halcyon.com

From fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!newsfeed.sunet.se!news00.sunet.se!sunic!news.sprintlink.net!news-peer.sprintlink.net!cs.utexas.edu!howland.erols.net!news-peer.gsl.net!news.gsl.net!news.mathworks.com!uunet!in2.uu.net!nwnews.wa.com!news2.halcyon.com!usenet Wed Sep 11 11:00:17 1996
Path: fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!newsfeed.sunet.se!news00.sunet.se!sunic!news.sprintlink.net!news-peer.sprintlink.net!cs.utexas.edu!howland.erols.net!news-peer.gsl.net!news.gsl.net!news.mathworks.com!uunet!in2.uu.net!nwnews.wa.com!news2.halcyon.com!usenet
From: jeeper@halcyon.com (Dennis Shinn)
Newsgroups: comp.cad.autocad
Subject: Re: wanted! Lisp
Date: Tue, 10 Sep 1996 03:27:57 GMT
Organization: Northwest Nexus Inc.
Lines: 39

paulk2@seanet.com (Paul Kohut) wrote:

>Pardon me for jumping in here, I've been gone for a few
>weeks and just caught this thread. How you doing Dennis?

I was hoping you or Tony or Reini or ... someone with far more knowlege of recursion would pop in here since all I know of it is what I've read and discussed with Roy at our AutoLISP SIG meetings. Frankly I'm not sure when and why I would ever need to write a truly recursive function but it's fascinating none the less.

As to how I'm doing, drop in on the PCGNet echoes - I don't think it's appropriate to squander bandwith in here to discuss my car problems (g)

>As far as Dennis's comments about recursion and the stack, using
>some custom stack managment routines you can solve the problems
>that he was talking about.

There are a few other problems associated with the (fact) function that don't relate necessarily to AutoLISP (as far as I know. Perhaps Tony can clarify). For kicks I decided to run (fact 100). It only took 30 levels to the point where my 486 laptop began to slow appreciably. The suprisingly enough on the way out - where the calculations are really done, when it got to the 16th level (coming out, now) the numbers became negative. For whatever reason, factorial 16 or 17 and beyond yield negative numbers.

Haven't tried in on the big box to see if it's a memory thing. Anyone have an idea why this is so?

Dennis Shinn
Seattle AutoCAD User Group
SAUG-BBS [206] 644-7115 [PCGNet]9:517/215
    Anatech Systems
    Construction Detailing
    3D modeling support for the construction industry
        http://www.halcyon.com/jeeper 
email: jeeper@halcyon.com

From fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!news.ecrc.de!news.compuserve.com!ix.netcom.com!netnews.worldnet.att.net!newsadm Wed Sep 11 11:00:52 1996 Path: fstgal00.tu-graz.ac.at!03-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!news.ecrc.de!news.compuserve.com!ix.netcom.com!netnews.worldnet.att.net!newsadm From: "Tony Tanzillo" <tony.tanzillo@worldnet.att.net> Newsgroups: comp.cad.autocad Subject: Re: wanted! Lisp Date: 10 Sep 1996 10:52:03 GMT Organization: Design Automation Consulting Lines: 80 Message-ID: <01bb9f05$e7290a60$3d2c46c7@pentiumpro> References: <50r2uo$3c2@news2.halcyon.com> <505c3f$oc8@news.halcyon.com> <4vt91o$qil@dfw-ix <96090709001212632@pc-aug.com> <5104dp$1l3@kaleka.seanet.com> <512nj0$iqq@news2.halcyon.com> NNTP-Posting-Host: 61.newark-1.nj.dial-access.att.net X-Newsreader: Microsoft Internet News 4.70.1155

I'm not sure why FACT was returning negative numbers, but the depth of recursion is dependent on several factors, including what is on the stack when you enter the function initially (testing at the command prompt is not realistic if the recursive function is being called deep from within another program which will also be using the stack).

The second factor is the function's local environment (both arguments and local variables). For each recursion, a copy of the local environment is put on the stack, so you can go deeper if you eliminate all unnecessary locals from the recursive function's body.

-- 
/*******************************************************/ 
/*   Tony Tanzillo     Design Automation Consulting    */
/*    Expert AutoCAD Programming and Customization     */
/* --------------------------------------------------- */
/*      Co-Author of Maximizing AutoCAD R13 and        */
/*        Maximizing AutoLISP for AutoCAD R13          */
/* --------------------------------------------------- */
/*       Contributing Author  CADENCE Magazine         */
/* --------------------------------------------------- */
/*             71241.2067@compuserve.com               */
/*           tony.tanzillo@worldnet.att.net            */
/*   http://ourworld.compuserve.com/homepages/tonyt    */
/*******************************************************/

Dennis Shinn <jeeper@halcyon.com> wrote in article <512nj0$iqq@news2.halcyon.com>...
> paulk2@seanet.com (Paul Kohut) wrote:
>
> >Pardon me for jumping in here, I've been gone for a few
> >weeks and just caught this thread. How you doing Dennis?
>
> I was hoping you or Tony or Reini or ... someone with far more knowlege of
> recursion would pop in here since all I know of it is what I've read and
> discussed with Roy at our AutoLISP SIG meetings. Frankly I'm not sure when and
> why I would ever need to write a truly recursive function but it's fascinating
> none the less.
>
> As to how I'm doing, drop in on the PCGNet echoes - I don't think it's
> appropriate to squander bandwith in here to discuss my car problems (g)
>
> >As far as Dennis's comments about recursion and the stack, using
> >some custom stack managment routines you can solve the problems
> >that he was talking about.
>
> There are a few other problems associated with the (fact) function that don't
> relate necessarily to AutoLISP (as far as I know. Perhaps Tony can clarify). For
> kicks I decided to run (fact 100). It only took 30 levels to the point where my
> 486 laptop began to slow appreciably. The suprisingly enough on the way out -
> where the calculations are really done, when it got to the 16th level (coming
> out, now) the numbers became negative. For whatever reason, factorial 16 or 17
> and beyond yield negative numbers.
>
> Haven't tried in on the big box to see if it's a memory thing. Anyone have an
> idea why this is so?
>
>
> Dennis Shinn
> Seattle AutoCAD User Group
> SAUG-BBS [206] 644-7115 [PCGNet]9:517/215
> Anatech Systems
> Construction Detailing
> 3D modeling support for the construction industry
> http://www.halcyon.com/jeeper
> email: jeeper@halcyon.com
>

Comments