[fpc-pascal] best? safest? fastest?
Mark Morgan Lloyd
markMLl.fpc-pascal at telemetry.co.uk
Thu Aug 7 10:35:28 CEST 2014
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]
More information about the fpc-pascal
mailing list