JOSHUA HOLBROOK flickr : github : twitter

Scipy 2010, Day 2 (posted 29 Jun 2010)

Meet Jenni:

(flickr)

(Incidentally, I wish Flickr would give me markdown, etc. in addition to stupid html. Is there a greasemonkey script for that? Anyways—)

I met Jenni back in science camp the summer after I graduated from high school, and it turns out she lives right here in Austin! She seems to appreciate having company from far off places, and has been giving me hookups on good eats the last few days. Also, a ride from the airport. Thanks Jenni!

PyCUDACafe Medici

I missed this tutorial. I swear my alarm went off at 7:00, and I looked away for a second, just one friggin’ second, and suddenly it was 8:30. Weak!

So, I took the opportunity to try out Medici’s. I have to say, they make a good cup. It’s way more mellow than I’m used to, though.

This is how I tend to think of coffee:

(flickr)

Medici’s coffee, on the other hand, is a gentle lover.

Lunch:

I found this awesome place that makes vietnamese sandwiches. I bought a garlic and hoisin tofu sandwich, and it was awesome…but HOT! :( My poor mouth.

Traits:

Enthought employees and Traits users seem to have a tough time explaining exactly what Traits is. I think this is because Traits has a few parts to it that have ended up being fairly coupled:

• Strict(er) Types, with checking, validation and stuff like that.
• Fancy Class Properties, derived values with auto-updating, memoization.
• Event-Based Action, in particular, notifications and responses for when different traits change, but there are also simply-firing Event traits as well.
• Simplified GUI toolkit action, which makes it relatively easy to bust out views and controllers for your traits models.

I have mixed feelings about the coupling of the typing part of Traits and the GUI part of Traits. See, if you make a class with Traits, it automatically has a simple view generated for that. On one hand, this is really slick if you want a stupidly-easy gui, like, Right There, and I’m sure it’s not THAT much overhead, and you don’t have to spawn a view if you don’t want to. On the other, it seems silly to have all that GUI views stuff there if all you want is to mitigate the downside of dynamic duck typing in Python.

It almost certainly works great for Enthought, though. See, Enthought makes most of its money not by licensing EPD, but by helping companies make custom (scientific) applications with nice GUIs, and that’s really what ETS was made for, and I think this is where Traits (and friends) shines. In fact, if I were to describe what Traits is, instead of listing all the little bits right off, I’d probably say,

Traits is a python framework for building scientific desktop applications.

Anyways: This coupling is something James has complained about with pygame. In particular, he’s used pygame’s gamepad interface in the past, but (like Traits) pygame couples this with a bunch of other stuff related to making games. Honestly, having not really used pygame, I can’t really comment on this too much. But, Traits seems to have a similar problem to me.

I would definitely consider using traits for a scientific-focused user interface–for example, if I were to pick up sfbe again and stuck with python, I’d definitely give Traits&Friends a whirl. On the other hand, for the little toys I make, where I wouldn’t necessarily want to bust out any GUI elements, eventing, etc., would it be worth importing Traits simply for the type-checking?

Maybe.

As an aside:

While I’m dumping unsolicited criticism on the developers in the scientific python community, I might as well comment on the short discussion I had with Brian Granger yesterday about the development of ipython.

First of all, iPython is very nice. I highly recommend it. In addition to the features of the standard python interpreter, it also gives you tab completion, easy access to docstrings, the ability to run scripts at the interpreter line, and lots of other goodies I’ve never used. In fact, this ties directly into my concern: Does ipython have a feature creep problem? Learning about ipython’s parallel computing toys yesterday.

It was a nice, quick and enlightening discussion.

First, he said that there has been some issues with feature creep in the past, though they’re trying to mitigate those now.

Second, talking with him gave me a better feel for ipython’s goals. I mostly use ipython to test things out while writing scripts and whatnot. Every once in a while, I’ll use it to quickly plot something with matplotlib. I think others, however, see ipython as taking a similar role in the scientific community (combined with python itself, of course) as MATLAB does. Thinking of ipython in this context, I think, puts their goals into perspective. I mean, you know either MATLAB has this functionality, or The Mathworks is working on it.

I guess I should say…

…I’m no hot-shot or anything. Seriously. I just started python-ing a little over a year ago. I just read a lot. ;) Hopefully I’m not coming across as some total douche that talks a lot of shit but fails when it comes to, say, Writing Great Code.

Mayavi2

This talk is being given by the guy that wrote the original mayavi. He’s an aerospace engineer from India. He strikes me as a cool, smart guy!

Something interesting with mayavi2 is that, even though simple python scripting through the mlab interface is a pretty compelling and marketed feature, that you should be able to use mayavi2 without ever touching python. Check out all the file types you can open:

(flickr)

At any rate: I’m digging mayavi2 so far, even though it’s beating the crap out of my poor computer. The mlab interface reminds me of matlab’s 3-D plots, except that they don’t look like total ass. In fact, I would call mayavi’s plots pretty. This, combined with the fact that it can read legacy VTK no-sweat, makes me think that mayavi2+sfepy would be a pretty win combination. Now, if only there was a good python-based, open-source mesher—perhaps this would do the trick (how I missed this before my five-seconds-ago interblag search, I don’t know). I will have to experiment with this.

(Interestingly enough, the author of meshpy is also the author of PyCUDA, and in fact gave this morning’s tutorial. You know, the one I missed.)

One interesting feature of Mayavi is code generation. COMSOL 3.5a does something very similar, actually, and I have to admit that it’s tainting my opinion of this feature. The idea here is that you can do something in the GUI and then generate a python script that will do the same thing. It looks like it has the same problems that COMSOL does, in that it generates a bunch of extra crud and isn’t necessarily the most readable thing ever. On the other hand, at least the code is something that you could generate from scratch with knowledge of the(documented) object-oriented mayavi API, unlike COMSOL 3.5’s abortions of m-files. That, and sometimes doing it in the GUI is the sensible thing to do.

I’ll have to blog about my COMSOL experiences sometime.

Friends:

ALL THE BLOGPOSTS STANDING IN THE LINE FOR THE BATHROOM: