I am trying to learn Lisp/Scheme and I tried implementing a very simple version of the mandelbrot set in it to get practice. The problem I ran into is that the code runs very, very slow. At first I thought it was because I was using recursion instead of imperative loops, but I tried re-writing more or less the same code (recursion included) in python (which doesn't even have tail-call optimisation), and it ran very smooth
So I am wondering if there is something obvious I am missing in my code and what I could do to make it run faster.
Here is the code snippet in Scheme (racket). I also did pretty much the same thing in SBCL and the speed was comparable
#lang racket
(define-syntax dotimes
(syntax-rules ()
((_ (var n res) . body)
(do ((limit n)
(var 0 (+ var 1)))
((>= var limit) res)
. body))
((_ (var n) . body)
(do ((limit n)
(var 0 (+ var 1)))
((>= var limit))
. body))))
(define (print-brot zr zc)
(if (< (+ (* zr zr) (* zc zc)) 2)
(display "#")
(display ".")))
(define (brot zr zc cr cc i)
(if (= i 0)
(print-brot zr zc)
(let ((z2r (- (* zr zr) (* zc zc))) (z2c (* 2 zr zc)))
(brot (+ z2r cr) (+ z2c cc) cr cc (- i 1)))))
(define (linspace i w)
(/ (- i (/ w 2)) (/ w 4)))
(define (brot-grid w h n)
(dotimes (i w)
(dotimes (j h)
(let ((x (linspace i w)) (y (linspace j h)))
(brot 0 0 x y n)))
(newline)))
(brot-grid 40 80 20)
(I hope the code block is not too clustery, it was hard to strip it to something more simple)
Also, I know Scheme and Common Lisp have complex numbers built in but I wanted to test it using regular real numbers, I don't think this is the reason it runs so slow.
The parameter "i" of the brot function is the number of iterations, and the parameter "n" of brot-grid is also the number of iterations to use for each point. When I set it to more than like 10, the code takes forever to run, which doesn't seem normal. The increase in time taken also doesn't seem to be linear, for instance it only takes about a second on my machine with n = 10 but takes several minutes with n = 15 and doesn't even finish with n = 20
So, what is it that makes this code run so slow?
Thanks in advance
Looking at your code, I think you're testing it using rational numbers. This means pretty accurate arithmetics, with the drawback being atht you quickly end up using rationals with huge bignums as both numerator and denominator.
One way to ensure you're using floats (I'd suggest double-floats) is to have an intermediate function that converts all inputs to doubles, to make it easier to just type (say) 0 instead of 0d0.
Once you've established that using doubles makes it faster, you can start sprinkling type declarations throughout, to make it possible for the compiler to generate better code for you.
Here is a Common Lisp variant:
(defun print-brot (zr zc)
(write-char (if (< (+ (* zr zr)
(* zc zc))
2.0d0)
#\#
#\.)))
(defun brot (zr zc cr cc i)
(loop repeat i
for z2r = (- (* zr zr) (* zc zc))
for z2c = (* 2.0d0 zr zc)
until (or (> (abs zr) 1.0d50)
(> (abs zc) 1.0d50))
do (setf zr (+ z2r cr)
zc (+ z2c cc)))
(print-brot zr zc))
(defun linspace (i w)
(/ (- i (/ w 2.0d0)) (/ w 4.0d0)))
(defun brot-grid (w h n)
(terpri)
(loop for i from 0.0d0 by 1.0d0
repeat w do
(loop for j from 0.0d0 by 1.0d0
repeat h do
(brot 0.0d0 0.0d0 (linspace i w) (linspace j h) n))
(terpri)))
Notice the use of double float constants. Also iterating both over double floats and integers.
Running it in SBCL unoptimized, but compiled to native code:
* (time (brot-grid 20 40 20))
........................................
....................#...................
....................#...................
....................#...................
...................###..................
.................#######................
...................###..................
................#########...............
..............#############.............
............#################...........
..............#############.............
...............###########..............
..................#...#.................
........................................
........................................
........................................
........................................
........................................
........................................
........................................
Evaluation took:
0.003 seconds of real time
0.002577 seconds of total run time (0.001763 user, 0.000814 system)
100.00% CPU
6,691,716 processor cycles
2,064,384 bytes consed
Optimizing the code then would mean:
higher compiler optimize setting
possibly adding some type declarations
getting rid of the float consing
Related
(Just for fun) I figured out a way to represent this:
250 : 8 = 31 + 2
31 : 8 = 3 + 7
∴ (372)8
in the following procedure:
(defun dec->opns (n base)
(do* ((lst nil (append lst (list pos))) ; this is also not so nice
(m n (truncate m base))
(pos (rem m base) (rem m base)) ) ; <<<<<<
((< m base) (reverse (append lst (list m)))) ))
The procedure does what it is supposed to do until now.
CL-USER> (dec->opns 2500000 8)
(1 1 4 2 2 6 4 0)
At this point, I simply ask myself, how to avoid the two times
(rem m base).
First of all because of duplicates are looking daft. But also they may be a hint that the solution isn't the elegant way. Which also is not a problem. I am studying for becoming a primary school teacher (from 1st to 6nd class) and am considering examples for exploring math in a sense of Paperts Mindstorms. Therefore exploring all stages of creating and refining a solution are welcome.
But to get a glimpse of the professional solution, would you be so kind to suggest a more elegant way to implement the algorithm in an idiomatic way?
(Just to anticipate opposition to my "plan": I have no intentions to overwhelm the youngsters with Common Lisp. For now, I am using Common Lisp for reflecting about my study content and using the student content for practicing Common Lisp. My intention in the medium term is to write a "common (lisp) Logo setup" and a Logo environment with which the examples in Harveys Computer Science Logo style (vol. 1), Paperts Mindstorms, Solomons et. al LogoWorks, and of course in Abelsons et. al Turtle Geometry can be implemented uncompromisingly. If I will not cave in, the library will be found with quickload in the still more distant future under the name "c-logo-s" and be called cλogos ;-) )
The closest to your code
You can reduce the reversing of the reversing and append -> by using cons only. The duplication of (rem m base) is only an optical issue, since the first (rem m base) gets executed only the first time the loop runs and the second (rem m base) in all other cases. Thus they are actually not a duplication. One cannot use a let here, because of the required syntax within the macro. (<variable> <initial-value> <progression-for-each-round>)
(defun dec->ops (n base)
(do* ((acc nil (cons r acc))
(m n (truncate m base))
(r (rem m base) (rem m base)))
((zerop m) acc)))
The most Common Lispy version
The rosetta solutions for Common Lisp seems to give the most Common Lisp-like ways - either using write-to-string/parse-integer or even some format quircks.
(defun decimal->base-n (n base)
(write-to-string n :base base))
(defun base-n->decimal (base-n base)
(parse-integer (format nil "~a" base-n) :radix base))
(defun decimal-to-base-n (number &key (base 16))
(format nil (format nil "~~~dr" base) number))
(defun base-n-to-decimal (number &key (base 16))
(read-from-string (format nil "#~dr~d" base number)))
;; or:
(defun change-base (number input-base output-base)
(format nil "~vr" output-base (parse-integer number :radix input-base)))
Source: https://rosettacode.org/wiki/Non-decimal_radices/Convert#Common_Lisp
(decimal-to-base-n 2500000 :base 8)
;;=> "11422640"
Solution without format or write-to-string/parse-integer
Use tail call recursion:
(defun dec->ops (n base &optional (acc nil))
(if (< n base)
(cons n acc)
(multiple-value-bind (m r) (truncate n base)
(dec->ops m base (cons r acc)))))
Try it:
[41]> (dec->ops 250 8)
(3 7 2)
[42]> (dec->ops 250000 8)
(7 5 0 2 2 0)
[43]> (dec->ops 2500000 8)
(1 1 4 2 2 6 4 0)
The do/do* macros are in this case not so nice, because one cannot capture the multiple values returned by truncate nicely (truncate is mod and rem in one function - one should use this fact).
If you really wants to use do*
(defun dec->ops (n base)
(do* ((acc nil (cons (second values) acc))
(values (list n) (multiple-value-list (truncate (first values) base))))
((< (first values) base) (nbutlast (cons (first values) (cons (second values) acc))))))
This works
[69]> (dec->ops 250 8)
(3 7 2)
[70]> (dec->ops 2500000 8)
(1 1 4 2 2 6 4 0)
I would go with the following implementation when trying to avoid recursion:
(defun digits-in-base (number base)
(check-type number (integer 0))
(check-type base (integer 2))
(loop
:with remainder
:do (multiple-value-setq (number remainder) (truncate number base))
:collect remainder
:until (= number 0)))
Multiple values are not directly handled by LOOP so instead of converting the values to a list I prefer using MULTIPLE-VALUE-SETQ to update multiple values at once.
The code first does some type checks because otherwise it can loop infinitely: the inputs are expected to be respectively positive or null, and greater than 1.
I put the :until condition at the end so that 0 gives (0).
Note that the digits are sorted from the smallest to the highest rank:
(digits-in-base 4 2)
=> (0 0 1)
(digits-in-base 250 8)
=> (2 7 3)
Alternatively, for the reverse order:
(defun digits-in-base (number base)
(check-type number (integer 0))
(check-type base (integer 2))
(loop
:with remainder :and digits
:do (multiple-value-setq (number remainder) (truncate number base))
:do (push remainder digits)
:until (= number 0)
:finally (return digits)))
(digits-in-base 4 2)
=> (1 0 0)
(digits-in-base 250 8)
=> (3 7 2)
In a previous version of this answer I said the first one (from low to high digits) is better for further manipulation of the digits, but I am not so sure.
Converting back to a number is quite easy with number arranged from high to low digits (all the code below use the second version):
(defun digits-to-number (digits base)
(reduce (lambda (n d) (+ d (* n base)))
digits
:initial-value 0))
So is formatting to a string:
(defun number-string-base (number base)
(format nil
(if (<= base 10)
"(~{~d~})~d"
"(~{~d~^'~})~d")
(digits-in-base number base)
base))
(number-string-base 250 8)
=> "(372)8"
(number-string-base 250 16)
=> "(15'10)16"
Since you expressed interest in various approaches, one thing worth remembering is that Lisp's great strength is creating and extending languages. Indeed all the iteration constructs in Common Lisp are such extensions: CL has no primitive iteration constructs at all.
So there is nothing preventing anyone writing their own, which will be just as good as the ones the language provides. For instance Tim Bradshaw's simple loops provides an 'applicative looping construct', looping, which makes this quite simple to implement:
(defun dec->ops (n base)
(looping ((m n)
(a '()))
(when (< (abs m) base)
(return (cons m a)))
(multiple-value-bind (q r) (truncate m base)
(values q (cons r a)))))
Using looping, the variables bound in the loop are updated by the values of the last form in the loop's body.
Of course this is rather close to the classic tail-recursive implementation (here using iterate):
(defun dec->ops (n base)
(iterate next ((m n)
(a '()))
(if (< (abs m) base)
(cons m a)
(multiple-value-bind (q r) (truncate m base)
(next q (cons r a))))))
People tend not to like things like this because they are 'not idiomatic CL' of course.
I'll illustrate what I want to do using Python (I want to write this in Clojure). I have this function:
def f(n):
s=0
for d in range(1,n+1):
s+=d*(n//d)
return(s)
Which is basically looping from d=1 to n inclusive, and summing up the values of d times the floor of n/d.
In Clojure I want to make this a recursive function. Python equivalent:
def f(d, n):
if d == 0: return 0
else: return d*(n//d) + f(d-1, n)
and then I'd call the function with f(n, n).
I am trying this:
(defn f
([n] (f n n))
([d n]
(if (> d 0)
(recur (dec d) n)
0)))
But I don't know if this is right so far or where to slip in the sum or how to do it, etc.
If you look at your Clojure f function, the [d n] arity recurs with
d decremented and
n unchanged
... until d is zero, when it returns 0.
If we write this arity as a distinct local function, using letfn, we can drop the unchanging n argument, picking it up from the f argument:
(defn f [n]
(letfn [(g [d]
(if (> d 0)
(recur (dec d))
0))]
(g n)))
This produces the wrong answer of course, always returning 0:
(f 10)
=> 0
But we can see where to put the sum in:
(defn f [n]
(letfn [(g [d]
(if (> d 0)
(+ (* d (quot n d)) (g (dec d)))
0))]
(g n)))
We have to revert the recur to an explicit recursive call to g, as it is surrounded by the +.
But at least it works:
(f 10)
=> 87
In Clojure I want to make this a recursive function.
Don't. I've done it above just to show you where the calculation fits in.
Explicit recursion is rare in idiomatic Clojure. Better use the functions that encapsulate its common patterns. I won't repeat what Carciginate has given, but once you get used to threading macros, I think you'll find the following clear and concise:
(defn f [n]
(->> (range 1 (inc n))
(map (fn [d] (* d (quot n d))))
(reduce +)))
By the way, a reasonable analogue of your Python code is
(defn f [n]
(loop [s 0, d 1]
(if (> d n)
s
(recur (+ s (* d (quot n d))) (inc d)))))
I managed to get 3 ways working. Unfortunately, this algorithm doesn't seem to lend itself to nice recursion.
To get safe recursion, I had to introduce a third parameter. I just couldn't get it arranged so the recur was in the tail position. I also decided to count up instead of down. I don't think there's anything left field here, although it did get quite long unfortunately.
(defn f3
([n] (f3 n 1 0))
([n d s]
(if (> d (inc n))
s
(recur n (inc d)
(+ s (* d (quot n d)))))))
(f3 10)
If unsafe recursion is ok, this can be simplified quite a bit. Instead of adding multiple argument lists, I decided to allow d to be defaultable using & [d?]] and a check later down. I tend to avoid adding multiple argument lists since par-infer has a difficult time handling the indentation required to make it work. This trick isn't possible with the first way due to how recur handles var args. It only works if you're not using recur, or you do use recur, but only destructure 1 var-arg.
(defn f2 [n & [d?]]
(let [d (or d? 1)]
(if (> d (inc n))
0
(+ (f2 n (inc d)) (* d (quot n d))))))
(f2 10)
Unless you really need recursion though, I'd just write it as a map and reduction:
(defn f1 [n]
(reduce + 0
(map #(* % (quot n %)))
(range 1 (inc n)))))
(f1 10)
Which to me is about as neat as it gets (without using a threading macro. See Thumbnail's answer).
Try this:
(defn f
([n] (f n n))
([d n]
(if (> d 0)
(+ (* d (quot n d)) (recur (dec d) n))
0)))
The below code gives wrong answer. It should give approximately 0.5 which is the average of an array with many random numbers between 0 an 1. I think the problem is because N is "to big", or perhaps the precision on the generated random number?. The code works well for smaller values of N (10^7, 10^6, etc). Some advices will be helpful.
Thank you in advance.
(defun randvec(n)
(let ((arr (make-array n)))
(dotimes (i n)
(setf (aref arr i) (random 1.0))
)
arr
)
)
(defparameter N (expt 10 8))
(setf *random-state* (make-random-state t))
(defparameter vector1 (randvec N))
(format t "~a~%" (/ (reduce #'+ vector1) (length vector1)))
Precision of floating point numbers
You are computing with single precision floating point numbers. By adding up all random numbers you get a single-float number. The more numbers you add, the larger the float will be. This eventually causes your result to have not enough precision.
double-floats like 1.0d0 have a higher precision than single-floats like 1.0s0. By default 1.0 is read as a single-float. (RANDOM 1.0d0) will compute a double float.
(defun randvec (n)
(let ((v (make-array n)))
(dotimes (i n v)
(setf (aref v i) (random 1.0d0))))) ; create a double float random number
(defun test (&optional (n 10))
(setf *random-state* (make-random-state t))
(let ((v (randvec n)))
(/ (reduce #'+ v) (length v))))
Example:
CL-USER 58 > (test (expt 10 8))
0.4999874882753848D0
Style
Please use common Lisp programming style when programming in Common Lisp:
don't use global variables, if not necessary. Write functions with local variables instead.
if you define a global variable with defparameter, don't name it n, but *n*.
format and indent your code correctly. Indentation should be done with editor help.
don't use parentheses on their own line.
See my example above.
I'm trying to expand a simple fibonacci function, and I need to use the values for each term more than once. So, I figured I'd use let to hold onto the values. But, I'm not getting what I think I should out of the function.
Here is the original fib function:
(define (fib n)
(if (< n 2)
n
(+ (fib (- n 1)) (fib (- n 2)))))
Here is my attempt at doing the same thing, but with let:
(define (fib-with-let n)
(if (< n 2)
0
(let ((f1 (fib-with-let (- n 1)))
(f2 (fib-with-let (- n 2))))
(+ f1 f2))))
Results:
> (fib 10)
55
> (fib-with-let 10)
0
Thanks!
You made a typo:
(if (< n 2)
0
...)
You mean n.
You mistyped your base case. In the first version you had:
(if (< n 2)
n
But then in your latter version you wrote:
(if (< n 2)
0
So just change 0 to n.
Your let is not really doing anything. You are still doing all of the extra calculations. Just because you define f1 as (fib-with-let (- n 1)) doesn't mean you won't compute the fib of n-1 again. f2 does not use f1. If you wanted f2 to see f1 you would use let*. However, even this is not really what you want.
As evidence of this, here are the running times for fib(35) and fib-with-let(35):
(time (fib 35))
cpu time: 6824 real time: 6880 gc time: 0
(time (fib-with-let 35))
cpu time: 6779 real time: 6862 gc time: 0
What you really want to do to avoid extra computations is use dynamic programming and recurse in a bottom-up fashion.
What you want is the following code:
(define (dynprog-fib n)
(if (< n 2)
n
(dynprog-fib-helper 1 1 2 n)))
(define (dynprog-fib-helper n1 n2 current target)
(if (= current target)
n2
(dynprog-fib-helper n2 (+ n1 n2) (add1 current) target)))
(time (dynprog-fib 35))
cpu time: 0 real time: 0 gc time: 0
(time (dynprog-fib 150000))
cpu time: 2336 real time: 2471 gc time: 644
As you can see, you can do the first 150,000 fibs in a third of the time the naive approach takes.
Since it looks like you are confused about what let does let me illustrate better:
When you say:
(let ((a 1)
(b 2))
(+ a b))
What you are saying is, let a be 1, and b be 2, add them together.
If you instead said:
(let ((a 1)
(b (+ a 1))
(+ a b))
Can you guess what you'd get? Not 3. It would be blow up with expand: unbound identifier in module in: a
In simple let, your assignments cannot see each other.
If you wanted to write the above you would have to use let*:
(let* ((a 1)
(b (+ a 1))
(+ a b))
That would give you the 3 you expect. let* essentially expands to:
(let ((a 1))
(let ((b (+ a 1)))
(+ a b)))
What you thought you were doing with the lets is called memoization. It's a technique where you store intermediate values so you don't have to repeat them. Let, however, does not do that for you.
Although your problem is a typo in your fib-with-let function, in its simplest form, let is "syntatic-sugar" for an anonymous lambda followed by the arguments that are then evaluated and passed to the lamba, which is then evaluated and a final value returned. So
(let ((f1 (fib-with-let (- n 1)))
(f2 (fib-with-let (- n 2))))
(+ f1 f2))
would be re-written without let to look like
((lambda (f1 f2) (+ f1 f2))(fib-with-let (- n 1))(fib-with-let (- n 2)))
My solution to exercise 1.11 of SICP is:
(define (f n)
(if (< n 3)
n
(+ (f (- n 1)) (* 2 (f (- n 2))) (* 3 (f (- n 3))))
))
As expected, a evaluation such as (f 100) takes a long time. I was wondering if there was a way to improve this code (without foregoing the recursion), and/or take advantage of multi-core box. I am using 'mit-scheme'.
The exercise tells you to write two functions, one that computes f "by means of a recursive process", and another that computes f "by means of an iterative process". You did the recursive one. Since this function is very similar to the fib function given in the examples of the section you linked to, you should be able to figure this out by looking at the recursive and iterative examples of the fib function:
; Recursive
(define (fib n)
(cond ((= n 0) 0)
((= n 1) 1)
(else (+ (fib (- n 1))
(fib (- n 2))))))
; Iterative
(define (fib n)
(fib-iter 1 0 n))
(define (fib-iter a b count)
(if (= count 0)
b
(fib-iter (+ a b) a (- count 1))))
In this case you would define an f-iter function which would take a, b, and c arguments as well as a count argument.
Here is the f-iter function. Notice the similarity to fib-iter:
(define (f-iter a b c count)
(if (= count 0)
c
(f-iter (+ a (* 2 b) (* 3 c)) a b (- count 1))))
And through a little trial and error, I found that a, b, and c should be initialized to 2, 1, and 0 respectively, which also follows the pattern of the fib function initializing a and b to 1 and 0. So f looks like this:
(define (f n)
(f-iter 2 1 0 n))
Note: f-iter is still a recursive function but because of the way Scheme works, it runs as an iterative process and runs in O(n) time and O(1) space, unlike your code which is not only a recursive function but a recursive process. I believe this is what the author of Exercise 1.1 was looking for.
I'm not sure how best to code it in Scheme, but a common technique to improve speed on something like this would be to use memoization. In a nutshell, the idea is to cache the result of f(p) (possibly for every p seen, or possibly the last n values) so that next time you call f(p), the saved result is returned, rather than being recalculated. In general, the cache would be a map from a tuple (representing the input arguments) to the return type.
Well, if you ask me, think like a mathematician. I can't read scheme, but if you're coding a Fibonacci function, instead of defining it recursively, solve the recurrence and define it with a closed form. For the Fibonacci sequence, the closed form can be found here for example. That'll be MUCH faster.
edit: oops, didn't see that you said forgoing getting rid of the recursion. In that case, your options are much more limited.
See this article for a good tutorial on developing a fast Fibonacci function with functional programming. It uses Common LISP, which is slightly different from Scheme in some aspects, but you should be able to get by with it. Your implementation is equivalent to the bogo-fig function near the top of the file.
To put it another way:
To get tail recursion, the recursive call has to be the very last thing the procedure does.
Your recursive calls are embedded within the * and + expressions, so they are not tail calls (since the * and + are evaluated after the recursive call.)
Jeremy Ruten's version of f-iter is tail-recursive rather than iterative (i.e. it looks like a recursive procedure but is as efficient as the iterative equivalent.)
However you can make the iteration explicit:
(define (f n)
(let iter
((a 2) (b 1) (c 0) (count n))
(if (<= count 0)
c
(iter (+ a (* 2 b) (* 3 c)) a b (- count 1)))))
or
(define (f n)
(do
((a 2 (+ a (* 2 b) (* 3 c)))
(b 1 a)
(c 0 b)
(count n (- count 1)))
((<= count 0) c)))
That particular exercise can be solved by using tail recursion - instead of waiting for each recursive call to return (as is the case in the straightforward solution you present), you can accumulate the answer in a parameter, in such a way that the recursion behaves exactly the same as an iteration in terms of the space it consumes. For instance:
(define (f n)
(define (iter a b c count)
(if (zero? count)
c
(iter (+ a (* 2 b) (* 3 c))
a
b
(- count 1))))
(if (< n 3)
n
(iter 2 1 0 n)))