Well a you have a center your ZIP code you then calculat a circle around and and see what other codes lies within that distance. I would pick a book about mathematics and check the chapter about trigonometry.
Friedrich has given you a way to go .. here is another ...
In questions of this kind, you can increase the response time of your program considerably by doing some preprocessing. Since you get the input at the beginning of the program, you can dynamically allocate a 2D array of dimension nXn where n is the number of cities ...
An entry [n][m] would indicate the distance from n to m ... the matrix will be symmetrical about its diagonal ... so you can compress it a bit if n is large ...
At run time all you need to do is get n and m, perform a lookup and display the result
Since this sounds like a homework question, I am not providing you any code ... give it a shot ... if you get stuck, we are here to help
Thanks for all the answer so far: I just would like to add something:
1. I can find the distance between one ZIP to another (but still thanks to Ozo).
2. However, there is over 50K of ZIP Code for US, or even worse, 780K of Postal code for Canada.
So if I calculation from one ZIP to 50K of other ZIP, find out the distance between each of the pair, sort them, and get the one that lies within the range, it would be ... tough. Let's say if make a Local Match Maker program, and about 100 people do the search at the same time then my server would run extremely slow.
So, what I am looking for IS ACTUAL CLEVER CODES that attacks this problem from another angle but so far which will reduce search time. As for me, I am stuck.
ignoring the oblateness of the Earth, one degree of latitude is slightly more than 69 miles, so check in the range ±100/69, 200/69, 500/69 for latitude
±100/(69*cos(latitude)) for longitude
Sorry, fingers slipped and I posted before I finished.
Pseudo Code
Seek Zip (LATITUDE-10miles)
Do
Calculate Distance
MoveNext Zip
While Zip<LATITUDE+10
Taking this further, create extra indexed fields Latitude & Longitude rounded to the nearest 5 degrees (possibly). This effectively divides the country up into a grid system. Then you would only need to process the cities that fall in the surrounding squares.
0
vtb2000Author Commented:
Final comments:
From a mathematical view points (I do need time to integraded your comments in). both Ozo and MortimerCat would best help to solve the problem. So ... I love to split the points (90 for Ozo and 35 for MortimerCat). Could it happen by EE system?
Quote: "For a 50 mile radius, you could quickly eliminate anything furthir than 50/69 degrees away"
This reduced my query time for smaller radii, but I noticed an increase in time when the radius reached 1000+. Has anyone else experimented with this technique?
0
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Regards
Friedrich