[fpc-pascal] best? safest? fastest?

[waldo kitty]

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) ;)

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...

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...

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...

   eg: take 100 TLE files and build one new TLE file containing only geosynch 
objects

> record starting with a database reference and then comprising slightly-massaged
> text. Run consistency checks on the new records until everything looks good
> (e.g. no non-numeric garbage resulting from a failed EBCDIC or GOST conversion),
> and only then parse it into numeric fields.

yeah, we don't have to worry about EBCDIC or similar because all that's done 
when those tools generate the TLE files they output... FORTRAN was used 
originally but these days, there's numerous languages used... the format is 
plain old 7bit ASCII characters of 0-9... if there's a 0th line with the 
object's ""name"" in it, it is only (IME) A-Z0-9... for my purposes, lowercase 
letters are no problem, though ;)

> Out of curiosity, I presume that times are GMT/UTC but does a day start at
> midnight or noon (civil and astronomers' convention respectively)?

i'm not sure on this either... i just know that my calculations return the same 
results as all the other programs and web sites i've validated against... i'm 
pretty sure that UTC is the base and i assume that the day starts at midnight... 
again, this because my calculations return the same results and projections as 
other programs and web sites i've validated against...

more information on the TLE format is available in numerous places on the web... 
one well known one is

   http://celestrak.com/columns/v04n03/

> Do the coordinates have to take into account changed ephemeris changes as the
> equinox precesses?

i presume so but am not sure... each TLE record stands on its own and can be 
used to create tracking forward and backward in time for X period of time... as 
time progresses from the epoch, the certainty of the calculations falls off for 
numerous reasons... solar flux, perturbations, atmospheric drag, boosting the 
orbit, etc...

-- 
  NOTE: No off-list assistance is given without prior approval.
        Please *keep mailing list traffic on the list* unless
        private contact is specifically requested and granted.