My Review of GEEK CLOCK

UncommonGoods

While everyone else was watching the clock, you were paying attention during math class, storing away square roots and factorials for a day where you could prove your mathematical prowess. Well, my geeky friend, that day has come. Pictured before you is a clock, where all the numerals have been rep...

GEEK CLOCK

Cool way to show off math geekiness!

Alex Palo Alto, CA 7/18/2009

 

4 5

Gift: Yes

Pros: Attractive Design, Striking original

Best Uses: Living room, Decoration, Kitchen

Describe Yourself: Budget Shopper

Primary use: Personal

I've hanged it up in the living room and just love the way friends and acquaintances do a double take the first time they see it (even if they are serious math geeks themselves). I'm seriously thinking of taking it to the office (or maybe buy another one to keep there -- this one was technically a gift to my wife, an even geekier geek than myself, so I guess I can't just take it to the office;-).

()

priceless...

feature
Originally uploaded by dratz

The web is full of cute and/or funny pictures, but once in a while, one really stands out...

Software development is not yellow

Best blog post I've read in a long time (and I read a lot!): Chris Dillow's Experts and the Demand for Certainty.

It's a sharp, spot-on, well-reasoned, well-written analysis, and -- it finally explains to me why I've always gotten so much push-back when, as an expert in my field (software development, and the management thereof), I offer "customers" my forecasts in the right form.

By "customers", here, I mean stakeholders of any stripe, including most product managers, top managers, etc -- even other developers, when they look up to me as a manager, mentor, or "senior advisor" figure rather than sensibly interacting with me as a peer!

And, the right form of forecast is always going to be expressed something like "X plus or minus Y" (or equivalently "between Z and T", where Z=X-Y and T=X+Y), accurately and explicitly expressing the margin of error that always accompanies any prediction (you can take the "with 95% probability" proviso as implied in any such quantitative expression).

Here's why I invariably get vehement push-back against expressing forecasts in the only sensible ways: the "customers" don't want from me, the expert, my knowledge; rather, what they want is certainty -- fake, bogus, fraudulent certainty is so much better than the messy, error-margin-involving business that's inevitable when you reach towards knowledge of reality:-(.

Now, this important realization doesn't teach me how to force stakeholders to face reality, but it does help me frame and understand their mindset, and thus helps me predict (with some margin of error, to be sure;-) how well or badly various communication strategies will work...

Strong types, weakly bound

Reading Strong opinions, somewhat weakly held on Jason Cohen's excellent A Smart Bear blog this morning, I was quoting this excellent soundbite (you really need to simplify it down to "strong opinions, weakly held" to make it work as a soundbite) out loud to Anna and musing about it -- and exactly at the same time she and I chorused about the analogy this has with Python's approach to typing... objects with strong, precise types, but "weakly held" (i.e., weakly bound) via names or slots in containers that might just as well hold objects of other (also strong) types.

This analogy may actually be the least "obvious" thing she and I found ourselves "chorusing" about, though such "choruses" happen more and more often and so it's becoming hard to tell;-). Anyway, I'll be sure to use this next time I need to present Python's typing approach -- now if I can only find a way to work ducks into it, too...

Get your blog typealyzed!

Fun URL to try: Typealizer (HT Greg Mankiw).

What Typealizer has to say about Aleaxity (quoted verbatim, including punctuation/grammar errors and typoes)...:

"""

The analysis indicates that the author of http://aleaxit.blogspot.com is of the type:
ISTP - The Mechanics
[ISTP]
The independent and problem-solving type. They are especially attuned to the demands of the moment are masters of responding to challenges that arise spontaneously. They generelly prefer to think things out for themselves and often avoid inter-personal conflicts.

The Mechanics enjoy working together with other independent and highly skilled people and often like seek fun and action both in their work and personal life. They enjoy adventure and risk such as in driving race cars or working as policemen and firefighters.
"""

The "enjoy adventure and risk" is as off-base as it could possibly be (if anything, I enjoy reducing and controlling risks and adventures by carefully and prudently balancing solid architectures, sound methodologies, best practices, ...), but other bits do appear rather spot-on;-).

Python tips: pickling it right

Here's an often-seen Python snippet...:

pickle.dump(stuff, open('foo.pik', 'w'))

What's wrong with this? Well, several things, as it turns out...!

1. Use cPickle, not pickle: that will speed things up by 5 or 6 times, effortlessly.


2. The common, sloppy use of open without a corresponding close is theoretically OK in today's cPython, but there's really no good reason to support it. Be neat instead, and write (after a from __future__ import with_statement if you're still using Python 2.5):
   

   
   with open('foo.pik', 'w') as f:
    cPickle.dump(stuff, f)
   



3. Unless there's a very special reason to make you want the pickle dump to be in ASCII (and I've hardly ever seen a good one), don't just use pickle's default, legacy protocol! Rather, explicitly request protocol 2, or better still, unless you need pickle files loadable by older releases of Python, request "the best protocol available".
   

So, the best equivalent of that little sloppy but alas-too-common idiom is:

with open('foo.pik', 'wb') as f:
 cPickle.dump(stuff, f, cPickle.HIGHEST_PROTOCOL)

Don't forget the little b in 'wb', by the way — it won't matter under Linux, OSX, or Solaris, but it will matter in Windows... and, anyway, as we all know, explicit is better than implicit!-)

Python: introspecting for generator vs function

At Baypiggies yesterday evening, Fernando Perez asked how to tell by introspection whether you're dealing with a "plain old Pythjon-coded function", like, say,

def f(): return 1

or rather a generator function, like, say,

def y(): yield 1

Apparently, he needs that info to perfect some decorator they're using as part of a nose-based test framework for scipy.

I don't think there's any other way except by looking at the bytecode for Yield vs Return opcodes; so, I jotted down on the spot the quick-and-dirty approach based on that idea:

import dis, sys
def is_generator(f):
   save_stdout = sys.stdout
   fake_stdout = cStringIO.StringIO()
   try:
       sys.stdout = fake_stdout
       dis.dis(f)
   finally:
       sys.stdout = save_stdout
   return ' YIELD_VALUE ' in fake_stdout.getvalue()

Of course, this does much more work than necessary (AND can be fooled by a function containing a peculiar string literal... like itself!-) . So, early this morning, I prepped a somewhat better performing and more solid version:

import opcode
YIELD_OP = opcode.opmap['YIELD_VALUE']
RETURN_OP = opcode.opmap['RETURN_VALUE']
HAVE_ARG = opcode.HAVE_ARGUMENT

def isgen(f):
    code = f.func_code.co_code
    n = len(code)
    i = 0
    while i < n:
        op = ord(code[i])
        i += 1
        if op >= HAVE_ARG:
            i += 2
        elif op == YIELD_OP:
            return True
        elif op == RETURN_OP:
            return False
    return False

Hope this can prove useful to someone else!-)


Alex