Google Code Search
Posted by Stephen Waits Thu, 05 Oct 2006 14:33:59 GMT
Wow this could be really useful in my work!
–Steve
Physics Sketch Program from MIT
Posted by Stephen Waits Thu, 05 Oct 2006 04:43:44 GMT
I’m basically in awe.. I want this.
tabs, spaces, and retarded programmers
Posted by Stephen Waits Mon, 03 Jul 2006 19:31:57 GMT
Wow, I ran across Elastic tabstops - the solution to the tabs-versus-spaces issue (via reddit) today. This is actually unbelievable to me.
It made me realize, again, that people are retarded. Like many of you, I experience this realization every day of my life.
The solution to this problem has always been simple. Use both tabs and spaces. Tabs control indentation, spaces control alignment. It’s easy, doesn’t slow your coding down a bit, and will render perfectly in every editor in the world.
I’ve been doing this for a decade+ myself, and have trained, or at least attempted to train many others in such elegance. For more detail, take a look at where I described this in detail several years ago in this Usenet post.
My new favorite Ruby Documentation Site
Posted by Stephen Waits Tue, 06 Jun 2006 15:35:57 GMT
Check out rubymanual.org. It’s fully searchable, nicely indexed, and allows for PHP.net style comments in the docs.
About John Koza
Posted by Stephen Waits Thu, 04 May 2006 03:51:59 GMT
Popsci.com is running a piece about John Koza, inventor of genetic programming.
Genetic programming is what got me interested in the entire realm of evolutionary algorithms. In 1997, my coworker and friend Francois loaned me a copy of this weird book, “Genetic Programming” (Koza). I still remember the excitement of reading through the Santa Fe Ant problem and GP solution! Thanks to Francois - that opened doors to a massive world for me; that of stochastic search and optimization. I love this stuff.
Since then I’ve played with all sorts of stuff, and applied it to real work many times. It’s really great, and I encourage any programmer nerd freak to check it out.
On API Design
Posted by Stephen Waits Sat, 29 Apr 2006 19:15:43 GMT
Here’s an interesting older article from the Trolltech guys about designing good (aka Qt style) C++ APIs.
Advanced Sudoku Solving Strategies
Posted by Stephen Waits Sun, 23 Apr 2006 03:50:35 GMT
A great compilation of advanced strategies for solving sudoku.
Understanding JOINs
Posted by Stephen Waits Wed, 29 Mar 2006 06:31:55 GMT
Understanding JOINs
Introduction
As my wife was taking a class on SQL, it occurred to me that some people may use JOINs without understanding how they work. When she began her class, I told her the toughest concept to grasp would be JOINs. Then one day she came home and said that they’d done JOINs that afternoon. They’d spent an hour or two out of a full five day course on one of the most conceptually difficult areas within all of SQL.
I believe understanding how something works makes it much easier to use. So, with that, to help her, and others, I decided to write this little tutorial. It’ll be written the way I came to understand joins.
The Cartesian Product
Forget about JOINs for now. We’re going to learn something else first.
It really all boils down to this. Understand what’s going on here, combined with your knowledge of SELECT statements and WHERE clauses, and you’ll have it. Don’t make it too difficult.
What is the Cartesian Product? It’s every possible combination of each of the rows in two or more tables. For example, let’s say we have two tables, T1, and T2.
T1 T2
== ==
a 1
b 2
c 3
Given that, the Cartesian Product of T1 and T2 is:
T1,T2
=====
a 1
a 2
a 3
b 1
b 2
b 3
c 1
c 2
c 3
Now go back to our definition of the Cartesian Product: every possible combination of the rows in two or more tables. See how the rows in T2 (1, 2, 3) are repeated once for each of the rows in T1 (a, b, c)? That’s the Cartesian Product.
Another example that may be more familiar to you:
Rank Suit
==== ====
A Spades
K Hearts
Q Diamonds
J Clubs
10
9
8
7
6
5
4
3
2
And the Cartesian Product?
Rank, Suit
==========
A Spades
A Hearts
A Diamonds
A Clubs
K Spades
K Hearts
K Diamonds
K Clubs
... (removed for brevity)
3 Spades
3 Hearts
3 Diamonds
3 Clubs
2 Spades
2 Hearts
2 Diamonds
... hint, hint, it's a full deck of 52 cards!
Notice the size of the Cartesian Product? 52. How is that? 13 Ranks, 4 Suits. 13 * 4 = 52. That’s right, it’s just the product of the number of rows in each of the tables involved. This isn’t that important.
A more complex example:
T1 T2 T3
== == ==
a 1 +
b 2 $
The Cartesian Product of more than two tables works just the same way as for two tables.
T1,T2,T3
========
a 1 +
a 1 $
a 2 +
a 2 $
b 1 +
b 1 $
b 2 +
b 2 $
Again, it’s just every possible combination of of each row in all of the tables involved. This time it was 8 rows because each of the three tables only had two rows in it. 2 * 2 * 2 = 8.
A Slightly More Useful Cartesian Product
Now let’s look at the Cartesian Product of two tables that might be a little more useful:
People id name
====== -- ----
0 Susan
1 Frank
Phones person_id phone
====== --------- -----
0 222-3456
1 777-8989
Here we’ve laid out two tables with a single relation. Clearly, we’re trying to represent two people stored in the People table, each with a phone number stored in the Phones table. Susan’s number is 222-3456 and Frank’s number is 777-8989.
And what happens when we mix these two tables up into a Cartesian Product?
people.id people.name phones.person_id phones.phone
--------- ----------- ---------------- ------------
0 Susan 0 222-3456
0 Susan 1 777-8989
1 Frank 0 222-3456
1 Frank 1 777-8989
What do we have here? Just another Cartesian Product. That’s each row from People combined with each row from Phones. Specifically, it’s the 1st row from People with the 1st row from Phones, the 1st row from People with the 2nd row from Phones, the 2nd row from People with the 1st row from Phones, and 2nd row from People with the 2nd row from Phones. Study this table until it makes sense to you!
Now do a JOIN
Here’s the thing. I told you not to think about JOINs, but we’ve actually been doing a JOIN this whole time. That’s right. The Cartesian Product is the result of JOINing two or more tables together. It’s actually a “join” in the most literal sense of the word. In fact, we got that combination (Cartesian Product) of People and Phones earlier by using this very SQL statement:
select * from people,phones;
Notice how we selected everything from two tables? Side note: this raw Cartesian Product is technically a “Cross Join”, but don’t worry about that for now. As we’ll see later that there are several types of joins.
Unfortunately, this JOIN is not that useful. It’s clear by looking at the People and Phones table that Susan’s phone number is 222-3456 and Frank’s phone number is 777-8989. But since the raw Cartesian Product (or a “Cross Join”) combines every row in one table with every other row in another table, we’re getting all kinds of bogus unrelated rows in our select.
How can we make it more useful? Let’s look at the data again. Try to pick out the related rows when you look at the data. In other words, which rows do we care about?
SELECT * FROM people,phones;
people.id people.name phones.person_id phones.phone
--------- ----------- ---------------- ------------
0 Susan 0 222-3456
0 Susan 1 777-8989
1 Frank 0 222-3456
1 Frank 1 777-8989
How will we tell the database server to keep the related rows and throw away the unrelated rows for us?
Well, just like most other SELECT statements, we need to add a WHERE clause to tell it exactly which rows we care about. Which rows do we care about in this case? Take a look at the result; we want the rows where “people.id” is the same as “phones.person_id”. In other words, just the rows that make sense. Let’s add that to our statement and run it again:
SELECT * FROM people,phones
WHERE people.id=phones.person_id;
people.id people.name phones.person_id phones.phone
--------- ----------- ---------------- ------------
0 Susan 0 222-3456
1 Frank 1 777-8989
Do you see what we did? We picked a few rows out of the (potentially huge) Cartesian Product. That’s all there is to it. Important Note: This is an INNER JOIN. It’s the alternate syntax and it’s the easiest to understand.
Now let’s make our INNER JOIN even more useful by only specifying the columns we care about in our SELECT statement:
SELECT people.name,phones.phone FROM people,phones
WHERE people.id=phones.person_id;
people.name phones.phone
----------- ------------
Susan 222-3456
Frank 777-8989
Now we’re getting somewhere! All we did this time was choose to only select the columns “people.name” and “phones.phone” instead of “*”.
Before we move on, we can do one more thing to this SELECT to clean it up a bit. In this case, we’ll use some aliases to shorten up our table names and make it a little easier to type
SELECT ppl.name,ph.phone
FROM people AS ppl,phones AS ph
WHERE ppl.id=ph.person_id;
In this case, we simply aliased “people” to “ppl” and “phones” to “ph”. This just makes it a little easier to read and edit.
Syntax
Most SQL programmers like to format their complex SELECT statements a little more nicely than all strung out on a single line. Our SELECT statement from above, when formatted nicely ends up looking like this:
SELECT ppl.name, ph.phone
FROM people AS ppl, phones AS ph
WHERE ppl.id=ph.person_id;
The INNER JOIN syntax we used here is implicit. See how the words INNER and JOIN never appear in this statement? That’s because this is an alternate syntax. In fact, it’s important to realize that the INNER JOIN above is exactly the same as the following INNER JOIN:
SELECT ppl.name, ph.phone
FROM people AS ppl
INNER JOIN
phones AS ph
ON ppl.id=ph.person_id;
This is the official syntax; however, the first syntax is widely accepted. I personally prefer the first, simpler syntax for INNER JOINs.
The most important thing to remember, though, is that these two are identical statements.
More JOINs
There’s actually a little more to JOINs than the basic INNER JOIN. However, it’s very important to remember that they’re all basically variations on this simple JOIN (aka Cartesian Product). In general, the JOIN builds up a huge wad of combined rows, and the WHERE trims it down to just the few rows you’re interested in.
This is the exact same process we followed earlier. Use the JOIN to build up a bunch of data, and use the WHERE to pull out only the useful data.
INNER - The intersection of two tables; a “default” JOIN.
LEFT OUTER - Every row in the “left” table, plus the right table, filling in empty right rows with NULLs as needed. This goes beyond the Cartesian Product because it will join in NULL rows that don’t really exist.
RIGHT OUTER - Like LEFT OUTER, but every row on the “right”, filling in NULLs on the “left”.
For more details on each JOIN type, please see the JOIN entry at Wikipedia.
Summary
JOINs are pretty simple. The actual JOIN itself builds up a large chunk of rows. Many of those rows won’t be useful at all. You use the WHERE clause to pull out only the rows that make sense and that you’re interested in.
The INNER JOIN, the most common, is always a subset of the Cartesian Product. The LEFT OUTER and RIGHT OUTER JOINs take that a little farther, but not much.
I hope I’ve helped you better understand JOINs.
My first Ruby Quiz!
Posted by Stephen Waits Fri, 24 Mar 2006 14:52:10 GMT
I’m so excited. Today’s my birthday, and I woke up to see my first Ruby Quiz get published!
sCrAmBlEd? HaCkZ!
Posted by Stephen Waits Fri, 24 Mar 2006 04:08:05 GMT
Wow.. This is some serious DSP-fu. Check it out: direct or on YouTube.
Via hack a day.
Black Person, Magic Wand, Emacs
Posted by Stephen Waits Thu, 23 Mar 2006 04:17:00 GMT
Three movies..
Another small Lisp
Posted by Stephen Waits Thu, 16 Mar 2006 17:03:26 GMT
In digging around Hedgehog, I found a mention of Pico Lisp. I don’t know if either meet my needs, but I’m definitely interested.
Wow. A full Lisp on top of Python.
Posted by Stephen Waits Wed, 15 Mar 2006 17:12:07 GMT
This is impressive. lython puts a Lisp syntax on top of Python.
Via Lemon Odor.
Collection of Fluid Dynamics Papers and Videos
Posted by Stephen Waits Sun, 05 Mar 2006 05:06:46 GMT
Check out Ron Fedkiw’s Page over at Stanford for a fantastic catalog of FD papers and videos. I seem to recall going to a talk of his at SIGGRAPH a few years ago. Bedazzling.
A small Lisp-like language
Posted by Stephen Waits Wed, 08 Feb 2006 16:01:25 GMT
Hedgehog looks interesting to me. Could be perfect for embedding into a video game. Though I’m not sure what debugging might involve.
Babbage Difference Engine in LEGO
Posted by Stephen Waits Wed, 08 Feb 2006 15:43:19 GMT
Andrew Carol built a LEGO Difference Engine. Very impressive.
Camping under a Rails Tent
Posted by Stephen Waits Fri, 03 Feb 2006 16:16:58 GMT
Ok, well, I’ve been sitting on this for awhile, so it’s kind of old news. But _why, the lucky stiff and a true mad genius, recently released Camping, a “microframework” conceptually similar to Rails.
To use it, without a database, you’ll find some good examples on the wiki. For use with a database you just need some familiarity with ActiveRecord, which is simple enough.
It looks like a great way to crank out a quick prototype, or even more. As usual, when _why speaks, people pay attention. Amazing guy…
Algorithms at WikiPedia
Posted by Stephen Waits Thu, 02 Feb 2006 15:55:59 GMT
WikiPedia has a very nice list of algorithms, with generally great descriptions of each. Looks like a very handy reference.
Web Dev Tools
Posted by Stephen Waits Tue, 24 Jan 2006 16:25:59 GMT
Discovered a few new web development tools:
Take a classic MIT CS course.. free!
Posted by Stephen Waits Sun, 22 Jan 2006 15:21:02 GMT
You can take the much talked about ”6.001 - Structure and Interpretation of Computer Programs” course, from MIT, for free! Just combine the more than twenty hours of lecture on video with the free html textbook and start studying. Be kind, use the Torrents!
Older posts: 1 2