March 31, 2009
Pwnage: A Dish Best Served With Sheep and Wheat
I should add, in response to this post, that I soundly returned the favour. We'll have to settle this over a real match...
Mediaglyphic Evidence
Well, not quite - but here's the Montreal session video. The more I train, the longer the path ahead...
Who Says You Can't Swear in C++?
I currently have the pleasure of using Och's YASMET tool for maximum entropy model optimization. (Quick background primer: maximum entropy is really a simple concept - assume nothing about the data beyond what you're given. In slightly more technical terms, you want the most uniform distribution that fits the constraints.) Looking at the source code is akin to reading one too many JAPH snippets or sifting through Google's obfuscated JavaScript - it's an experience both awe-inspiring and twitch-inducing. Of course, it's GNU GPL'd, so anyone who can navigate the mess of two-letter variable names, magic numbers, and minimally-whitespaced text is free to modify it! (A re-indenting utility might help here - though a quick run against the K&R style expands it to 362 lines and reveals the terrifying depth of the conditional statements lurking within. Fair warning.)
Labels:
c++,
machine learning,
optimization,
SMT
March 30, 2009
Ow, My Hands
A few of us here in Ottawa (well, only three) hit up Montreal this last weekend to get a session in with some of the local traceurs. The Stade Olympique (less than fondly referred to as the "Big O", both for its shape and for the enormous debt incurred from its construction) is unsightly to most - and an absolute paradise for skateboarders, BMXers, and traceurs of all skill levels. The photos are up here.
In other news: if you haven't done so already, check out Pretty Lights. Who says you can't give away the music PWYC-style and make a good run of things? Oh, right - these thugs do.
March 26, 2009
And the total is...
76302. Of course, this is just the metadata - I wouldn't be so reckless as to hammer the CBC Radio 3 servers with 200 GB worth of download requests in a day! (Nor would my bandwidth permit me to suck down that much data in anything less than a couple of weeks. Oh well.) Next up: filter it down to a list of songs that I might actually want.
Labels:
bash,
music,
programming,
python
2017 Songs and Counting
Your guess as to what this does:
(Yes, I've left out some details - like what exactly those scripts do under the covers. I'll post about that when it's finished!)
Better make that 3156 songs. And counting.
#!/bin/bash
for i in `seq 0 25`; do
echo "http://radio3.cbc.ca/nmc/artists.aspx?offset=${i}"
done | tee -a artists.log |\
./url-dumper 1.0 |\
egrep -o "/bands/[^\"]*" | uniq |
while read line; do
b=`basename "$line"`
echo "/play/band/${b}"
done | uniq | tee -a bands.log | ./cbc3-get-music-info 1.0
(Yes, I've left out some details - like what exactly those scripts do under the covers. I'll post about that when it's finished!)
Better make that 3156 songs. And counting.
Labels:
bash,
crawling,
music,
programming,
python
March 24, 2009
Brothers From, er, The Same Mother
I'd like to congratulate my brother Neil on his acceptance into both Technical Illustration at Sheridan and Industrial Design at Humber. He's definitely one of the most talented artists I know, and I'm sure he'll make the most out of whichever program he chooses. So: congratulations!
Labels:
art,
congratulations,
family,
neil
March 23, 2009
Synergy: Now Useful
This synergy, that is. (Thanks to Jeff Verkoeyen for the app tip.) Installation is absolutely painless, especially with the APT repos on Ubuntu; in less than five minutes I was happily swerving my mouse around my newly augmented screen real estate.
Oh, and the installation pics are up. Enjoy!
Oh, and the installation pics are up. Enjoy!
RAIDers of the Nuked Fridge
After following these directions, my new Ubuntu 8.04 system with 1.5 TB RAID 5 is operational! Bonus: GRUB installed and ran without incident, suggesting that some effort had been put into fixing the mentioned bugs even before the Intrepid release. Moreover, I'm impressed to see that 1680x1050 resolution works out of the box. Ubuntu has come a long way since I started using it. Windows users take note: if you wrote off this increasingly popular distro, you owe it to yourself to give it another shot.
I'll post the partitioning and installation pics to my Computers album after work. Next up: development utilities, minor config tweaks, and a bit of A/V "testing" with some Cowboy Bebop.
I'll post the partitioning and installation pics to my Computers album after work. Next up: development utilities, minor config tweaks, and a bit of A/V "testing" with some Cowboy Bebop.
March 22, 2009
Computer Pics
Here they are. (Yes, it's a complete mess of cables. Yes, that's a microATX board in an ATX case. Yes, there's a giant opening in the front - I'm thinking about slapping in a fan above the optical drive. Yes, I put four hard drives in there - I'm going to put them in RAID 5, with a small RAID 1 partition on each to accomodate GRUB.)
Ordinateur!
Just finished building my first computer this morning, and am now using it (off Live CD!) to write this post. If you haven't tried putting together your own box before, I can assure you that it really is as straightforward as your friendly neighbourhood unwashed computer geek insists it is. There are several guides available online, though for most first-time builders the useful advice is easily summarized:
I'll post some photographic evidence to my Picasa albums shortly.
- Decide what the computer is for. Is it a workstation? A gaming rig? A webserver? Or are you just using it to surf and type? This will dictate what parts you need.
- Research your parts: get specs, find user reviews, make sure everything is compatible, pick up the necessary tools (read: precision screwdrivers.)
- Static = bad: don't build on carpet, and either ground yourself frequently or pick up an anti-static wrist strap - they're a lot cheaper than your parts (unless you snatched them from a scrap pile somewhere.)
- Cooling = good: not enough and your system dies a very pungent death, too much and...well, there is no such thing. The CPU fan/heatsink is absolutely necessary, and most people recommend having both intake and outtake fans for decent airflow.
I'll post some photographic evidence to my Picasa albums shortly.
March 21, 2009
In Search of Wireless
Last night, my search for free wireless in Ottawa brought me by bike across the Pont des Chaudières to the Elmdale House Tavern, an old standby out in Hintonburg that (somewhat anachronistically) is one of the only non-coffee-shop places where you can satisfy your connectivity urges without leeching off the poor suckers who still haven't set a network password. (Said suckers: I have no qualms with "borrowing" your bandwidth. It's dead easy to fix.) The joint has a deliciously no-frills ambience, and they serve up a decent pint of Beau's from nearby Vankleek Hill. Vive les microbrasseries!
March 20, 2009
Miscellaneous Perverse Tree Tricks
Unless you're Google, SQL-based relational databases are the de facto standard for storing web application data. Trouble is, MySQL et al. are great at storing relations - lists and sets, essentially - and are absolutely horrible for everything else, right?
Well, not quite. Tree structures are easily and efficiently stored using modified preorder traversal, which relies on nested intervals. This alone is enough to tackle many problems, like ACL-style permissions. I've seen the adjacency list method in use - if you like scalability, don't do it.
(For the truly masochistic: you can even pull off a decent directed acyclic graph implementation by computing the transitive closure.)
Well, not quite. Tree structures are easily and efficiently stored using modified preorder traversal, which relies on nested intervals. This alone is enough to tackle many problems, like ACL-style permissions. I've seen the adjacency list method in use - if you like scalability, don't do it.
(For the truly masochistic: you can even pull off a decent directed acyclic graph implementation by computing the transitive closure.)
Labels:
data structures,
databases,
programming
Public Service FUD
Just when you thought PSAs couldn't get any more ridiculous, they roll this out. If you can't make out the text above, here it is in all its glory:
Sodium kills 30 Canadians each day. Get the facts!
Sick of it? Sodium101.ca
Yay for Efficiency!
(Caveat: This post is somewhat C++-centric, but its main points translate to any language.)
I've been continuously optimizing my first project so that I can run ever-larger experiments. The project boils down to two main problems:
(If the preceding part made absolutely no sense, you might want to stop reading now.)
Lesson The, er, Zeroth. Take advantage of sparse data.
This should be obvious - if I can ignore the holes in my data rather than trudging through each one, it can only help efficiency.
Lesson The First. boost::tr1::unordered_map is not always preferable to map.
The latter beats the former hands-down in iteration, and the ordering property of a map permits more efficient linear sweeps for a variety of iteration-based algorithms - sparse-vector arithmetic, for example. In some cases, a sorted array might be better still.
Lesson The Second. Use the structure that fits the problem best.
The second problem above is a classic use case for the disjoint sets structure. Using anything else is a recipe for gross inefficiency - you can't beat the amortized inverse Ackermann cost for all operations.
Lesson The Third. You can make file output faster.
std::endl flushes the write buffer - unless you need the output immediately, use "\n" instead. Dump large structures in compact binary formats where possible. If you go this route, test that your read/write operations undo each other; this sanity check prevents most nasty surprises. If you're really in a pinch, use <cstdio> instead of <iostream>.
Lesson The Fourth. Consider using heuristics.
Do you really need an exact answer? Most of the time - especially when dealing with massive datasets - the answer is no. Look for small assumptions or shortcuts that work for your dataset. For instance, when performing the nearest-pair search, I only consider pairs that have non-zeros in the same coordinate at least once. This works well with the sparse representation, allowing me to search over a sub-quadratic number of pairs.
I've been continuously optimizing my first project so that I can run ever-larger experiments. The project boils down to two main problems:
- searching a list of high-dimensional sparse vectors for nearest-neighbour pairs; and
- keeping track of the sets generated by merging those pairs.
(If the preceding part made absolutely no sense, you might want to stop reading now.)
Lesson The, er, Zeroth. Take advantage of sparse data.
This should be obvious - if I can ignore the holes in my data rather than trudging through each one, it can only help efficiency.
Lesson The First. boost::tr1::unordered_map is not always preferable to map.
The latter beats the former hands-down in iteration, and the ordering property of a map permits more efficient linear sweeps for a variety of iteration-based algorithms - sparse-vector arithmetic, for example. In some cases, a sorted array might be better still.
Lesson The Second. Use the structure that fits the problem best.
The second problem above is a classic use case for the disjoint sets structure. Using anything else is a recipe for gross inefficiency - you can't beat the amortized inverse Ackermann cost for all operations.
Lesson The Third. You can make file output faster.
std::endl flushes the write buffer - unless you need the output immediately, use "\n" instead. Dump large structures in compact binary formats where possible. If you go this route, test that your read/write operations undo each other; this sanity check prevents most nasty surprises. If you're really in a pinch, use <cstdio> instead of <iostream>.
Lesson The Fourth. Consider using heuristics.
Do you really need an exact answer? Most of the time - especially when dealing with massive datasets - the answer is no. Look for small assumptions or shortcuts that work for your dataset. For instance, when performing the nearest-pair search, I only consider pairs that have non-zeros in the same coordinate at least once. This works well with the sparse representation, allowing me to search over a sub-quadratic number of pairs.
Labels:
c++,
machine learning,
NRC,
optimization,
programming
March 19, 2009
Ouch.
Twisted my ankle last night at OGC - I pulled off a monkey vault over one of their balance beams, only to have my right foot make a supremely graceful landing in the weak spot between two mats. Oops. Of course, one might contend that this sort of thing is bound to happen when you leap, vault, and climb over everything in sight for fun. I don't disagree - minor scrapes, bruises, and sprains are relatively commonplace in parkour. Major injuries, however, are not; these usually result from trying to show off or exceeding one's limits.
Parkour is NOT a rooftop sport. I repeat: it's NOT a rooftop sport.
Unfortunately, the more spectacular manoeuvres garner the most press, with the inevitable result that teenagers court serious injury and death jumping roof gaps because they think it's parkour. It's not. Every single experienced traceur that I've spoken with says the same thing. It reminds me of the rules from our CTF games on the University of Waterloo campus:
"Don't cheat! If you get hurt, you're cheating. If you're cheating, you're likely to get hurt."
So - don't cheat on your training! The people you see leaping between buildings - and making it, every time - have the confidence, power, and consistency that come from years of diligent practice.
(As an aside: I see that there is a good level for demand for starting an informal CTF league in Waterloo. I'm game - if nobody creates this group before I get back to campus, I'll do it myself. In the meantime, there's always Manhunt.)
Parkour is NOT a rooftop sport. I repeat: it's NOT a rooftop sport.
Unfortunately, the more spectacular manoeuvres garner the most press, with the inevitable result that teenagers court serious injury and death jumping roof gaps because they think it's parkour. It's not. Every single experienced traceur that I've spoken with says the same thing. It reminds me of the rules from our CTF games on the University of Waterloo campus:
"Don't cheat! If you get hurt, you're cheating. If you're cheating, you're likely to get hurt."
So - don't cheat on your training! The people you see leaping between buildings - and making it, every time - have the confidence, power, and consistency that come from years of diligent practice.
(As an aside: I see that there is a good level for demand for starting an informal CTF league in Waterloo. I'm game - if nobody creates this group before I get back to campus, I'll do it myself. In the meantime, there's always Manhunt.)
March 17, 2009
And One Reason To Love It
It's biking season! For the first time yesterday, I eschewed four wheels for two in my semi-weekly Westboro adventures, thereby bringing a whole new level of pain to this morning's post-gym-session awakening. For what it's worth, it's heartening to see at least a half-decent network of bike lanes.
Another good thing: every time I head to a gym session or outdoor meet, I see new faces. This bodes well for the parkour community here in Ottawa - personally, I'd like to see it survive forever, well past the next wave of graduations. As inspiration, I'll post a video: Stephane Vigroux on parkour. Memorable quote:
"None of the founders supported the previous 'World Freerun Championship'. None of us support this. Let's make it clear."
Wise words from one of parkour's most skilled practitioners, and a strong indicator that the community aspect of parkour may very well survive the hype brewing around it. Let's hope it can. No - let's make it that way, each and every last one of us.
March 16, 2009
Another Reason to Hate Ottawa
Where's the wifi? I might have to start frequenting coffee shops, especially now that I've got a bike up here.
Post-Emptive Strike
Yes, I blocked Wikipedia at work by overriding HOSTS. (Yes, NRC uses Windows for internal purposes, with the inevitable result that everyone installs Cygwin to avoid incurring undue mental trauma when working with our UNIX clusters.) I look forward to reaching unprecedented heights of productivity - starting, naturally, with spending 5 minutes blogging about it.
Update: In the same vein, I've decided to install the Email Addict feature from Gmail Labs. Any other thoughts on reducing distractions?
Update: In the same vein, I've decided to install the Email Addict feature from Gmail Labs. Any other thoughts on reducing distractions?
Labels:
productivity,
wikipedia,
work
Subscribe to:
Posts (Atom)




