Concern

That he also was at class, is also so quiet, and went to eat at the same restaurant, makes me think we’re similar. And that he’s 20 or 30 years older than me and apparently also alone, it makes me think that this solitude is permanent.

It’s not so troubling — one gets used to it — but it’s hard to fully accept that this is it, that this is all to life.

I left work early today (not by much; I got there at 8 AM and left at 4 PM, so maybe that doesn’t quite count as early) and took 101 up to 84, then took 84 to 1, and that all the way home [context].

The real striking thing, other than how stunningly beautiful that drive can be, is the real feeling of how little perspective I have on things, even though I realize that it’s exactly that lack of perspective that’s the problem. Gaining a brief glimpse at a wider view — just from driving along the coast of California in a hazy sunset — made me feel how narrow my view is.

This has been causing me to nearly hurt people close to me, so changing this view is important.

The biggest comfort is that it’s out of my control, and it’s not so much my fault.

I was considering the idea of a kind of Drake equation for dating and romance, prompted by a recent episode of This American Life. You take the population of where you live, and start taking away percentages of people that won’t fit you romantically, and you’re finally left with a really shockingly small number of people you could have a serious relationship with.

• The population of Santa Cruz, CA, is about 58,000 as of 2008. [1]
• Of these, roughly 50% are women (which matches my tastes), leaving 29,000.
• Of these, 32.6% are between the ages of 25 and 34, using data from 2000, leaving 9,454 [2]. This part of the sieve happily gets rid of the UCSC undergrad population almost entirely, so we at least won’t have to do that cut below.
• 13% of people in Santa Cruz are married. This might be a low estimate, since women in this age group are the most likely to be married, and since that number indicates just the number who live with a spouse. This leaves 8,225. [ibid]
• Assume half of these people are in serious, committed relationships, and aren’t interested in a new relationship in the near future. 4,113.
• About 46% of people in Santa Cruz had “some college” in 2000. Assuming that this is a good indicator of someone intelligent enough that I could be interested in, this leaves 1,905 [3].
• Now, getting into something I’m pulling out of my ass, assume that I’d find one in ten of this remaining group “attractive,” and that their personality would match what I’m looking for in a long-term relationship. 190.
• Now assume that one in ten of those women would find me equally attractive (yes, this is a seriously, seriously, seriously optimistic estimate, I think; I have pretty strong evidence that I’m not attractive, but we’ll play along with our 0.1 estimate). That’s 19.

Nine. Teen.

So, 0.03% of all the people in Santa Cruz are even potential matches, or about 1 in 3,000. If I met one new person a week, every week — which really doesn’t happen, since I pretty much see the same people over and over — I’d have even odds (50/50) of meeting one of them in four years. I never even go on any dates, so it’s not even like I’m trying out anyone I’d be meeting.

Now, Santa Cruz is a relatively small town, and things get a little better if we go outside it. San Francisco has about 15 times the population of Santa Cruz, so if I moved there the potential pool would jump to 285, and maybe I could meet more new people every week. It’s still grim. And lonely.

Edited 2009-02-18 @20:05 to add: yeah, OK, who am I kidding? The reverse attraction rate would be more like 1 in 100 women who would find me attractive. If that. So in all of Santa Cruz, there is one, maybe two, women who I have any potential with.

I have a couple lazyweb questions, this time concerning some topics in computer graphics. For, uh, my own edification:

• Rasterizing a circle (a disc). Say we want to take a circle, represented by a point (x, y) and a radius r, and produce a grayscale bitmap of this circle. This circle has some real, idealized size, on the order of millimeters (though, some of them a lot smaller), and our synthetic camera will have a specific length per pixel that it’s capturing, approximately; call the length per pixel l. My solution was to consider each pixel a l by l square, located where the pixel would be, and then I first see if it intersects the circle at all (pretty easy to compute), and if it’s completely inside, set the pixel to full white. If it’s fully outside the circle, set the pixel to full black. Otherwise, compute the area of intersection between the rectangle and the circle (which, actually seems to be really computationally expensive), and divide that by the area of the pixel. Set the pixel to full white times the quotient, so the pixel will be some percent of white, depending on how much the pixel overlaps the circle.

  This is pretty slow, if we’re working with large circles compared to pixels; for small circles, around the size of a few pixels to a few dozen pixels, I just find the bounding box of the circle, expand that to encompass whole pixels, and do the same rasterization per pixel, but just in that box. Is there any way to generally speed this up? Is there a fast way to get the intersection of a circle and a square?

  (I want this to be camera-accurate, not an approximation, of which there are a lot of ways to do that. I’d like to be as camera-accurate as possible, but don’t like how slow it is now.)

• Computing projective transforms. Now, I also have a projective transform that I’m applying to images, and this is how I’m doing it:
  1. First, compute how large a new image we will need to contain the entire transformed image, which will just be the bounding box of the polygon P = { T(-w/2, -h/2), T(w/2, -h/2), T(w/2, h/2), T(-w/2, h/2) }, where T applies the transform. The width and height of this bounding box is the new image width and height, and the minimum corner of this bounding box will be an offset we’ll use to map pixels into our new image.
  2. Now, for each pixel in the source image, compute the projected pixel, which will be another polygon: P = { T(x, y), T(x+1, y), T(x+1, y+1), T(x, y+1) }. We’ll look at the bounding box of this polygon, expanded to encompass whole pixels, and then for each of these pixels, we compute its intersection with the projected pixel from the source image (this — computing the area of intersection of two polygons — turns out to be pretty hairy too). The value of the pixel in the new image is then this area of overlap times full white.
  3. Finally, we add in this value to the pixel in the new image — addition because that pixel in the new image might overlap multiple pixels in the source image, so we have to account for that; all pixels start out as black.

  This works surprisingly well, except for (1) it’s insanely slow, and (2) it seems like rotations along the X or Y axis are hugely exaggerated. For example, this is a square that should be rotated along X and Y by only 0.001 radians:

  

  It gets much worse as the angles increase, so any rotation at all borks the entire image. Rotation in Z looks perfect. My suspicion is that the issue is Z: we’re essentially right on the image plane when we begin, and edges that move “toward” us come way too close, and likewise edges that move “away” from us go way too far.

  Are there any optimizations here? One example would be computing the intersection of two quadrilaterals, or maybe better, a quadrilateral and a square, but I haven’t figured out how to do that yet. Also, any clue as to why a rotation in X or Y is so exaggerated?

• Transformations at raster time. One speedup (and improvement in image quality) was to do the transformation at raster time, so when I’m doing the simple rasterization I described above, of features like circles, can I apply the projective transform then?

  One thing I think might do this, but haven’t gotten working yet, is to first rasterize a feature in the shape plane, and then transform that rasterization to the image plane. All we need in this case is a sufficient resolution rasterized in the shape plane, and transforming that little rasterization (which might span a single pixel in the image plane) into a rasterization for the final image.

  Are there any other solutions for this? I assume you could do this by transforming the shape being rasterized by the transform, but the geometry here seems like it would get a whole lot more complicated; just measuring the overlap of a rectangle and a circle, or two polygons, is difficult enough already.