I'd post the code, but it wasn't really that interesting (just a algorithm for computing Pascal's triangle, mod 2). Although I did enjoy having completed the assignment in about half as much code as anyone else in the class (since everyone else I knew wrote their program in Java).
EDIT: On second thought, here is the code. If anyone has suggestions for improving or shortening it, please post them.
(def factorial (n)
(if (> n 0)
(* n (factorial (- n 1)))
1))
(def choose (n k)
(/ (factorial n) (factorial k) (factorial (- n k))))
(def indices (n)
(map (let n -1 [++ n]) (n-of n nil)))
(def pascal-triangle (n)
(for i 0 n
(apply prs (map [mod (choose i _) 2] (indices (+ i 1))))
(prn)))
(pascal-triangle 64)You can improve this by using the recursive formula for Pascal's triangle rather than the closed form. Specifically, n choose k equals (n-1) choose (k-1) + (n-1) choose k. Memoize and you can do (pascal-triangle n) in O(n^2), optimal since that's the amount of prints you have to do.
There is also probably an quicker formula for n choose k mod 2, if you don't have to print the entire triangle. Perhaps try using Legendre's formula for the largest power of a prime that divides a factorial.
see: http://mathworld.wolfram.com/Factorial.html
Also you might be able to find some useful recursive formula based on the fact that Pascal's triangle mod 2 looks like a Sierpinski triangle.
-----
def f(n, k):
if n and k are both 0:
return 1
if n is even and k is odd:
return 0
return f(floor(n/2), floor(k/2))
-----
from: http://en.wikipedia.org/wiki/Rounding
Although it is customary to round the number 4.5 up to 5,
in fact 4.5 is no nearer to 5 than it is to 4 (it is 0.5
away from both). When dealing with large sets of
scientific or statistical data, where trends are
important, traditional rounding on average biases the data
upwards slightly. Over a large set of data, or when many
subsequent rounding operations are performed as in digital
signal processing, the round-to-even rule tends to reduce
the total rounding error, with (on average) an equal
portion of numbers rounding up as rounding down. This
generally reduces upwards skewing of the result.-----
The benefit of the pascal triangle is that through a simple number triangle you can find binomial coefficients. It has since been redefined as the binomial coefficient. But historically it was interesting because it could provide binomial coefficients through simpler math than n choose k.
If you have to calculate the whole triangle, then I would probably recursively define it and calculate it that way. (Pascal's formula shows that each subsequent row is obtained by adding the two entries diagonally above) Instead of constantly calculating it at each position with n choose k.
I guess you could use the binomial coefficient definition and memoize the choose and factorial. Memoization alone is what is saving you here. Luckily arc provides this functionality.
Anyways, this is a fun problem. Much easier to solve elegant and efficiently in arc, thanks to memoize. Try this in an imperative language and you'll definitely have to fall back on the recursive definition because all those factorials and chooses will kill the performance. There is one other benefit to using the recursive definition - you won't use any extra memory memoizing factorials. Instead you'll just have the chooses appearing in the tree.
-----
-----
So a useful formula for counting digits is, a positive integer x has floor(log10(x)) + 1 digits. You can figure this out yourself by thinking, where does the digit-counting function bump up a notch? At 10, 100, 1000, etc. So asymptotically the number of digits in x is O(log x).
So n! has O(log n!) digits. The trickier part is figuring out or knowing that O(n log n) = O(log n!). Using log ab = log a + log b you can expand out the factorial:
O(log n!) = O(log (n * (n-1) * ... * n * 1))
= O(log n + log (n-1) + ... + log 2 + log 1)
= O(n log n)
log n + log (n-1) + ... + log 2 + log 1 < n log n
log n + log (n-1) + ... + log 2 + log 2 > log n + log (n-1) + ... + log (n/2)
> (n/2) log (n/2)
In general the rules of thumb you use to reduce O(log n!) are:
1. complicated expressions inside factorials are ugly, you should simplify them
2. O(sum of n things) is usually O(n * the biggest thing)
-----
And usually in this case I would leave of the O, as that usually refers to the performance of an algorithm in time or space. I suppose you could construe the number of digits to be "space" but multiplying O(n) numbers doesn't make that much sense.
-----
(range 0 i)
(indices (+ i 1))
0..i
(indices (+ i 1))
Edit2: It's also better to use true tail recursion:
(def factorial (n)
((afn (acc n)
(if (< n 2)
acc
(self (* acc n) (- n 1))))
1 n))-----
(def prsall (rest)
(if rest
(do (pr (car rest) #\space)
(prsall:cdr rest))))
(def map (f l)
(if l
(cons (f:car l) (map f (cdr l)))))
(def factorial (n)
(if (> n 0)
(* n (factorial (- n 1)))
1))
(def choose (n k)
; arc2c only supports two-arg forms for math
(/ (/ (factorial n) (factorial k))
(factorial (- n k))))
(def indices (n)
(let self nil
; no support for '= yet
(set self
(fn (i)
(if (isnt i n)
(cons i (self (+ i 1))))))
(self 0)))
(def pascal-triangle (n)
(let self nil
(set self
(fn (i)
(if (<= i n)
(do
; Anarki make-br-fn not supported yet
(prsall (map (fn (_) (mod (choose i _) 2)) (indices (+ i 1))))
(prn)
(self (+ i 1))))))
(self 0)))
(pascal-trangle 4)
-----