So I am new to lisp, and I am quite confused about the problem I have:
(defun factorial (x)
(if (>= x 1)
(* x (factorial (- x 1)))
1))
The factorial function can output 3000! without a problem, however
(defun sum (x)
(if (<= x 1)
1
(+ x (sum (- x 1)))))
Stack overflows at (sum 10000), I am using clisp.
Could anyone please clarify why this is happening?
Your functions are not tail-recursive, so the compiler (and interpreter) increase stack for each iteration, eventually running out of it.
Your options are enumerated in FAQ How do I avoid stack overflow?; the relevant are:
Compile the functions
Increase Lisp stack size
Rewrite using iteration instead of recursion
Rewrite using tail-recursion and compile
Related
(defun *smaller* (x y)
( if (> x y) y
x))
(defun *minimum* (lst)
(do ((numbers lst (cdr numbers))
(result (car numbers) (*smaller* result (car numbers))))
((null numbers) result)))
LISP says that variable "numbers" in "minimum" function is an unbound one although I think I've bound it to "lst". What am I missing?
Do binds in parallel. The expression for the initial value of result is (cdr numbers), and numbers is unbound there. Do* would work here.
Another approach to this problem is to try and think about it inductively.
an empty list has no minimum;
if the list is not empty, its first element is a candidate minimum:
if the rest of the list is empty it's the answer
else the candidate minumum is the smaller of the current candidate and the first element of the list, and carry on through the rest of the list.
This translates very naturally into Lisp:
(defun smaller (x y)
(if (< x y) x y))
(defun running-minimum (candidate tail)
(if (null tail)
candidate
(running-minimum (smaller candidate (first tail)) (rest tail))))
(defun minimum (list)
(when (null list)
(error "?")) ;ed is the standard text editor
(running-minimum (first list) (rest list)))
Notes
For good, if now mostly historical, reasons, CL makes no guarantees that code like this will be turned into an iterative process. Many implementations do so, but a conforming implementation need not, and even implementation which do so may not always do so, for instance in interpreted code or code compiled for ease of debugging. So a minimum function like the above is not really very idiomatic CL, and is certainly not completely safe if the code is meant to be portable.
However that is not my goal in this answer: one of the important things that you should get from learning lisp, in my opinion, is the ability to think inductively about solving problems. In other words to think about a class of problems which can be solved by starting from a simple base case and then steps which get from some general case closer to the base case, and then expressing this in code. This is a very different approach to programming than the approach which is natural in more imperative languages, and once you understand it it's a very powerful way of thinking.
As someone whose first serious language was FORTRAN (in the days when that was the correct way of writing its name even!) I think that this inductive approach is very important, and it's that which I wanted to get across here.
(defun smaller (x y)
"returns the smaller number"
(if (> x y)
y
x))
(defun minimum (list)
"returns the smallest number of a list"
(do* ((numbers list (rest numbers))
(result
(first numbers)
(if numbers
(smaller result (first numbers))
result)))
((null numbers) result)))
First of all, as pointed above, you should use do* instead of do, in order to bind the variables sequentially.
Second, you are testing (null numbers) to end the loop. However, when only one element is left to process, numbers is not nil but then it becomes (cdr numbers) which is nil. This nil value is what is being passed to *smaller* as second argument, and that's why you get the error message. To avoid this, you should test for (null (cdr numbers)) instead:
(defun *smaller* (x y)
( if (> x y) y
x))
(defun *minimum* (lst)
(do* ((numbers lst (cdr numbers))
(result (car numbers) (*smaller* result (car numbers))))
((null (cdr numbers)) result)))
This exits the loop when there is only one item left in the list.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This is a follow up to my previous question. I’m not convinced that Lisp code is as Homoiconic as machine code on a Von Neumann architecture. It seems obvious to me that in both cases code is represented as data, but it also seems apparent that you can exploit this property much more freely in machine code than you can in Lisp.
When mucking around with machine code, self modifying code is so easy it happens all the time, often by accident and with (in my experience) hilarious results. While writing a simple “print the numbers 0-15” program I might have an “off by one” error with one of my pointers. I’ll end up accidentally dumping whatever is in Register 1 into the address in memory that contains the next instruction, and a random instruction gets executed instead. (Always great when it’s some sort of “goto”. God knows where it’s going to end up and what it’s going to do after that happens)
There really is no separation between code and data. Everything is simultaneously an instruction (even if it’s just a NOP), a pointer, and a plain old number. And it’s possible for the code to change before your eyes.
Please help me with a Lisp scenario I’ve been scratching my head over. Say I’ve got the following program:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
; -- Demonstrate the output of factorial --
; -- The part that does the Self modifying goes here –
; -- Demonstrate the changed output of factorial
Now what I want to happen is to append to this program some Lisp code which will change the * to a +, change the <= to a >=, stick a (+ 1 2 3) somewhere in there, and generally bugger the function up. And then I want the program to execute the absolute mess that results.
Key point: Unless I’ve made some fatal error in the sample code you’re only allowed to alter the -– More code goes here –- part. What you see above is the code. I don’t want you quoting the entire list and storing it in a variable so that it can be manipulated and spat out as a separate function with the same name; I don’t want a standard redefinition of factorial as something completely different. I want that code, right there that I can see on my screen to change itself before my eyes, just like machine code.
If this is an impossible/unreasonable request then it only solidifies further in my mind the idea that Homoiconicity is not a discrete property that a language either has or doesn’t have, it is a spectrum and Lisp isn't at the bleeding edge. (Alternatively Lisp is as Homoiconic as they come and I'm looking for some other term to describe machine-code-esque self-modification)
That's easy. You only need to change the list representation. All you need is a Lisp interpreter.
The Common Lisp implementation LispWorks provides us with a Lisp interpreter:
CL-USER 137 > (defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
FACTORIAL
CL-USER 138 > (fifth (function-lambda-expression #'factorial))
(IF (<= N 1) 1 (* N (FACTORIAL (- N 1))))
CL-USER 139 > (fourth (fifth (function-lambda-expression #'factorial)))
(* N (FACTORIAL (- N 1)))
CL-USER 140 > (setf (first (fourth (fifth (function-lambda-expression
#'factorial))))
'+)
+
CL-USER 141 > (fourth (fifth (function-lambda-expression #'factorial)))
(+ N (FACTORIAL (- N 1)))
CL-USER 142 > (factorial 10)
55
CL-USER 143 > (setf (first (fourth (fifth (function-lambda-expression
#'factorial))))
'*)
*
CL-USER 144 > (factorial 10)
3628800
Here is an example where a function modifies itself. To make it slightly easier, I use a feature of Common Lisp: it allows me to write code which is not just some nested list, but a graph. In this case the function can access its own code:
CL-USER 180 > (defun factorial (n)
(if (<= n 1)
1
(progn
(setf (first '#1=(* n (factorial (- n 1))))
(case (first '#1#)
(+ '*)
(* '+)))
#1#)))
FACTORIAL
Above function alternatively uses + or * by modifying its code.
#1= is a label in the expression, #1# then references that label.
CL-USER 181 > (factorial 10)
4555
In earlier times (70s/80s) in some Lisp groups the developers were not using a text editor to write Lisp code, but a structure editor. The editor commands were directly changing the structure of the Lisp code.
If I write this function in emacs-lisp:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
=> factorial
It works well for small numbers like 5 or 10, but if I try and calculate (factorial 33) the answer is -1211487723752259584 which is obviously wrong, all large numbers break the function. In python this doesn't happen. What is causing this problem?
You can always invoke Emacs' calc library when dealing with large numbers.
(defun factorial (n)
(string-to-number (factorial--1 n)))
(defun factorial--1 (n)
(if (<= n 1)
"1"
(calc-eval (format "%s * %s"
(number-to-string n)
(factorial--1 (- n 1))))))
ELISP> (factorial 33)
8.683317618811886e+036
Further reading:
http://www.masteringemacs.org/articles/2012/04/25/fun-emacs-calc/
C-hig (calc) RET
C-hig (calc) Calling Calc from Your Programs RET
Integers have a specific range. Values outside this range can't be represented. This is pretty standard across most -- but not all -- programming languages. You can find the largest number Emacs Lisp's integer datatype can handle on your computer by checking the value of most-positive-fixnum.
Go to your *scratch* buffer -- or any Lisp buffer -- and type in most-positive-fixnum. Put the cursor at the end, then press C-x C-e. On my computer, I get 2305843009213693951 as the value. Yours might differ: I'm on a 64 bit machine, and this number is about 2^61. The solution to the factorial of 33 is 8683317618811886495518194401280000000. That's about 2^86, which is also more than my Emacs can handle. (I used Arc to calculate it exactly, because Arc can represent any size integer, subject to boring things like the amount of memory you have installed).
The most simple solution seems to be Paul's one:
(defun factorial (n) (calc-eval (format "%s!" n)))
ELISP> (factorial 33)
8683317618811886495518194401280000000
However, I tried for fun, by another Calc way, without using calc-eval and string.
Because much more complex Emacs Lisp programs with Calc can be done in this way.
Calc's defmath and calcFunc- functions are so powerful within Emacs Lisp.
(defmath myFact (n) (string-to-number (format-number (calcFunc-fact n))))
ELISP> (calcFunc-myFact 33)
8.683317618811886e+36
I landed on this question searching for a quick and easy way to compute a factorial in Elisp, preferrably without implementing it.
From the other answers, I gather that it is:
(calc-eval "10!")
which is equivalent to
(calc-eval "fact(10)")
and which is as concise as, and more powerful than, redefining a factorial function. For instance, you can have a binomial coefficient this way:
(calc-eval "7!/3!(7-3)!")
or even that way:
(calc-eval "choose(7,3)")
Calc is really worth exploring. I suggest doing the interactive tutorial inside Emacs. You can launch it with C-x * t.
As for calc, you can use it with C-x * c, or with M-x calc.
(define (sqrt-iter guess x)
(if (good-enough? guess x)
guess
(sqrt-iter(improve guess x)
x)))
(define (improve guess x)
(average guess(/ x guess)))
(define (average x y)
(/ (+ x y) 2))
(define (good-enough? guess x)
(< (abs (- (square guess) x)) 0.0001))
(define (square x)
(* x x))
(define (sqrt-g x)
(sqrt-iter 1.0 x))
This is a program for sqrt. And the question is what happens when you attempts to use new-if to replace if with new-if.
(define (sqrt-iter guess x)
(if (good-enough? guess x)
guess
(sqrt-iter(improve guess x)
x)))
This is new if
(define (new-if predicate then-clause else-clause)
(cond (predicate then-clause)
(else else-clause)))
My opinion is the result of two program gonna be the same. because new-if and if can produce the same results.
However, new-if proved wrong, because it is a dead circle when I tried.
So, why?
new-if is a function. All the arguments to a function are evaluated before calling the function. But sqrt-iter is a recursive function, and you need to avoid making the recursive call when the argument is already good enough.
The built-in if is syntax, and only evaluates the then-branch or else-branch, depending on the value of the condition.
You can use a macro to write new-if.
This is the perfect example for demonstration the algebraic stepper!
In the the algebraic stepper you can see how the course of the computation differs from your expectation. Here you must pay notice to the differences in evaluation of, say, (new-if 1 2 3) and (if 1 2 3).
If you haven't tried the algebraic stepper before, see this answer to see what it looks like.
Since racket is an applicative procedure the 3rd argument to the new-if is (sqrt-iter(improve guess x) x)). Since sqrt-iter is recursive the 3rd argument never has a value assigned to it. Therefore you never move into the procedure of new-if to evaluate the function.
I recognize that there's an obvious pattern in the output to this, I just want to know why lispbox's REPL aborts when I try to run anything > 52. Also, any suggestions on improving the code are more than welcome. ^-^
(defun count-reduced-fractions (n d sum)
(setf g (gcd n d))
(if (equal 1 d)
(return-from count-reduced-fractions sum)
(if (zerop n)
(if (= 1 g)
(count-reduced-fractions (1- d) (1- d) (1+ sum))
(count-reduced-fractions (1- d) (1- d) sum))
(if (= 1 g)
(count-reduced-fractions (1- n) d (1+ sum))
(count-reduced-fractions (1- n) d sum)))))
All I get when I call
(count-reduced-fractions 53 53 0)
is
;Evaluation aborted
It doesn't make much sense to me, considering it'll run (and return the accurate result) on all numbers below that, and that I could (if i wanted to) do 53 in my head, on paper, or one line at a time in lisp. I even tested on many different numbers greater than 53 to make sure it wasnt specific to 53. Nothing works.
This behaviour hints at a missing tail call optimization, so that your recursion blows the stack. A possible reason is that you have declaimed debugging optimization.
By the way, you don't need to make an explicit call to return-from. Since sum is a self-evaluating symbol, you can change this line
(return-from count-reduced-fractions sum)
to
sum
edit: Explanation of the proposed change: "sum" evaluates to its own value, which becomes the return value of the "if" statement, which (since this is the last statement in the defun) becomes the return value of the function.
edit: Explanation of declaimed optimization: You could add the following to your top level:
(declaim (optimize (speed 3)
(debug 0)))
or use the same, but with declare instead of declaim as the first statement in your function. You could also try (space 3) and (safety 0) if it doesn't work.
Tail call optimization means that a function call whose return value is directly returned is translated into a frame replacement on the stack (instead of stacking up), effectively "flattening" a recursive function call to a loop, and eliminating the recursive function calls. This makes debugging a bit harder, because there are no function calls where you expect them, resp. you do not know how "deep" into a recursion an error occurs (just as if you had written a loop to begin with). Your environment might make some default declamations that you have to override to enable TCO.
edit: Just revisiting this question, what is g? I think that you actually want to
(let ((g (gcd n d)))
;; ...
)
My guess is that there's a built-in stack depth limit with lispbox. Since Common Lisp does not guarantee tail-recursive functions use constant stack space, it's possible that every invocation of count-reduced-fractions adds another layer on the stack.
By the way, SBCL runs this algorithm without problem.
* (count-reduced-fractions 53 53 0)
881
* (count-reduced-fractions 100 100 0)
3043
As a matter of style, you could make d and sum optional.
(defun test (n &optional (d n) (sum 0)) .. )
Probably a Stack Overflow (heh).