Season's Greetings to all! This is a test message from my cell phone.

The Skeptic and Santa Claus

Vinny is really excited about the upcoming visit of Santa Claus.  I am enjoying his excitement and enthusiasm.

After he was born, I had some reservations about Santa. I enjoyed the tradition of Christmas stockings filled with gifts.  But I was unsure how to handle the existence (or non-existence) of Santa Claus.  I did not want to lie to my child, after all.  On the other hand, I recalled a story about my parents telling my older sister that Santa was not real -- "I don't want to know that!" she replied. So being truthful wasn't all it was cracked up to be, either.

I remembered from reading "Ask Marilyn" years ago that she told her kids that Santa represented holiday joy and love, but was not real, and they would all pretend to believe in him.  I thought that was probably how I would handle it, until I read the book Parenting Beyond Belief by Dale McGowan.

In the book, they had dueling articles about whether a freethinking family should endorse or eschew the Santa legend with their children.  After reading them both, I was convinced of the wisdom of teaching my child about Santa, to give him an early lesson in reasoning.*

Santa, you see, has a number of parallels with the another supernatural peeping-Tom myth that persists well past childhood in the majority of the American population.  They are both watching and judging you. They both have big white beards.  If you are good, you will be rewarded.  Whatever you get, you deserved -- anything lacking is your fault.  So puzzling through the Santa myth is just a dry run for puzzling through the God myth.  The same logic refutes both.

I've already gotten some skeptical questions about Santa from Vinny.  "How does he go to all those houses?" I was asked just the other day.  "Some people say his sleigh is magic," I replied.  "What do you think of that?"

For now, that was an acceptable answer to his question.  But at some point, says McGowan, the desire to know the truth about Santa will outweigh your child's desire to believe in Santa.  The trick is to allow your child to reason through it on his own, and to never lie to him when he asks direct questions.  That's why, following McGowan's lead, I deflected with "some people say," and allowed him to assess the validity of the answer.

Someday, he will puzzle it all out himself.  He will realize that Santa and his parents use the same wrapping paper, and have the same handwriting.  He will fathom the sheer numbers of houses Santa allegedly serves, and deduce that it is impossible.  He will no longer believe in magic.  And he will put it all together, decide that the benefits of knowing the truth outweigh the benefits of living in denial, and stop believing in Santa.  And when he makes this decision, it will feel good, and not be disappointing, because he figured it out himself.

And I will be proud of my little skeptic, and feel confident that he will use his intellect to dismantle other myths he's exposed to (not just higher powers, but myths about gender, race, politics, relationships, himself, etc.).


* Read McGowan's Santa article here, and then buy the book to read the rest!

Adventures in Speaking Too Soon

Alas, I spoke too soon in the previous post.  He was able to sleep on his own for about a week but now we're back to square one.  Sigh.  I know it can't last forever -- if nothing else, he'll become a teenager and not want anything to do with us at some point.  But it sure is frustrating.

Adventures in Migraines

I can't say that I am a fan of migraines, but the last one I had actually resulted in something good.

I've been getting them with more and more frequency, probably 3 times a month over the past couple of months, which has been pretty unpleasant to say the least.  I went to the doctor, and she has scheduled me for a CAT scan to make sure I don't have a tumor or something, but otherwise I just have to collect information and try to figure out any kind of pattern to them.

On Wednesday night, I had a really, really painful one.  It is my job to put Vinny to bed every night.  Lately he has been too scared to fall asleep on his own, because developmentally he has gotten to the stage where he knows something about death and is afraid of being alone.  So I have sat there and played on Melvin (the tiniest, babiest computer) until he falls asleep -- thus the recent spate of prolific postings on this blog.  But on Wednesday, my head just hurt way too much to be able to do that.  And of course, that evening he was particularly hyper and not ready to fall asleep at bedtime.  I was getting angry and because I was so frustrated and in so much pain.  So I went downstairs to Jeff and asked him to help me.  Jeff went upstairs and lay down the law, telling Vinny that Mama was going to bed because her head hurt really badly, and that Vinny could goof off and play if he wanted to, he just had to stay in his room.  There was some crying, but Vinny did it.

The next morning, Vinny pointed out to me that he had been promised a prize for falling asleep all by himself and staying in his bed all night.  (This prize had been dangled in front of him after he returned from that week at Grandpa and Grandma's, where he had fallen asleep by himself with no problems, in an attempt to convince him to do the same thing here, but to no avail at the time.)  Upon confirming what had happened that night with Jeff, I agreed and awarded him the prize: sunglasses with blinking blue lights on the sides (one of the best pieces of swag we picked up at the conference).  Then I told him if he did it again that evening, he would get another fantastic prize.  The next morning, he was rewarded with another piece of light-up swag.  And yesterday I told him if he did it for the next two nights he would get yet another prize.  Last night was a success, and I anticipate tonight will be too.

I think he'll be falling asleep on his own for the foreseeable future, which is a great thing!  So for perhaps the first time ever, something good came out of a migraine!

Winter Weather

It has been pretty cold here lately!  Why, today I don't think the temperature rose above freezing.  I excitedly wore several layers of clothes today.

It doesn't get quite this cold that often here in Tennessee.  The weather (although not the complete lack of snow) reminds me of my days in Illinois.

Speaking of Illinois, when I told Vinny that one of his cousins lives in Illinois, he suggested that his cousin actually lives in "Billinois" and just laughed like it was the most hilarious thing ever.  Then I suggested that Vinny lived in "Sillynois" and laughed a bit myself (although Vinny did not find that as humorous as his own joke).  I am still trying to figure out the four-year-old sense of humor.  So far it seems to me that watching him laugh is about the funniest part of his jokes.

Fun with Creative Play

Vinny's been really into creative play these days, which I really love.  He has a great imagination and it is so fun to see what he comes up with.

Tonight, he was C3PO and Jeff was R2D2, and when I joined in the play I was dubbed Darth Vader.  Luckily, I didn't have to behave like Darth Vader particularly, and all our conflicts were solved with a pizza party.  If only it were that easy in real life!

Computers and Me (Part 2)

In that first semester of grad school, I suddenly realized that I had a lot of work to do to catch up to all these people with computer science bachelors degrees.  I was a pretty good programmer for a physicist ("for a physicist" being the operative phrase) -- but the thing is, there is so much more to computer science than just programming.  It was pretty tough going, but with help from friends and my very patient adviser, I eventually learned everything I needed to know to get that doctorate.

I was more on the math side of things than the programming or hardware side through my graduate career.  (Thus the title of this blog, started in my final semester of graduate school.)  I resisted learning any more of the technical side than I needed to, but I knew I needed to learn more.  But I was scared -- it all seemed so complicated, and to admit that I didn't know something was a big risk -- what if I failed at learning it?

I took a research assistantship at the supercomputing center, which turned out to be the best thing I ever did careerwise.  I got used to working with big supercomputers and started to feel a lot more comfortable programming in parallel.  This allowed me to do the computing I needed to do for my dissertation, which could not have been done on anything smaller than a supercomputer.  It was a risk I took that paid off many times over.

In my postdoc, I learned a lot more about programming and designing scalable parallel algorithms, which was awesome, but I was still kind of light on the hardware side when I started my current job.  I had hoped to stay that way but quickly realized that I was on the side of things where I actually had some input into the design of the next-generation leadership supercomputer.  (Okay, very little input, but more than I had ever had.)  So instead of just not having an opinion, I had to actually start thinking about computer architecture and how it impacts the scalability of parallel algorithms.

But I really didn't know enough about computer architecture to have a particularly valid or useful opinion.  So, when I was asked to help give a workshop on using our machines, I volunteered myself for the part where we explained the machine architecture.  I then learned Computer Architecture 101 (courtesy of Wikipedia) and translated what I had learned into a presentation for a lay audience.  This helped me to understand computer architecture in a way that I had never understood before.  Suddenly all those discussions about next-generation machines made a lot more sense.  And I could throw around computer hardware jargon with the best of them.

Today, I am pretty sure that I have no interest in designing computer hardware, but I am interested in how the components fit together and how this relates to algorithms for high-performance computing.  I am really happy in my current job because I now have just enough knowledge of computer architecture to understand what is going on.

Computers and Me (Part 1)

I have always loved computers, as long as I remember.  I remember my dad bringing home a computer when I was very young, and using a modem (which was a cradle for the rotary phone's handset) for something-or-other.

The summers between my early elementary school years I took some computer science classes for kids.  We programmed in BASIC on some mainframes at the university.  One of my teachers was a woman, but I don't remember the gender makeup of the class.

I do remember being the only girl in the electrical engineering class I took the next year, though.  I was self-conscious about it because I was just learning about gender roles and the fact that my interests were not typical for those with a matching 23rd pair of chromosomes.  I think I was a bit overwhelmed by the boys in the class, but I did learn a lot about resistors and capacitors and other interesting things.

When I was nine, we got our own home computer.  It had two floppy disk drives, no hard drive, and a monochrome (amber) monitor.  You had to boot it from the A drive.  It had BASIC so I was able to write some programs, just like I had done in my computer science classes.

In junior high, I was interested in joining the computer club, but I was intimidated by the boys in my class and did not join.  They weren't just loud and boisterous; they actually made fun of me for wanting to join the computer club, urging me to return to the kitchen where I belonged.  So it was not a welcoming or safe space for me and I stayed away.

I went to a math, science, and technology magnet school for high school.  In my math class my sophomore year, we wrote programs in Quick Basic, so no line numbers were necessary.  I remember for our final exam we had to write a code that would determine whether the number you input was prime, and that I wrote a program to do this in no time flat, while the rest of the class was struggling with it.  (Of course, the method I used, namely counting by odd numbers and testing whether the number was divisible by any odd number from 3 to the square-root of the number in question, is not scalable for large numbers, but that is beyond the scope of this post.)

There was an advanced computer science course offered, but at the time I had found that I had a great interest in chemistry, so I took AP Chemistry instead of computer science.  I enjoyed playing on our computer at home, but my formal computing education waited until college.

In college, I took a class on FORTRAN for engineers.  It was really easy and I aced the programming projects and the exams.  At that time I was majoring in chemical engineering, but I soon switched to physics. 

I thought I wanted to be an experimental scientist until I did a summer internship simulating physics on a computer.  At that point I discovered where my heart really was!  So I did a concentration in computational physics for my major.  To do that concentration, I took a class on numerical methods, and aced it.  It was in that class that I got the first inkling that maybe I could go into computer science.  I got a problem set back with a 100% grade and a personal note from the professor: "Have you considered graduate school in computer science?  I would love to have a student like you!"

I took an extra year to complete my undergrad and took some additional CS classes that final year.  I was overjoyed to discover that I was admitted to the institution from which I eventually earned my Ph.D. some seven years later.

(Stay tuned for Part 2!)

Debugging in Parallel

Sometimes* when you write a computer program, there are bugs in it.  Some of those bugs can be easy to catch (e.g., I forgot to put a semicolon at the end of line 67 and my code won't compile), while others are not.  There are different types of bugs, too -- memory errors that cause a segmentation fault, typos that might cause one variable to be updated instead of another, and errors in your algorithm, to name a few.  Each of them is uniquely challenging to find and fix.

But when we add an additional layer of complexity to a code by making it run in parallel, the difficulty of finding and fixing bugs goes up by several orders of magnitude.  The most insidious of bugs will appear only at high process counts, or irregularly.  How then can we find out where our code is going wrong?

A classic method of finding bugs is by inserting print statements in the code.  Using the print statements and running the code, we can follow a sort of bisection algorithm to determine where things go bad.  Typically we insert a few print statements at the first pass, and then further hone down to the point where the error occurs with several subsequent runs.  But this is highly time consuming, and produces a lot of excess data.  I for one would hate to insert all those print statements in a complicated code, not to mention sift through the output of print statement debugging across 200,000 processes.  It can take weeks to find a bug in this way, especially if you have to wait for a batch system to run your jobs.

The best solution is to use a debugger.  Using a debugger, you can pinpoint the exact line at which the bug occurs in a single trial (for bugs such as segmentation faults).  And you can insert break points around areas of the code you suspect are faulty, and examine the contents of the variables.  You can also step through the code slowly and figure out how x came to equal 27 instead of 32 (for example).

Parallel debuggers exist, and do scale up to hundreds of thousands of processes.  Of course, these are commercial products but I'm guessing you don't have a 200K-core supercomputer in your basement.  Most supercomputing centers have a license for a commercial debugger such as Allinea DDT or TotalView.  Both of these are great products that will help you to find your bugs quickly and relatively painlessly.  And if you stubbornly insist on not using a commercial product, most mpirun or mpiexec commands allow you to attach your favorite free debugger to your parallel execution.

Do you think it is too hard to learn to use a debugger, that by the time you do learn it you could have already found that bug and moved on to something else?  Invest in your future and learn to use a debugger anyhow!  Let me tell you the sad, sad story of a graduate student I knew quite well.

This graduate student felt that by the time he/she learned to use a debugger, that final bug sitting between the student and graduation would have been found and fixed.  Because, of course, that was the final bug.  He/she said this, bug after bug after bug.  Looking back, this person realized that by investing a day learning to use a debugger, he/she could have graduated (and started earning for-real money instead of measly graduate student stipends) about six months earlier.

Don't be like that graduate student.  Learn to use a debugger and stop wasting your time!


* Actually, pretty much every time you write anything more complicated than "Hello, world!"

Running Me Ragged

So, today my Mean Running Coach* took me on a route that was over 5 miles.  This is farther than I have ever run before.  I hasten to add that I probably ran half of it at most -- but we did complete the whole thing in maybe an hour and a quarter, which is pretty respectable.

But oh, was it painful!  The good thing is, it will be a lot easier to do on Friday.  It is amazing how the body gets stronger so quickly.


* She is actually really nice and one of my dearest friends at work.