Subject: Re: wanted! Lisp

Date: Sat, 07 Sep 1996 05:52:43 GMT
From: jeeper@halcyon.com (DennisShinn)
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 thecamping trip you described in the PCGNet echoes .... more on that via PCGNet ifyou're interested.

Now back to our regularly scheduled programming.

Recursive does indeed imply repetition but with a catch: A recursivefunction "calls" itself rather than simply repeating itself. It callsitself from within the initial program call. Thus for each repitition there isanother "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 firstprogram call. Meaning, of course, the user must have the opportunity to enterany 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' tothe function. We can pass parameters to AutoLISP functions in that it is, afterall a programming language. Script files are defined, of course, but must becalled with another command, the SCRIPT command that tells AutoCAD to performthe 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 anddecide on some action to take. The action is, of course, more or lessdetermined by the programmer but nevertheless, it opens up a pretty widespectrum 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 tothe function. We test the value to see if it's 0. (now before you or anyonecalls me on this one, I realize that entering 0 returns 1 which is notpossible. Factorial 0 doesn't count in this example! (g))

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

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

(T), the AutoLISP shorthand for 'True', always evaluates to True, of courseso 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 comingaround 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 thatwe'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 thistest is conducted within another complete call to the (fact) function, it issaid to "recurse" or call itself in it's entirety.

Now ... the function actually takes some real action as we return throughthe recursions back to the top level. You see, Paul, we've never left theoriginal call to (fact). Each time it occurs within the initial call, it"recurses" one level for each increment of the parameter we'vesupplied. So a true recursive function must "back out" to make thereturn 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 yourun 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 havelittle use for parenthises but humor me on this one. Enter:

	(trace fact)

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

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

Now at the Command: line enter (fact 5), or any other number you wish. (becareful .... 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: 24Result: 120120

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 functionparamter 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 onlywe 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 andn=0.

We could write the same thing another way to illustrate another advantageof 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 DEfineFUNction 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 thenumber entered as the PARAMETER to the function. Since the factorial operationinvolves the number of numbers to be multiplied less 1 we can perform thisCALCULATION within our function.

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

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

Note - in this case, without ERROR TRAPPING which is a nice feature of aprogramming language, both 0 and 1 are undefined since neither allow theitteration to happen; the repeat simply doesn't repeat. But for the purpose ofillustrating the advantage(s) of using a true programing language to performtrue 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 nothingthat references pausing for user input. By user input I mean something beyond amenu 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 firstand 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 trueprogramming 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 thetrue definition of recursion. I don't expect you to accept that, of course butyou might accept one small bit of advice and instead of calling the script byname 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 oflayer management and plotting scripts that I will go to the matt with anyonewho argues against their use. But you asked me once to challenge you to dosomething in AutoLISP that you couldn't do by using script. Frankly I thinkthis whole arguement is no less silly than the first time we got into it backin the echoes, but do this for me.

Given a list of numbers, any list in any form you chose, write a scriptthat 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: nilResult: nilnil

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

Peace, myfriend.

Dennis ShinnSeattle AutoCAD User GroupSAUG-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

Excellent tutorial, Dennis! I actually understand every word of it (thanksto your clear, precise writing) and think it's worth repeating, so I'm quotingits 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 tocall our original dialog a silly argument. It's more like the argument my wifeand I had in the vein of "tell me what you can do that I can't." Mysmart-alec answer was, of course, "father a child."

My challenge, if I'd taken the thought to be precise, should havecontstrained the "do" to "drawing automation," not just anyold function. I don't know that I'd ever want to do any function as recursivelyas 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 whereI do use a recursive routine. It's in my SCRIPT generator program, written indBASE. Aha! you say - so you can't do it in SCRIPT. Well, yes, I can. I justwouldn'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 drawinghelical shapes using REVSURF to generate a conveyor frame from a polylinecross-section, then usind PEDIT to MOVE the vertices into correct positionalong the z-axis. It was that the tech support people at Autodesk, CATIA,UNIGRAPHICS, and CADD said couldn't be done without "bringing down thehouse." Their problem was attempting to do the task as simultaneousradial/axial calculations with unrestrained resolution (attempting to generatea smooth curve) whereas my method takes a far simpler approach, productingacceptable results. The "recursive" part was selecting which vertexto move from an unpredictable number of vertices.

My comment regarding "user input pause" may be confusing DIESELfor 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 producingdrawing data. I wouldn't even try to argue which is more efficient at thispoint, except for the difference between inserting a predrawn block vs.generating one with a LISP routine (and while percentages may always favor theformer, today's cpu speeds make the difference moot).

Years ago, I departed from the mainstream of AutoCAD applicationdevelopment because I wanted instant gratification to integrate AutoCAD with adatabase. At that time, the combination of SCRIPT and dBASE (could also havedone it with Lotus123/QUATTRO PRO - my first professional career programminglanguages after Fortran IV, but that's another story). Now I do it that way soeasily, it'll take much more than a crowbar to get me to change (yet, I didswitch to Windows, eventually NT, didn't I?).

If ever I switch to using AutoLISP, there'll be one thing certain: It's allyour 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 ina shell command such as SH ODDEVEN 2 4 6 8 9 That would be the input toODDEVEN.BAT which then evaluates 2, 4, 8, 8, 9 in turn as %1, %2, %3, etc. I'duse the SHIFT feature to move each number into %1 position to evaluate as alabel (as in GOTO 2) target. The program would then go to :2 of the batch fileand execute ECHO 2 IS EVEN>>EVAL.TXT.

When the batch file finishes its run, it returns to the next line of thescript, which would import the file EVAL.TXT into the current drawing (or opena 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 tocall a QBASIC program which would parse a number of any size, evaluating onlythe 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 allnumbers ODD even if only one of them is. ;)

When problem solving, the GOAL is more important than the METHOD, and insome circumstances, the first solution is the right one, allowing you toprogress 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 forthe 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. >

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 isit that you did? I've written a number of AutoLISP programs that generatehelical extrusions (as a series of one or more polyface or polygon meshobjects), 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 bedone, but I can tell you that the people I know at Autodesk who were doing techsupport 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 ofvertices.

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

> My comment regarding "user input pause" may be confusingDIESEL
> 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 gladlydemonstrate 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 backkeystrokes (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- definedobjects that cannot have variable parameters from one instance to the next.There is no analogy between parametriclly-driven objects and statically-definedblocks. The fact that parametrically-driven objects are created in the form ofBLOCK insertions in AutoCAD is merely because that is the most-convenient wayto 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 todepart from the "mainstream of AutoCAD application development" inorder to do this.

Personally, I think you're hiding behind your lack of understanding of theAutoLISP language, or at least, that's the impression that I get by how manyhoops you seem willing to jump through to achieve what would be consideredchilds 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    *//*******************************************************/

Thanks for taking it in the spirit in which it was offered, Paul. As youknow, I'm every bit an advocate of whatever it takes to get the job done as youare. With respect to recursion, that little effort was in fact an excuse to getcloser to the real meaning for myself as for anyone. This is, in fact, whatI've always appreciated about the on line discussion. The more questions weanswer 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 toanswer questions from those who ask them is perhaps knowing the right place tolook 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 thespell 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/evendetermination.

I thought about using the fibonacci series to perform an infinte recursionbut thought better about it. My reference for my research into this question,BTW was "LISP", A Gentle Introduction to Symbolic Computation byDavid S. Touretzky. While this book deals with common lisp as opposed toAutoLISP, the principles are the same. In fact, since AutoLISP has no built-infunction as does common lisp for the form (oddp x) to determine the oddness ofa 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 orodd (rem x)/=0.

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

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

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 withthe least amount of effort, and it's right when we're done, that's the mainthing.

> Make the computer to the dumb work.

Amen!

> My comment regarding "user input pause" may be confusingDIESEL
>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 handleuser input and decision making. So in effect, I, too, use a hybrid system muchlike 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 halfthe space on one of my drives here at home if I eliminated all the batch filesbut then I'd be stuck with a lot of manual dumb stuff and as you said, I'llleave that for the confuser to do. Writing batch files is quickly becoming adieing 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 listwere 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 thisgroup. I mean we see questions asking for an AutoLISP routine to do somethingthat can be done with basic Acad commands directly at the command line. I wouldhave 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 supportfor 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 1996Path: 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!usenetFrom: jeeper@halcyon.com (Dennis Shinn)Newsgroups: comp.cad.autocadSubject: Re: wanted! LispDate: Tue, 10 Sep 1996 03:27:57 GMTOrganization: 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 ofrecursion would pop in here since all I know of it is what I've read anddiscussed with Roy at our AutoLISP SIG meetings. Frankly I'm not sure when andwhy I would ever need to write a truly recursive function but it's fascinatingnone the less.

As to how I'm doing, drop in on the PCGNet echoes - I don't think it'sappropriate 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 thatdon't relate necessarily to AutoLISP (as far as I know. Perhaps Tony canclarify). For kicks I decided to run (fact 100). It only took 30 levels to thepoint where my 486 laptop began to slow appreciably. The suprisingly enough onthe way out - where the calculations are really done, when it got to the 16thlevel (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 havean idea why this is so?

Dennis ShinnSeattle AutoCAD User GroupSAUG-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

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

The second factor is the function's local environment (both arguments andlocal variables). For each recursion, a copy of the local environment is put onthe stack, so you can go deeper if you eliminate all unnecessary locals fromthe 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 moreknowlege of
> recursion would pop in here since all I know of it is what I've readand
> discussed with Roy at our AutoLISP SIG meetings. Frankly I'm notsure when and
> why I would ever need to write a truly recursive function butit's fascinating
> none the less.
>
> As to how I'm doing, drop in on the PCGNet echoes - I don't thinkit'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 theproblems
> >that he was talking about.
>
> There are a few other problems associated with the (fact) functionthat don't
> relate necessarily to AutoLISP (as far as I know. Perhaps Tonycan clarify). For
> kicks I decided to run (fact 100). It only took 30 levels to thepoint where my
> 486 laptop began to slow appreciably. The suprisingly enough on theway out -
> where the calculations are really done, when it got to the 16thlevel (coming
> out, now) the numbers became negative. For whatever reason, factorial16 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
>
>Â