But I'm not complaining; everything looks like it's working out well.

Going back to Scheme, the next Project Euler problem is:

The prime factors of 13195 are 5, 7, 13 and 29. What is the largest prime factor of the number 600851475143 ?

And straightforwardly:

(define gpf ; greatest prime factor
  (lambda (n try) ; n is the number to find the factor of; try is the lowest number to try
    (cond
      ((> try (sqrt n)) n) ; no need to try a factor higher than the square root; if we get here, n is prime
      ((divides try n) (gpf (/ n try) try)) ; divide out the current trial factor and try again
      (else (gpf n (+ try 1))))))
(define euler3
  (lambda (n) (gpf n 2)))

(euler3 600851475143) gives us the answer 6857 pretty quickly.

But this is getting boring; I'm not using the interesting parts of Scheme. This sort of problem cries out for a prime number generator, and that cries out for call-with-current-continuation, and that cries out for some more playing and learning. I'll see what I can do.

• timepickr
• widget tutorial
• extending widgets
• flexcal
• googlesearch and ajaxpopup
• textpopup and hebrewkeyboard

And on top of that, chili stopped working with jQuery 1.4 and I haven't fixed it yet. Andrea Ercolino was nice enough to send me an updated version, but I haven't gotten around to installing it yet.

Update: got chili to work!

So much for using my spare time to learn Scheme!

And her comment about not eating red food when you're sick is absolutely right. Never give your kid red popsicles when they've got a stomach bug; you'll just rush into the ER worried that they're throwing up blood.

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ... Find the sum of all the even-valued terms in the sequence which do not exceed four million.

Brute force Fibonacci generator:

(define fibo
  (lambda (n)
    (cond
      ((= n 1)
       1)
      ((= n 2)
       2)
      (else (+ (fibo (- n 1)) (fibo (- n 2)))))))

But that takes exponential time, and the problem requires generating all of the numbers anyway, so we can use something like:

(define fibo-sum
  (lambda (a b lim)
    (let* ((c (+ a b)))
      (cond
        ((< lim c) 0)
        (else (+ c (fibo-sum b c lim)))))))

to get the sum of all the fibonacci numbers less than lim (use (fibo-sum 1 2 4000000)). I could add a test for even numbers to solve the problem, but more elegantly we notice that the pattern of the fibonacci numbers has to be odd-odd-even-odd-odd-even, so we have:

(define euler2
  (lambda (a b lim)
    (let* ((c (+ a b))
           (d (+ b c))
           (e (+ c d)))
      (cond
        ((< lim e) 0)
        (else (+ e (euler2 d e lim)))))))
(euler2 1 0 4000000)

We start the fibonacci sequence with 1 0 so that the 2 is part of our sum. And we get the correct answer, 4613732, imperceptibly fast.

One bug that took me forever to find was a mistyped line:

(let* ((c (+ a b))
  (d (+ b c))
   (e (+ d e)))

Where e was defined in terms of d and e, so it used the global value of e. If it hadn't been defined, it would have given me an error immediately, but unfortunately, DrScheme has it pre-defined as #i2.718281828459045 so my code went happily along giving me the wrong answers.

Problem 1:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

Translating Javascript to Scheme means function(x, y) {foo;bar;} becomes (lambda (x y) (foo) (bar)) and var x = y; becomes (define x y) and realizing that all loops have to be made into tail-recursive function calls gives us this pretty easily:

(define divides
  (lambda (a b)
    (= 0 (remainder b a))))

(define euler1
  (lambda (n)
    (cond
      ((= n 1) 
        0)
      ((or (divides 5 n) (divides 3 n))
        (+ n (euler1 (- n 1))))
      (else (euler1 (- n 1))))))

(euler1 999)

And the correct answer is 233168. Not bad for my first Scheme program! (Certainly more interesting than (display "hello, world")).

Addendum: I just looked at the forum at Project Euler and I see that there's a much better solution; just add the series 3+6+9....999, which is simply 3*(1+2+3+...333) or 3* 333 * (333+1)/2, to the series 5+10+15+...995, or 5 * 199 * (199+1)/2 and subtract the series 15+30+45... which is counted twice. No loops! Less interesting for learning to program, though.

So I've kept my current Mac (a blue & white G3, the "Mickey Mouse" one) just to be able to run Quicken 2001 under Classic. I can't upgrade to an Intel Mac, since Classic won't work. And I want to balance my checkbook while talking to my wife, not only downstairs in my basement office. So I wanted something I could run on my dual-boot (XP and Ubuntu) laptop.

I've been looking at alternatives to Quicken for 5+ years, but with 20 years of data I was too scared. Until now. I've been using gnuCash for just a week now, but it seems to everything I need it to, including importing all my data, even from multiple investment accounts, from Quicken's exported QIF file. I haven't done any complicated investment things, so I don't know how well that side of it works.

Strong points

• It Just Works. Does what I expect it to do, in the way I expect it to. Of course, I'm a geek who understands double-entry bookkeeping, so that may not be surprising.
• I can control-S and save the file; I always felt out of control with Quicken since you couldn't force it to save.
• Open source. I will probably never have the time to tinker, but it's nice knowing that I could

Weak points

• Keyboard shortcuts. I miss being able to assign my own keystrokes; I hate going back to the trackpad to do anything. But see Open Source above; I can probably fix that.
• I'm going to have to learn Scheme to create custom reports. Not sure if that's a bug or a feature.

The biggest advantage is the feeling of freedom of not being tied to Intuit anymore. I'll see how it works out, but I'm not going back.

From the publisher's summary:

A comprehensive overview of Jewish History from Creation through the redaction of the Talmud, illuminating the intricacies and complexities of Torah tradition and philosophy according to the sages and classical commentaries, spanning the length and breadth of Jewish experience to resolve many of history’s most perplexing episodes, offering profound insights and showing their relevance to life in the modern world. An invaluable resource for scholars and laymen. A priceless tool for education and outreach.

How did the sin of Adam transform mankind and the world? How were the prophecies of Noah fulfilled through the rise of the Greek Empire? How did the builders of the Tower of Babel believe they could wage war against G-d? Why did there have to be three patriarchs? What was King David's crime regarding his involvement with BasSheva? Why did some Jews oppose the construction of the Second Temple? How can we trust the transmission of Torah if our scholars engaged in such fierce disagreements? These and many other questions are answered in this unique volume.

There's a far more complete manual that comes with the download, but these are the steps I used to generate the data for the webservices graphs. It assumes you've got a black and white image of the graph, with continuous lines for the data and orthogonal gridlines, and linear axes.

We'll use the bilirubin risk levels from the AAP bilirubin guidelines:

1. Open the digitizer

   You can't use Open with... from the context menu because the program expects filenames as part of the options; you can read the manual to see how to modify the context menu. Click Import on the toolbar: and select your image file:

   

   Save your work (it's a .dig file) often. You don't need me to remind you.

2. Set the axes

   Click Axis Point in the toolbar: and click on the origin (lower left corner) of the graph and enter the x,y values for the origin in the units of the graph (not pixels!). Usually that's (0,0) but can be anything. Click on the maximum of the y-axis (upper left corner), then the maximum of the x-axis (lower right corner).

3. Remove the grid

   Select Grid Removal... from the Settings menu. Select "Remove thin lines parallel to the axes" and play with the "Minimum line thickness" until the gridlines are gone from the preview on the bottom but the real curves are still there.

   

   Now the grid is gone and digitizing the curves will be easy:

   

4. Create curves

   Select Curves... from the Settings menu. Create as many curves as you need (we have three). Give them descriptive names if you like:

   

5. Digitize each curve

   Click Segment Fill in the toolbar: . For each curve, select it from the curve menu: and click the points on the graph for that curve until it is covered with points. There's no undo command. If a wrong point is included, use the Select tool: to select the bad points and use the Delete key. To add individual points, use the Curve Point tool: . In a few clicks, you have the fully digitized graph:

   

6. Set up the export

   If you exported the data now, you'd have lots of points; probably far more than is justified from the original graph. Decide which x-axis values should be exported (the program will interpolate appropriately if the digitized points don't land exactly). Select Grid Display... from the Settings menu:

   

   The values to be specified are related by count = (stop - start)/step so you only need to specify three; select the one you don't want to specify from the Disable dropdown menu. Make sure that the start and stop values are actually in the curve; the program will happily extrapolate off the curve but it's probably not scientifically legitimate. Ignore the y axis grid lines.

   Select Export Setup... from the Settings menu. In the Points Selection section, select Intepolate Y's at gridline X's.

   

7. Export

   Click the Export icon in the toolbar: . Pick a name and you now have a CSV file with your data. Simple, no?

So how to get the numbers off the graph? I emailed the lead author of the original paper, but haven't gotten any answer. I can pull the graphs as gif's from the PDF of the paper (thanks to OpenOffice.org and Sun's PDF importer; Adobe's reader seems to get more limited with each upgrade). I was afraid I would have to digitize the graph by hand; I read the cool article on Sudoku recognition and figured I could learn about Hough transforms to get the graph, and 2-D Fourier transforms to remove the gridlines, then blob detection to find the lines. Turning pixels into measurements would be the trivial last step. Sounds like fun, if I had an infinite amount of free time.

Luckily, I found Engauge Digitizer. With almost no time reading the manual, I had it removing gridlines, digitizing the curves on the graph, and exporting values at x-values that I selected into CSV files. It was close to easy. Not quite automated, but with only 4 graphs to digitize, I was done in half an hour. Highly recommended. With my remaining free time, I'll write a quick tutorial so I don't forget what I did.

Parsing the header is straightforward; the mime-types are separated by commas (note that the top-level separation is the comma, not the semicolon) and within each mime-type description the parameters are separated by semicolons. The first field is the mime-type itself (with possible wild card '*'), the second (if present) is the quality factor, "q={number from 0 to 1}" which describes how much the requestor wants that particular mime-type, and the remainder of the fields are other parameters.

As the specification says, parameters in the Accept: header are rare, and my programs don't use them, so we will ignore them. That means that Accept: text/html; q=0.8; level=2, text/html; q=0.2; level=1 is interpreted the same as Accept: text/html; q=0.2; not exactly the same as the spec but easier to code.

The q parameter technically should be weighted by how much the host wants to send that type. Thus, Accept: image/jpeg; q=1, image/gif; q=0.2 means "Send me a png; I'll accept a jpeg, but I'll be only 20% as happy." If the host feels that the gif is 10 times better than the jpeg, it should rank the gif as 10*0.2 = 2 and the jpeg as 1*1 = 1, and send the gif. My code doesn't have such strong feelings and ignores such niceties.

A q parameter of 0 should be interpreted as "never send me this type" but my code simply ignores it and, if there are no other mime-types in the Accept: header, sends the default. If it's the default type that has the q=0, then the requestor loses.

One subtle trick from Kris Jordan's Recess: wild card ('text/*' and '*/*') types should rank below more specific types with the same q parameter. We subtract 0.0001 from the stated q to push them lower; the specification says the value cannot have more than 3 decimal places.

function parseAccept ($accept){
	$mimetypes = array( // associate types with file extensions
		'*/*' => 'html',
		'text/*' => 'txt',
		'text/plain' => 'txt',
		'text/html' => 'html',
		'text/csv' => 'csv',
		'text/javascript' => 'js',
		'image/*' => 'png',
		'image/png' => 'png',
		'image/gif' => 'gif',
		'image/jpeg' => 'jpg',
		'application/*' => 'js',
		'application/json' => 'js',
		'application/xml' => 'xml'
	);

	$types = array();
	foreach (explode(',', $accept) as $mediaRange){
		@list ($type, $qparam) = preg_split ('/\s*;\s*/', $mediaRange); // the q parameter must be the first one according to the RFC
		$q = substr ($qparam, 0, 2) == 'q=' ? floatval(substr($qparam,2)) : 1;
		if ($q <= 0) continue;
		if (substr($type, -1) == '*') $q -= 0.0001;
		if (@$type[0] == '*') $q -= 0.0001;
		$types[$type] = $q;
	}
	arsort ($types); // sort from highest to lowest q value
	foreach ($types as $type => $q){
		if (isset ($mimetypes[$type])) return $mimetypes[$type];
	}
	return 'html';
}

The same sort of code would work for Accept-Encoding: and the other Accept-type headers.