Bringing Reason to Zip Code Radius Searches
ageemichael.com
ageemichael.com
Like more than zero?
> seemed extremely inefficient to do the calculations each time a user initiates a search
In general, the radius can vary for each query.
> coders are in love with writing elegant code instead of solving a problem
It seems that way because you're using the wrong tool for the job.
> python script to populate these columns
So, caching?
Yes, radius varies, but the OP's solution addresses that, so what's your point?
10/10 would be drenched in smugness again.
Michael complained that the query repeated the same computation each time, which is an odd thing to say, because that is its purpose. He expected memoization, which the library function did not offer, so he added that. But there's no reason to be dissatisfied with the code for not doing something its not supposed to do, or its developers for not adding an unnecessary feature.
His memoization does support varying radius, but only in a narrow subset of {5, 10, 20, 30, 40, 50}. Of course this is a huge performance optimization for the app, but in general it is impractical for provide memoization like this for an arbitrary radius.
Memorization=tabling which is exactly what I'm doing, but in a static sense.
Yes, its narrow, but the owners of the app don't want more than the 6 options given.
My point is that doing calculating the area of a circle around a give point on earth more than once is redundant. points on the earth don't move so if two points are within 1 mile of each other. They will always be so..
1. If you can eliminate the http req/query ratio... love to hear it.
2. A radius of 5 miles from a give point never varies...
3. What tool would you use?
4. Caching is not possible for this scenario...