total hypocrite ([info]totalhypocrite) wrote,
@ 2003-12-15 10:49:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Uber personals
Uber personals has some new features. You can "rate" people - except unlike the happy-sappy bullshit world of Friendster, the person you rate has no option to decline your rating. However, they can make a rebuttal - and both the rating and rebuttal show up on your profile as well as the person you rated. COMEDY AND ADVENTURE ENSUES.

And there's other stuff too.

Tell your friends! (But only if they're hott.)

(9 comments) - (Post a new comment)


[info]endquote
2003-12-15 10:17 am UTC (link)
If I search for girls who want boys sorted by proximity to the ends of the earth, it says there are 229 results but doesn't show any. Sorted by other things works, though.

(Reply to this) (Thread)

[info]totalhypocrite
2003-12-15 11:21 am UTC (link)
Proximity search never worked... I meant to remove it from the templates entirely (it now is removed.)

The old proximity search did a braindead "subtract the zipcodes from each other" method. Ben did that and I was like, "does that work?"

"Yeah, I think so."

And then two minutes after thinking about it and reading about zip code distance calculation I called him an idiot.

I just never got around to doing the real proximity thing until now. (That's what the "within 5,10,25,50 miles thins is.) Doing it in other ways is pretty difficult.

(Reply to this) (Parent)(Thread)

[info]endquote
2003-12-15 11:37 am UTC (link)
I have a table that maps zip codes to lat/long coordinates, if you want. Converting that to distance shouldn't be hard.

(Reply to this) (Parent)(Thread)

[info]totalhypocrite
2003-12-15 11:47 am UTC (link)
I have that info too. The problem is not that it's hard to convert to distance, but that you don't really want to have to do all those mathematical operations for each search, and precalculating them isn't a good option either.

To do a distance ranking you'd have to add to your SQL (lat1-lat2)^2 + (lon1-lon2)^2. If you have 10,000 users, for every search query you're doing 20,000 squaring operations, 20,000 subtractions, and 10,000 additions. The point is, the time to do the query will always grow linearly with your users, which is very bad for scaling. (That's why we have databases and, so searches don't take linear time.)

The other option would be precalculating them, but then the storage would grow exponentially. (You'd need num-users x num-users storage at best if you only precalculated the zip codes users had, and at worst you would have number-of-zip-codes in the US x number-of-zip-codes entries. Which you could pare down to half since x to y is the same as y to x, but then you'd have indexing and searching complications.)

This is why the precalculating zip codes in 5,10,15,25, and 50 miles is actually a pretty good solution in terms of speed, storage space, and practicality. That is, you don't *really* care that somehow in the midwest is closer to you than someone on the east coast, you mostly just care if they're withing driving distance or not within driving distance.

But what the hell do I know, it's not like the site is ever going to make money.

(Reply to this) (Parent)(Thread)

[info]endquote
2003-12-15 01:04 pm UTC (link)
I guess I hadn't really thought it through that far. I need to do it for my next project, so I guess I'll have to consider the scalability issue. I'll have to think about precalculating it. So whenever someone saves a zip, you figure out what the distance between them and everyone else is, round to the nearest 5/10/15/etc, throw out anything over 50 miles, and save that? I guess that doesn't sound so bad.

Although I think mostly I'll be doing it for event location vs user location, and comparing one user location with the location of N future events should be a lot simpler than one user vs all of them, so it should be doable without figuring things out ahead of time.

(Reply to this) (Parent)(Thread)

[info]totalhypocrite
2003-12-15 03:03 pm UTC (link)
Actually, I just used these data files

http://www.cryptnet.net/fsp/zipdy/data_files/

For each zip code I just stored the zip codes within 5, 10, 15, 25 and 50 miles of it. Then it's basically a constant time operation to find the zip codes within the right distance, and I narrow my search for users to those who have one of those matching zip codes.

But anytime you can avoid math ops in your SQL statements you probably save yourself some time. Anyway, you can always just do it a braindead way and optimize later if the queries are what drag you down. Premature optimization is bad - but it helps to think about that sort of stuff a little.

(Reply to this) (Parent)(Thread)

[info]endquote
2003-12-15 03:20 pm UTC (link)
Wow, kickass. I'm totally going to use that.

(Reply to this) (Parent)

[info]herbaliser
2003-12-15 11:10 am UTC (link)
Oh that's brilliant.

(Reply to this) (Thread)

[info]totalhypocrite
2003-12-15 11:24 am UTC (link)
Finally my brilliance is recognized! Thanks.

(Reply to this) (Parent)

(9 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…