Planet Python/SoC - 2009 edition

New rolling torus code

2009-10-15T21:32:37+00:00

I changed the code to the rolling torus example pretty significantly. Little fixes in how the arrows representing the body fixed unit vectors are now fixed. Additionally, I added some code that calculates the kinetic, potential and total energy of the system, and plots it. The scipy solver seems to do a pretty good (not perfect) job of maintaining constant energy. I think tightening up the error tolerances would improve this, but the simulation is well behaved at this point so I didn’t bother.

Professor Bends Matter To His Will, Not a Supervillain”

2009-10-10T17:46:19+00:00

Ed: This was published in the Okanagan Phoenix on Oct 7th, 2009
Last week, I interviewed a UBC-O Engineering professor, Dr. Kenneth Chau, about his recent research. Dr. Chau joined the school of Engineering in January, from the National Institute of Standards and Technology (NIST) in the USA. His particular specialty is nanotechnology. Nanotechnology is a field dealing with technology and objects that are at the nanometer(nm)-scale size. To put it in perspective, a nanometer, which is 1 billionth(1000 million) of a meter, is 1/1000th the width of a human hair and the wavelength of visible light goes from 400-700 nm.

Dr. Chau recently made a significant advancement in the field of nanotechnology, where he demonstrated that light could actually pull a nano-scale object, rather than just push. The implications are very important, both for the field, and eventually for the production of military, scientific, and consumer products.

The kind of materials that Dr. Chau and others in his field work with, named ‘metamaterials’, offer many benefits to military, scientific, and consumer fields. For the military, such materials and devices can create new metal alloys, with potential unique properties, like extreme heat resistance or superior strength. On top of that, metamaterials offer the possibilities of perfect lenses, or perfectly reflective mirrors. In the more futuristic list of possibilities, it is believed that this field of nanotechnology will eventually allow us to build an invisibility cloak, or even optical computers, but both such inventions are far from being created.

All objects can be characterized by a refractive index, or an index of refraction as it is also called. This is the degree to which light is slowed down within the medium. As well, when light crosses the boundary between two mediums with different refractive indexes, light bends. Microscopes and lenses work by bending light in useful ways. All natural mediums have a positive refractive index, meaning that light is slowed down within the medium. However, some metamaterials have a property known as a negative refractive index, where light is bent in the opposite direction than in materials with a positive refractive index.

This is where the radiation pressure of light comes into play. Light has momentum, like any object that is in motion. However, light has a very small momentum, and can only affect small particles. The radiation pressure effect of light is why comets’ tails are always pointed away from the sun; the charged particles are pushed away by the radiation pressure of light. Picture a fire hose being pointed at you. The pressure of the hose pushes you away.

When the radiation pressure of light is combined with a negative index of refraction, Dr. Chau, proved, via experiment, that light can actually exert a pull force, in addition to pushing around particles. It is like some method of making the fire hose pull you, instead of pushing you away. If researchers can construct objects with arbitrary optical properties, then they can manipulate light in arbitrary ways, leading to all of the innovations listed previously, and many more not imagined yet. We have things, previously thought to be only in the realm of science fiction, happening in labs every day, around the world, and even on our campus.

Currently, the Chau Research group Dr. Chau is working on several exciting projects, and require talented and capable students with diverse backgrounds. One project Dr. Chau is involved in is the construction of a computer cluster, also known as a supercomputer, for simulating complex physical phenomenon. Another is a project to build a sensor, capable of detecting contaminants in water, by using spectroscopic analysis of light that comes out of properly formed droplets of water. One possible use for this optical sensor is to detect vanishingly small amounts of impurities in water.

The Microsoft Courier: Better than the font

2009-10-10T17:44:33+00:00

This was published in the Okanagan Phoenix on October 7th, 2009

On Tuesday, September 22nd, Microsoft released details about a product now in “late development”, the Microsoft Courier. Microsoft calls it a “booklet”, rather than a “tablet”, due to the two touchscreens the Courier offers, with a bendable spine. The Courier also comes with a camera on the back of one half of the booklet, as well as a single Apple-like Home button in the spine, which is used for powering the device on and off as well.

The Courier will be a full-featured computer, running a specialized GUI meant specifically for the Courier. It will have wireless and Microsoft’s famed handwriting recognition, however, there is no indication of USB ports or other items. The killer feature though is the handwriting recognition, which in XP, Vista, and now Windows 7, is beyond fantastic.

There is a video circulating which shows a fantastic, and well-thought out GUI, which is focused on productivity and Getting Stuff Done, rather than the cool, slick, media-focused iPhone and iPod Touch. With the two screens, the handwriting recognition, and the the integration with the OS, the Courier looks like an ideal tool for executives, creative professionals, and students.

Microsoft has not yet detailed what the specs of the Courier will be, and there is no word on battery life.

There is speculation that this is part of a business move to lower sales and interest in Apple’s rumored iTablet. However, the promotional material and the design of the Courier is very distinctive and unique, and seems to be trying to carve a new niche for Microsoft, in the world of the Professional.

The only downside to the Courier, is that it is not out yet, and not before this editor graduates.

Japan’s Love Affair with Droids

2009-10-10T17:42:30+00:00

Ed: This was published in the Okanagan Phoenix Sept. 23, 2009
We’ve all seen robots and androids like Data from Star Trek, C3PO and R2D2 from Star Wars, as well as real-life robots, like ASIMO from Honda, and they all seem to be coming from Japan lately. There are a wide variety of reasons why robots and androids enjoy such a large popularity in Japan, ranging from cultural to purely economic reasons.

Part of the reason why the Japanese are so fascinated, and even encouraging of robots and androids, is that for the longest time, Japanese and other Asian fiction lacked a common trope that is often seen here in the west; that of the robots rising to crush their so-easily-crushed oppressors. Namely, us. It wasn’t until recently that this trope was seen in Japanese popular culture, and an excellent example is Cashern, a hyper-surreal action movie, where artificial life rises up and kills us all.

Some sociologists theorize that Japan lacks this common trope because industrialization was seen as largely positive for the country, particularly in the aftermath of WWII. In contrast, there was a large amount of social upheaval in western countries during their industrialization periods, where the machines were seen as a distinct threat.

On average, Japan has one of the oldest populations in the industrialized world. In just a few short years, many Japanese will reach the age of 65, and retire, making it so that 1 in every 4 Japanese will be over the age of 65. This is leading to a significant lack of employees, in turn leading to increasing wage costs for companies.

There are two major markets for robots and androids in Japan, one for the elderly, and one for replacing limited employees where possible. The elderly market requires assistants and companions, especially for the elderly that have no family, or whose family doesn’t visit them. There are already a few preliminary models of elderly assistants, and they are selling very, very well. The other market requires robots to replace humans in easy-to-automate jobs, like store greeters, or waitresses in busy restaurants. One particular requirement is that they look and act as human as possible within the limited purview of the job.

The increasing use of robots and androids in Japan has already sparked several major concerns with their use. There are worries that people will begin to prefer talking to and dealing with robots and androids over their human brethren. As well, there are concerns about the material costs of robots and androids, especially maintenance costs, and whether it really would be more cost-effective than the humans that are being replaced. In addition, Japan has signed several environmental treaties, and increasing their high-tech usage will only hurt their compliance with these treaties.

There is also an issue from an economic viewpoint. The desire to replace humans with robots is because the humans are becoming more expensive to employ. This increases the number of people available for jobs, thus driving down the average wage, making it cheaper to hire people again. However, once hiring increases, then people become more expensive to employ again. It is an inherently unstable situation, unless the government steps in to stabilize the see-saw effect.

One thing is for sure, Japan loves their robots, and they are currently the world leader in practical robotics.

Quantum Superpositioning: Like Kids with ADHD, both excited and grounded.

2009-10-10T17:40:55+00:00

Ed: This was published in the Okanagan Phoenix Sept. 23, 2009
Scientists at the Max-Planck-Institut fur Quantenoptik in Germany(Max Plank Institute for Quantum Optics) are proposing a bold new experiment dealing with quantum super-positioning. What they propose to do is to place a virus into a superposition.

What super-positioning means is when something is in two or more states at the same time. The classic analogy is known as the Schroedinger cat experiment. This is a thought-experiment(meaning its never been performed in real life, but only in the mind) where a cat is placed in a box, where a poison will be released only if a radioactive object decays within the time period inside the box. The decay probability is 50%, so the cat has a 50% chance of being alive, and an equal chance of being dead. The trick, however, is that until observed, the cat is in both states, as in, the cat is both dead and alive. The cat is in a superposition, two states at once.

This is intuitively difficult for many people, including physicists. When the cat is observed, the cat becomes either dead or alive, but not both. This is called collapsing the wave function, where observation of some form(even by a sensor) causes the superposition to resolve to one state or another.

What the researchers want to do is to cool some matter, namely a virus, down to its quantum ground state in a vacuum, until there is no subatomic activity from the virus. Then they zap the virus with a special kind of laser, which causes the virus to both be in an excited state, and a ground state, at the same time; a superposition. Having performed this same experiment with photons, electrons, and even whole molecules, they wish to see if they can make a much larger bit of matter reach a superposition. This will help show if such quantum mechanical effects apply on the macroscopic(large) scale, instead of just the microscopic scale.

The virus they need to use for the experiment needs to have several special qualities, and luckily(for our karmic revenge) the common flu virus fits this bill. In addition the tobacco mosaic virus would also be perfect for the experiment.

Gyrostat

2009-10-10T04:20:16+00:00

I just added an example of use for the derivation of the equations of a gyrostat using PyDy. It is located in the examples/gyrostat/ subdirectory.

In case you aren’t familiar, here is the definition of a gyrostat:

A gyrostat is a mechanical system which is comprised of more than one body and yet has the rigid body property that its inertia components are time independent constants.

The reason I became interested in gyrostats is because in modeling the bicycle, the rear frame and the rear wheel can be treated as a gyrostat, and in doing so, the number of parameters that appear in the equations of motion will be reduced by two. The same can be done for the front fork and handlebar assembly and front wheel.

In addition to the Python script that generates the equations, I took the time to do a complete write up of the model in LaTeX and generate a nice pdf of it.

siddhantgoel

2009-10-07T21:13:50+00:00

I’ve always been a hopper. As in like, I’ve always kept on hopping between stuff. When I say stuff, I mean a Linux distribution, and things like that. I still haven’t bought a Macbook, so these tiny little annoying things are going to bother me for quite some time.

I cannot use Windows for any work that I intend to do. Even if I try to, I cant. Setting up things are just plain pain. Plus every other tool I need to work with almost always doesn’t support Windows. So I cannot use it. I *need* a Linux distribution to work on. I started with RedHat linux, then moved to Fedora for quite some time. Then I moved to Ubuntu. Then I tried my hands on Debian. Then I gathered some guts and tried Gentoo (which I used for one full week, before I got pissed off by its everything-compiles nature). Then came Archlinux, and *that* put an end to all my distro hops. But that’s an altogether different story (maybe a different blog post on that).

But this post deals with the DE, rather than the distribution. I’ve always been a GNOME user, until a few months ago when I decided I should switch to something else. So I installed XFCE, and quite liked it. It was stable, fast, and gave me almost everything I could ask for in a DE. But then there were some problems with the xfce4-panel package; it kept on crashing on startup (and at times at random). I searched on forums, but didn’t find anything. I should have bugged some good folks at Archlinux/XFCE, but then decided I should try something else. So I went ahead and installed LXDE, which again, suited me fine. In fact, I’ve been using it as my main environment for quite some time now.

But now, I think I should go back to either of GNOME or KDE. There are tiny little annoying things that bug me too often in light weight DE’s. I probably wouldn’t mind spending those extra machine resources on a full blown DE, as long as I don’t have to tinker around to make things work. I’ve probably done enough of that. I need something usable. Now until and unless I don’t have a job, I wont buy a Macbook. So until then, its either one of GNOME or KDE. GNOME scares me. The last GNOME version I used was 2.26, and it took horrible, really horrible times to move from the login screen to the main desktop. I have some not so bad memories of using KDE from an internship. I’d probably give KDE a whirl this time. The latest KDE version looks awesome!

siddhantgoel

2009-09-29T17:07:15+00:00

There is this thing about interviews. This weird thing. That I’m just a little too stumped in them. I know I know the answers. And I know the questions I have been asked aren’t difficult at all. They just need a concentrated effort for like 2 or 3 minutes, and you can come up with a solution. Of course that might not be an O(1) solution, but still coming up even with an O(n^2) algorithm should be decent for a start. You can always have a discussion with the interviewer (provided he is nice; both the interviews I’ve been through were with pretty nice interviewers), and then improve upon the solution. And the whole activity is fun. Optimizing stuff, removing unnecessary executions, cleaning up the code, is really a fun activity.

So interviews are basically fun. Until you put me in the room, that is. Maybe the reason for this whole thing is that I’ve given just 2 interviews, but I’m usually a little nervous, not being able to think when someone is watching each and every step of mine. Both the interviews were with the best companies in India, and just thinking that this could actually screw my chances of working with some of the best minds, irks me.

For instance, the interviewer asked me to reverse a linked list. Now I’ve done this question like a hundred times before, and I know the solution, which is nothing more than trivial. But, at that time, all I did was getting lost between arranging the pointers. The function to reverse a linked list is no more than 3 statements (a recursive one), but for some strange reason, I couldn’t perform it at that time. Sad.

Just for my own sake, I’ll write down the solution here. I hope the solution is correct.

void reverse (struct node *start) { if (start->next == NULL) return; reverse(start->next); start->next->next = start; }

No more than 3 statements in the entire function (I’m assuming it does the job). Nothing more than trivial. But there is this really weird thing about interviews.

Maybe its just the fact that I’ve given only 2 interviews. I need to bring my brain to the work-while-some-is-watching-you mode. Lets see how long it takes. I hope I don’t screw up any more interviews.

GSOC meeting @ HSB

2009-09-24T22:56:28+00:00

The coming Tuesday (29.09.09) there will be meeting of all the GSOC’ders in the Benelux. This meeting will be at the HSB in Brussels during TechTue25 (more info at HSB). There will be a lot of other people from outside of GSOC so you are always welcome if you would like to connect with technical minded people and share ideas.

PS Bring you GSOC-tshirt if it arives on time!

Alan Turing: One badass dude

2009-09-12T22:38:11+00:00

(This was originally published in the UBC-O Phoenix student newspaper on Thursday September 10th, 2009, written by me)

There is a debate raging in the halls of Britain’s government, across the internet, and across many people’s minds. Right now, there is a growing movement for the British government to apologize to Alan Turing, posthumously, for their, to modern-day sensibilities, atrocious treatment.

Alan Turing is regarded by many to be the father of modern computing. His work formalized the concept of the algorithm(a way of solving a problem, like how to do long-division without a calculator) and many other things. One of the most important facets of his work was on that of the “halting problem”, which asks if there is an algorithm that can determine if another algorithm will ever complete, given a set of inputs. He was able to show that there is no such algorithm, that will work with every algorithm and set of inputs, in a fairly long and involved proof. He also developed the notion of a programmable machine(the Turing machine), able to emulate any other machine, only as long as that machine can emulate a Turing machine.

All of modern computing, from Facebook, to Halo, owes Turing a debt of gratitude for his work and efforts in designing computers, formalizing many of the important mathematics underlying modern computers, and demonstrating their use during WWII. For a time, Turing was responsible for the unit(known as Hut deciphering Nazi naval communications, and was responsible for saving many lives during WWII. He also designed the bombe, which was the key tool to breaking Enigma, the Nazi cipher. And he did all this before the age of 42.

Because it was at the age of 42 when Alan Turing died, of suicide. Two years previous, in 1952, Turing was outed as a homosexual, and under the laws of Britain at the time, tried and found guilty of being a homosexual. The punishment: castration. Turing was found guilty of the same laws that Oscar Wilde suffered under, only Turing chose to be chemically castrated, rather than go to jail.

These laws have since been repealed in Britain, and are now against the UN Charter of Human Rights, and against the EU constitution. What is happening right now, is that people want the government of Britain to acknowledge wrongdoing in their actions, not just against Turing, but against anyone that suffered under those laws, many of whom are still alive today. Over 6000 signatures have already been added to the petition regarding the apology at the time this article went to press.

Editors note: The British Government, on the same date of publication, offered up an apology to Alan Turing and the thousands of other gay men wrongly punished under this law.

E-textbooks vs Textbooks

2009-09-12T22:36:02+00:00

(This was published in the UBC-Okanagan Phoenix student newspaper on Thursday, September 10th)
When school starts, during the initial rush at the bookstore, some people may notice a new form of textbooks. This is the “ebook” or the electronic book. The ebooks that we will see in the UBC-O bookstore are offered by a company called Coursesmart(http://www.coursesmart.com), which specializes in offering ebooks for textbooks. They’ve been around since 2007, and have over 6000 textbooks available.

E-textbooks provide several advantages over paper textbooks. For example, you do not have to carry around a 500 page, 3 pound textbook, in addition to a laptop and other matériel. Finally, our backs can breathe easy. In addition, the e-textbook saves on gasoline, since it doesn’t need to be shipped. As well, the e-textbook can save you significant money, always important to starving students, with the e-textbooks selling for half the price of the paper textbook. Coursesmart provides extensive tools to make their e-textbooks that much more useful, like search, go to page X, notes you can add to any point in the book, highlighting any section you wish, or undoing the highlighting, copy, paste, and even printing pages out on demand. These are certainly powerful tools, that many students have wished they had with the paper textbooks.

However, there are certain limitations to the system. You can only download your e-textbook to one computer, and there is little indication of the process for getting another book through Coursesmart if your computer hardware fries. On the other hand, you can choose to access the e-textbook through Coursesmart’s website, and have it available on any computer, as long as you have a supported browser. In addition, the e-textbook will only be available for 180 days, which is certainly long enough to outlast your classes.

To obtain and use e-textbooks, you must first check if the professor for your course is okay with the students using e-textbooks. If so, the book for your course will also have a second tag, listing an e-textbook for purchase. Then you inform the cashier you are buying the e-textbook, and follow the cashier’s instructions. You will receive a receipt with a code on it, and a URL to visit. This URL, at press-time, was http://www.coursesmart.com/redemption?coupon= where you place the PIN after the equal sign.

Follow the instructions at Coursesmart, and choose whether to download the e-textbook, or access it online through Coursesmart’s website. You cannot choose both. Downloading the e-textbook will require the download and installation of Coursesmart’s Bookshelf software. Both downloading and accessing the book through Coursesmart’s website offer the exact same functionality.

The other process is to sign up with Coursesmart directly, find the book for your course, and buy it through them.

There is also a limitation on printing with Coursesmart’s e-textbook. You can only print ten(10) pages at any one time, for a maximum of 150% of the total pages in the textbook. So if the textbook has 200 pages, you can print a total of 300 pages. Coursesmart acknowledges there may be a bug that occurs sometimes with printing, where a user will run out of their allowed pages, at which point, you can contact Coursesmart’s customer service to enable more pages to print.

Coursesmart’s e-textbooks provide a cheap, planet-conscious, weight-less alternative to expensive, dead-tree, and heavy textbooks. This, obviously, comes with some restrictions, which depending on the person can be reasonable, or completely unreasonable. Itis up to the students to decide what is the best option for them. It can certainly be useful to buy an e-textbook for a course that isn’t one’s major, but is still required by the university.

An economic look at DRM

2009-09-12T14:59:17+00:00

This morning, I saw a slashdot article, this one, where an indie game developer mentions the free-rider problem in regards to DRM. The problem is, there is a significant misunderstanding of the free-rider problem and how DRM deals with it(hint, it doesn’t).

The free-rider problem is an issue in economics and game theory, where someone is able to get a free-ride off of the effort of others. One example is where you have two trappers. Now, if both trappers work hard on their own traps, they’ll each come out ahead at about three resources each. However, if one trapper decides to poach the other trapper’s lines, then that trapper gets six resources. If they both poach, neither gets anything. Typical self-interest says that it is better to poach than to trap, as there is a possibility of getting more resources, for less effort. However, in terms of the collective interests of both trappers, its better if neither poaches. Because there is a very real risk that if both trappers poach, then neither gets anything, and this is an extremely negative outcome. Usually, people spend the effort, or the cost to get the benefits because of the risks associated with free-riding(like jail-time for theft and fraud).

So in terms of piracy, if everyone free-rides, then everyone loses in the end. This is fairly understandable to all pirates, regardless of reason. However, free-riders exist in any system where there will be a possibility of free-riding. Theft will always exist. Fraud will always exist. The incentives and motivations are too great. The question is, how much do the free-riders cost you, and if everyone that pirates really is a free-rider?

One of the central fallacies used by DRM proponents is that every act of piracy, is a lost sale. This is, frankly, wrong. Its a very complex situation, but it can be broken down. Lets consider a customer and an artist. The artist produces a work that is either good or bad. The artist only profits when someone buys a work. A customer, however, may have money, or may not have money now(student for example). So if a customer has money, and they choose to buy, there is basically two outcomes: where the work is good, and both benefit, or where the work is bad, and only the artist benefits. It can be hard to determine if something is worth buying these days with such varied tastes, and such varied levels of quality. Now, imagine if the customer with money pirates instead. There are three outcomes here. One where if the work is good, the customer will buy it or something else from the artist, and thus, both profit. If the work is bad, the customer will not buy anything, and thus saves their money. And finally, the customer doesn’t care, and doesn’t buy anything from the artist either way. This is where a lost sale happens. Not when the customer pirates, but when it doesn’t matter what the quality of the work is, they will still pirate the work.

There is also the alternate side, where a customer doesn’t have money now. This is what artists should be concerned about. Lets say the poor customer doesn’t pirate. They have no money, so they can’t do a lot of social activities, and so they basically end up bored. There are of course libraries and that, so we’ve changed the behavior of our customer to that of someone that contributes nothing negative or positive to the situation. However, if the poor customer pirates instead, there are four possible outcomes. The first is where the work is good, and the poor customer saves up/earns the money to buy from the artist. Both profit in that instance. Or, the poor customer spreads the word of mouth about the product, and gets others, with money, to buy it. This is potentially a situation where the artist can gather many new customers, because word of mouth is hard to quantify at exactly how much of a benefit the artist will gain. Then there is the instance where the poor customer discovers the product is bad. The poor customer profits, in that they don’t waste theirs or others money on a product not worth the money. And finally, the instance where it doesn’t matter, the poor customer will pirate anyways, and there will be no profit for the artist.

This can all be summed up by a simple picture:

Nash Equilibrium of Piracy

Basically, the artist fails to understand the motivations of the customer, namely that they don’t want to waste money on crappy works. So its to the customer’s benefit to pirate, even if they have the money, as the risks are minimized for them. For the artist, its to their benefit to produce something good, and worthy of the money. So unfortunately, what DRM does is it messes up this equilibrium, where customers end up spending money on products they want to buy, and the artists have a good incentive to produce good works. DRM forces customers to waste money, and the artist has spent a significant amount of money doing this. The costs outweigh the benefits, which to be frank, were dubious in the first place. The artist spends money and effort on a DRM system which is easily circumvented, as long as someone finds it worthwhile to do so.

This is done for a variety of reasons, ranging from the invasiveness of the DRM, to just the technical challenge of doing so. There is also a possibility that the DRM makes the product worse, and the pirates wish to work around this. By placing DRM in the way, the artist creates an incentive to break it. So either the DRM doesn’t get in the way, and works perfectly, or don’t use DRM.

Essentially, the way to deal with piracy isn’t DRM, but in making good stuff. If you make good stuff, and don’t place technical barriers in the way, you create a strong incentive for customers to pay for your work. Even better, instead of letting people evaluate the works via piracy, provide representative samples, that are constantly changed, 100% free, and good quality. An example would be providing two songs from an album, along with short samples of the other songs. This helps the customer see that it is worth the money on the album, especially if buying each song individually is more than buying the album. Or, just sell the songs individually.

GSoC ends, but work goes on

2009-09-11T13:47:15+00:00

Well GSoC came to an end. Thanks to my supportive mentor, Seth Lemons, for grading my work as satisfactorily meeting the intial requirements, and thus making my GSoC work a success.

But the work doesn't come to an end here. I plan on keeping this blog alive. Though got really busy for the past couple of weeks, with college coming to an end, project thesis presentations, shifting to a new place, setting up the new place... it was pretty much a mess.

Now, I've plans to work on my fork of figleaf. I made the C and Python report integration work properly, but the tool needs to be made user friendly. I still haven't submitted the patches for the test suite of Py3k that I wrote, need to get feedback from devs on that, and write more tests in the meanwhile.

GSoC was a great gateway into the world of core Python development, and I plan to make a good use of it, for the long term.

Keep expecting updates.

Belgium media and police still not entirely sure just how the internetz work...

2009-09-09T15:32:33+00:00

I was quite shocked this morning when I read on deredactie.be about a terror alert aimed at a local school in the Belgium city “Mechelen”. A total of 333 police agents where dispatched, 9 arrest where made and there was even a helicopter circling the airspace in search of possible killers.

Only later this day I learned that the source of all this commotion, was a message posted on 4chan.org saying: “293 days to go until I strike at KTA Lyceum Mechelen, watch the news”.

That’s correct, 4chan the internet community famous for several internet memes like Rick’Roll, Chocolate Rain, the Sarah Palin email hack, spamming YouTube with porn, claiming Steve Job died of a heart attack, spamming the swastika symbol into Google Hot Trends, the Project Chanology, the pedo bear, threatening to bomb several football stadiums with dirty bombs, posting pictures of mock pipe bombs, and several other ‘joke’ threads.

Well on this 4chan someone threatens to harm a school almost 9 months after the posting the actual message on a site that could be considered the social dumpster of the internet. The only thing this overreaction the can ensure is just more jokes of 4chan….

asmeurer

2009-09-07T06:49:12+00:00

Sorry about the extreme delay with this. I of course have been busy with classes.

Note that this will just be a summary of the summer, with my comments looking back on it. If you want more details on each individual thing that I implemented, look back on my previous blog posts.

Let me start from the beginning. Around late February to early March of this year, I discovered the existence of Google Summer of Code. I knew that I wanted to do some kind of work this summer, preferably an internship, so it piqued my interest. At that time, the mentoring organizations were still applying for GSoC 2009, so I could only look at the ones from 2008. Most of them were either Linux things or Web things, neither of which I had any experience in or am I much interested in. I took a free course in Python at my University the previous semester, and it was the programming language that I knew best at the time. I had learned some Java in my first semester CS class (did I mention that this was my first year at college?), and I hated it, and I was still learning C for my second semester CS class. So I looked at what the Python Foundation had to offer. I am a double major in math and computer science, so I looked under the math/science heading. That’s when I saw SymPy.

I should not that I have been ahead in Math. It was my second semester, and I was taking Discrete Mathematics, Ordinary Differential Equations, Basic Concepts of Math, and Vector Analysis. So I looked for project ideas on the SymPy page that related to what I knew. The only one that I saw, other than core improvements, was to improve the ODE solving capabilities. I got into contact with the community and looked at the source, finding that it was only capable of solving 1st order linear equations and some special cases of 2nd order linear homogeneous equations with constant coefficients. I already at that point knew several methods from my ODE course, and I knew much of what I would learn.

Application Period
The most difficult part of the Google Summer of Code, in my opinion, is the application period. For starters, you have to do it while you are still in classes, so you pretty much have to do it in your free time. Also, if you have never applied for Google Summer of Code before, you do not really know what a good application should look like. I have long had my application available on the SymPy Wiki, and I will reference it here a few times. First off, it was recommended to me by some of the SymPy developers that I put as many potential things that I could do in the summer in my application as I though I could do. I was still only about half way through my ODEs course when I wrote the application, but I had the syllabus so I knew the methods I would be learning at least by name. So that is exactly what I did: I packed my application with every possible thing that I knew we would be learning about in ODEs.

After I felt that I had a strong application, and Ondrej had proofread it for me, I submitted it. There were actually two identical applications, one for the Python Software Foundation, and one for Portland State University. This is because SymPy was not accepted as a mentoring organization directly, so they had to use those two foundations as proxies. A requirement of acceptance is to submit a patch that passes review. I decided to add a Bernoulli solver, because Bernoulli can be solved in the general case much like the 1st order linear ODE, which was already implemented.

After I applied, there was an acceptance period. I used that period to become aquatinted with the SymPy community and code base. A good way to do this is to try to fix EasyToFix issues. I found issue 694, which is to implement a bunch of tests from a paper by Michael Wester for testing computer algebra systems. The tests cover every possible thing that a full featured CAS could do, so it was a great way to learn SymPy. The issue is still unfinished, so working on it is still a good way to learn how to use SymPy.

Also, it was important to learn git, SymPy’s version control system. The learning curve it pretty steep if you have never used version control system before, but once you can use it, it becomes a great tool at your disposal.

Acceptance
After being accepted, I toned down my work with SymPy to work on finishing up my classes. My classes finished a few weeks before the official start, so I used that period to get a jump start on my project.

The GSoC Period
For the start of the period, I followed my timeline. I implemented 1st order ODEs with homogeneous coefficients and 1st order exact ODEs. These were both pretty simple to do, as I expected.

The next thing I wanted to do was separable. My goal at this point was to get every relevant exercise from my textbook to work with my solvers. One of the exercises from my book (Pg. 56, No. 21) was . I soon discovered that it was impossible for SymPy to separate , because the second would be automatically combined in the core. I also discovered that expand(), which should have been the function to split that, expanded using all possible methods indiscriminately. Part of my separatevars() function that I was writing to separate variables in expressions would be to split things like and , but expand()
as it was currently written would expand those.

So I spent a few weeks hacking on the core to make it not auto-combine exponents. I came up with a rule that exponents would only auto-combine if they had the same term minus the coefficient, the same rule that Add uses to determine what terms should auto combined by addition. So it would combine , but would be left alone. It turns out that some of our algorithms, namely the Gruntz limit algorithm, relies on auto-combining. We already had a function that could combine exponents, powsimp(), but it also combined bases, as in , so I had to split the behavior so that it could act only as auto-combining once did (by the way, use powsimp(expr, combine='exp', deep=True) to do this). Then, after some help from Ondrej on pinpointing the exact location of the bugs, I just applied the function there. The last thing I did here was to split the behavior of expand, so that you could do expand(x*(y + 1), mul=False) and it would leave it alone, but expand(exp(x + y), mul=False) would return exp(x)*exp(y). This split behavior turned out to be useful in more than one place in my code.

This was the first non bug fix patch of mine that was pushed in to SymPy, and at the time of this writing, it is the last major one in the latest stable version. It took some major rebasing to get my convoluted commit history ready for submission, and it was during this phase that I git finally clicked for me, especial the git rebase command. This work took a few weeks from my ODEs time, and it became clear that I would not be doing every possible thing from my application. The reason that I included so much in my application was that my project was non-atomic. I could implement a little or a lot and still have a working useful module.

If you look at my timeline on my application, you can see that the first half is symbolic methods, and the second half is other methods, things like series. It turns out that we didn’t really learn much about systems of ODEs in my course and we learned very little about numerical methods (and it would take much more to know how to implement them). We did learn series methods, but they were so annoying to do that I came to hate them with a passion. So I decided to just focus on symbolic methods, which were my favorite anyway. My goal was to implement as many as I could.

After I finished up separable equations, I came up with an idea that I did not have during the application period. dsolve() was becoming cluttered fast with all of my solution methods. The way that it worked was that it took an ODE and it tried to match methods one by one until it found one that worked, which it then used. This had some drawbacks. First, as I mentioned, the code was very cluttered. Second, the ODEs methods would have to be applied in a predetermined order. There are several ODEs that match more than one method. For example, has coefficients that are both homogeneous of order 2, and is also exact, so it can be solved by either method. The two solvers return differently formatted solutions for each one. A simpler example is that 1st order ODEs with homogeneous coefficients can be solved in two different ways. My working solution was to try them both and then apply some heuristics to return the simplest one. But sometimes, one way would create an impossible integral that would hand the integration engine. And it made debugging the two solvers more difficult because I had to override my heuristic. This also touches on the third point. Sometimes the solution to an ODE can only be represented in the form of an unevaluatable integral. SymPy’s integrate() function is supposed to return an unevaluated Integral class if it cannot do it, but all too often it will just hang forever.

The solution I came up with was to rewrite dsolve using a hints method. I would create a new function called classify_ode() that would do all of the ODE classification, removing it from the solving code. By default, dsolve would still use a predetermined order of matching methods. But you could override it by passing a “hint” to dsolve for any matching method, and it would apply that method. There would also be options to only return unevaluated integrals when applicable.

I ended up doing this and more (see the docstrings for classify_ode() and dsolve() in the current git master branch), but before I could I needed to clean up some things. I needed to rewrite all of dsolve() and related functions. Before I started the program, there were some special cases in dsolve for second order linear homogeneous ODEs with constant coefficients and one very special case ODE for the expanded form of .

So the first thing I did was implement a solver for the general homogeneous linear with constant coefficients case. These are rather simple to do: you just find the roots of the characteristic polynomial built off of the coefficients, and then put the real parts of the roots in front of the argument of an exponential and the imaginary parts in front of the arguments of a sine and cosine (for example, would give . The thing was, that if the imaginary part is 0, then you only have 1 arbitrary constant on the exponential, but if it is non-zero, you get 2, one for each trig function. The rest falls out nicely if you plug 0 in for into $e^{ax}(C1\sin{bx} + C2\cos{box})$ because the sine goes to 0 and the cosine becomes 1. But you would end up with instead of just in that case. I had already planned on doing arbitrary constant simplification as part of my project, so I figured I would put this on hold and do that first. Then, once that was done, the homogeneous case would be reduced to 1 case instead of the usual 2 or 3.

My original plan was to make an arbitrary constant type that automatically simplified itself. So, for example, if you entered C1 + 2 + x with C1 an arbitrary constant, it would reduce to just C1 + x. I worked with Ondrej, including visiting him in Los Alamos, and we build up a class that worked. The problem was that, in order to have auto-simplification, I had to write the simplification directly into the core. Neither of us liked this, so we worked a little bit on a basic core that would allow auto-simplification to be written directly in the classes instead of in the Mul.flatten() and Add.flatten() methods. It turns out that my constant class isn’t the only thing that would benefit from this. Things like the order class (O(x)) and the infinity class (oo) are auto-simplified in the core, and things could be much cleaner if they happened in the classes themselves. Unfortunately, modifying the core like this is not something that can happen overnight or even in a few weeks. For one thing, it needed to wait until we had the new assumptions system, which was another Google Summer of Code project running parallel to my own. So we decided to shelf the idea.

I still wanted constant simplification, so I settled with writing a function that could do it instead. There were some downsides to this. Making the function as general as the classes might have been would have been far too much work, so I settled on making it an internal-only function that only worked on symbols named C1, C2, etc. Also, unlike writing the simplification straight into Mul.flatten() which was as simple as removing any terms that were not dependent on x, writing a function that parsed an expression and simplified it was considerably harder to write. I managed to churn out something that worked, and so I was ready to finish up the solver I had started a few paragraphs ago.

After I finished that, I still needed to maintain the ability to solve that special case ODE. Apparently, it is an ODE that you would get somewhere in deriving something about relativity, because it was in the relativity.py example file. I used Maple’s excellent odeanalyser() function (this is where I go the idea for my classify_ode())to find a simple general case ODE that it fit (Liouville ODE). After I finished this, I was ready to start working on the hints engine.

It took me about a week to move all classification code into classify_ode(), move all solvers into individual functions, separate simplification code into yet other functions, and tie it all together in dsolve(). In the end, the model worked very well. The modularization allowed me to do some other things that I had not considered, such as creating a special “best” hint that used some heuristics that I originally developed for first order homogeneous which always has two possible solutions to try to give the best formatted solution for any ODE that has more than one possible solution method. It also made debugging individual methods much easier, because I could just use the built in hint calls in dsolve() instead of commenting out lines of code in the source.

This was good, because there was one more method that I wanted to implement. I wanted to be able to solve the inhomogeneous case of a nth order linear ode with constant coefficients. This can be done in the general case using the method of variation of parameters. It was quite simple to set up variation of parameters up in the code. You only have to set up a system of integrals using the Wronskian of the general solutions. It would usually be a very poor choice of a method if you were trying to solve an ODE by hand because taking the Wronskian and computing n integrals is a lot of work. But for a CAS, the work is already there. I just have to set up the integrals.

It soon became clear that even though, in theory, the method of variation of parameters can solve any ODE of this type, in practice, it does not always work so well in SymPy. This is because SymPy have very poor simplification, especially trigonometric simplification, so sometimes there would be a trigonometric Wronskian that would be identically equal to some constant, but it could only simplify it to some very large rational function of sines and cosines. When these were passed to the integral engine, it would cause it to fail, because it could not find the integral for such a seemingly complex expression.

In addition, taking Wronskians, simplifying them, and then taking n integrals is a lot of work as I said, and even when SymPy could do it, it took a long time. There is another method for solving these types of equations called undetermined coefficients that does not require integration. It only works on a class of ODEs where the right hand side of the ODE is a simple combination of sines, cosines, exponentials, and polynomials in x. It turns out that these kinds of functions are common anyway, so most ODEs of this type that you would encounter could be solved with this method. Unlike variation of parameters, undetermined coefficients requires considerable setup, including checking for different cases. This would be the method that you would want to use if you had to solve the ODE by hand because, even with all the setup, it only requires solving a system of linear equations vs. solving n integrals with variation of parameters, but for a CAS, it is the setup that matters, so this was a difficult prospect.

I spent the last couple of weeks writing up the necessary algorithms to setup the required system of linear equations and handling the different cases. After I finally worked out all of the bugs, I ran some profiling against my variation of parameters solver. It turned out that for ODEs that had trigonometric solutions (which take longer to simplify), my undetermined coefficients solver was an order of magnitude faster than the variation of parameters solver (and that is just for the ODEs that the variation of parameters engine could even solve at all). For ODEs that only had exponentials, it was still 2-4 times faster.

I finished off the summer by writing extensive documentation for all of my solvers and functions. Hopefully someone who uses SymPy to solve ODEs can learn something about ODE solving methods as well as how to use the function I wrote when they read my documentation.

Post-GSoC
I plan on continuing development with SymPy now that the Google Summer of Code period is over. SymPy is an amazing project, mixing Python and Computer Algebra, and I want to help it grow. I may even apply again in a future year to implement some other thing in SymPy, or maybe apply as a mentor for SymPy to help someone else improve it.

Advice
What follows is some general advice for someone who wants to apply for Google Summer of Code. Some of the advice pertains specifically to SymPy, and some of it is general advice that I think would apply to any project.

- Get involved early. As soon as you decide that you want to participate in Google Summer of Code, start getting involved in the project. Get into contact with them and discuss possible projects. If you are looking before the participating organizations are announced, look at the organizations from previous years. For some organizations, it will vary; for others (like Python), it is almost given that they will be accepted every year.

- Some projects (including SymPy) require you to send in a patch that passes review to be accepted. This will give you a change to start familiarizing yourself with the code base. If you are applying to SymPy, the Wester example I mentioned above is a really good way to learn what SymPy can do and how it works.

- Subscribe to the mailing list, and once you are comfortable with it, participate. Also, it is a good idea to idle in IRC (SymPy is on freenode at #sympy). This will help you get to know the main contributors for the project.

- For you application, see if the people in the project you are applying for will review it. If they like your project idea, they will try to help you write a good application so you can be accepted and you can implement it. If they don’t like your idea, then they will tell you and you should change it, otherwise you will not be accepted, no matter how well written your proposal is. I have my proposal on the wiki (see link above). I am not saying that it is necessarily a very good proposal, but it did get accepted. If you are applying to SymPy, Ondrej will proofread your applications for you.

- If you are an IRC fan, there is also #gsoc on freenode, where you can ask all your GSoC related questions. Be warned that it does get pretty noisy in the application period, especially right before the applications are due and right before proposals are accepted.

- I cannot stress this one enough. If you have never worked with a version control system before, it is perhaps more important to spend your time learning it than it is to learn the code base for your project. These things have a steep learning curve if you have never used them before. Once you master them though, they can make your life much easier. Also, the sooner you learn to use them well, the easier your life will be later on down the road. I spent a good part of the last week of GSoC cleaning up my commit history from the first half of the summer when I bad very poor committing/log habits. If your project uses git, such as SymPy does, you might look at this tutorial. If it uses something else, good luck. Seriously, git is the only good version control system. See this video.

- Expect to spend only about half of the summer actually implementing stuff. You may think that you are a good programmer and that your code will not be so buggy that you will need to spend that much time fixing bugs, and you may be right. But the fact is, you will be working on code bases written by may programmers that are not so good. You will need to fix several already existing bugs to make your code work, which means that you will need to learn the code base well, learn how to read other people’s code, and how to fix bugs that you had no part in creating. You will be glad if a bug is in your code because you will usually know immediately what causes it and how to fix it. But if a bug is somewhere else, you will need to find it, figure out why it happens, what is supposed to happen, and how to fix it without breaking anything else. This is also why it is important to be active in the developer community.

- Good luck.

Summer of Code is over

2009-09-05T10:21:17+00:00

Google Summer of Code program is officially over. It has been four months of intense work, exciting benchmarks and patch reviewing. It was a huge pleasure working with you guys!

As for the project, I implemented a complete logic module and then an assumption system for sympy (sympy.logic, sympy.assumptions, sympy.queries). I even had time to make the logic module fast. On top of this, there’s the refine module. It is there where you can see some nice examples and where all the power of sympy.queries and sympy.logic is exposed.

Although this sounds good, there are some things that I did not complete on time. I could not remove the old assumption system. There are simply too many things that depend on this to remove it on one move. However, I agreed with Ondrej that we both would be working on this the days 15-30 September. This has to be done because we definitely do not want to make a sympy release with two different assumption systems!

PD: a more detailed report lives here

scikits.statsmodels Release Announcement

2009-08-31T23:01:23+00:00

We have been working hard to get a release ready for general consumption for the statsmodels code. Well, we're happy to announce that a (very) beta release is ready.

Background
==========

The statsmodels code was started by Jonathan Taylor and was formerly included as part of scipy. It was taken up to be tested, corrected, and extended as part of the Google Summer of Code 2009.

What it is
==========

We are now releasing the efforts of the last few months under the scikits namespace as scikits.statsmodels. Statsmodels is a pure python package that requires numpy and scipy. It offers a convenient interface for fitting parameterized statistical models with growing support for displaying univariate and multivariate summary statistics, regression summaries, and (postestimation) statistical tests.

Main Feautures
==============

* regression: Generalized least squares (including weighted least squares and least squares with autoregressive errors), ordinary least squares.
* glm: Generalized linear models with support for all of the one-parameter exponential family distributions.
* rlm: Robust linear models with support for several M-estimators.
* datasets: Datasets to be distributed and used for examples and in testing.

There is also a sandbox which contains code for generalized additive models (untested), mixed effects models, cox proportional hazards model (both are untested and still dependent on the nipy formula framework), generating descriptive statistics, and printing table output to ascii, latex, and html. None of this code is considered "production ready".

Where to get it
===============

Development branches will be on LaunchPad. This is where to go to get the most up to date code in the trunk branch. Experimental code will also be hosted here in different branches.

https://code.launchpad.net/statsmodels

Source download of stable tags will be on SourceForge.

https://sourceforge.net/projects/statsmodels/

or

PyPi: http://pypi.python.org/pypi/scikits.statsmodels/

License
=======

Simplified BSD

Documentation
=============

The official documentation is hosted on SourceForge.

http://statsmodels.sourceforge.net/

The sphinx docs are currently undergoing a lot of work. They are not yet comprehensive, but should get you started.

This blog will continue to be updated as we make progress on the code.

Discussion and Development
==========================

All chatter will take place on the or scipy-user mailing list. We are very interested in receiving feedback about usability, suggestions for improvements, and bug reports via the mailing list or the bug tracker at https://bugs.launchpad.net/statsmodels.

2009-08-31T11:10:23+00:00

This will probably be my last post for the project. Id like to thank again my mentor Chis Mueller and backup mentor Stéfan van der Walt, I think they did a lot in helping to make this project happen in the first place.

I've written a bunch of documentation on the CorePy wiki (a lot of it came from the code/README):

http://corepy.org/wiki/index.php?title=CoreFunc

When any updates to this work occur, the wiki page will be updated.

The SciPy talk went pretty well I think, though I wish I had more than 10 minutes to talk. A lot of important things got left out, and I felt there were places I didn't explain things very well. Even so, it was great to be able to go to SciPy and give a talk -- thanks to the people who make SciPy happen! There seemed to be quite a few people interested in CorePy; I had quite a few questions and had some nice discussions with various people.
Slides:
http://www.osl.iu.edu/~afriedle/presentations/scipy-corepy-afriedle.pdf

Video recording of my actual talk:
http://www.archive.org/details/scipy09_day1_08-Andrew_Friedley

As promised I used the CoreFunc framework to update Chris' particle simulation demo. Pretty cool stuff -- I was able to move the entire particle position/velocity update calculation into a ufunc. At 200,000 particles I was seeing ~100x speedup over the pure NumPy version, though my measurement wasn't particularly scientific. Check out the glparticle-cf.py file in the project repository/branch (listed in an earlier post).

New Computer

2009-08-29T21:39:01+00:00

Well GSoC is officially finished but there is still work to do. The connection for the whiteboard still needs to be closed, and there are many GUI-related problems. Unfortunately I don’t think I will be able to commit for a while because I just bought a new computer (asus G51VX-A1) and I need to install the dev environment on it. Also, I am going back to school in two days and it will be hectic until classes start.

I’m currently trying to get an internship for third year, or third year summer. This seems interesting

GSoC Is Over

2009-08-27T20:59:32+00:00

Whoa, where did the last month go? The Google Summer of Code 2009 officially ended this Monday. Though I haven't taken a breath to update the blog, we (Josef and I) have been hard at work on the models code.

We have working and tested versions of Generalized Least Squares, Weighted Least Squares, Ordinary Least Squares, Robust Linear Models with several M-estimators, and Generalized Linear Models with support for all (almost all?) one parameter exponential family distributions. We have also provided some more convenience functions, created a standalone python package for the models code, and obtained permissions to distribute a few more datasets. Due to a lack of time, there is only experimental (read untested) support for autoregressive models, mixed effects models, generalized additive models, and convenience functions for returning strings (possibly html and latex output as well) with regression results and descriptive statistics. I will continue to work on these as I find time.

I will soon post a note on the progress that was made in the robust linear models code. Also, look out for a (semi-) official release of the code in the next few days. We have decided to name the project statsmodels and distribute it as a scikit. We need to finalize the documentation (should be ready to go in the next day or so...I am back taking courses) and clean up some of the usage examples, so people can jump right in and use the code, give feedback, and hopefully contribute extensions and new models.

As for the future of statsmodels, we are discussing over the next few weeks the immediate extensions that we know would like to make. It's looking like I will be wearing my microeconometrician hat this semester in my own coursework. More specifically, I will probably be working with cross-sectional and panel data models for household survey data in my own research and finding some time for time series models as part of my teaching assistantship. Josef has also mentioned wanting to work more with time series models.

If anyone (especially those from other disciplines) would like to contribute or see some extensions (my apologies to those who have made requests that I haven't yet been able to accomodate) feel free to post to the scipy-dev mailing list. I'm more than happy to discuss/debate with users and potential developers the design decisions that have been made, as I think the code is still in an unsettled enough state to merit some discussion.

Python keyring lib, new blog address

2009-08-26T09:38:00+00:00

After three days full-time working on Java and ActionScript 3.0, I finally get time to write a post about recent news.

#1 Python keyring lib released
We've released python keyring lib four days ago. It's exciting to see my work get released, and I've created a site for it.

Address of the site: http://home.python-keyring.org

You can find our mailing list, documentation page, repository and issue list on the site. If you've any advice or question, don't hesitate to tell us.
Someone reported installation problems on our tracker. I'll try to fix these bugs and release v0.2 at this weekend.

I'd like to thanks Tarek again for his great help on this project. I've learned a lot from him on this project, and I'll continue with the project to make it better. A new post about the tips and experiences I've got in this summer will be published later, when I get a new break. :-)

#2 New domain name for this blog and new homepage for myself
I'm going to move this blog to http://blog-en.kangzhang.org. To let the subscribers of this blog see this post and re-subscribe it at new address, it will be ready after the next 12 hours. (I really miss Tarek's Atomisator now.)
http://home.kangzhang.org is also available now.

New examples of use with PyDy

2009-08-24T05:11:54+00:00

In the last several days I’ve made a lot of updates to tools for using PyDy and have come very close to settling on the way that PyDy is used to derive the equations of motion. I have added and updated several examples, including the double pendulum and a rigid body with two reaction wheels used for attitude control. Animations for each example have been added using visual python, so visualization of the dynamics is very tangible.

There are two main things that I am still trying to iron out with PyDy. The first is how to handle ignorable coordinates and how to allow for the user to control whether or not they are included in the output equations of motion. For example, for the symmetric rolling disc, there are 4 ignorable coordinates: two for the location in the ground plane, one for the heading and one for the spin. For purposes of stability analysis, the kinematic differential equations associated with these coordinates are not needed. However, for purposes of animation, these equations are needed. My goal is to make it easy to clearly specify whether or not these equations are desired in the output equations.

The second major thing that still needs work is handling dependent generalized speeds in nonholonomic systems. When the motion equations are generated, they will involve these dependent generalized speeds, and their time derivatives, but these quantities can be computed from the constraint equations and therefore can be left implicit in the final equations of motion. The derivatives of the dependent generalized can be intelligently computed by some careful formations of the gradients of the components of the matrix that relates the dependent speeds to the independent ones.

I will be working on both of these tasks this week and will be writing examples for the Whipple bicycle model in addition to a spinning top and the rattleback.

freemalloc

2009-08-24T03:47:42+00:00

I’m glad to say that my Google Summer of code project was successful, despite the features that didn’t make it in fwrap by August 17th.

Oh, yeah — if you’re wondering what ‘fwrap’ is, that’s the new name of ‘f2cy’. The rebranding was appropriate since ‘f2cy’ didn’t quite capture all that the utility does. fwrap wraps fortran for a number of languages (C, Cython & Python), so ‘f2cy’ was deemed a misnomer since it seems to wrap fortran just for cython, besides the confusion with ‘f2py’.

fwrap was presented at the SciPy 2009 conference, and I was glad to find a good amount of interest; two (Kyle & Chris) stepped up to work on fwrap once I can get it to a state that’s comprehensible They work on a code called ‘clawpack’ at the U-Washington, and want to use fwrap for their ‘pyclaw’ version of clawpack. But I’m getting ahead of myself.

Here’s where you can find the presentation abstract (note that it was written early June — its heavy on promised features that didn’t all make it in fwrap by August 17th), and here are the talk slides. The presentation itself is here.

What’s the state of fwrap? It can handle scalar arguments with aplomb. Assumed-shape arrays are working. Explict-shaped & assumed-size arrays are soon to come. I’m sketching out callbacks as we speak (a feature that Kyle & Chris are particularly interested in).

The parser used by fwrap needs stabilization — some obvious things need work (public/private module attributes), and I’m finding out just how unruly the full Fortran language specification is. The language allows you to be expulsively verbose & clunky (‘integer(kind=FOOBAR), intent(in), dimension(2) :: an_int_array’) — yet difficult to fully parse, since each attribute (‘intent,’ ‘dimension,’ ’save,’ etc.) can instead be a statement on a line a ways away from the actual ‘integer an_int_array’ line; or you can be cryptic & bug-prone by using the implicit declaration anti-feature well-hated by all those who have ever had a misspelled variable in their code.

The above rant is a long way of saying that there are many little things that fparser chokes on. This is not to be interpreted as a complaint with fparser — I’m grateful for all of Pearu’s work thus far on it, and for his ambition to tackle parsing such a barnacled language. He has graciously opened up fparser to me to work on it, and has allowed us to package fparser with fwrap. Thanks, Pearu!

Anyway, work on fwrap will be a bit slow for the next week or two, as I turn my full attention to my research. But I’m energized and motivated to get the first release out before 2010.

Speed improvements for ask() (sympy.queries.ask)

2009-08-19T22:36:36+00:00

I managed to overcome the overhead in ask() that arises when converting between symbol and integer representation of sentences in conjunctive normal.

The result went beyond what I expected. The test suite for the query module got 10x times faster in my laptop. From 26 seconds, it descended to an impressive 2.03 secs. There is still room for improvement, but it is no longer “so desperately slow”.

I’ll submit those patches soon to sympy’s trunk, but in the meantime they are in my logic branch:

git pull http://fseoane.net/git/sympy.git logic

gminick

2009-08-19T16:59:05+00:00

(Most up-to-date version is located in the repository on bitbucket)

Sphinx comments/fixes web application

Sphinx provides you with a feature of building your documentation as a web application, which gives you a way to interact with your users.

Users are permitted to submit comments as well as their fixes for the documentation. Developers have additional rights of deleting comments/fixes and committing fixes to the documentation repository.

Building a webapp along with documentation

Building your documentation along with a web application, which will serve it, is almost as simple as building the documentation itself.

1. Start a new Sphinx project:

$ mkdir sphinx-project

$ cd sphinx-project

$ sphinx-quickstart

[ ...usual sphinx-quickstart questions... ]

2. The documentation is empty as for now. Create at least one file with some content. Now, you can build a webapp which will serve your documentation:

$ make webapp

[...]

Build finished. The webapp HTML pages are in _build/webapp.

3. Run the server:

$ cd _build/webapp/

$ python server.py

Running at 127.0.0.1:8000…

OK, there it goes. Now you can check it with web browser!

The webapp configuration file

The variables and values of webapp.conf file are based on conf.py file.

NOTE: Always change the values of variables in conf.py file.

licence – A name of the licence for fixes submitted by the users. Default is ‘BSD’.

reporoot – The name of a directory in which the repository files should be located in build directory. Default is ‘repo’.

repodir – If the documentation is located in a subdirectory of a repository, this should be a directory name of the documentation. For example, when the files for Sphinx are copied/cloned to reporoot directory, the directory for documentation in the repository is: _build/webapp/repo/doc/, because the documentation for Sphinx is held in sphinx/doc directory. Default is doc, which works well for Sphinx, but may fail for your project. Please, change it accordingly.

repopath – This variable is only visible in webapp.conf file. Its value is created by joining reporoot and repodir values.

reposums – A filename for MD5 sums of files from the repository. Default is reposums.pkl.

piddbfile – A filename for a database which sorts paragraphs by repository filename and paragraph ID. Default is piddb.pkl.

File structure of the build

After building your documentation, the _build/webapp/ directory gets populated with a number of directories and files.

Directories:

comments – a database for all the comments added to any paragraph.
fixes – a database for all the fixes added to any paragraph.
openidstore – OpenID logging database
html – HTML templates used by the webapp
public – your documentation generated by Sphinx
repo – source files of your documentation in a repository
xapian_db – a database for Xapian search engine

Files:

server.py – a simple WSGI server, useful for testing purposes
webapp.conf – a configuration file for the webapp (based on values from Sphinx’s conf.py file
developers.txt – a list of OpenIDs of users who should be granted developer’s rights
piddb.pkl – a database of paragraphs sorted by filename and paragraph ID
reposums.pkl – a database of MD5 sums for files in repo directory. Whenever a sum is not matching reality, the source file is rebuilt.

All for now, folks!

Logic module (sympy.logic): improving speed

2009-08-18T21:35:37+00:00

Today I’ve been doing some speed improvements for the logic module. More precisely, I implemented an efficient internal representation for clauses in conjunctive normal form.

In practice this means a huge performance boost for all problems that make use the function satisfiable() or dpll_satisfiable(). For example, test_dimacs.py has moved from 2.7 seconds to an impressive 0.3 sec, and ask() runs on average 3x times faster, although both problems still have an overhead because of the conversion to this new representation that can be avoided in most times.

Now, the details. Traditionally, dpll (the algorithm that we use for deciding satisfiability) used to store clauses as arrays of symbols, and this worked fine, but sadly comparing symbols in sympy is slow, and this algorithm does a lot of comparisons … but we can map each sympy symbol to a unique integer, and with minor modifications to the algorithm we get these performance gains.

Now, the code. You can pull from my branch logic:

git pull http://fseoane.net/git/sympy.git logic

There are now some obvious performance tweaks we can do:

- in ask(), we can skip the conversion to integer representation by ‘precompiling’ known_facts_dict into this representation. This should be easy and will probably give performance boosts of several orders of magnitude.

- this integer representation is very similar to the one used in dimacs CNF files, so a parser that directly converts CNF files to this integer representation should make solving CNF files much faster.

—

I would like to give some credit to Ronan Lamy, who sent a patch some time ago, and although I did not include it (yet) into main sympy branch, it inspired me for these modifications.

asmeurer

2009-08-17T22:33:00+00:00

[Sorry for the delay in this post. I was having some difficulties coming up with some of the rationales below. Also, classes have started, which has made me very busy.]

If there was one ODE solving method that I did not want to implement this summer, it was undetermined coefficients. I didn’t really like the method too much when we did it my my ODE class (though it was not as unenjoyable as series methods). The thing that I never really understood very well is to what extent you have to multiply terms in the trial function by powers of x to make them linearly independent of the solution to the general equation. We did our ODEs homework in Maple, so I would usually just keep trying higher powers of x until I got a solution. But to implement it in SymPy, I had to have a much better understanding of the exact rules for it.

From a user’s point of view, the method of undetermined coefficients is much better than the method of variation of parameters. While it is true that variation of parameters is a general method and undetermined coefficients only works on a special class of functions, undetermined coefficients requires no integration or advanced simplification, so it is fast (very fast, as well shall see below). All that the CAS has to do is figure out what a trial function looks like, plug it into the ODE, and solve for the coefficients, which is a system of linear equations.

On the other hand, from the programmer’s point of view, variation of parameters is much better. All you have to do is take the Wronskian of the general solution set and use it to set up some integrals. But the Wronskian has to be simplified, and if the general solution contains sin’s and cos’s, this requires trigonometric simplification not currently available in SymPy (although it looks like the new Polys module will be making a big leap forward in this area). Also, integration is slow, and in SymPy, it often fails (hangs forever).

Figuring out what the trial function should be for undetermined coefficients is way more difficult to program, but having finnally finished it, I can say that it is definitely worth having in the module. Problems that it can solve can run orders of magnitude faster than the variation of parameters, and often variation of parameters can’t do the integral or returns a less simplified result.

So what is this undetermined coefficients? Well, the idea is this: if you knew what each linearly independent term of the particular solution was, minus the coefficients, then you could just set each coefficient as an unknown, plug it into the ODE, and solve for them. It turns out that resulting system of equations is linear, so if you do the first part right, you can always get a solution.

The key thing here is that you know what form the particular solution will take. However, you don’t really know this ahead of time. All you have is the linear ode (as far as I can tell, this only works in the case where the coefficients are constant with respect to x. I’d be interested to learn that it works for other linear ODEs. At any rate, that is the only one that works in my branch right now.). The solution to the ode is , where is the solution to the homogeneous equation , and is the particular solution that produces the term on the right hand side. The key here is just that. If you plug into the left hand side of the ode, you get .

It turns out that this method only works if the function only has a finite number of linearly independent derivatives (I am unsure, but this might be able to work in other cases, but it would involve much more advanced mathematics). So what kind of functions have a finite number of linearly independent solutions? Obviously, polynomials do. So does , , and . Also, if we multiply two or more of these types together, then we will get a finite number of linearly independent solutions after applying the product rule. But is that all? Well, if we take the definition of linear independence from linear algebra, we know that a set of n vectors , not all zero, are linearly independent only if holds only when , that is, the only solution is the trivial one (remember, this is the definition of linear independence). They are linearly dependent if there exist weights , not all 0, such that the equation is satisfied. Using this definition, we can see that a function will have a finite number of linearly independent derivatives if it satisfies for some and with for some . But this is just a homogeneous linear ODE with constant coefficients, which we know how to solve. The solutions are all of the form or , where a, b, and c are real numbers and n is a non-negative integer. We can set the various constants to 0 to get the type we want. For example, for a polynomial term, b will be 0 and c will be 0 (use the cos term).

So this gives us the exact form of functions that we need to look for to apply undetermined coefficients, based on the assumption that it only works on functions with a finite number of linearly independent derivatives.

Well, implementing it was quite difficult. For every ODE, the first step in implementation is matching the ODE, so the solver can know what methods it can apply to a given ODE. To match in this case, I had to write a function that determined if the function matched the form given above, which was not too difficult, though not as trivial as just grabbing the right hand side in variation of parameters. The next step is to use the matching to format the ODE for the solver. In this case, it means finding all of the finite linearly independent derivatives of the ODE, so that the solver can just create a linear combination of them solve for the coefficients. This was a little more difficult, and it took some lateral thinking.

At this point, there is one more thing that needs to be noted. Since the trial functions, that is, the linearly independent derivative terms of the right hand side of the ODE, are of the same form as the solutions to the homogeneous equation, it is possible that one of the trial function terms will be a solution to the homogeneous equation. If this happens, plugging it into the ODE will cause it to go to zero, which means that we will not be able to solve for a coefficient for that term. Indeed, that term will be of the form in the final solution, so even if we had a coefficient for it, it would be absorbed into this term from the solution to the homogeneous equation. For example, variation of parameters will give a coefficient for such terms, even though it is unnecessary. This is a clue that Maple uses variation of parameters for all linear constant coefficient ODE solving, because it gives the unnecessary terms with the coefficients that would be given by variation of parameters, instead of absorbing them into the arbitrary constants.

We can safely ignore these terms for undetermined coefficients, because their coefficients will not even appear in the system of linear equations of the coefficients anyway. But, without these coefficients, we will run into trouble. It turns out that if a term or is repeated solution to the homogeneous equation, and or is not, so that is the highest power that makes it a solution to the homogeneous equation, and if the trial solution has or terms, but not or terms, so that is the highest power of in the the trial function terms, then we need to multiply these trial function terms by to make them linearly independent with the solutions of the homogeneous equation.

Most references simply say that you need to multiply the trial function terms by “sufficient powers of x” to make them linearly independent with the homogeneous solution. Well, this is just fine if you are doing it by hand or you are creating the trial function manually in Maple and plugging it in and solving for the coefficients. You can just keep upping the powers of x until you get a solution for the coefficients. Creating those trial functions in Maple, plugging them into the ODE, and solving for the coefficients is exactly what I had to do for my homework when I took ODEs last spring, and this “upping powers” trial and error method is exactly the method I used. But when you are doing it in SymPy, you need to know exactly what power to multiply it by. If it is too low, you will not get solution to the coefficients. If it is too high, you can actually end up with too many terms in the final solution, giving a wrong answer.

Fortunately, my excellent ODEs textbook gives the exact cases to follow, and so I was able to implement it correctly. The textbook also gives a whole slew of exercises, all for which the solutions are given. As usual, this helped me to find the bugs in my very complex and difficult to write routine. It also helped me to find a match bug that would have prevented dsolve() from being able to match certain types of ODEs. The bug turned out to be fundamental to the way match() is written, so I had to write my own custom matching function for linear ODEs.

The final step in solving the undetermined coefficients is of course just creating a linear combination of the trial function terms, plugging it into the original ODE, and setting the coefficients of each term on each side equal to each other, which gives a linear system. SymPy can solve these easily, and once you have the values of the coefficients, you can use them to build your particular solution, at which point, you are done.

The results were astounding. Variation of parameters would hang on many simple inhomogeneous ODEs because of poor trig simplification of the Wronsikan, but my undetermined coefficients method handles them perfectly. Also, there is no need to worry about absorbing superfluous terms into the arbitrary constants as with variation of parameters, because they are removed from within the undetermined coefficients algorithm.

But the biggest thing was speed. Here are some benchmarks on some random ODEs from the test suite. WordPress code blocks are impervious to whitespace, as I have mentioned before, so no pretty printing here. Also, it truncates the hints. The hints used are 'nth_linear_constant_coeff_undetermined_coefficients' and 'nth_linear_constant_coeff_variation_of_parameters':

In [1]: time dsolve(f(x).diff(x, 2) - 3*f(x).diff(x) - 2*exp(2*x)*sin(x), f(x), hint='nth_linear_constant_coeff_undetermined_coefficients')
CPU times: user 0.07 s, sys: 0.00 s, total: 0.08 s
Wall time: 0.08 s
Out[2]:
f(x) == C1 + (-3*sin(x)/5 - cos(x)/5)*exp(2*x) + C2*exp(3*x)

In [3]: time dsolve(f(x).diff(x, 2) - 3*f(x).diff(x) - 2*exp(2*x)*sin(x), f(x), hint='nth_linear_constant_coeff_variation_of_parameters')
CPU times: user 0.92 s, sys: 0.01 s, total: 0.93 s
Wall time: 0.94 s
Out[4]:
f(x) == C1 + (-3*sin(x)/5 - cos(x)/5)*exp(2*x) + C2*exp(3*x)

In [5]: time dsolve(f(x).diff(x, 4) - 2*f(x).diff(x, 2) + f(x) - x + sin(x), f(x), hint='nth_linear_constant_coeff_undetermined_coefficients')
CPU times: user 0.06 s, sys: 0.00 s, total: 0.06 s
Wall time: 0.06 s
Out[6]:
f(x) == x - sin(x)/4 + (C1 + C2*x)*exp(x) + (C3 + C4*x)*exp(-x)

In [7]: time dsolve(f(x).diff(x, 4) - 2*f(x).diff(x, 2) + f(x) - x + sin(x), f(x), hint='nth_linear_constant_coeff_variation_of_parameters')
CPU times: user 5.43 s, sys: 0.03 s, total: 5.46 s
Wall time: 5.52 s
Out[8]:
f(x) == x - sin(x)/4 + (C1 + C2*x)*exp(x) + (C3 + C4*x)*exp(-x)

In [9]: time dsolve(f(x).diff(x, 5) + 2*f(x).diff(x, 3) + f(x).diff(x) - 2*x - sin(x) - cos(x), f(x), 'nth_linear_constant_coeff_undetermined_coefficients')
CPU times: user 0.10 s, sys: 0.00 s, total: 0.10 s
Wall time: 0.11 s
Out[10]:
f(x) == C1 + (C2 + C3*x - x**2/8)*sin(x) + (C4 + C5*x + x**2/8)*cos(x) + x**2

In [11]: time dsolve(f(x).diff(x, 5) + 2*f(x).diff(x, 3) + f(x).diff(x) - 2*x - sin(x) - cos(x), f(x), 'nth_linear_constant_coeff_variation_of_parameters')

The last one involves a particularly difficult Wronskian for SymPy (run it with hint=’nth_linear_constant_coeff_variation_of_parameters_Integral’, simplify=False).

Wall time comparisons reveal amazing speed differences. We’re talking orders of magnitude.

In [13]: 0.94/0.08
Out[13]: 11.75

In [14]: 5.52/0.06
Out[14]: 92.0

In [15]: oo/0.11
Out[15]: +inf

Of course, variation of parameters has the most difficult time when there are sin and cos terms involved, because of the poor trig simplification in SymPy. So let’s see what happens with an ODE that just has exponentials and polynomial terms involved.

In [16]: time dsolve(f(x).diff(x, 2) + f(x).diff(x) - x**2 - 2*x, f(x), hint='nth_linear_constant_coeff_undetermined_coefficients')
CPU times: user 0.10 s, sys: 0.00 s, total: 0.10 s
Wall time: 0.10 s
Out[17]:
f(x) == C1 + x**3/3 + C2*exp(-x)

In [18]: time dsolve(f(x).diff(x, 2) + f(x).diff(x) - x**2 - 2*x, f(x), hint='nth_linear_constant_coeff_variation_of_parameters')
CPU times: user 0.19 s, sys: 0.00 s, total: 0.19 s
Wall time: 0.20 s
Out[19]:
f(x) == C1 + x**3/3 + C2*exp(-x)

In [20]: time dsolve(f(x).diff(x, 3) + 3*f(x).diff(x, 2) + 3*f(x).diff(x) + f(x) - 2*exp(-x) + x**2*exp(-x), f(x), hint='nth_linear_constant_coeff_undetermined_coefficients')
CPU times: user 0.09 s, sys: 0.00 s, total: 0.09 s
Wall time: 0.09 s
Out[21]:
f(x) == (C1 + C2*x + C3*x**2 + x**3/3 - x**5/60)*exp(-x)

In [22]: time dsolve(f(x).diff(x, 3) + 3*f(x).diff(x, 2) + 3*f(x).diff(x) + f(x) - 2*exp(-x) + x**2*exp(-x), f(x), hint='nth_linear_constant_coeff_variation_of_parameters')
CPU times: user 0.29 s, sys: 0.00 s, total: 0.29 s
Wall time: 0.29 s
Out[23]:
f(x) == (C1 + C2*x + C3*x**2 + x**3/3 - x**5/60)*exp(-x)

The wall time comparisons here are:

In [24]: 0.20/0.10
Out[24]: 2.0

In [25]: 0.29/0.09
Out[25]: 3.22222222222

So we don’t have orders of magnitude anymore, but it is still 2 to 3 times faster. Of course, most ODEs of this form will have sin or cos terms in them, so the order of magnitude improvement over variation of parameters can probably be attributed to undetermined coefficients in general.

Of course, we know that variation of parameters will still be useful, because functions like , and do not have a finite number of linearly independent derivatives, and so you cannot apply the method of undetermined coefficients to them.

There is one last thing I want to mention. You can indeed multiply any polynomial, exponential, sin, or cos functions together and still get a function that has a finite number of linearly independent solutions, but if you multiply two or more of the trig functions, you have to apply the power reduction rules to the resulting function to get it in terms of sin and cos alone. Unfortunately, SymPy does not yet have a function that can do this, so to solve such a differential equation with undetermined coefficients (recommended, see above), you will have to apply them manually yourself. Also, just for the record, it doesn’t play well with exponentials in the form of sin’s and cos’s or the other way around (complex coefficients on the arguments), so you should back convert those first too.

Well, this concludes the first of two blog posts that I promised. I also promised that I would write about my summer of code experiences. Not only is this important to me, but it is a requirement. I really hope to get this done soon, but with classes, who knows.

asmeurer

2009-08-17T18:42:57+00:00

Last weekend, Luke came to visit Ondrej in Los Alamos, so I decided to drive him up from Albuquerque and visit him again. It was nice meeting Luke and seeing Ondrej again.

Aside from coding (the main thing that I did was fix an ugly match bug that was preventing dsolve() from recognizing certain ODEs), we visited the atomic museum in Los Alamos, the Valles Caldera, and some of the surrounding hot springs.

Here are some pictures that Luke took with his iPhone. Stupid WordPress seems to insist on flipping some of them (I can’t fix it):

This is one of three posts that I plan on doing this week. I just finished my GSoC project today/last night, so I will be blogging about that. I plan on doing a post on the method of Undetermined Coefficients, as well as some other things that I managed to do. The other post will be my general musings/advice for GSoC. That will probably be my last post here in a while. I plan on continuing work with SymPy, but I get very busy with classes, so I most likely won’t be doing much until next summer.

Refine module

2009-08-17T17:20:23+00:00

This commit introduced a new module in sympy: the refine module.

The purpose of this module is to simplify expressions when they are bound to assumptions. For example, if you know that x>0, then you can simplify abs(x) to x. This code was traditionally embedded into the core, but now this will be part of an external module (sympy.refine) upon which the core has no dependencies.

In a not very original move, I named the main function in this module refine(). It’s syntax is very straightforward: first argument is an expression and second argument are assumptions. Some examples (from isympy):

In [1]: refine(1+abs(x), Assume(x, Q.positive))
Out[1]: 1 + x

In [2]: refine(exp(I*x*pi), Assume(x, Q.odd))
Out[2]: -1

In [3]: refine(exp(I*x*pi), Assume(x, Q.even))
Out[3]: 1

Right now the module lacks some rules, but the design (very similar to the query module) will make adding these rules an easy task.

2009-08-16T14:47:01+00:00

Closing in on the finish here. I think I've achieved all the goals described in my original proposal, and ended up going a little further using the framework to write custom ufuncs. To refresh, the SVN is here:

https://svn.osl.iu.edu/trac/corepy/browser/branches/afriedle-gsoc-ufunc

I cleaned up the framework a little, and extended it to support multiple output arrays. In fact, any combination of inputs and outputs is supported as long as the total is = 5. 5 is a limitation of the x86_64 register file -- 2 registers are required for each input or output (a pointer and a element 'step' or increment value), and I've managed to clear up 10 registers for this purpose. I could support 10 inputs/outputs if I pushed the step values onto the stack (or chose not to use them); I wouldn't expect anything more than a minor performance hit from this, if any.

I've experimented with a couple more ufuncs. Wanting to try conditionals, I implemented a 'greater' ufunc and ran into an issue -- I don't know of a good way to return a boolean array (Python boolean objects) from a CorePy-based ufuncs; all I have is the native integer/float types. If 1/0 integer values were suitable as truth values, the conditional ufuncs would be no problem.

Moving along, I tested the multiple-output support by writing an 'addsub' ufunc. This ufunc takes two arrays as inputs, and outputs two arrays. The first output array contains the sum of each pair of elements, while the second output array contains the difference. Nothing fancy there, just a simple test to make sure my code did what I wanted.

Mark Jeffree suggested vector normalization as a good example for a custom ufunc:

L = 1.0/sqrt(x**2 + y**2)
X = x * L; Y = y * L

This ended up pretty fun to work with, as it is simple, but just involved enough to allow playing around with various optimization tricks. What I ended up doing was using the AMD optimization manual's suggestion of using the reciprical-squareroot instruction combined with a single iteration of newton-raphson to get accuracy slightly less than IEEE, but with better performance than the sqrt instruction. It's kind of funny how a sequence of ~10 instructions is faster than one single instruction! Another advantage is that the longer instruction sequence pipelines much better when unrolling loop iterations. The sqrt instruction has a latency of something like 18 cycles (might be wrong, that's off the top of my head), and a new sqrt instruction can only be issued every 15 cycles. On the other hand, reciprocal-squareroot with an iteration of newton-raphson uses a series of instructions with 4 cycles or less of latency and all can be issued every cycle.

The approach the AMD optimization manual described combined recprocal-squareroot with newton-raphson to get the squareroot as the result (they describe a similar approach for division). I actually wanted the reciprocal of the square root to avoid the division of each component by the length, and was able to remove one multiplication from the newton-raphson. For some reason SSE only has the reciprocal-squareroot and reciprocal instructions for 32-bit floats, not 64-bit floats. So the 64-bit float implementation was pretty boring; I just used sqrt and division instructions.

I just spent a while writing a README and fairly detailed documentation of the gen_ufunc() and create_ufunc() functions that make up my framework. Hopefully things are clear enough that others can use this work. This more or less wraps up my project! Over the next week I'm going to try my hand at implementing a custom ufunc to do the entire computation for a particle simulation demo Chris Mueller (my mentor) did. I'm also attending SciPy next week; I will be giving a talk on recent CorePy work on thursday I believe. Since the talks got cut down to 10 minutes instead of 35, I'll barely have time to highly various things we have going on, spending the most time on what's most relevant to this audience -- my GSoC project.

Expect one more post next week with an update on the particle system and SciPy.

os.py test cases

2009-08-16T07:21:12+00:00

Added 7 new test cases to test_os.py which tests the os module.

Following is a test class to test os.renames(). It starts by creating a temporary directory tree, and then renaming it. A walk is performed on the top most directory later on, and it is examined to verify that the renaming has taken place.


class RenamesDirTest(unittest.TestCase):
  def setUp(self):
      if os.path.exists(support.TESTFN):
          os.remove(support.TESTFN)
      os.mkdir(support.TESTFN)

  def test_renames(self):
      base=support.TESTFN
      self.old=os.path.join(base, "dir1", "dir2", "dir3", "dir4")
      os.makedirs(self.old)
      self.new=os.path.join(base, "dir1", "dir2", "test3", "test4")
      os.renames(self.old, self.new)
      for (dirpath, dirnames, filenames) in os.walk(base, topdown=False):
          self.assertEqual(self.new, dirpath)
          break
   
  def tearDown(self):
      if os.path.exists(self.new):
          os.removedirs(self.new)
      elif os.path.exists(self.old):
          os.removedirs(self.old)

A test for os.chdir(). Current directory for the current process is changed using os.chdir(), and later confirmed by calling os.getcwd(). A test case to see that os.chdir() fails when called with a directory argument that doesn't exist is also added.


#Tests for changing directory paths
class ChangePathTests(unittest.TestCase):
   def setUp(self):
       self.tempdir=support.TESTFN
       os.mkdir(self.tempdir)
       self.tempdir2=support.TESTFN+"2"

   def test_chdir(self):
       if os.path.exists(self.tempdir):
           os.chdir(self.tempdir)
           cwd=os.getcwd()
           self.assertEqual(cwd, self.tempdir)

   #Test to check chdir fails if nonexisting directory passed
   def test_chdir_nonexistent(self):
       if os.path.exists(self.tempdir2):
           os.rmdir(self.tempdir2)
       try:
           os.chdir(self.tempdir2)
       except OSError:
           pass
       else:
           self.fail("Did not raise OSError")

   def tearDown(self):
       if os.path.exists(self.tempdir):
           os.rmdir(self.tempdir)

A test class to test os.geteuid() and os.getgid(). Both are verified by comparing with values returned by os.stat().


class PosixGetUidGidTests(unittest.TestCase):
   def setUp(self):
       f=os.open(support.TESTFN, os.O_CREAT|os.O_RDWR)
       os.close(f)
       self.stats=os.stat(__file__)
 
   def tearDown(self):
       if os.path.exists(support.TESTFN):
           os.remove(support.TESTFN)
         
   if hasattr(os, "geteuid"):
       def test_geteuid(self):
           self.assertEqual(os.geteuid(), self.stats.st_uid)
 
   if hasattr(os, "getgid"):
       def test_getgid(self):
           self.assertEqual(os.getgid(), self.stats.st_gid)

A test class for testing os.getenv() and os.putenv().


class GetPutEnvironTests(unittest.TestCase):
   def test_putenv(self):
       try:
           os.putenv("KEY", "VALUE")
       except:
           self.fail("Not able to set environment variable")
 
   def test_getenv(self):
       keyvalue={"KEY":"VALUE"}
       os.environ["KEY"]=keyvalue["KEY"]
       value=os.getenv("KEY")
       self.assertEqual(value, keyvalue["KEY"])

I am designing a few more tests to test the os.spawn* family of functions.

Another update

2009-08-13T08:47:45+00:00

The basic whiteboard is done thanks to lots of help from Asterix, Liori, and Nikos. I’m currently adding features like deletion and editing. I don’t have much time left, and recently my right wrist got carpal tunnel so I’m typing this with my left hand. I’m getting good at that so I hope I can finish at least one more big commit.

Developments in PyDy

2009-08-12T22:26:28+00:00

I haven’t blogged in about two weeks, and there has been a lot of progress in PyDy. For starters, PyDy now ‘automatically’ derives the equations of motion for a rolling disc and a rigid body in space. I haven’t blogged in about two weeks, and there has been a lot of progress in PyDy. For starters, PyDy now ‘automatically’ derives the equations of motion for a rolling disc and a rigid body in space. One of the more useful methods I implemented is the output_eoms() method in the NewtonianReferenceFrame class. Once the equations of motion have been derived, this method creates python functions for them (in the form that scipy.odeint wants them in) and writes them to a file that you specify. Once you have this, you can import the function and use it for numerical integration. Additionally, this method also outputs a function that calculates the generalized speeds given the coordinates and their time derivatives, which is useful if you know the initial conditions of the coordinates time derivatives but need to determine the initial conditions of the generalized speeds when you want to perform a numerical integration. Finally, this method also optionally outputs an animate function, which takes a variable number of Points and (Axis, Angle) tuples and outputs a function which given the coordinates and parameters, will compute the inertial position and orientation of Points and/or Reference Frames. This is useful when you want to animate your simulation.
Both the rolling_disc.py and rigidbody.py files in the pydy/examples folder demonstrate the usage of these new methods.

One issue that has been repeatedly rearing its ugly head is the use of Function instances instead of Symbol instances. For everything except time differentiation, PyDy expressions could work fine with Symbols instead of Functions. I have become to realize that everything just works faster and more efficiently in Sympy with Symbols, so I will be working in the next week or so to replace the use of Functions in PyDy with Symbol instances instead. This should allow lots of things to work much better without having to call a bunch of helper methods to get expressions in their simplest form, or having to repeatedly substitute and back substitute with Symbols and Functions. For time differentiation, I will keep track of a list of symbols that represent the generalized coordinates, and then any expression that needs time differentiation will be examined to see if it has any occurrences of those coordinates. For expressions involving those coordinates, the partial derivative will be taken with respect to each coordinate, and then multiplied by the symbol that will be used to represent the time derivative of that coordinate, in essence a manual (as opposed to letting Sympy take care of it by using sympy Function) application of the chain rule. The user will be required to eclare these coordinate symbols in a special way, specifically using the .setcoords() method. Finally, I will implement method that will replace the symbols with Function instances (depending on time), so that if one wants to play with an expression interactively, all that they will have to do is call this function so that things like q1 = Symbol(’q1′) get replaced with q1 = Function(’q1′)(t), and then time differentiation will work just fine.

asmeurer

2009-08-12T21:27:21+00:00

So, the hard deadline for GSoC it Monday, so this will probably be my last post until then (I am very busy trying to finish up the ode module by then). But this is one of those things that you just have to blog about.

So I have this checksol function in test_ode.py that attempts to check it the solutions to odes are valid or not. It was a relic of the old ode module. For that, it would just substitute the solution into the ode and see if it simplified to 0. That is what it still does, if the solution is solved for f(x) (the function for all of my ode tests). But if the solution is implicit in f, either because solve() is not good enough to solve it or because it cannot be solved, then that method obviously does not work. So what I was trying to do is what my textbook suggested. Take the derivative of the solution implicitly n times, where n is the order of the ode, and see if that is equal to the ode. Basically, I was subtracting the ode from it and seeing if it reduced to 0.

However, it wasn’t really working at all for most of my implicit solutions, even the really simple ones. I ended up XFAILing most of my implicit checksol tests. I think every single homogeneous coefficients had an implicit solution, and none of them were working with checksol().

So I started to ask around on IRC to see if anyone had any better ideas for testing these. Ondrej couldn’t think of anything. Luke and Chris worked on an example that I gave them, and it seemed to be that it wasn’t correct (which I didn’t believe for a second, because the solution was straight out of my text, and both homogeneous coefficients integrals produced that same solution). It turns out that we were mixing up and terms. One of those appeared in the ode and the other appeared in the solution (the ode was and the solution is , number 9 from my odes text, pg. 61.

So Chris had a novel idea. For 1st order odes, you can take the derivative of the solution and solve for , which will always be possible, because differentiation is a linear operator. Then substitute that into the original ode, and it will reduce.

So we were talking about this on IRC later, and I had an epiphany as to why my original method wasn’t working. After trying it manually on an ode, I found that I had to multiply through the solution’s derivative by to make it equal to the ode. Then, that reminded me of an important solution method that I didn’t have time to implement this summer: integrating factors. I remember that my textbook had mentioned that there is a theorem that states that every 1st order ODE that is linear in the derivative has a unique integrating factor that makes it exact. And I realized, the derivative of the solution will be equal to the ODE if and only if the ODE is exact. I checked my exact tests and verified my hunch. I had to XFAIL all of my implicit homogeneous coefficients solutions, but all of my exact checksols were working just fine.

So I refactored my checksol function to do this, and it now can check almost every one of my failing checksols. The exceptions are some where trigsimp() cannot simplify the solution to 0 (we have a poor trigsimp), a second order solution (the above trick only works on 1st order odes, I believe), and some other simplification problems.

The only down side to this new routine is that it is kind of slow (because of the simplification). I am going to have to skip a test of only 6 solutions because it takes 24 seconds to complete.

The Status of 0.2

2009-08-10T22:59:47+00:00

Last Wednesday I pushed out the first release candidate of 0.2. The main motivation behind the release was to get the new caching code (needed by matplotlib) out into the wild as soon as possible.

However, soon after my mentor, Michael Droettboom, sent me a patch adding support for the MathML torture tests to mathtex. These tests resulted in several issues being filed against mathtex. Further, Michael was kind enough to provide patches for many of then — which I hastily added to mathtex.

The result? The mathtex of today has much better rendering than the mathtex of a week ago. However, it does also mean that the differences between 0.2 RC 1 and 0.2 will be substantial — enough to warrant a version-bump. It is for this reason that I am planning to skip the 0.2 release series and go straight to 0.3 RC 1.

I expect to tag the release in the next day or so, but there is at least one issue which I would like to squish before doing so.

PyMW: Summer-y of Code

2009-08-10T20:05:40+00:00

Today is the “suggested pencils down” date for Summer of Code and I’m very happy to say that my proposal is complete and I feel the summer was a great success!

For those of you who don’t know, PyMW is a Master-Worker computing framework in Python. It wraps several other Master-Worker frameworks such as MPI, Condor, BOINC or even just using multi-core processors, and exposes them as a simple and elegant API.

The way it works is, you create tasks and submit them to a Master and the master uses an interface/wrapper (BOINC, Condor, MPI, etc) to process those tasks. The master distributes the tasks out to compute nodes (or processor cores), called Workers, and the results get sent back to the Master. This allows you to debug using the multi-core interface (a single machine) and then, by changing one switch on the command line, you can run the same code on thousands of machines using BOINC or any other supported interface.

My proposal was to improve BOINC integration with PyMW by 1) eliminating the startup script and the need to compile C code; 2) adding pure-Python support for BOINC Assimilators and Validators; and 3) by adding a new checkpointing mechanism for long running jobs (optional).

I completed (2) very quickly by virtue of some old Python code I found in BOINC, but (1) took a lot of sweat and tears — the existing BOINC interface was functional, but in need of some serious work. It was running under Mac and Linux, however the Windows client was crashing on every task. To get it working under Windows I ended up creating a C++ launcher application to avoid using batch scripts.

In addition to my proposal, I also added a few other tasks. When working with BOINC, the existing interface assumed that Python was already installed and on the system PATH environment variable. This is not a very safe assumption and so I also crated a portable Python interpreter integrated with the BOINC API. PyMW will now install this interpreter as your BOINC application so that clients no longer need to have Python installed to run PyMW-BOINC compute jobs. Along the way I also created a new logo and graphic design for the PyMW web site and setup WordPress, check it out.

Sadly goal (3) was not completed, however, it was originally proposed as an optional part of the project. I actively chose to pursue the BOINC-Python interpreter over (3) because I felt it was more important to the BOINC interface. In the end, checkpointing can always be done manually, but sending the Python interpreter is a considerably harder task.

I am still wrapping up a few odds and ends, but for the most part, I feel very happy with the state of the BOINC interface. If you are looking for a distributed or parallel processing framework for a future project, please consider PyMW.

If you have any questions or comments, I would love to hear them!

Query module - finally in trunk

2009-08-10T19:51:51+00:00

The query module is finally in the main SymPy repository. I made substantial changes since last post, most of them at the user interface level (thanks to Vinzent and Mateusz for many insightful comments).

Main function is ask(), which replaces the old expression.is_* syntax. You can ask many things. For example, you can ask if a given expression is integer, prime or real:

>>> ask(2, Q.integer)
True
>>> ask(x**2, Q.integer)
None
>>> ask(x**2, Q.integer, Assume(x, Q.integer))
True
>>> ask(sqrt(2)*x, Q.integer, Assume(x, Q.integer))
>>> ask(I*x, Q.real, Assume(x, Q.imaginary))
True
>>> ask(x*y, Q.prime, Assume(x, Q.prime) & Assume(y, Q.prime))
False

as you see, it returns True when it is sure that the expression is an integer, None if it does not know, and False if it is certainly not an integer.

The second argument, which we will call ‘key’ specifies what we want to ask about. For example, Q.integer ask wether expression is an integer, Q.negative wether it’s a negative, etc.
For a complete list of all the keys available, see doc/src/modules/queries.txt in sympy codebase.

It also accepts an optional third argument where you can specify assumptions that symbols in expr satisfy. That can be any kind of boolean expression involving assumptions, for example:

Assume(x, Q.positive) & Assume(x, Q.integer)

Assume(x, Q.positive) | Assume(x, Q.negative)

, or even

NAnd(Assume(x, Q.positive), Assume(x, Q.integer)

asmeurer

2009-08-10T17:30:22+00:00

Before I started the program, I implemented Bernoulli equations. But the general solution to Bernoulli equations involves raising something to the power of , where n is the power of the dependent term (see the Wikipedia page for more info). This works great, as I soon discovered, unless n == 1. Then you get something to the power of . So I had to go in and remove the corner case.

So you think that after that I would have been more careful after that about checking that if general solution that divides by something I would test to see if that something is not zero before returning it as a solution.

Well, as I was just trying to implement some separable equation tests, I was going through the exercises of my ode text as I usually do for tests, and I came across . If you recall, this equation also has coefficients that homogeneous of the same order (1). From the general solution to homogeneous coefficients, you would plug it into where or where (here, P and Q are from the general form ). Well, it turns out that if you plug the coefficients from my example into those equations, the denominator will become 0 for each one. So I (obviously) need to check for that and are not 0 before running the homogeneous coefficients solver on a differential equation.

PEP Submission

2009-08-10T17:01:00+00:00

Now that the coding is more or less complete, I have produced and submitted the following P.E.P. I have not officially been assigned a P.E.P. number but I stuck 3144 on there as the newest one when I began writing this one was 3143.

PEP: 3144
Title: Asynchronous I/O For subprocess.Popen
Author: (James) Eric Pruitt, Charles R. McCreary, Josiah Carlson
Status: Draft
Type: Standards Track
Requires: 324
Created: 04-08-2009
Content-Type: text/plain
Python-Version: 3.2

Abstract:
In its present form, the subprocess.Popen implementation is prone to
dead-locking and blocking of the parent Python script while waiting on
data from the child process.

Copyright:
This P.E.P. is licensed under the Open Publication License;
http://www.opencontent.org/openpub/.

Motivation:
A search for "python asynchronous subprocess" will turn up numerous
accounts of people wanting to execute a child process and communicate
with it from time to time reading only the data that is available
instead of blocking to wait for the program to produce data [1] [2]
[3]. The current behavior of the subprocess module is that when a user
sends or receives data via the stdin, stderr and stdout file objects,
dead locks are common and documented [4] [5]. While communicate can be
used to alleviate some of the buffering issues, it will still cause
the parent process to block while attempting to read data when none is
available to be read from the child process.

Rationale:
There is a documented need for asynchronous, non-blocking
functionality in subprocess.Popen [6] [7, comments] [2] [3]. Inclusion
of the code would improve the utility of the Python standard library
that can be used on Unix based and Windows builds of Python.
Practically every I/O object in Python has a file-like wrapper of some
sort. Sockets already act as such and for strings there is StringIO.
Popen can be made to act like a file by simply using the methods
attached the the subprocess.Popen.stderr, stdout and stdin file-like
objects. But when using the read and write methods of those options,
you do not have the benefit of asynchronous I/O. In the proposed
solution the wrapper wraps the asynchronous methods to mimic a file
object.

Reference Implementation:
I have been maintaining a Google Code repository that contains all of
my changes including tests and documentation [9] as well as blog
detailing the problems I have come across in the development process
[10].

I have been working on implementing non-blocking asynchronous I/O in
the subprocess.Popen module as well as a wrapper class for
subprocess.Popen that makes it so that an executed process can take
the place of a file by duplicating all of the methods and attributes
that file objects have.

[1] http://mail.python.org/pipermail/python-bugs-list/2006-December/036524.html
[2] http://ivory.idyll.org/blog/feb-07/problems-with-subprocess
[3] http://stackoverflow.com/questions/636561/how-can-i-run-an-external-command-asynchronously-from-python
[4] http://docs.python.org/library/subprocess.html#subprocess.Popen.wait
[5] http://docs.python.org/library/subprocess.html#subprocess.Popen.kill
[6] http://bugs.python.org/issue1191964
[7] http://code.activestate.com/recipes/440554/
[8] http://code.google.com/p/subprocdev/source/browse/doc/subprocess.rst?spec=svn2c925e935cad0166d5da85e37c742d8e7f609de5&r=2c925e935cad0166d5da85e37c742d8e7f609de5#437
[9] http://code.google.com/p/subprocdev
[10] http://subdev.blogspot.com/

Movie Module Progress Week 10-Follow up

2009-08-10T16:41:33+00:00

Okay, so I found the source of the desync issue for one kind of video, and fixed that. It was a solution I created for dealing with seeking. I’ll have to come up with a better one. One other video I have, which is great as a test video due to its weird occurrences of pts values and packets, still has a desync problem. I will give a go at fixing it today. I know its somewhere in the video system.

GLM Residuals and The Beauty of Stats with Python + SciPy

2009-08-10T10:25:34+00:00

I just finished including the Anscombe residuals for the families in the generalized linear models. The Anscombe residuals for the Binomial family were particularly tricky. It took me a while to work through the math and then figure out the SciPy syntax for what I need (some docs clarification coming...), but if I had had to implement these functions myself (presumably not in Python), it would have taken me more than a week! I thought it provided a good opportunity introduce the residuals and to show off how easy things are in Python with NumPy/SciPy.

Note that there is not really a unified terminology for residual analysis in GLMs. I will try to use the most common names for these residuals in introducing the basics and point out any deviations from the norm both here and in the SciPy documentation.

In general, residuals should be defined such that their distribution is approximately normal. This is achieved through the use of linear equations, transformed linear equations, and deviance contributions. Below you will find the five most common types of residuals that rely mainly on transformations and one that relies on deviance contributions, though there are as many as 9+ different types of residuals in the literature.

Response Residuals

These are simply the observed response values minus the predicted values.

In a classic linear model these are just the expected residuals

However, for GLM, these become

where is the link function that makes our model's linear predictor comparable to response vector.

It is, however, common in GLMs to produce residuals that deviate greatly from the classical assumptions needed in residual analysis, so in addition we have these other residuals which attempt to mitigate deviations from the needed assumptions.

Pearson Residuals

The Pearson residuals are a version of the response residuals, scaled by the standard deviation of the prediction. The name comes from the fact that the sum of the Pearson residuals for a Poisson GLM is equal to Pearson's statistic, a goodness of fit measure.

The scaling allows plotting of these residuals versus an individual predictor or the outcome to identify outliers. The problem with these residuals though is that asymptotically they are normally distributed, but in practice they can be quite skewed leading to a misinterpretation of the actual dispersion.

Working Residuals

These are the difference between the working response and the linear predictor at convergence (ie., the last step in the iterative process).

Anscombe Residuals

Anscombe (1960, 1961) describes a general transformation in place of so that they are as close to a normal distribution as possible. (Note: "There is a maddeningly great diversity of the forms that the Anscombe residuals take in the literature." I have included the simplest as described below. (Gill 54, emphasis added)) The function is given by

This is done for both the response and the predictions. This difference is then scaled by dividing by

so that the Anscombe Residuals are

The Poisson distribution has constant variance so that it's Anscombe Residuals are simply

Easy right? Sure was until I ran into the binomial distribution. The Anscombe residuals are built up in a different way for the binomial family. Indeed, the McCullagh and Nelder text does not even provide the general formula for the binomial Anscombe residuals and refers the reader to Anscombe (1953) and Cox & Snell (1968). The problem is that following this transformation for the binomial distribution leads to a rather nasty solution involving the hypergeometric 2F1 function or equivalently the incomplete beta function multiplied by the beta function as shown by Cox and Snell (1968).

Gill writes "A partial reason that Anscombe residuals are less popular than other forms is the difficulty in obtaining these tabular values." The tabular values to which he is referring are found in Cox and Snell (1968) p. 260. It is a table of the incomplete beta function that was tabulated numerically for an easy reference. How difficult would it be to get this table with NumPy and SciPy?

import numpy as np
from scipy import special
betainc = lambda x: special.betainc(2/3.,2/3.,x)

table = np.arange(0,.5,.001).reshape(50,10)
results = []
for i in table:
results.append(betainc(i))

results = np.asarray(results).reshape(50,10)

That's it!

Now the Anscombe residuals for the binomial distribution are

Where n is the number of trials for each observation (ie., 1, , or )

To implement this in the GLM binomial family class, I defined an intermediate function cox_snell similar to the above. It now looks like

from scipy import special
import numpy as np

def resid_anscombe(self, Y, mu):
cox_snell = lambda x: special.betainc(2/3.,2/3.,x)*special.beta(2/3.,2/3.)
return np.sqrt(self.n)*(cox_snell(Y)-cox_snell(mu))/(mu**(1/6.)*(1-mu)**(1/6.))

We multiply the above formula by np.sqrt(self.n) the square root of the number of trials in order to correct for possible use of proportional outcomes Y and mu.

Also, see the ticket here for a note about the incomplete beta function.

Deviance Residuals

One other important type of residual in GLMs is the deviance residual. The deviance residual is the most general and also the most useful of the GLM residuals. The IRLS algorithm (as will be shown in a future post) depends on the convergence of the deviance function. The deviance residual then is just the increment to the overall deviance of each observation.

where are defined for each family.

Note that most of these residuals also come in variations such as modified, standardized, studentized, and adjusted.

Selected References

Anscombe, FJ (1953) "Contribution to the discussion of H. Hotelling's paper."
   Journal of the Royal Statistical Society, B, 15, 229-30.

Anscombe, FJ (1960) "Rejection of outliers." Technometrics, 2,
  123-47.

Anscombe, FJ (1961) "Examination of residuals." Proceedings of
  the Fourth Berkeley Symposium on Mathematical Statistics and
  Probability. Berkeley: University of California Press.

Cox, DR and Snell, EJ (1968). "A generalized definition of
  residuals." Journal of the Royal Statistical Society B, 30, 248-65.

Movie Module Progress Week 10

2009-08-09T03:20:04+00:00

Okay, so we made some progress this week.

I did:

Finished addition of a command queue, for every modification of the system.
Fixed a bug with surfaces that happened rarely
Added filepath checks, to ensure the file exists.
Made significant improvements in audio/video syncing, but it still desyncs within a minute. This took up the rest of my week.

Unfortunately, I’m having a serious issue with audio/video desyncing. I’m going to be studying the ffmpeg tutorial, and ffplay.c for clues and understanding of where I’ve gone wrong. I will try on either Sunday or Monday to replace the current sound system I use with one similar to ffplay’s and see if that makes a difference. But I suspect it is an issue with the video thread, not the audio, because when the video is turned off, the audio doesn’t stutter at the beginning for one of my test videos. Then after that, I will be working to make my module work on Windows.

django, change language settings dynamically

2009-08-07T14:12:26+00:00

After some failed attempts, I just found how to change the language settings dynamically in django, and I thought it could be useful to someone. Just use function activate() from django.utils.translation. For example:

from django.utils.translation import activate

activate(‘es-ES’)

will change global language settings to ‘es-ES’ (Spain spanish). I use it because I have two forms and I want that errors appear in different languages, but I do not want to get into gettext

FreeType awesomeness in PyGame

2009-08-06T22:18:00+00:00

Hello everybody, and as always, apologies for not keeping this blog up to date with my developments. Just a quick note here to let you know that the project is mostly finished, and most importantly, it has been ported to the original PyGame so now it works under PGreloaded and Pygame with pretty much the same code base. How great is that? Very great!

The FreeType module still isn't on the Pygame trunk, but you can check it out on its own branch:

svn co svn://seul.org/svn/pygame/branches/pygame-ftmod

It's your classic PyGame, the one that you love, but now with 300% more FreeType awesomeness! That's right, three timas as much text drawing, and it even comes with full HTML documentation!

Stay tuned to see how I manage to trick people into bringing this into trunk.

How Star Trek XI should have been made

2009-08-06T14:50:33+00:00

So if you haven’t seen the new Star Trek movie, and still want to… why did you wait so long?

Its also the reason I waited to post this. I didn’t want to give any spoilers. So, lets say that the suits realized what an abomination of a movie JJ Abrams made, and so they gave it to me to fix. The requirements would be that I stick with the same general plot as they can’t afford to re-film everything. So, here we go, down the rabbit hole:

We start off with old Spock arguing before the Romulan senate, going from a shot of a CGI wonderland supernova to the senate room. He is arguing that Romulus is under threat of destruction from the Hobus start going supernova. The romulans jeer, and boo old Spock off, and he retains his calm(obviously!). A miner, named Nero, youngish, idealistic, believed in what Spock had to say, and wants to help, especially to save Romulus. And again, we go to a scene of Nero and Spock having just finished their presentation, Nero glowing with passionate pride. The Vulcans say “No. It is simply not logical to expend effort on the behalf of a race of people that have sought to destroy us, and will try to destroy us again.” and they all turn to leave. Nero rails against this proclamation, shouting, calling them cowards, emotion-less computers. Spock sighs and tells Nero to cease, his arguments will have no effect.

This is where Nero shrugs off Spock’s arm, and he turns angrily to Spock, “I’m going back to Romulus, to save my wife and child. You can stay here, with the rest of your despicable kind.” and he spits at the floor, marching off.

Unfortunately, Nero is too late, and he has to watch the death of his home-world, with his wife and child on it before him. He struggles to hold it together, but we can see he has become equal parts anger and sadness. His subordinates tell him they’ve picked up the some of the Romulan Senate. Nero whips his around, and growls ferally. Grabbing a knife from a subordinate, he marches down to the senate, and pretends to welcome them. He kneels before the Praetor, then snarling, stabs upward to kill him. Nero’s subordinates, after a pause, follow his lead and kill the Senate members.

Nero pushes the dead corpse out of the way, and snarls, “Now… let us destroy Vulcan… and the rest of the treacherous Federation.”

Then we see a few months later, the small mining ship Narada noticeably transformed into a sinister and nearly undefeatable warship.

His subordinates tell him that a small ship has managed to somehow prevent the Hobus supernova from destroying the universe. Nero discovers this is Spock, whom had finally gotten a concession from the Vulcan council for the equipment he needed. Nero growls again, and orders the ship to destroy Spock’s ship. Unfortunately, Spock’s ship is being drawn into the singularity he created, and Nero’s revenge-fueled rush to destroy him causes the Narada to be drawn into the singularity as well.

Now we come to the alternate timeline, where the USS Kelvin is responding to reports of a massive singularity wrecking some ships. Then we have the Kelvin scenes almost unaltered, except that George Kirk remembers to use the autopilot and runs to the shuttle. Unfortunately, he dies on the way, on the Com channel with his wife. We see the Narada being pushed back into the singularity by the Enterprise’s bulk.

The next scene, in dramatic contrast with the dark, gloomy, and sad scene previously, is bright and sunny, and we hear someone call “Kirk!” Chris Pine turns around and greets warmly Doctor McCoy. They discuss the Kobayashi Maru test that Kirk is going to take for the third time. McCoy thinks he’s being ridiculous. Kirk insists. He is still cocky, and arrogant, with a knowing swagger to his steps. Then we see the Kobayashi Maru scenes, and then the testimonial scene of Kirk vs Spock. Only this time, the Admirals consider the situation, and order Kirk to perform community service, by helping Spock improve the simulator, and fix the bug that Kirk exploited. As a reward for creative thinking, Kirk is promoted from Cadet to Ensign. We can put in scene in here about how Kirk has the “rubber-neck” mentality, and chases women.

Then we go a few more years later, and Kirk looks a bit older. He’s calmer, settled, and has Lieutenant stripes on his shoulder. He’s boarding the enterprise, having been transferred there. Pretty women in mini-skirts walk by, and in contrast to the scene just before, he checks them out discreetly. He’s still a skirt-chaser, but is a lot less cocky and arrogant, and doesn’t get distracted easily by women anymore. He’s no longer a Frat Boy. He meets Spock again, at the rank of Commander. “Welcome Lieutenant Kirk. Captain Pike sent me to welcome you, since we are already acquainted.”

Lt. Kirk makes it to the bridge, and looks around, smiling at everyone on the bridge. Pike nods, and directs Kirk to the conn. Then they receive a distress message from a Klingon fleet, talking about how some deadly ship appeared from a singularity…which tenses Kirk right up. He turns and tells the captain that this may be what destroyed the USS Kelvin. Every ounce of swagger is gone from Kirk’s demeanor, and he is genuinely worried. Pike takes the recommendation to heart, and exercises caution on arriving at the latest sighting of the mysterious warship, in Vulcan’s system. Everyone pales and becomes noticeably quieter as they see other Starfleet ships’ wreckage scattered around, bouncing off the shields. They scan the system, and find the Narada. They open hailing frequencies, as per standard operating procedure, but at Red Alert status. Nero sees young Spock and smiles, like a cat finding a mouse. “Send over both your captain and first officer or I will destroy Vulcan.” The communication ends there. The science officers confirm that the Narada indeed has such power, and is ready to do it at a moment’s notice. Pike sighs, and nods to Lt. Kirk, “Take command, myself and Mr. Spock will go over there and try to save Vulcan. Keep locked onto our lifesigns, I don’t trust this Romulan bastard.”

Almost as soon as the shuttle with Pike and Spock on it leaves, the Enterprise receives a message from one of Vulcan’s moons. Old Spock appears, and Kirk has a moment of recognition. “Jim old friend, we have not a second to lose. Please beam up myself and someone you will find extremely useful, Mr. Scott.” Kirk demands to know whats going on, “Jim, all I can see is this is an instance of time-travel, and I had to wait till my previous self left the ship. Please, trust me.” Kirk makes a decision, and orders the two people beamed up. “Mr. Spock, if that is who you really are, I would like some explanation now.”

Just that moment, the lifesigns for Pike start becoming erratic, as if he’s being tortured. Spock tilts his head, and narrows his eyes. He strides over to the science station, and with an ease born of familiarity, inputs information and reconfigures the sensors, with Commander Spock’s authentication code. He raises an eyebrow to young Kirk as if to say, “There. I am Spock.” With these changes, they’re able to beam aboard, to try to save Pike and young Spock. Kirk, Sule and a few red shirts go over. They manage to save Pike, and rescue young Spock, but not before Nero presses the button to destroy Vulcan. The blast lances out, piercing the planet, which begins to crumble inwards. Kirk orders the Enterprise to begin beaming up as many survivors as possible as soon as they can. Young Spock waits in the transporter bay for the first batch of survivors, the Vulcan High Council… but as he watches, his mother’s trace disappears, and the young transporter tech is horrified. Spock retains his calm, and hurries back to the bridge. We see a single scene of Spock’s fist tightening, knuckles turning white, hand nearly shaking, but otherwise, he is completely composed.

He reaches the bridge, with Pike sent to the infirmary. Kirk gets up to give Spock his command back, with old Spock having slipped out before young Spock shows up. Spock shakes his head. “I am afraid, Lt. Kirk, that I would not be capable of command in my present state. I am afraid I am emotional, and that these emotions will negatively impact my capabilities. Thus, you must take command, Kirk. Nero said his next target was Earth. Our duty is to stop him.” Kirk nods, and sits back in the chair. “Plot a course to Earth, maximum warp Ensign…” Chekov turns around, “Chekov sir.”

“Fascinating.” Spock says, finding the science station already has information input into it, “With this data, we should be able to beam through the shields of the Narada… but…” Scotty comes over to look, and they confer quietly, as the ship warps to Earth. “Gentlemen, tell me we have a way to stop this ship.” Scotty looks up and gives a trademark grin, “Oh aye, Captain… we do.” Kirk spends some time talking to old Spock in secret, to find out just what is going on. Chekov warps them into the solar system, out of reach of the Narada’s sensors, where Spock and Scotty outline their plan. They’ll need the Enterprise to attack the Narada, to weaken the shields first. They’ve managed to strengthen the shields and power output of the engines thanks to the calculations given by old Spock. Kirk hails the Narada, and tells Nero to let go of his quest for destruction. “What happened to your wife and child was a regrettable tragedy, Nero. One I feel for. But there is no need to do this.” Nero snarls, and says to the viewscreen, “No diplomacy, no peace talks, no negotiations will stop me. I will have my vengeance.” and turns off the communications, yet again.

“Time to try two-fisted diplomacy fellas.” Kirk says, and the crew gets to work. The Enterprise swoops in, rocking the Narada with the force of its blasts. The Enterprise gets hit back, hard, and the shiny uber-Apple bridge begins to get smokey, and filled with sparks. “Keep firing! We’ve got to save Earth!” Kirk holds on for dear life. Finally, the Narada’s shields are weakened, and Kirk, Sulu, Spock, and more red-shirts beam aboard the Narada. This time, they get between Nero and the death beam button. Nero manages to disarm Kirk, while the rest are busy fighting Nero’s crew. Kirk struggles with Nero, and in homage to TOS, uses the infamous Kirk punch. Barely able to stay standing up, Kirk looks almost beaten while the victorious Nero is about to deliver the coup de grace. Spock comes in, and delivers an uncharacteristic punch, knocking Nero over. Kirk yells, “Don’t Spock!” but Spock does it anyway, and vaporizes Nero. He sighs, and turns to Kirk, helping him up. Kirk looks around and tells Spock, “This ship was advanced in its own time, 100 years in the future. We need to keep this technology out of enemy hands.” Spock concurs, and they set about turning on the self-destruct sequence. They escape the ship, and beam back to the Enterprise.

There, everyone is promoted, especially Kirk. However, due to his murder of Nero, Spock receives no promotion, and Kirk is given the command of the Enterprise.

And voila! Took almost 2000 words, but isn’t this a better movie?

figleaf-py3k and gcov report integration

2009-08-05T00:40:14+00:00

It's done and its working. And there isn't much new to tell. If you have read my report on the integration of figleaf for py2.6, the details are very similar, just that the syntax is of course py3kish. I used Titus' port of figleaf to py3k (http://github.com/ctb/figleaf/tree/py3k), with a few minor fixes.

The working is very similar to how the figleaf for py2.6 works. You have to use the -c/--c-coverage switch to give the directories holding C modules built with gcov support, and figleaf will incorporate their coverage report as well.

Now its time to work on writing new test cases for different modules. Many modules aren't 100% covered by its test suites, and there is a lot of room for improvements there. Of course I can't make all of them get completely covered, but I will write as much new tests as possible. I hope once I get started on the process and get used to it and get better familiarity with the code base, I can go on with the tests improvement well beyond GSoC.

Meanwhile, I am also going to give a try to make figleaf easy to use with gcov, and try to automate the static compilation of C modules for use with gcov.

I just added a comment system to my blog...

2009-08-04T07:22:03+00:00

From now on you can post comment on this blog thank to the friendly people of Disqus. Adding Disqus to Tumblr (or any other bog system for that matter) is very simple, and I can’t recommend enough to anyone who wants to add comments to his/her blog.

PS The comment section’s layout is still a bit ugly, I will fix that later…

2009-08-03T16:47:14+00:00

While messing around with my cosine ufunc I realized that NumPy's performance for cosine over float32's is horrible, while float64 performance is more normal:


cfcos type 'numpy.float32'
inp sizes      1024    10240   102400  1024000  3072000
numpy        0.7241   9.3472 115.6120 995.1050 3027.2000
corepy   1   0.0191   0.1521   1.6742  16.3748  50.1912
corepy   2   0.0160   0.0811   0.8180   8.2700  25.5480
corepy   4   0.0219   0.0889   0.8180   4.1308  12.9910

cfcos type 'numpy.float64'
inp sizes      1024    10240   102400  1024000  3072000
numpy        0.0970   0.9248   9.3892  93.8919 277.4410
corepy   1   0.0370   0.3450   3.4950  35.4860 106.4019
corepy   2   0.0319   0.1729   1.7591  17.8859  53.5469
corepy   4   0.0288   0.0958   0.8941   8.9951  26.8750

I started a thread on numpy-discussion, and it's gotten a bit of attention. :) I'm not sure what causes this right now, still have some things to try out. See the thread for details:

http://mail.scipy.org/pipermail/numpy-discussion/2009-August/044274.html

The main thing is that my float32 cosine wasn't so fast after all -- NumPy is just really slow, at least on some installations (including mine). Some other users weren't able to reproduce the slowness.

I've implemented a few different ufuncs now, so figure it's worth summarizing them and the types they work over:

add: int{8,16,32,64}, float{32,64}
multiply: int{8,16,32,64}, float{32,64}
cosine (faster less accurate version): {float32,64}
cosine (using x87, slower but accurate): {float32, 64}
maximum: int{32,64}, float{32,64}

All of these written using the framework I've developed, of course. As I ran my test code for writing this post, I found that the x86-based cosine is segfaulting at 4 threads/cores. It wasn't doing this earlier.. will have to investigate.

Maximum was fun to do, particularly for int32. I spent time iterating on the code, and came up with something pretty creative. I use SSE compare instructions to create a sort of selection mask to use with bit-wise operations to choose the maximum values without a branch. All SIMD, too. Unfortunately I don't have the instructions to do this for int64 (no quadword compares), but I can/will do the same thing for int8/int16. SSE has a specific instruction for selecting the maximum values from two vectors, so I just used that there. Very easy to take advantage of the hardware. :)

Future work: I'm planning on doing a couple more ufuncs, particularly one logical comparison and one bitwise (AND, OR) operation. The idea is to build up a collection of different types of ufuncs to show that the framework works and can be used to develop more.

After that I'm going to look at using the framework to build more complex, custom ufuncs. Initially just something like fused multiply-add, and then maybe some entire algorithms (particle simulation?) in a single ufunc. The idea here being that we can use the framework to do any sort of computation, and use it to reduce memory traffic, leverage the CPU functionality, and go faster without much trouble.

Progress

2009-08-02T20:48:42+00:00

A list of what we have implemented:
-Declaring C++ classes and methods from extern
-Instanciating and deleting C++ objects
-C++ methods overloading (still with some problems with function overloading...)
-Operators overloading (not all them, but it's a really simple work)
-Declaring template types (C++ classes and functions)

Next step is to allow using template types.

Rendering Improvements

2009-08-01T23:07:56+00:00

Over the past couple of days I have been working to improve the rendering quality of mathtex. Rather than describe the changes with several paragraphs of prose I thought it more apt to have a before-and-after picture instead.

Before:

After:As can be seen the result is much closer to that produced by LaTeX.

Movie Module: Week 8 and 9

2009-08-01T18:23:02+00:00

I apologize that I didn’t post an update earlier. I didn’t do a post for week 8(from July 6-10), and the next week was only a partial week as I left on vacation on Thursday. I was on vacation from the 16th to the 24th. Then I’ve just completed another week of progress. I’ll just sum up everything I’ve done in one big gigantic post.

What I’ve done since then:

Fixed video sync issues after pausing and unpausing
Fixed a bug dealing with overlay and surface releasing and resizing
Expanded unit tests for all the backends
Added more commenting, cleaning up code
Began working on subtitle support but discovered that ffmpeg 0.5 has no demuxers for subtitles so decided to delay this feature for after GSoC
Worked on various references issues
Moved audio packet processing to its own thread
Wrote a more optimized routine for writing data to an SDL_Surface, still slow on large screens
Added some profiling
Merged branch with trunk revisions
Fixed slowdown issues
Added seeking. No relative seeking yet, it is absolute for now.
Updated the code to work with older ffmpeg libraries. Only one section is incompatible, and waiting on a response from the libav* mailing thread
Began working on a command queue to make the module more thread safe.

There are some current issues at the moment.

If using surfaces, and you resize the window smaller, there ends up being corruption in the bottom of the window. I have no idea why this happens.
I will be adding relative seeking this next week.
Found an issue where commands issue from the Python interpreter thread in sequence but with no delay cause a big crash. Thus the necessity of the command queue.
Code seems a bit slow, and very very rarely, audio and video get desynced.
No path expansion yet.

And there we go!

Crazy Trig Wronskian (SymPy)

2009-08-01T17:39:48+00:00

Well, the last time I posted a project update, I had resigned myself to writing a constant simplifying function and putting the Constant class on the shelf. Well, just as I suspected, it was hell writing it, but I eventually got it working. Already, what I have in dsolve() benefits from it. I had many solutions with things like or in them, and they are now automatically reduced to just . Of course, the disadvantage to this, as I mentioned in the other post, is that it will only simplify once. Also, I wrote the function very specifically for expressions returned by dsolve. It only works, for example, with constants named sequentially like C1, C2, C3 and so on. Even with making it specialized, it was still hell to write. I was also able to get it to renumber the constants, so something like C2*sin(x) + C1*cos(x) would get transfered to C1*sin(x) + C2*cos(x). It uses Basic._compare_pretty() (thanks to Andy for that tip), so it will always number the constants in the order they are printed.

Once I got that working, it was just little work to finish up what I had already started with solving general linear homogeneous odes ( with constant for all ). Solving these equations is easy. You just set up a polynomial of the form and find the roots of it. Then you plug the roots into an exponential times for i from 1 to the multiplicity of the root (as in ). You usually expand the real and complex parts of the root using Euler’s Formula, and, once you simplify the constants, you get something like for each i from 1 to the multiplicity of the root. Anyway, with the new constantsimp() routine, I was able to set this whole thing up as one step, because if the imaginary part is 0, then the two constants will be simplified into each other. Also, SymPy has some good polynomial solving, so I didn’t have any problems there. I even made good use of the collect() function to factor out common terms, so you get something like instead of , which for larger order solutions, can make the solution much easier to read (compare for example, with the expanded form, as the solution to ).

I entered all 30 examples from the relevant chapter of my text (Ordinary Differential Equations by Morris Tenenbaum and Harry Pollard), and the whole thing runs in under 2 seconds on my machine. So it is fast, though that is mostly due to fast polynomial solving in SymPy.

So once I got that working well, I started implementing variation of parameters, which is a general method for solving all equations of form . The method will set up an integral to represent the particular solution to any equation of this form, assuming that you have all linearly independent solutions to the homogeneous equation . The coefficients do not even have to be constant for this method to work, although they do have to be in my implantation because otherwise it will not be able to find general solution to the homogeneous equation.

So, aside from doing my GSoC project this summer, I am also learning Linear Algebra, because I could not fit it in to my schedule next semester and I need to know it for my Knot Theory class. It turns out that it was very useful in learning the method of variation of parameters. I will explain how the method works below, but first I have a little rant.

Why is the Wikipedia article on variation of parameters the only website anywhere that covers variation of parameters in the general case? Every other site that I could find only covers 2nd order equations, which I understand is what is taught in most courses because applying it to anything higher can be tedious and deriving the nth order case requires knowledge of Cramer’s Rule, which many students may not know. But you would think that there would at least be sites that discuss what I am about to discuss below, namely, applying it to the general case of an nth order inhomogeneous linear ode. Even the Wolphram MathWorld article only explains the derivation for a second order linear ODE, mentioning at the bottom that it can be applied to nth order linear ODEs. I did find a website called Planet Math that covers the general case, but it wasn’t on the top of the Google results list and took some digging to find. It also has problems of its own, like being on a very slow server and some of the LaTeX on the page not rendering among them.

This partially annoys me because the Wikipedia article is not very well written. You have to read through it several times to understand the derivation (I will try to be better below). The Planet Math site is a little better, but like I said, it took some digging to find, and I actually found it after I had written up half of this post already.

But it is also part of a larger attitude that I am finding more and more of where anything that is not likely to be directly applied is not worth knowing and thus not worth teaching. Sure, it is not likely that any person doing hand calculations will ever attempt variation of parameters on an ode of order higher than 2 or 3, but that is what computer algebra systems like SymPy are for. Unfortunately, it seems that they are also in a large part for allowing you to not know how or why something mathematically is true. What difference does it make if variation of parameters can be applied to a 5th order ODE if I have to use Maple to do actually do it anyway. As long as the makers of Maple know how to apply variation of parameters to a nth order ODE, I can get along just fine. At least with SymPy, the source is freely available, so anyone who does desire to know how things are working can easily see. Anyway, I am done ranting now, so if you were skipping that part, this would be the point to start reading again.

So you have your linear inhomogeneous ODE: . cannot be zero (otherwise it would be a n-1 order ODE), so we can and should divide through by it. Lets pretend that we already did that, and just use the same letters. Also, I will rewrite as to emphasize that the coefficients do not have to be constants for this to work. So you have your linear inhomogeneous ODE: . So, as I mentioned above, we need n linearly independent solutions to the homogeneous equation to use this method. Let us call those solutions . Now let us write our particular solution as . Now, if we substitute our particular solution in to the left hand side of our ODE, we should get back. So we have . Now, let me rewrite as a summation to help keep things from getting too messy. I am also going to write instead of on terms for additional sanity. Every variable is a function of x. . The particular solution should satisfy the condition of the ODE, so
.

Now, if we apply the product rule to this, things will get ugly really fast, because we have to apply the product rule on each term as many times as the order of that term (the first term would have to be applied n times, the second, n-1 times, and so on). But there is a trick that we can use. In the homogeneous case, there is no particular solution, so in that case the terms must all vanish identically because the solutions are linearly independent of one another. Thus, if we plug the particular solution into the homogeneous case, we get

We already know that if we plug the terms in individually of the terms, that the expression will vanish identically because the terms are solutions to the homogeneous equation. The product rule on each term will be evaluated according to the Leibniz Rule, which is that . Now the terms will vanish because we can factor out a and they will be exactly the homogeneous solution. Because the expression is identically equal to zero, the remaining terms must vanish as well. If we assume that each for each j from 0 to n-2, then this will take care of this; the terms with higher derivatives on will also be 0, if this is true, though we do not need them for our derivation. In other words,

.

So, turning back to our original ODE with the particular solution substituted in, we have

.
But we know that most of the terms of this will vanish, from our assumption above. If we remove those terms, what remains is . So this is where it is nice that I learned Cramer’s Rule literally days before learning how to do Variation of Parameters in the general case. We have a system of n equations (the n-1 from above, plus the one we just derived), of n unknowns (the terms). The determinant that we use here is used often enough to warrant a name: the Wronskian. We have that , or , where is the Wronskian of the fundamental system with the ith column replaced with . So we finally have .

Well, that’s the theory, but as always here, that is only half of the story. A Wronskian function is already implemented in SymPy, and finding simply amounts to times the Wronskian of the system without the ith equation, all times . So implementing it was easy enough. But it soon became clear that there would be some problems with this method. Sometimes, the SymPy would return a really simple Wronskian, something like , but other times, it would return something crazy. For example, consider the expression that I reported in SymPy issue 1562. The expression is (thanks to SymPy’s latex() command, no thanks to WordPress’s stupid auto line breaks that have forced me to upload my own image. If it wasn’t such a pain, I would do it for every equation, because it looks much nicer.):
.
This is the Wronskian, as calculated by SymPy’s wronskian() function, of
, which is the set of linearly independent solutions to the ODE . Well, the problem here is that, as verified by Maple, that complex Wronskian above is identically equal to -4. SymPy’s simplify() and trigsimp() functions are not advanced enough to handle it. It turns out that in this case, the problem is that SymPy’s cancel() and factor() routines do not work unless the expression has only symbols in it, and that expression requires you to cancel and factor to find the (see the issue page for more information on this). Unfortunately, SymPy’s integrate() cannot handle that unsimplified expression in the denominator of something, as you could imagine, and it seems like almost every time that sin’s and cos’s are part of the solution to the homogeneous equation, the Wronskian becomes too difficult for SymPy to simplify. So, while I was hoping to slip along with only variation of parameters, which technically solves every linear inhomogeneous ODE, it looks like I am going to have to implement the method of undetermined coefficients. Variation of parameters will still be useful, as undetermined coefficients only works if the expression on the right hand side of the equation, has a finite set of linearly independent derivatives (such as sin, cos, exp, polynomial terms, and combinations of them (I’ll talk more about this whenever I implement it).

The good news here is that I discovered that I was wrong. I had previously believed that among the second order special cases were cases that could only be handled by variation of parameters or undetermined coefficients, but it turns out I was wrong. All that was implemented were the homogeneous cases for second order linear with constant coefficients. In addition to this, there was one very special case ODE that Ondrej had implemented for an example (examples/advanced/relativity.py). The ODE is
, which is the second derivative of with respect to x. According to the example file, it is know as Einstein’s equations. Maple has a nice odeadvisor() function similar to the classify_ode() function I am writing for SymPy that tells you all of the different ways that an ODE can be solved. So, I plugged that ODE into it and got a few possible methods out that I could potentially implement in SymPy to maintain compatibility with the example equation. The chief one is that the lowest order of f in the ODE is 1 (assuming you divide out the term, which is perfectly reasonable as that term will never be 0. You can then make the substitution , and you will reduce the order of the ODE to first order, which in this case would be a Bernoulli equation, the first thing that I ever implemented in SymPy.

But I didn’t do that. Reduction of order methods would be great to have for dsolve(), but that is a project for another summer. Aside from that method, Maple’s odeadvisor() also told me that it was a Liouville ODE. I had never heard of that method, and neither it seems has Wikipedia or “Uncle Google” (as Ondrej calls it). Fortunately, Maple’s Documentation has a nice page for each type of ODE returned by odeadvisor(), so I was able to learn the method. The method relies on Lie Symmetries and exact second order equations, neither of which I am actually familiar with, so I will not attempt to prove anything here. Suffice it to say that if an ODE has the form
, then the solution to the ODE is

You could probably verify this by substituting the solution into the original ODE. See the Maple Documentation page on Liouville ODEs, as well as the paper they reference (Goldstein and Braun, “Advanced Methods for the Solution of Differential Equations”, see pg. 98).

The solution is very straight forward–as much so as first order linear or Bernoulli equations, so it was a cinch to implement it. It looks like quite a few differential equations generated by doing for some function or x and y generates equations of that type, so it could be actually useful for solving other things.

Before I sign off, I just want to mention one other thing that I implemented. I wanted my linear homogeneous constant coefficient ODE solver to be able to handle ODEs for which SymPy can’t solve the characteristic equation, for whatever reason. SymPy has RootOf() objects similar to Maple that let you represent the roots of a polynomial without actually solving it, or even being able to solve it, but a you can only use RootOf’s if you know that none of the roots are repeated. Otherwise, you would have to know which terms require an additional to preserve linear independence. Well, it turns out that there is a way to tell if a polynomial has repeated roots without solving for them. There is a number associated with every polynomial of one variable called the discriminant. For example, the discriminant of the common quadratic polynomial is the term under the square root of the famous solution . It is clear that a quadratic has repeated roots if and only if the discriminant is 0. Well, the same is true for the discriminant of any polynomial. I am not highly familiar with this (ask me again after I have taken my abstract algebra class next semester), but apparently there is something called the resultant, which is the product of the differences of roots between two polynomials and which can also be calculated without explicitly finding the roots of the polynomials. Clearly, this will be 0 if and only if the two polynomials share a root. So the discriminant is built from the fact that a polynomial has a repeated root iff it shares a root with its resultant. So it is basically the resultant of a polynomial and its derativave, times an extra factor. It is 0 if and only if the polynomial has a repeated root.

Fortunately, SymPy’s excelent Polys module already had resultants implemented (quite efficiently too, I might add), so it was easy to implement the discriminant. I added it as issue 1555. If you are a SymPy developer and you have somehow managed to make yourself read this far (bless your heart), please review that patch.

Well, this has turned out to be one hella long blog post. But what can I say. You don’t have to read this thing (except for possibly my mentor. Sorry Andy). And I haven’t been quite updating weekly like I am supposed to be, so this compensates. If you happened upon this blog post because, like me, you were looking for a general treatment of variation of parameters, I hope you found my little write up helpful. And if you did, and you now understand it, could you go ahead and improve the Wikipedia article. I’m not up to it.

PyBOINC Work Continues

2009-08-01T00:07:14+00:00

I am still working on PyBOINC (the embedded Python interpreter with support for BOINC). The actual integration (exposing the BOINC API to Python) was easy, it’s the cross-platform build that’s most difficult.

The problem is that when running an application on BOINC, you have no guarantee of what libraries will be available, so you must either distribute the libraries you need or compile them statically. I chose the later, which also caused lots of issues with the Python standard library. It’s mostly working now, with the exception of the sqlite module.

I moved the repo over to my bit bucket account since Nicolas is busy with other projects. The latest code can be found here.

The color masks of the camera are working correctly now…

2009-07-31T20:40:23+00:00

The color masks of the camera are working correctly now…

Short note...

2009-07-29T14:35:42+00:00

Figleaf working with py3k now after a few minor modifications. Time to put its integration with gcov code in place.

YAPP (Yet Another Progress Report)

2009-07-29T12:52:48+00:00

It only just hit that it has been well over a week since my last blog post. This is unfortunate, as I like to blog at least once a week. Without further ado here is what has been happening in mathtex this week.

Firstly, the matplotlib integration was tidied up. Mathtex is currently an optional component of matplotlib and has completely replaced the internal TeX rendering engine. I am hopeful that with a few tweaks it can be merged in the near future into the mainline matplotlib repository.

Secondly, the first public version of mathtex was released — 0.1 RC 1. However, due to an (embarrassing) slip-up on my part it was quickly superseded by 0.1 RC 2. For those who are interested it can be downloaded from http://code.google.com/p/mathtex/downloads/list Assuming all is well I hope to have a final release out by the end of the week.

Finally, the mailing list has been more active than ever! Over the past few days there have been several interesting discussions on equation breaking, build errors and how to use mathtex from a C/C++ application. Although not broad enough to constitute a blog post the topics make interesting reads nether the less.

Recursive methods for computing equations of motion

2009-07-28T16:07:59+00:00

In the last week, I added methods to the NewtonianReferenceFrame class of PyDy which start at the top of the reference frame tree and the point tree and do several things. The first method, recursive_subs(expr), is designed to take kinematic differential equations (which arise through a combination of linear nonholonomic constraints and/or holonomic constriants, and definitions of generalized speeds) and substitute them into all expressions for relative angular velocity between ReferenceFrames and relative velocity between Points. In doing so, the angular velocity and velocity expressions will involve only the independent time derivatives of coordinates. The second method, recursive_acc(), parses the Point/ReferenceFrame trees and forms the relative angular acceleration and acceleration. The third method, apply_gravitational_forces(), allows one to apply a gravitational forces to every particle and rigid body in the system with one command.

Currently, the NewtonianReferenceFrame class is acting like a container class for information about the system which is somewhat global in nature. For example, definitions of generalized coordinates, their time derivatives, and generalized speeds must all be assigned as attributes of this class in order for it to work correctly.

On the todo list is to write fr() and frstar(), which will also be recursive functions which will compute the equations of motion in one command. More work on the functions dealing with constraints is also needed, and there are at least two approaches that I could potentially implement for this. In particular, the approach taken with nonholonomic systems versus holonomic systems may necessitate different approaches. Currently, the work flow is as follows:
1) Form angular velocity and velocity expressions (linear in time derivatives of coordinates)
2) Form constraint equations arising from differentiated holonomic constraints and/or simple motion (rolling) constraints (m equations, linear in time derivatives of coordinates).
3) Define n-m generalized speeds as linear combinations of time derivatives of coordinates.
4) Solve generalized speed equations (item 3) for n-m ‘independent’ time derivatives of coordinates, in terms of the n-m generalized speeds and the m ‘dependent’ time derivatives of coordinates.
5) Solve constraint equations for m ‘dependent’ time derivatives of coordinates in terms of the ‘independent’ time derivatives of coordinates.
6) The complete set of kinematic differential equations will be the equations arising from item 5 and item 4.
7) Substitute these expressions into the expressions for angular velocity and linear velocity so that the constraints and definitions for generalized speeds are imposed, and so that the constrained partial velocities and partial angular velocities can be formed.

In taking this approach, the minimal set of n-m dynamic equations of motion will be formed, and they will obey all the constraints. These n-m equations, combined with the n kinematic differential equations comprise the complete set of motion equations that describe the system.

PyDy’s examples are being updated to reflect this new functionality, especially the rolling torus example. Additionally I have added a bicycle model which should soon have the nonlinear equations of motion for a very standard bicycle model.

webapp workflow mini

2009-07-27T16:57:31+00:00

To make it easier to imagine what’s my project about, I’ve created a chart which presents the main idea of the Sphinx’s webapp in action:

It’s not, how it works at the moment – it’s how it will look at the end of GSoC. What I need to add is version control system integration and a cache system for the HTML docs. And that’s what I am working on now.

Prep the PEP

2009-07-27T15:39:00+00:00

The CRLF Windows issues is the only thing holding me back from producing a patch and PEP and submitting it for inclusion into the Python Core. I posted on comp.lang.python and until I get a response, I will be gathering sources, references and planning out my PEP as well as looking over my code and checking to see where optimizations can be made.

Win32CryptoKeyring and CryptedFileKeyring

2009-07-27T02:22:00+00:00

We've finished the keyring for Windows: Win32CryptoKeyring. It is based on the Windows's CryptAPI. CryptAPI is a set of APIs which can encrypt/decrpty the data using the login user's info. Thus, the user dose not need to type in the password when he/she is going to unlock the data.

We've also created a CryptedFileKeyring in the similar way. The difference between Win32CryptoKeyring and CryptedFileKeyring is that CryptedFileKeyring uses the AES algorithm provided by PyCrypto to encrypt/decrypt users' passwords. This results that CryptedFileKeyring need the user input their password in encryption/decryption. This may be annoying, so this keyring is not encouraged for daily use.

Both keyrings extend the BasicFileKeyring in the lib. BasicFileKeyring is the abstract base class for general file keyring which supports encryption/decryption. You can created a keyring with your encrypt/decrypt algorithms by easily extending BasicFileKeyring.

For example, here is the source code for the UncryptedFileKeyring of the lib.

class UncrpytedFileKeyring(BasicFileKeyring):
    """A simple filekeyring which dose not encrypt the password.
    """
    def filename(self):
        """Return the filename of the password file. It should be
        "keyring_password.cfg" for Windows, ".keyring_password" for other
        platforms.
        """
        import sys
        if sys.platform in ['win32']:
            return "keyring_password.cfg"
        return ".keyring_password"

    def encrypt(self, password):
        """Directly return the password itself.
        """
        return password
    def decrypt(self, password_encrypted):
        """Directly return encrypted password.
        """
        return password_encrypted

    def supported(self):
        """Applicable for all platforms, but do not recommend.
        """
        return 0

Since UncryptFileKeyring dose not encrypt the password, its implementation is simple. The BasicFileKeyring handle all file parsing/stroring affairs. Here we just need due with the encryption/decryption.

Notice that there is a supported() method for the keyring. It is a new abstract method added for the KeyringBackend. Every keyring needs implement this method to tell if it is applicable for current environment.

We've also polish the code according to PEP 008. So some method names have been changed. Here is the new definition for the KeyringBackend.

class KeyringBackend():
    """The abstract base class of the keyring, every backend must implement
    this interface.
    """
    __metaclass__ = ABCMeta

    @abstractmethod
    def supported(self):
        """Return if this keyring supports current enviroment.
        -1: not applicable
         0: suitable
         1: recommended
        """
        return -1

    @abstractmethod
    def get_password(self, service, username): 
        """Get password of the username for the service
        """
        pass

    @abstractmethod
    def set_password(self, service, username, password): 
        """Set password for the username of the service
        """
        return -1

For more information, please visit our repository.