Meditationg at Muir Beach

I managed to to get out last weekend with a few friends and we made it to Muir Beach on the North peninsula. The day was absolutely beautiful and we had a good time wandering around before heading back to Berkeley to watch the Superbowl. There are a few more pictures in the image gallery from the trip in the ‘2010 Berkeley Spring’ album.

Cover of Goss' book 'Close to the Wind'

Just finished Pete Goss’ book Close to the Wind: An Extraordinary Story of Triumph Over Adversity in record time, about 3 days. Great story. Has little or no value aside from the entertainment, but that is just what I needed while sitting around in the airport. If you like sailing & reading then this is probably a good choice.

Proposed by Sam Vandervelde, St. Lawrence University, Canton, NY.
First we let and . In other words, is the set of all nonzero rational numbers written in lowest terms. Find, with proof, the value of

.

I joined the C.B. Harris Group! The principle investigator (PI) is pretty awesome, and the group itself has thus far seemed like a very good fit. I keep hearing horror stories from other first-years about how they are having trouble with their lab-mates/PI and I am just glad that I have had zero conflicts. Specifically I joined what is known as the ’surface-side’ of the Harris Group which studies how electrons behave on surfaces; more details can be found on the group website. I haven’t started real research yet since the learning curve on the apparatus is pretty steep (not to mention my lack of theoretical knowledge about surface science), but next semester I will be gearing up — picking a project and hopefully starting to really work on collecting data.

What is kinda crazy is that Harris is my great-grand-advisor in a manner of speaking. My undergraduate PI, C. Stromberg, studied under M. Fayer @ Stanford, and Fayer was one of Harris’ first graduate students! Small world eh?

I will be in Berkeley for another few days before I head home to MD to spend Christmas with the family. I am really looking forward to taking some time off so I can come back refreshed and ready to do some science!

San Francisco/Berkeley

So I am living in Berkeley now and going to UCB (University of California at Berkeley) full-time. Life is good, though obscenely busy — I TA for a section of Chem 1A, I am actively looking for a research group to join, and I have two grad classes each of which is enough to keep me busy full time, and I have all three to do at once! But to be fair I am in the same situation as countless other grad students and I am sure it will all work out fine.

• Went to the Tetons and hiked Granite Canyon trail (~16 miles)
• Putzed around Missoula, MT and drank a lot of good beer
• Camped at Peck Gulch on the Koocanusa Lake
• Climbed at the Stone Hills (Koocanusa Lake area) half a dozen times
• Spent a day kayaking on Whitefish lake
• Spent a day mountain biking up Big Mountain and in Round Meadows
• Hiked the Highline trail (~20 miles) in Glacier National Park to Swiftcurrent Peak
• Hiked the Two Medicine trail (~20 miles) in Glacier National Park and saw a Black Bear
• Lay around at various small lakes and drink beer
• Met a bunch of my sister’s/Keith’s cool friends
• Ate a bunch of really good totally home-cooked food

A hard life for sure — can’t wait to visit again. A few pictures are below, the rest are in my photo album.

Now I realize that there are umpteen million methods for breaking down the steps in problem solving most effectively. I am not claiming that Rich’s method is the best, or even that I am relating the method exactly as he explained it to me. What I am claiming is that I think it is simple and effective; the epitome of the KISS principle that I hold dear. Below I give a general overview of SPRI and later I will post a specific example of its use.

Statement; Problem; Resolution; Implementation

Statement

In order to plan your future wisely, it is necessary that you understand and appreciate your past.
-Jo Coudert

The first part of solving any problem is to accurately and completely describe and explore the situation. This generally starts by enumerating the end goal of the project in an almost idealistic or theoretical manner. Be specific — ill-defined goals lead to crappy solutions. At this point you shouldn’t hamper yourself with questions like ‘Can we actually do that?’. Instead you need to think to yourself ‘If I had unlimited resources, what would I want to accomplish?’. This is your chance to think BIG.

Once you have the end goals well-established you need to completely explore the current state of affairs in regards to the problem. That is, you need to do the footwork to figure out what has been done in the past. In academia this typically means doing long, tedious literature searching, but this approach is not the end-all by any means. For programming projects I typically search online forums, look for open-source project, and email/PM experts in the field. However you accomplish it, at the end of the day you should have a complete education of what has been tried in the past — this will stop you from trying to ‘reinvent the wheel’. A failure to do this will be just that, a failure, certainly not a good way to start.

Problem

We have met the enemy and they are ours.
-Oliver Hazard Perry

Here is where you need to identify exactly what is keeping you from your goals; it starts with identifying the obvious problem, but then you move on to the analysis, that is the breaking down of the problem into its most basic constituent parts, which is the most important part of solving any problem. This step typically involves some sort of abstraction, and as simple as many think it, it is frequently more subtle than you might think. There are usually many levels of abstraction for a given problem, and your goal is to find the correct level of abstraction. Too little abstraction and you probably haven’t gotten to the heart of the problem, and too much abstraction and you will probably end up with a vacuous problem statement.

I find it really amazing how this step can simplify the whole problem solving process; a previously impossible looking problem can generally be reduced to a series of small, very-manageable sub-problems that were not at all visible beforehand. Incidentally, these sub-problems are typically the ones that screw over people that don’t thoroughly analyze a problem before trying to work on the solution — you can’t solve a problem if you don’t know that it exists!

Resolution

A good plan is like a road map: it shows the final destination and usually the best way to get there.
-H. Stanley Judd

This step is where you decide on the methods/techniques you will use to solve the problem — aka, the planning phase. You ought to be able to bring together the initial research, the detailed problem statement, and your own set of skills to determine a path to a solution, or at least a path that will probably lead to a solution (remember that problem solving is frequently an iterative process). In experimental research this is typically where you decide what experiments you need to run. In programming this is where you’d decide what algorithms and paradigms to use. In any case, your resolution step should leave you with a clear and detailed road map of how to proceed. Without this road map you will be aimlessly guessing at solutions with only the smallest hope of success.

Occasionally you might find yourself at an impasse at this point. You think that you see the problem(s) clearly, but you can’t figure out how the hell to solve it; your idealistic goals meet reality. This is where you might have to either revise your original goals to be more attainable, or have another try at analyzing the problem. Thus from this step you might very well find yourself looping back to a previous step. This is OK, it’s the way problem solving works. Don’t get discouraged, get determined.

Implementation

No plan of operation extends with any certainty beyond the first contact with the main hostile force. Only the layman thinks that he can see in the course of the campaign the consequent execution of the original idea with all the details thought out in advance and adhered to until the very end.
-Helmuth von Moltke

Up until this point you shouldn’t have written a line of code, run a single experiment, or cut a piece of lumber. Here is where you finally get to do something! You take the plan that you made in the last step and enact it. Nothing more, and certainly nothing less. This is typically the easiest step of all, which is ironic because most novice problem solvers skip all of the previous steps and get stuck in the Implementation step for eternity.

This step, even more than the last can end up at an impasse. You might find out that your plan was incomplete in which case you will need to revise it, or you may find that the plan was utterly unfeasible in which case you might have to backtrack to any one of the previous steps. Again, this is OK, I swear that it’s just the way problem solving works. The more practice you have with problem-solving the less the backtracking will happen, but it will never go away completely.

Happy problem solving!

The Cover of Fox's 'Always Looking Up'

I bought a copy of Michael J. Fox’s new book, Always Looking Up: The Adventures of an Incurable Optimist, while at an airport about a month ago and I have just finished reading it. First off, it is definitely not the type of book I would usually read. Aside from the Feynman books I can’t even remember the last time I read anything that approached a memoir, which is what this book is. Interestingly enough, that is precisely the reason I bought it; I figured it was time I read something besides epic fantasy and technical literature.

At the end of the prologue Fox accurately describes the content and organization his book:

What follows is a memoir of this last decade. But unlike Lucky Man, it is thematic rather than chronological. Work, Politics, Faith, and Family. These are the struts of my existence. These are the critical supports of my life.

Fox relates countless anecdotes about himself, his family, and his friends, all of which are told with his unique sense of humor. As I read I found myself laughing out loud as he related things like his cross country car-trek, where his father apparently had a resolute ‘no are-we-there-yet’ policy. In addition to the stories he also devotes a decent number of pages to the Michael J. Fox Foundation, which spearheads the effort to find a cure for Parkinson’s Disease.

Overall I am pretty happy that I read this book. Always Looking Up didn’t let me escape to an alternate reality like fantasy does, and it didn’t really educate me in any substantive way, but what it did do was to take me on the awe-inspiring roller-coaster ride that has been Michael J. Fox’s life for the past decade. It was wonderful to see how Fox’s steadfast optimism and drive could turn something so debilitating as Parkinson’s Disease into a positive influence.

The JHelioviewer Java Webstart Application

Back in winter and spring of 2008 I took a semester off and worked full time for the European Space Agency in Greenbelt, MD as a programmer on the SOHO project team. They tasked me with exploring the feasibility and starting the coding on a new type of solar image viewing application. The new part is that instead of using old image file types, this application was to use the JPEG2000 file format. The reason behind this was that older file formats were not well-suited to deal with the beast that is solar data — solar datasets are absolutely, ridiculously large and contain lots and lots of important metadata. A second reason to move to the JPEG2000 standard was that Part-9 of the standard was a interactive protocol that allowed for extremely efficient network-based viewing of the images; thus allowing the solar images to be stored and viewed much more effectively.

I spent the first couple weeks just trying to figure out the technical details of the JPEG2000 standard — something that turned out to be both difficult and interesting. Once I had an inkling of the underlying concepts in play I started looking for available implementations. I quickly found the Kakadu library, which I promptly started using to create the application which was shortly dubbed JHelioviewer. (The name comes from the fact that Helioviewer already existed and this was to be the Java counterpart to it.)

I ended up finding a Google Summer of Code project by Juan Pablo Ortiz that seemed like a good place to start and spent the next several months with my nose to the grindstone, occasionally working 50+ hour weeks. The work was hard for me, after all I’m not really a programmer. I kept smashing face-first into technical roadblocks that a real programmer would have easily dealt with. Instead I would stay up late schooling myself on things like the Java Native Interface, semaphores, and what the heck a convolution was. I did a lot of reading and spent a lot of time writing code to figure out if I really did understand how things worked. Heck, at one point I spent several days tracking down a bug in some system C-code!

Overall I think the experience was really good for me. Since I was working more or less alone I had to rely on myself for almost everything. I had to take the initiative simply because there was no one else to do it. That is not to say that the guys I worked with were not helpful — I spent countless hours discussing ideas with almost everyone else in the department — but they were not actively working on the code. It was for all intensive purposes my code; I took a lot of personal ownership in it, and I believe that is why in my opinion it turned out well.

By the end of my employment I had created a working application that, although extremely rudimentary, was what they had asked me for. I spent the last week or so documenting and reorganizing the code in order to hand it off to the next person that would work on the project. When I handed the code off I was a bit apprehensive — I was worried that my inexperience might have irrevocably tainted the project. I am glad to say that I no longer believe this is the case. About a year and a half has passed since I handed the code over and many much more qualified people have worked on it since then. The result is that they have turned my mangled, proof of concept code into a functional and feature rich beta application.

There are two points I’d like to hit in closing. First is that I have an inordinate about of pride that a project that I initiated is turning into something big. It’s a real boost to the ego for sure! I wish the project nothing but the best. Second is that not only did my hard work pay off for the project, but the project paid off for me. After I left the project, the project scientist wrote up an article for Computing in Science & Engineering and included me as an author! (I feel bad that my name is on there as an author and I didn’t actually write any of the paper, but after reading it I realized that I did significantly contribute via the code I wrote and the discussions I had with the author.) The paper has been accepted as of June 2009 (what initiated this otherwise chronologically-misplaced post) and is awaiting the ‘production checklist’, whatever that is. A pre-print can be found at the bottom of the JHelioviewer site. I’m finally published!!!