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).
Related
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
Continuation describes what happens next with some value, right?
Isn't that just a function that takes a value and does some computation?
(+ (* 2 3) 5)
the continuation of (* 2 3) is (+ _ 5)
(define k (lambda (v) (+ v 5)))
What is the point of using call/cc in here and not using the function k ?
True. All programs have continuations until it halts. One continuation is usually one step in the calculation done by the underlying implementation.
Your example:
(+ (* 2 3) 5)
The combination + is dependent on the combination * to finish first. Thus (+ result 5) is indeed the continuation of (* 2 3). It's not a procedure in this context though. The usefulness of call/cc is when you have an continuation you regret and want to do something else instead or you want to come back to this at a later time. Lets do the first:
(define g 0)
(call/cc
(lambda (exit)
(/ 10 (if (= g 0) (exit +Inf.0) g))))
Clearly, there is a division which is the continuation when the result of the if is done, but since exit is run the whole thing gets short circuited to return +Inf.0.
How would you do that with a procedure without getting it to do the division afterward? In this style, you can't.
It isn't really magic since Scheme converts your code to Continuation Passing Style(=CPS) and in CPS call/cc is no special. It's not trivial writing code in CPS.
Here's the CPS definition of call/cc
(define (kcall/cc k consumer)
(consumer k (lambda (ignore v) (k v))))
Congratulations! You've just invented continuation-passing style! The only difference between what you've done and call/cc is that call/cc does it automatically, and doesn't require you to restructure your code.
A 'continuation' is the entire future of a computation. Every point in a computation has a continuation which, in naive terms, you can think of as the current program-counter and current stack. The Scheme call/cc function conveniently captures the current configuration and packages it up into a function. When you invoke that function you revert back to that point in the computation. Thus, a continuation is very different from a function (but the continuation function is, well, a function).
There are two common cases where one typically sees call/cc applied:
non-local exit. You establish a continuation, do some computation, to abruptly end the computation you invoke the continuation.
restart/reenter a computation. In this case you save the continuation and then call it again as you please.
Here is an example for case #1:
(begin
;; do stuff
(call/cc (lambda (k)
;; do more
;; oops, must 'abort'
(k 'ignore)))
;; continue on
)
And here is an example for case #2:
> (define c #f)
> (let ((x 10))
(display (list (+ 1 (call/cc (lambda (k) (set! c k) x))) 111))
(display " more"))
(11 111) more
> (c 20)
(21 111) more
> (c 90)
(91 111) more
For this case #2 is it worth noting that the continuation brings you back to the top-level read-eval-print loop - which gives you a chance to re-invoke the continuation in this example!
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.
(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.
While coding a predicate that tests whether or not a number is divisible by all integers across a certain range, I was wondering if it is possible to make rules about input, maybe through the "declare" symbol?
Code:
(defun integer-divisiblep (n m i)
(declare (integer n m i))
(do ((x m (- x 1)))
((< x n) (return t))
(when (not (integerp (/ i x)))
(return nil))))
In this case I may like to specify that the input value "n" must be smaller than "m". Is there anyway to do this with an inbuilt function? I can't seem to find what I want with the declaration-identifiers on the Hyperspec.
Also, I'm using SBCL, if that makes a difference.
Common Lisp does not provide static type checks for argument types. Some Common Lisp compilers do it as an extension, most notably CMUCL and SBCL. These static type checks use the typical declarations of variable types provided by DECLARE. You need to see the syntax of the various types to see what can be declared.
Dynamic checks at runtime are best done with CHECK-TYPE and ASSERT.
In this case I may like to specify that the input value "n" must be smaller than "m"
This is something like:
(assert (and (numberp m) (numberp n) (< n m)) (m n))
The list (m n) at the end is a list of variables which can be interactively set by the user, if the assert is violated. After entering a different value, the assertion will be checked again, until the assertion is satisfied.