vomjom

I've used Kall8 and RingCentral. While I'd generally recommend RingCentral (especially if you use a lot of minutes), it depends on your requirements.

Kall8's advantages over RingCentral:

- Recorded calls

- Can get the name of the caller through caller ID (RingCentral only offers the phone number)

RingCentral's advantages:

- Much, much cheaper. RingCentral Office gives you unlimited minutes (well, realistically it's about $20 for 5000 minutes because they have "fair usage limits", so you have to buy more lines if you use more)

- Allows for simultaneous dialing. This is critical if you want your 800 number to be answered immediately.

I've never used Kall8 or RingCentral for digital lines, by the way, so I'm not sure how well they work in that case.

It's extremely unlikely that he makes money. From the article, the rent is set by auction. So, it's a common value auction with incomplete information, the perfect setting for the Winner's Curse:

http://en.wikipedia.org/wiki/Winner%27s_curse

If you won the rent auction, then you definitely overbid.

Well, considering bandwidth is more important to google than storage, they could take the more obvious approach and just choose the appropriate method and codec for a person's web browser.

I own one and can't tolerate regular keyboards anymore.

The main disadvantage is that it's incredibly expensive (note that you can find it for as low as $260 if you search the web). I spilled water on my first one and had to buy a second one because I just can't get used to normal keyboards.

It also has some minor bugs:

1. If you hold down = and press certain keys (as programmers often might), you get put into different input modes which may confuse you.

2. Shift and Ctrl get stuck sometimes (not the keys, but the input).

3. The Esc key is tiny and inconvenient, especially since I'm a Vim user. The function keys are also tiny, which is terrible if you use them for gaming. Some games where you have to reach to the right side of the keyboard with your left hand are impractical to play.

If another company makes a keyboard with the same shape, but at a cheaper price, I'd buy it in an instant.

Frankly, CLRS goes over a lot of the basic knowledge you need to get through the book. I don't think a discrete math textbook will help you if your main goal is to get through CLRS; the math in that book isn't that dense. Like all things, it just takes practice. Spend a lot of time on sections that are hard to understand, and future sections will become a lot faster and easier.

Try the MIT algorithms video lectures: http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Compute...

My suspicion is that they're not counting the ethanol in their MPGe calculation. They claim to be using E85. In other words, the fuel mixture may contain about 85% ethanol. Their MPGe calculation probably only counts the gasoline in that mixture, the 15%.

Wow, you completely missed the point. Obviously, the author knows that height is already taxed.

The real point is that some members of society are more productive than others. Apparently, tall people are more productive than short people. What we want to make equal (from a utilitarian point of view) is income per unit effort. If you're from a disadvantaged background, but put as much effort as a person from an advantaged background, then you would make the same after-tax income.

He's demonstrating that this point of view is impractical in reality.

What? Long-Term Capital Management didn't use Black-Scholes. It hired Merton and Scholes, but used a completely different trading strategy.

They tried fixed income arbitrage with very high leverage. Black-Scholes ONLY applies to options.

The work that won the Nobel Prize had nothing to do with the downfall of Long Term Capital Management. Get your facts straight.

Variations of Black-Scholes are still used successfully in the trading world. The only difference is that no one thinks that returns follow a normal distribution anymore (but the Black-Scholes formula allows you to choose any probability distribution you want).

I'm a little late to the conversation, but I'll explain the reasoning. You don't want the hash and the bucket size to have a common divisor. A prime bucket size is the best way to ensure that.

For example, let's suppose you have a bucket size of 8 and a flawed hash function that produces multiples of 12 more often than other hashes (it can even be only slightly more common, but will still have an effect). Then the 0 and 4 spots will be used more often than any other.

Obviously, if you have a super awesome hash function, then it isn't a problem. Most of the time, making a hash function with good distributive properties is hard and makes the hash function slower.

There's also a simple universal hashing solution using prime bucket sizes:

http://en.wikipedia.org/wiki/Universal_hashing

http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Compute...

Rarely do most people who go to top schools pay full price. Only those from extremely wealthy families do.

All (yes, all) the top schools are need-blind, meaning they don't look at your financial situation when deciding whether to accept you. A few of them (Stanford, Harvard I think) are offering completely free tuition if your parents make less than $100k. For other situations, you typically would get around 75% of your tuition free even if your parents make over $100k a year.

The difference in first year average salary for an MIT grad vs. a state school grad is enough to make up that difference.

The main problem with AppEngine is vendor lock-in.

If you write your program to AppEngine, and Google decides one day to close down your site, you have no options.

For the bouba and kiki example, maybe the reason we associate shapes with sounds is because we already have words in our vocabulary that are associated with similar shapes?

For example, bouba is similar to bubble, which has no sharp edges. Kiki is similar to cut.

It'd be more interesting if you found similar associations in people who speak a completely different language with different origins.

I think you misunderstand the goals of sqlite, which is why you think it's a bug and the author does not.

Sqlite doesn't intend to include a very smart query planner simply because that would make it much larger and more complex. That means it'll do stupid things for some queries sometimes, but in return, you get a small library that's quick for common queries.

If you'd prefer a more accurate and less misleading introduction to money, you can try these Yale video lectures:

http://oyc.yale.edu/economics/financial-markets/

Specifically, these lectures:

http://oyc.yale.edu/economics/financial-markets/content/sess...

http://oyc.yale.edu/economics/financial-markets/content/sess...

Or Paul Krugman's article on the gold standard:

http://www.slate.com/id/1912/

The name of the project tells you what it does. If you don't understand from the name of the project, you'll certainly have no use for it.

The team that's been on top (BellKor, the same people who wrote the article) already combined with another strong team. The main problem is that a lot of teams already do the same stuff, so the benefit of combining isn't always that great.

Actually, it's often the opposite.

In particular, clang tries to use the least amount of memory possible for better caching effects, which is why it compiles much faster.

For the compiled program, it's also comparable in speed (and sometimes faster) in most benchmarks. That's pretty impressive given that GCC has been around much longer and has more developers.

"To check that they had not merely discovered that creative people are more likely to choose to live abroad, Dr Maddux and Dr Galinsky identified and measured personality traits, such as openness to new experiences, that are known to predict creativity."

Is this what passes for controls these days? It'd be much smarter to test people right before they're about to go abroad.

I was all prepared to rant about how wrong he was, but he convinced me.

I've had all kinds of problems with PostgreSQL because its planner would choose a poor query plan in certain situations. Specifically, we don't have a good way of estimating random page fetches for index scans on multi-column indexes.

I also had this weird problem suddenly occur. When one of my tables got to a certain size (about 40 million rows), Postgres started giving a completely different query plan that it thought was faster. The query execution time went from a few minutes to many hours. It took me all day to debug this problem because you simply don't expect the query plan to suddenly change like that.

To tell Postgres that you want the query to run in a different way, you must turn off certain things, like disabling sequential table scans or bitmap scans. You can't tell it specifically how you want it to execute. The reason is pretty simple: SQL is a declarative language. You declare want results you want, and the server figures out how it'll get you there.

I think the author is right. We need a simple language where we can tell the server exactly how we want to get the result. This is essential, because, like the author said, finding the optimal query plan is NP-hard. In practice, most programs run only a few queries. It'd be worth the time invested to try out a few query plans and find out which one is the best and stick with that over having the SQL server replan the query almost every time you submit it.

There could even be third party planners where it could take SQL input and return the resulting executable s-expr if you want to retain that functionality. This way, the development of planners remains separate from the development of the database.

If you want Python to "be smart enough to cast x automatically", then you want a weakly typed language. Weakly typed languages are difficult to reason about.

For example, should "3" == 3? Should 3 automatically be converted to "3" in that instance, or vice-versa?

Anyway, a better solution is: print "x: %s" % x