Migrating from Wireless-G to 10-Base-T

For almost a week now, I've been working with my wife on a total conversion for our apartment. Since we spend most of our day in the computer room, we decided to try swapping it with the larger room that used to be our bedroom. It's been hard work moving furniture and reorganizing, but I think it will be worth it. Finally, I have the elements of a real office: printer, filing cabinet, and a mini-fridge stocked with red bull. I never got Ubuntu to connect to my WPA2 network (my best hypothesis is that I'm using the wrong driver for my specific chipset, though I had no luck with ndiswrapper either). With the new set up, I can connect to my wired LAN.

GEB Week 2: Chapter 4, Consistency

It's been a crazy week. Surprisingly, I found time to read this week's assignment. In the last few chapters, the author has tactfully introduced many of the important concepts in studying and understanding formal systems. One particular argument he has made is that the form of a formal system is completely disconnected from its meaning. Here's an excerpt which takes this further:

It now becomes clear that consistency is not a property of any formal system per se, but depends on the interpretation which is proposed for it. By the same token, inconsistency is not an intrinsic property of any formal system. (GEB20 94)

An alternative conclusion might have been that "all formal systems are consistent by definition," but the author disagrees with this characterization. Instead, he makes the stronger claim that it is completely improper to assign "consistency" or "inconsistency" to a formal system. What distinction is he making, and to what end?

GEB Week 1: Ch 1-3

This week's reading contains an infinite hierarchy of meaning and fun. There are many explicit and hidden puzzles to be solved, and I won't ruin them for you, but certainly encourage you to work through them yourself. Here is an excerpt from Chapter 2 which I found interesting:

People enjoy inventing slogans which violate basic arithmetic but which illustrate "deeper" truths, such as "1 and 1 make 1" (for lovers), or "1 plus 1 plus 1 equals 1" (The Trinity). You can easily pick holes in those slogans, showing why, for instance, using the plus-sign is inappropriate in both cases. But such cases proliferate. Two raindrops running down a window-pane merge; does one plus one make one? A cloud breaks up into two clouds--more evidence for the same? It is not at all easy to draw a sharp line between cases where what is happening could be called "addition", and where some other word is wanted. (GEB99 56)

This hints at a very important theme of the book; that counting in hierarchical systems can be "fuzzy." Does this reflect a deep aspect of reality, or rather, the function and organization of the brain?

GSoC Book Club: Format and a Challenge

If you aren't reading GEB with us by now, you just might be the only one! I've gotten quite a few questions and comments about the format of the book club, so let's set a few things straight:

First, each date on the schedule represents the start of the week in which the specified chapter will be discussed. I've updated the Google calendar to reflect this by making each chapter extend a week. Originally, I assumed putting each chapter on one day would look less cluttered for someone importing the calendar, but I think it was more confusing than helpful.

Secondly, the schedule is designed to pace the reader to finish by the end of summer. If you don't follow it, great! Still visit now and then and add your thoughts. You can comment on anything at any time, with one exception: don't give any spoilers for puzzles, riddles, etc.

Several people have also asked about the format of discussions. I decided against a web forum or weekly IRC chat for two reasons: chances are it would be underutilized in the long run, and we already have the GSoC blog community, which I feel to be a great discussion medium. The central place to begin discussions will be my weekly blogs, but it is my hope that discussion will branch out to your blog as well.

...which brings me to the GSoC Book Club 2007 Challenge: at some point during the summer, choose a section or idea that you really liked or were affected by, and blog it! I look forward to reading and linking to your GEB-related posts!

In case you haven't noticed, I'm not planning on posting about the chapters on Monday morning of each week. In general, I hope to post at least once a week on something from the assignment, but with so many interesting things going on this summer, it might take me a few days.

One final note. Last week, I initially posted the wrong assignment for this week. Just in case you missed the correction, chapters one, two, and three are relatively short, so we're reading all three of them this week. Sorry for any confusion.

SymPy Graphing: Starting with PyOpenGL and Feisty

Just a brief update. Progress has been a little slower this week because I've begun working on the new graphing implementation using PyOpenGL and the sample function I wrote about last week. After about a day of tinkering, I had no luck with PyOpenGL on Windows using Python 2.5 (not officially supported yet, apparently). As a result, I've been working in Feisty for the last few days. Unfortunately, I'm having a hard time convincing Feisty to connect to my wpa2-protected wifi, and this is putting a damper on my work flow. Once I get that and a few other nags sorted out, I should be on track.

GEB Week 0: Introduction, strange loops

Okay--I'm not exactly Oprah and this isn't going to be like that. With that said, let's start discussion of GEB for the Google Summer of Code 2007. If you don't already have a copy, you still have time to pick it up from amazon or your local library, used book store, obscured dusty shelf in closet, roommate, russian site of questionable legality, etc.

For this week, you should try to read the introduction and the first dialogue, "Three-Part Invention". You should also try to read Chapters 1-3 for next week, if you want to stay completely up to speed (I'm grouping dialogues with the chapters they follow, so that reading for Chapter 1 "includes" the dialogue "Two-Part Invention"). However, like its subject matter, the process of reading GEB is not completely straightforward. Don't worry too much about sticking to the schedule; the book club is primarily about finding motivation to read and think critically about new ideas on a consistent basis this summer.

In the introduction, Hofstadter gives us a first taste of strange loops, a "phenomena [which] occurs whenever, by moving upwards (or downwards) through the levels of some hierarchical system, we unexpectedly find ourselves right back where we started." A simple yet fascinating example of this concept is demonstrated with Bach's "Endlessly Rising Canon," a piece of music which changes key upwards repeatedly until reaching the starting key, implying an infinite progression. The author also demonstrates strange loops in several of Escher's pieces, such as his famous waterfall, fed by a perplexing aqueduct which defies either gravity or reason.

Since I'm currently reading a book of rigorous number theory for the first time, I am reminded of the Peano axioms, which define the natural numbers by induction. How about a quine, a program which outputs itself?

How many strange loops can we list?



Update: Corrected reading assignment for next week.

New direction for SymPy Graphing

In addition to gaining some new perspective on my project this weekend, I've gotten a lot done.



On Friday, I said I wanted to stop supporting matplotlib and to begin focusing on a fresh OpenGL plotting solution. It turns out that matplotlib has better 3d support than I suggested, though it is buggy and still doesn't have everything I need. Fortunately, it turns out we can have it both ways.

I've moved matplotlib 2d plotting support out of modules/graphing.py and into examples/mplot2d.py. I've also added 3d plotting support in examples/mplot3d.py. In accomplishing this, I created a generic sampling function in modules/graphing.py which generates plotting data from a 2d or 3d function over an interval or rectangle:


>>> from sympy.modules.graphing import sample
>>> from sympy import Symbol
>>> x = Symbol('x')
>>> sample(x, (x, 0, 2, 2))
[[0,1,2],[0,1,2]]
>>> sample(x**2, (x, 1, 3, 2))
[[1,2,3], [1,4,9]]


This approach will allow me to support multiple plotting solutions. You should now be able to graph many varieties of functions using matplotlib with the implementations in examples/mplot2d.py and examples/mplot3d.py.


>>> mplot3d(x**2-y**2, (x, -10.0, 10.0, 20), (y, -10.0, 10.0, 20))


The Case for Dropping Matplotlib

My pet motivation for SymPy Graphing is to aid in the creation of interactive calculus visualizations. I want to be able to write an example program which visualizes the normal and tangential components of acceleration along a curve. I want to be able to graph a 3d surface subject to a constraint, perhaps to see only the portion of a surface which falls within a cylindrical boundary. Ondrej mentioned that he would like to be able to plot curvature as the vertex color across a 3d surface. All of these things should be doable. At the same time, SymPy Graphing should be simple and intuitive enough for a non-programming Calc III student to use in Python's interactive mode as a graphing calculator.



In my work on 2d graphing this week, I've utilized matplotlib's pylab interface. Using matplotlib to plot functions from SymPy is pretty straightforward, though I find it clunky and have had many frustrations with it. But as the name implies, matplotlib isn't meant to do much beyond plotting, and has only limited 3d support. I want to do a lot more with SymPy Graphing.

As mentioned above, I'd like to support plotting an arbitrary function as the vertex color across a surface; matplotlib has no mechanism for this. Jason and I have discussed allowing geometric figures and line segments from the geometry module to be drawn through the graphing interface; again, not possible. I'd also like to support interactive rotation, zooming, translation, etc., and possibly someday (outside the scope of GSoC) point-picking; to my knowledge, you cannot do these things in matplotlib.

As I said in my proposal, 3d graphing will be supported through PyOpenGL. In general, this is not a very difficult task (there is a good summary of what it entails at the plot3d website) and this approach will provide the flexibility I want.

The upshot of all this is that I am considering a shift away from matplotlib altogether and toward supporting all graphing, 2d and 3d, through a unified OpenGL interface. I only want to support a fraction of the features of matplotlib. (I'm not trying to banish matplotlib from sympy. In any event, one can easily use matplotlib directly. See the current revision of modules/graphing.py in SVN for an example.) If my project goal was simply to write a SymPy wrapper for matplotlib, I'd be done before the official coding period even begins. To do this right, I'm going to need to get my hands a bit dirtier.

Update:
The 3d support in Matplotlib is better than I'd thought (it can do interactive rotation and scaling). There is a good example here. It also looks like it might be able to do colormaps. I'm looking into it in more depth right now.

Sympy Graphing: Usable Progress, Early Frustrations

Over the weekend, I did a bit of refactoring and added a couple of improvements to sympy/modules/graphing.py (where Fabian had laid a good foundation already). First, I've extended plot() to accept a list of functions in addition to a single function.

from sympy import Symbol
from sympy.modules.graphing import plot
x = Symbol('x')
plot([sqrt(x), log(x), sin(x)], xlabel="x label")


I also added in some code so that functions with discontinuities, such as sqrt where x < 0, are plotted correctly.

f_list = [sqrt(x), sqrt(-x), -sqrt(x), -sqrt(-x)]
plot(f_list, [x, -10.0, 10.0], title="Square Roots")


Unfortunately, this code has hit a snag getting through automated testing. At this point, my best hypothesis is that there is some incompatibility between py.test/doctest and the Tk backend for pylab. I'm going to try a different backend next. Ondrej has opened an issue here.