[fpc-pascal] sorting and merging array of records

[waldo kitty]

On 1/10/2012 16:41, Sven Barth wrote:
> On 10.01.2012 22:02, waldo kitty wrote:
>> hummm... i may not need this specialization, then... i'm not comparing
>> the entire record but portions of the fields in the records... i've made
>> a few changes that should make this easier for me to do... let me show
>> an example of an input record...
>
> It's not about YOU comparing the entire record. The TFPGList uses that
> internally for it's own bookkeeping.

ahhh!

> The specialization is mostly for type safety and ease of use. As I show you
> below a simple pointer based TList works as well (if you follow some advices).
> In the end it should be easier to handle than an array ;)

i never did like pointers... hard to wrap my head around what was what and how 
to access certain things... but then again, i'm self-taught ;)

>> ISS (Zarya)
>> 1 25544U 98067A 11355.91136867 .00021672 00000-0 28116-3 0 6701
>> 2 25544 51.6441 296.4760 0024445 190.7247 276.2995 15.58432251750217
>>
>>
>> this breaks out like this...
>>
>> line columns example description
>> 0 1-24 ISS (Zarya) common name
>>
>> 1 1 1 element line number
>> 1 3-7 25545 catalog number
>> 1 8 U elset classification
>> 1 10-17 98067A international designator
>> 1 19-32 11355.91136867 epoch (UTC)
>> 1 34-43 .00021672 1st deriv of mean motion
>> 1 45-52 00000-0 2nd deriv of mean motion
>> 1 54-61 28116-3 B* drag term
>> 1 63 0 element set type
>> 1 65-68 670 element number
>> 1 69 1 checksum
>>
>> 2 1 2 element line number
>> 2 3-7 25545 catalog number
>> 2 9-16 51.6441 orbit inclination
>> 2 18-25 296.4760 rt ascension acend node
>> 2 27-33 0024445 eccentricity
>> 2 35-42 190.7247 arg of perigee (degrees)
>> 2 44-51 276.2995 mean anomaly (degrees)
>> 2 53-63 15.58432251 mean motion (revs/day)
>> 2 64-68 75021 rev number at epoch
>> 2 69 3 checksum
>>
>>
>> so i now have the following to define the record... since i only need
>> the catalog number to check for duplicates and the epoch to determine
>> which one to keep, i've added those two fields to the record and pull
>> them during the reading of the data (see Input_Satellite_List procedure
>> below)...
>
> Wouldn't it be easier for you to parse the complete two lines into a full blown
> record (just asking).

in the future, i will want to do this... however, this tool is a first step into 
mangling^H^H^H^H^H^Hssaging TLE data... the only purpose for this tool is to 
merge TLE files together into one master file with /ALL/ available satellite 
TLEs listed... the current old DOS program simply cannot do this due to memory 
constraints... as such, i only need know the catalog number and the epoch of the 
two... once the final sorted merged list is completed, it is all going to be 
written back to a plain 7bit ascii text file like it all originated from... this 
text file is then used for my other satellite and astronomy related applications ;)

> Then you don't need to parse them later on and can just do
> a "YourRecord.MeanAnomaly" (for example). Using a TStringList with the correct
> parameters can also remove the burden from you to seperate the values by hand.

at this time, this only needs be done with these two (sub)fields in the TLE 
entries... i'm only interested in these two but am storing everything to make it 
easier to later run thru the list or collection or array and write the three 
original lines to a master TLE text file...

>> Function IsSameReal(num1,num2 : double) : integer;
>>
>> begin
>> if (num1 < num2) then IsSameReal := -1
>> else
>> if (num1 = num2) then IsSameReal := 0
>> else
>> if (num1 > num2) then IsSameReal := 1;
>> end;
>
> You can shorten this by using the "CompareValue" function from unit "Math":
>
> function IsSameReal(num1,num2: Double): Integer;
> begin
> IsSameReal := CompareValue(num1, num2);
> end;

interesting! in fact, i don't really even need "IsSameReal" as i can simply use 
CompareValue directly with these two numbers?

> (though I would name that function CompareReal instead of IsSameReal ;) )

hahaha! true :)

>> something else i need to make sure of is that this will compile on my
>> OS/2 FPC 2.4.2 since that is the environment it will be under when it
>> goes production... unless, of course, there's a shiney new
>> 0s2260full.zip file for me to play with ;)
>>
> [...]
>>
>> as i wrote in another message, my windows' boxen update from SVN and
>> every time i've tried to update FPC and make whatever, it breaks and i'm
>> scared to break what i currently have working... i always have to blow
>> the directory away, then svn it all back down, and then do the make
>> thing... the ugly part is that i also have lazarus built with and using
>> this svn'd version of FPC so i definitely do not want to be breaking
>> that, either...
>>
>> a second reason is i don't do the svn thing on the OS/2 box and so have
>> to rely on an install package for that OS... the last time i did this, i
>> unzipped os2242full.zip to /fpc and went from there... i recall having
>> to manually configure a lot of stuff, though... include paths and the
>> like... i still don't have the help working properly in any environment
>> which greatly hampers things :/
>
> You'll need to ask Tomas Hajny then as he is the one who is most familiar with
> OS/2. But there seems to indeed be a os2260full.zip at SourceForge :) (So it
> might be worthwhile to investigate in an update, not only because of generics ;) )

it is something i'll have to play with... my windows' boxen should be all set 
for me to pick and choose which FPC version i use... i've not (yet) done similar 
for lazarus but that's for another place ;)

>>> 2. You can then use the TList which is based on pointers (and requires
>>> a bit
>>> manual housekeeping, but I can help you here as well if you want)
>>
>> TList? hummm... better? smaller? faster? easier to use? small memory
>> footprint? i'm game to try things as long as it works in the end ;)
>
> TList is basically an array wrapped in a class (though I would suggest TFPList
> as that is faster than TList (TList is based on TFPList)). Both can be found in
> unit Classes.

ok... this is another one of the several possible solutions i've been looking 
at... uncle google has been showing me a lot but i don't seem to find much that 
has a decent example that's close enough to my needs to whack it into submission...

> The following you need to know: T(FP)List works on pointers, thus you need to
> 1. declare a pointer type to your record type (e.g. Pthree_line_data =
> ^three_line_data)
> 2. allocate a Pthree_line_data variable if you want to add a new entry to the list

this looks vaguely similar to what i did in TP/BP with a TSortedCollection which 
built a sorted list of paths that messages took during their transit from the 
originating machine to my machine... those paths were all numeric and there was 
only one path per "record" so it was much easier to work with than what i'm 
flailing about with now...

[TRIM]
> 5. At the end of the list's lifetime you need to Dispose all items (or before
> you clear the list)
>
> E.g.
>
> for i := 0 to aList.Count - 1 do
> Dispose(Pthree_line_data(aList[i]));
> aList.Clear; // or aList.Free depending on the context
>
> I hope this helps you along, but feel free to ask more if you need help. :)

this is looking kinda familiar, really... the last time i did this, ie: the 
message path program mentioned above, i went on "vacation" to the mountains and 
spent the whole 7 days holed up with my pascal books, a computer, and a lot of 
sample data to work with... i did get the task accomplished but never really got 
to enjoy my "vacation in the mountains"... at least not more than simply getting 
away where there were no distractions...

"i'll be bach" :P