Fixing Emacs and Latex on Mac OS

So I bought a shiny new macbook, and immediately set about installing emacs and latex. A few hiccups. First, emacs couldn't find the latex executables. This was remedied with

(setenv "PATH" (concat "/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/usr/texbin:/usr/bin:" (getenv "PATH")))
(setq exec-path (append '("/opt/local/bin" "/opt/local/sbin" "/usr/local/bin" "/usr/local/sbin" "/usr/texbin" "/usr/bin") exec-path))

Next, I typically want pdf rather than dvi output, and I'd like to use Preview to view these. Emacs defaults to Evince, which is unhelpful in a gnome-less world.

(setq TeX-PDF-mode t)

This can be set in Customize, but trying to do these next two was problematic, since there were drop-down menus in customize defaulting to the builtin list.

(setq TeX-view-program-list '(("Preview" "open %o")))
(setq TeX-view-program-selection '((output-pdf "Preview")))

Now I'm a latex compiling machine!

Data

Anyone ever tried to use excel to view a large csv file and gotten really sad? Like frustratingly sad?

Here's how this came about. Rahm Emmanuel in all his wisdom opened up the city of chicago's data as much as possible. One dataset is crime 2001 to present here. Well, if you go to this, and export to csv, you get ~1.08 GB of information. Loading this into Excel was were the fun began. First, my Excel for Mac 2011 seems to have a limit on worksheet sizes of about one million. Second, the helpful dialog pops up saying that the import failed, but that I'll get as many rows as can fit, and that I should import the remainder using "start import at row: n" in the csv dialog. Which makes a lot of sense. However, the most positive integer which is allowed in the dialog box for row number is 37677, 2^15 - 1. A signed 16 bit integer is still in a modern excel running on a 64 bit host? I'm awestruck by the quality.

I will try this same experiment later on in windows using excel 2010 to see what gives.

In defense of excel, bringing up eshell in emacs 24, then typing `cat Crimes... | grep NARCOTICS` gave me three lines before it froze the program. There should have been over 511,000 lines for that.

This is going to be fun.

A Small Experiment

One proof of the infinitude of prime numbers goes as follows:

Assume there were k primes, and we had them all in a list. Now consider the number one more than the product of all these primes. None of the primes in our list divides this number. Either it is prime, or it has a prime divisor not in our list. So there is no such k, that is, the primes are without number.

I started to think, which primes would we discover if this was our only method? I fiddled around for a few minutes with a piece of lisp code to generate these "euclidean" primes (Euclid included this proof long ago in the Elements).


(defun factor (n)
  "return a list of factors of n"
  (let ((test 3)
(limit (+ 1 (floor (sqrt n)))))
    (cond
      ((eq n 1) nil)
      ((evenp n) (cons 2 (factor (/ n 2))))
      (t (do()
 ((or (zerop (mod n test)) (> test limit)))
  (incf test 2))
(if (> test limit)
    (list n)
    (cons test  (factor (/ n test))))))))



(defun euclidean-primes (n)
  "generate the n primes generated by euclids proof"
  (let ((primes (list 1)))
    (do ((count 0 (1+ count)))
        ((= count n) (remove 1 primes))
      (let ((eprimorial (1+ (reduce #'* primes))))
        (setf primes (union primes (factor eprimorial)))))))

So I ran this, an up to (euclidean-primes 8) there is no issue, with a nice result:

(31051 1033 607 547 139 13 7 2 3 43 3263443 29881 67003 9119521 6212157481)

But running this for 9 proved time consuming, as the value to be factored was an unwieldy 

(FACTOR 12864938683278671740537145998360961546653259485195807)

which I found in the debugger when I was wondering why my CPU had pegged at 100% for several minutes. The overhead of bignum-truncate and bignum-normalize were swamping the process.

Now, I bet that my factorization is unnecessarily complicated, and that it's not the most efficient program for doing this, but it was an interesting thought experiment. Also, it appears union does some funny thing to element ordering, while I was expecting these to be ascending or descending, it looks like the smallest values tend to propagate to the center.

Just for a full picture:

(loop for i from 1 upto 8 do (print (euclidean-primes i)))

(2) 

(2 3) 

(3 2 7) 

(7 2 3 43) 

(43 3 2 7 13 139) 

(139 13 7 2 3 43 3263443) 

(3263443 43 3 2 7 13 139 547 607 1033 31051) 

(31051 1033 607 547 139 13 7 2 3 43 3263443 29881 67003 9119521 6212157481)