[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