Math - could slack off, and still get good grades

To be honest, what I liked best about math was that I could slack off and still be at or near the top of the class. The harder the math got, the better I did, relative to the rest of the class.

Image via Wikipedia

Ultimately, I got a pretty decent undergrad math education from UCLA, took some graduate level algebra as an undergrad. I never had to rise above a loping slacker's pace.

Lacked and would have appreciated: category theory (zip zero zilch taught), better differential equations (I got a decent grade with no need to understand the subject, which is lame), continuous distributions and how they relate to the Fourier transform (if this was taught to me, I don't remember it).

It is shocking how much I need to learn now was invented/developed after I graduated from college. Before 1993 - No distributed revision control, no distributed operating systems, no decent theory of just-in-time compiling, no decent published real-world examples of Bayesian probability, Judea Pearl's theory of causality wasn't invented yet, no decent cryptographic hashes, no Bloom filters, no decent introductory texts on decision analysis. My wife says that is why she doesn't want our daughter to go into computers - you have to keep learning and forget the crap that just doesn't matter anymore. Whatever. I think it is inescapable that you have to keep learning just to keep somebody from eating your lunch.

Image by hyperboreal via Flickr

Frankly, I am glad I didn't do well enough, overall, to attempt a post-graduate degree in math or computers, back in 1993. A lot of what passes in academia today is pretty weak sauce, in applied math and computer science. God bless the IntarWebs. I can just grab the info I need and go. One problem, the tempo has increased.

Optimize python functions by marking certain promises about its behavior : Python

promise: bytecode optimisation using staticness assertions.

http://pypi.python.org/pypi/promise

This is a module for applying some simple optimizations to function bytecode. By promising that a function doesn't do certain things at run-time, it's possible to apply optimizations that are not legal in the general case.

Reddit Comments: Optimize python functions by marking certain promises about its behavior : Python: "
I gave a talk on this at our local users group a few weeks ago, the slides are online if anyone's interested:

http://wiki.python.org/moin/MelbournePUG?action=AttachFile&do=get&target=promise.odp

"

The above presentation is really nice - great, simple example of the power of this technique.

I was thinking along these lines. Having code where we specify two "speeds":

(1) flexibility/expressiveness/global-mutability/side-effects-happen-globally-immediately are important (at cost to throughput and low-latency)

i.e. dispatch on pattern matching ASTs on global mutable list of patterns, global mutable generic functions, global mutable generic methods

Allow global mutable objects in general. All mutable state is handled like distributed-revision-control & write-on-change, with all communication going through a key-hole (enforcing low latency by throttling large data transfers) as asynchronous messaging as transactions (and building transactions).

Side effects are GO!  Allow global state to change, allow outside communication, all happening ASAP, might pre-calculate while waiting for reply, but wait to the bitter end for reply none-the-less.

(2) throughput and low-latency (performance) are important (at cost to flexibility/expressiveness/global-mutability) - no side effects (all "side-effect messages" are stored, to be returned as a group when function returns, maybe each "side-effect message" is paired with a continuation)

Image via Wikipedia

i.e. dispatch on low level bytecode (think: LLVM), preferred data structures are immutable and have the "shape" of directed acyclic graph (possibly a much more restricted form of directed acyclic graph, where each node has an immutable index, and parent indexes are always less than child indexes), the limited explicitly mutable state is local to OS-thread or green-thread.  No traditional asynchronous side-effects allowed.

And there are speeds in the middle, by being explicit about what you are relaxing and what you are constraining. Typically, you expect to pay a "compiling" cost to get down to the low level bytecode - again, by being explicit, if you are doing a lot of this "compiling", you can improve by being explicit about what you are relaxing and what you are constraining.

Low-latency (ability to best react to asynchronous signals) will always be preferred over throughput. If you want to put throughput over low-latency, you have to explicitly say so, with the knowledge that you have very little influence over that isolated code (isolated so able to make no compromise in throughput)

[Edit]

Hey, cool.  People are trying "Promise" out on code in the wild.  Here is creator Ryan Kelly explaining how to make use of the bytecode improvements:

http://panela.blog-city.com/the_promise_of_faster_python_1.htm#1

1. Ryan Kelly left...

2010.01.05 Tue 4:25 pm :: http://www.rfk.id.au/

Matt, thanks for taking the time to put this together. The optimizations applied by promise are certainly not in the same league as something like psyco - they have to be quite well targeted to have any measurable effect.
Some clarifications: promising a function pure() doesn't optimise that function at all, but it can speed up things that call that function by inlining its bytecode at the call site. To get this to work, you have to use constant() to promise that references to the pure function won't change. Example:

..@promise.pure()
..def calculate(a,b):
......return a + 2*b
..@promise.constant(("calculate",))
..def aggregate(pairs):
......return

In this scenario, the bytecode for "calculate" will be inlined directly into the "aggregate" function and will save the overhead of many function calls.
By far the biggest speedup that can currently be obtained using promise is inlining pure functions that get called in a loop.

python-patch

Image via Wikipedia

README - python-patch - Project Hosting on Google Code: "

This project started because windows platform lacks native tool to apply patches. There are plenty of tools on my PC to produce diffs - from scripts bundled with python to several version control systems, but none of them is able to apply these diffs back.

Usually patches are applied with a patch tool - a UNIX utility that continues to be UNIX only as a part of GNU tools. There is windows port of patch, but it's rather buggy, insecure to be run on a web server and not customizable without a C compiler. That's why this version was born. And I've always wanted to have a diff.py counterpart bundled with Python.

"