From: glen herrmannsfeldt on
e p chandler <epc8(a)> wrote:

> Understanding how the ISAM was used might be important for historical
> purposes, but in this particular application it is not needed, for two
> reasons. I won't show the relevant code.

Well, historically it was because computers didn't have so
much memory. Complicated systems that could find records on
disk without keeping everything in memory were a way around that.

> 1. The flat file extracted from the data base, which the OP is using is
> already sorted on the frequency part of the primary key. So one pass through
> the data file, excluding unwanted frequencies, works quite well and is
> certainly fast enough.

If it only needs to go through the file once, yes. If more than once,
and it runs on relatively modern machines, then read the whole
thing into memory and search in memory.

> 2. The ISAM key scheme is part of a complicated optimization which was
> designed to exclude records by latitude and longitude *without* doing an
> actual distance calculation. It basily calculated points due N, E, W and S
> of the center of the target circle, then used max and min lat. and long. to
> form a bounding rectangle. Stations outside this rectangle are rejected
> without calculating the distance.

> BUT this actually does not work! The earth is not flat! In fact the OP
> complained to me that the original program (with ISAM commented out)
> excluded too many stations when the radius was small, say 100 miles or so.

Hmmm, it shouldn't be that hard to get right. Also, the non-flat
approximation fails for larger radius, and should be very close
for small radius. I suspect another problem.

> Replacing the complicated key logic with a simple

> for all records in the input file
> if frequency is too low, next record
> if frequency is too high, end of run
> if distance is less than radius then print reports
> else next record

> works quite well.

Sounds good to me.

> Selecting within 100 miles of Detroit returned reasonable results.

-- glen