What's weird is that your business model sounds exactly like Zipcar, which a quick Google indicates can operate legally in Texas. One possible difference is that they rent pretty-standard compact cars, which are certainly legal on Texas roads.

Yes, I've read it. Meaningless lives, sweating on the hedonic treadmill.

In my post, I was not prescribing make-work as a solution to America's economic problems. I made no prescriptions at all, because I do not know what should be done. My only point was that automation, which is often presented as a silver bullet, will create very-unequally distributed rewards.

I get what you're saying: You build a factory that employs five guys, and, sure, you may have only employed those five guys, but they will spend their money in the local community, which helps to spur the creation of secondary and tertiary jobs.

The problem is that, the more efficient the operation is, the less money actually trickles down to the community. We already see this, for instance, in data centers, which are the most automated facilities currently in operation: You buy a big building, fill it with computers, staff it with a dozen people, and generate significant wealth for the owners but contribute no more to the local economy than that handful of salaries.

Ultimately, I do not know what this means. Since money only has value in inequality (double everyone's account balances tonight, and, once everyone knows, each dollar will be worth half as much), we're obviously not making money. Precisely the role it serves still eludes me.

Now who's imagining a Brave New World? ;-)

Are we trying to make widgets, or jobs? And who is "we?"

Say someone with the capital to invest in automation builds a giant widget factory in Kentucky. They hire five guys to man the control room. How much good does it do that Kentucky town? The only people benefiting are those five guys, and the owner of the robots. From everyone else's perspective, that factory might as well be in China.

Now you can say, "there will now be robot maintenance jobs." Sure. There will be. But obviously factory owners will not be contributing as much to the local economy by paying robot-fixers as they would by paying workers -- because if they did have to pay as much, then the robots wouldn't be a sensible investment.

Automation can increase manufacturing output. It can make people with capital very wealthy. It can create a small number of highly-skilled jobs. It will not put a ton of unemployed people back to work.

The floating point numbers (say, IEEE whatever-whatever) are a subset of the rationals, sure.

Sure. I think my point wasn't as immediately practical as that. It was more philosophical. Some revered mathematicians was quoted as saying something to the effect of "progress in mathematics happens by calling things the same that are different." E.g., saying that a real number IS a Cauchy sequence of rationals. In the same way, you can say that some C++ object that stores a rational (and some state), and can advance to a next rational IS the sequence it generates, and IS a real number -- (if it is Cauchy, which, if the object is a black box, you cannot tell from the outside.) However, I'd neglected something obvious:

That same code is represented on the computer by a finite-length sequence of symbols from a finite alphabet, so it can also be interpreted as being a natural number. Since we have a bijection from the naturals to the sequence-generating programs, and we know that the set of reals is larger than the set of naturals, the map from sequence-generating programs to the reals must not be onto.

So I guess there are real numbers that it is impossible to write programs to converge to (even with arbitrary-precision rationals). Huh.

(All this must be extremely introductory computational theory... It's got to be...)

Since one way to define a real number is as an (equivalence class of) sequences of rationals, I suppose any object that (1) stores a rational number, and (2) can advance to a "next" rational number, could be called a real number. (That's so long as the sequences it generates are Cauchy.)

I guess I'm saying you just need to make all your evaluation really, really lazy, and you can work with arbitrary precision. :-)

Since when did Apple do R&D?

Apple does a little D. But the closest thing to a technological advance that has recently been associated with Apple would be Siri, which they bought from SRI, International. That work, in turn, was mostly funded by tax dollars.

In defense, it works like this:

Government labs do taxpayer-funded research.

If the research bears fruit, the lab licenses the technology, at a loss (the license fees are typically minimal), to a defense contractor.

The defense contractor sells the final product at a profit to the taxpayer.

In that industry, why do research when the government will do it for you?

The only industries I can think of that really do research are (1) pharmaceuticals, and (2) microelectronics. Because it pays off. Intel is ahead of AMD on the process roadmap, and look at the results. Pfizer discovers Viagra and they make a healthy profit. I don't know where else research is happening outside the military-academic complex.

My understanding is as follows:

There are basically two business models used by credible universities, and neither is based on undergraduate tuition.

At a Tier-1 research university, the real core of the business model is research grants. It works like this:

Professors write grant proposals. The grants are typically split about 50%/50% between the professor (who uses it to pay his grad students and buy equipment), and the university.

Grad students write conference and journal papers to keep the funding agencies happy, and to increase the professor's credibility and ability to compete for subsequent grants.

That's the business model. Teaching undergrads is just an afterthought, a necessary ritual to keep the appearance and prestige of a university.

At an elite private college, the real core is different; it's donations from rich alums. Here the idea is to maintain a good 'ol boys' network with links to finance and other lucrative professions, and to produce alumni who have fond memories of their institution. Then it relies on donations from those alums.

(Very-low-tier, for-profit colleges -- the kind you see ads for on the subway -- do base their business models on tuition, but I'm only talking about "real" universities.)

...which raises the question: What is the most efficient way to store points on the sphere for lookup? Computationally? And in terms of storage?

1.) You can store lat/long, and use the Haversine formula, as you suggested. This requires trig functions, and has O(n) complexity; you need to iterate through all the points. You also have varying resolution over the surface, which makes bounding and early-outs a bit harder.

2.) A great many other coordinate charts also exist, and it's hard to say why you should choose one over the other without looking in detail at how the distance calculations are performed, etc.

3.) By using multiple charts -- e.g., a cube projection -- you can avoid issues with singularities, at the cost of branching. The complexity of distance calculations depends on the projection, but, without looking too carefully, my bet is that, in terms just of raw speed, cubemap vs. lat/long is probably a wash.

4.) Why use a coordinate chart at all, when you can use an embedding? If you store points in 3d, proximity calculations (since the points are on the sphere) just become a dot product. Much faster! It also opens up the possibility of, e.g. (if you will be doing many lookups but few insertions), storing indexes sorted along the three axes (or more!) to speed bounding-box (or more generally, sweep-'n-prune) calculations. Bins, bounding volume hierarchies, and the other standard tricks of computational geometry come into play. On the other hand, you're wasting a lot of codewords on points that don't actually lie on the sphere.

5.) Is there a more efficient use of codewords? Perhaps a (nearly-)-constant-resolution encoding scheme? If you start with the idea that a node in an octtree can be thought of as an octal number, you can see how you can encode points as real numbers in the interval [0, 1] -- e.g. "octal: .017135270661201") Of course, this still wastes codewords on points not on the sphere, so let's consider a refinement of this idea: At each level of the octree, discard any cube that does not intersect the sphere, and use arithmetic encoding, with the base varying between 8 and 2 depending on the number of cubes that intersect the sphere. This now seems like a (memory)-efficient way to encode points on the sphere -- but it is surely not computationally efficient. On the plus side, this same idea works for any manifold embedded in any Euclidean space, so at least it generalizes.

6.) Since #5 is a mapping from [0,1] to the sphere, one wonders if there are space-filling curves on the sphere. Of course there are -- e.g., the Hilbert curve in 2d, composed with any inverse coordinate chart. Not that this helps much!

I think my favorite of these is #5, but, practically, #1 or #4 are probably better choices.

So how do the real GiS systems do it?

...but it looks like joining the swarm, logging IPs, and writing John Doe lawsuits is still just as must an option...

And doesn't widespread NAT hurt DHT a lot?

It's hard to screw up a LaTeX document because, beyond doing the basics like defining headings and writing paragraphs, it's hard to do anything in LaTeX. If there's a style file or an environment that does what you want, you're golden, but if you want to design your own, god help you.

What I wish is that LaTeX had a sane box model, and a language designed around the idea of defining constraints (soft and hard) that relate various boxes. It is close to being this, but the gap is frustrating. It also needs the ability to flow content between boxes.

Furthermore, math should be semantic. I should be able to evaluate a properly-written LaTeX math expression. I say this because, at present, the semantics and presentation of math are so tied together that you cannot, e.g., switch a document from one- to two- column format and expect your math to reflow accordingly. LaTeX cannot reflow your math, because LaTeX does not sufficiently understand the structure of the expressions you're writing. Really, in order to automatically typeset math, you need to understand its parse tree.

So that's what I want. A sane box model, with constraints and flow between boxes. And parseable math.

The HTML DOM seems a lot more consistently designed to me, but there are no good typesetting systems that take HTML+CSS as input, as far as I know (and MathML may be more semantic, but it is also much too verbose). HTML also currently lacks one very important thing that LaTeX has, which is the ability to define new tags/commands in terms of old ones. So although with some imagination HTML is almost a viable alternative to LaTeX, it is not quite.

I stick with LaTeX. But it leaves much to be desired.

I believe I've read of tribes in some locations (the Amazon?), in which it is common practice for men to immerse their testes in very hot water one (or more?) times a day as a contraceptive method. By itself, I imagine it's not tremendously effective, and I wonder what the failure rate is. Anybody want to dig through pubmed?

I don't think "communing with nature" is the point. I think cheap accommodation is. People like to be able to travel around the country in a moving "house." I once met, for instance, a guy who drove around the US for a year with his wife, with a camper hitched to the back of a small pickup, in order to see the country and, among other things, decide where they'd want eventually to settle down. I get the impression that many retirees, likewise, buy campers and go touring. It seems like a reasonable enough thing to do. I'd be curious to know what would be cheaper: that, or traveling in a fuel-efficient sedan and staying at Motel 8s.

Part of my problem has been that I've been using fink instead of Macports. Rookie mistake, I guess.

At the time I was writing my earlier post, I was compiling a program (IPE, a drawing tool) from source, which is available both in the Ubuntu repositories and as a Windows binary. I'm a little new to Mac OS, but I'd heard of fink, so I searched for IPE in its repositories, had no luck, and consequently compiled the source tarball instead, which took some fiddling. What I really should have done is check MacPorts as you suggested; it does have an IPE package, which, although not quite as up-to-date as the tarball, is new enough, and the same version as is available for Windows.

I have mixed feelings about this. The status quo for television is kind of a screwed up experience. I don't think Google TV was going to improve the situation -- it would have been just-another-set-top-box -- but it'd be nice if something were done to make TV-watching more seamless, especially for older people.

For instance, how many people can't work their own DVD player? "THIS needs to be ON, and set to THIS input, and then the TV needs to be a Channel X, but it isn't really Channel X, because THAT is set to 'DVD,' and..." I've had to explain things too many times to older family members, and still they forget. They're afraid they'll "break" the TV. I've even met people young enough that you'd think they'd know better who were unable to play DVDs in their own house ("Oh, my husband knows how that works."). In the year 2011, it's ridiculous. A setting gets changed and then the TV is "broken" for six months until I come visit.

Somebody needs to make a good, consistent, universal user interface for this stuff. Sometimes I wonder if the thing I should do is set up a super-simple media center PC for my parents, running something like Windows Media Center, that handles absolutely everything, so they don't need to understand three remotes and related input settings. You can imagine it being very simple. But I'm not so naive. Sadly, I think it'd end in tears.

It's also possible that the emergence of HDMI commands will fix things -- turning DVD players and the like into extensions of the television, operated by the same remote. But somehow I don't see the kind of strong interoperability needed to make this happen actually occurring either.