There are a number of fringe arguments that the sixteenth amendment, allowing an income tax, wasn't properly ratified.

If you're going to do a comparison like this you really need to count just the 23 special wards (14,485 per square kilometer). Tokyo the prefecture-equivalent "metropolis" includes a lot of areas which are essentially suburban sprawl west of Tokyo -- the Tama area. I don't think anyone would really consider, for example, Hachioji to be part of Tokyo the city, but it is a substantial fraction of Tokyo metropolis -- and if you're coming up with a number as low as 6,810 you're including it.

This is complicated by the fact there is no longer a government for Tokyo City, which is what used to be the 23 wards. The wards themselves are cities, somewhat comparable to a more independent and smaller form of NYC Boroughs. Conversely, Tokyo metropolis would be something like a separate State of New York City which includes both the Boroughs and Long Island and a couple of small islands in the Caribbean.

With that said, there's no ward of Tokyo which is as dense as Manhattan. mostly because there aren't a lot of tall buildings. The technology to build earthquake resistant skyscrapers is relatively new compared to a lot of the construction.

You don't need to itemize to deduct student loan interest -- and conversely, the amount of student loan interest you deduct doesn't affect whether you'd itemize or not.

This is a standard strategy, which I've seen referred to as "turboing", which is particularly effective when standard channels fail. The key point is that, really, you're not trying to speak to senior management, you're trying to speak to the PA of someone in senior management.

[citation needed]

A bug in your script is far more likely than a collision between two files in full 128 bit md5, barring a deliberate attack on md5 to create the collision.

No it isn't. It might not be in P, but it almost certainly is not NP hard. (Barring something like P=NP that would imply everything in P is NP hard)

This result was rather interesting for SODA because it wasn't an improvement in time complexity over the best known algorithm. There are asymptotically faster previously known algorithms for computing sparse FFTs, but they aren't actually faster than the current (extremely optimized) FFT implementations unless the output is extremely sparse.

This algorithm isn't quite as asymptotically fast but it has a much better constant factor, so it is more likely to be effective in practice on inputs which are not extremely large and/or outputs which are not extremely sparse.

Posting a story about how a presentation will be given at SODA... about a day after SODA ended.

I actually went to this talk, which was scheduled for the first 8:30 AM timeslot as part of their evil conspiracy to get me to wake up early. The approach seemed remarkably straightforward, but I haven't gotten around to actually reading the paper yet -- I was too busy sightseeing around Kyoto.