waldo kitty wrote:
On 8/6/2014 4:08 AM, Mark Morgan Lloyd wrote:
waldo kitty wrote:
i suspect this is going to be like the long-standing joke of
cheap, fast, stable: choose two
over the years, i've seen two schools of code for dealing with
dates... years,
specifically... one school is string based and the other is math
based... both
have their faults and pluses...
eg: string based fault : prepend '19' to single digit year value
math based fault : 2003 - 1900 = 103 (3 is intended result)
I'd be inclined to start off using your method 1, i.e. text
manipulation until
the format is consistent.
i don't understand "until the format is consistent"... the format has
been in use since the 60s at least (AFAIK) ;)
What I mean is, while you're doing the initial processing to e.g. add
century digits to the date and possibly to check number of decimal
places etc.
FWIW: i have taken some time and reworked things to be math based while
still taking the required text format into account... i've seen a very
nice increase in processing speed and now need to just make sure that i
don't run into any of the basic and well known flaws that math
processing of date strings seem to have ;)
Flatten the original record and save it in a database, create a new
flat text
this appears that you are speaking of a sql database or similar? that
may be a later feature but for now, everything is/has to be done with
the raw TLE files...
Databases, even for plain-text records, can be incredibly useful.
i'm not sure what you mean by "flatten", either... currently i break
down the TLEs into their major records for storage in the in-memory
""database""... the processing i posted is done before that storage
takes place...
I was thinking that the first thing you could do was convert the two
lines into a single one for processing, but on reflection it would be
better to save the original with as little modification as possible-
possibly with any accession info you had (i.e. what body had provided
that particular TLE).
the goal of the program is to build the in-memory database from all
specified TLE files and then to write out new TLE files which may be
filtered on a selection property so that only certain matching TLE
records are saved...
The problem there being that once the program stops you've then got to
rebuild the next time. What I normally do when handling large bodies of
tabular info is to either have a series of database tables or a series
of text files, where ideally the text files are absolutely predictable
(all fields a known length and appropriately padded).
What I'm normally looking for is rate-of-change over multiple records
with irregular timestamps, which is an awkward job however it's done.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
