frances makes good food. frances makes vegetarian thanksgiving that makes turkey-eaters cry. cry, turkey-eaters, wah wah wah.

On the fractions front, my professor gave me a thesis which introduced me to the wonderfully bent world of p-adic fields, each of which is essentially the standard completion of the rationals with a different metric on it: two rationals are "close" if their canonical difference is divisible by large powers of the prime p in question.

What's interesting about p-adic arithmetic is in how their digital (radix expansion) representations differ. Having exchanged the property of "magnitude" for the property of "divisibility", division makes numbers "further apart" and multiplication makes them "closer together", but if you fix a digit length, and hence a subset of Q (defining the maximum closeness and farness) you get a remarkable set in which arithmetic amongst the remaining terms is "exact" with respect to the standard norm on Q.

Intuitively, this makes sense: if you were to have fixed the number of digits you use to represent the "normal" rationals, you would be able to represent only a certain subset of rationals by their size. Say if you fix 3 digits worth, you could only represent numbers between 999.0 and 0.999; nonetheless you could exactly represent every number in that range, and the results of its arithmetic, so long as they stay in that range. In the p-adics, you're exchanging the meaning of digits, and by truncating to those 3 digits you get the ability to represent all rationals regardless of magnitude which happen to have a canonical form (reduced to coprime * power-of-prime) in which they are divisible by a 0..3 digit power of the base prime.

The profound effect this has, if I follow the thesis correctly, is that the propagation error of operations on finite p-adic representations (or one such, which she calls "hensel codes") can be systematically compensated for after each operation. So you can make a fixed-length representation and completely quantify the error of any operation on that representation by the error introduced when reading numbers in and approximating them.

So now I think maybe there's hope for computer arithmetic after all. I have to go make some software which uses this system, and try it out.

Also, I have to give huge props to wei dei's crypto++ library. I've had occasion to need crypto code recently, and this library is the shit. Anyone who's still making crypto libraries when something this cleanly designed, modular, reusable and simple is available is a fool. normally, when you want to make parts of a crypto library work together in a way they weren't designed to by the author, they don't fit. In crypto++, they do. Every part has been designed to cleanly fit into every other part, so you can fabricate new crypto systems, complete with i/o facilities, in a few minutes of thinking and coding.

Finally, I made a saddening empirical discovery about makefiles: your time is actually best spent (I measured) by not only having 1 makefile for the whole project, but also listing explicitly each target, and all its dependencies, and the rule to remake it, in that 1 makefile. It takes a few moments of fiddling with find(1) to produce file lists, but it is actually less time than you spend getting your pattern rules, dependency generators and recursive invocations right. Furthermore, once you have such a makefile, its behaviour is completely predictable. Bugs in makefiles simply do not occur if you use them this way. Everything that needs remaking always gets remade in exactly the right order, you never need to make clean, you never have obscure bugs from old .o files, you never need to mess with automake, and best of all when your tree is up to date, running make returns immediately rather than after 100 recursive invocations. peter miller is right. dan bernstein is right. it is a better use of your time to use make the way it was intended.