search

yakra / tmtools

Tools to aid in development of the TravelMapping project
0 stars 0 forks source link

canvas: toward sorting by tier #58

Closed yakra closed 6 years ago

yakra commented 6 years ago

Thinking things out...

I could probably have saved a good bit of bloat, complication, complexity and overthinking by scrapping custom system CSVs. But I choose to keep them...

What do I do about InclSys?

env::set

SysDeq is written:

Ergo, InclSys is populated before systems are read in from CSV

yakra commented 6 years ago

Sorting & pointers

For list::sort to actually work, I have to be working with actual objects, not pointers. Convert vector<highway> HwyVec to list\<highway> HwyList. (Using a vector adds ~50% to total run time (probably all the copying and resizing) and uses considerably more RAM. A list is the wiser choice here.)* This will require a rework of BuildRte. Maybe even fold into highway ctor. (Done.) Gisplunge will be affected. (incl. mutex & HwyList.pop_front(), inspired by siteupdate.py) This may also somewhat affect what's described below...

badc5435071831a4e501f93e6e428a8e36756a96 highway.cpp 0f1556eb52a7b7c8b3928ed46af1f3af17f90c9d canvas.cpp 3a070096c2d6ac07b42cad04ebd3e805f57ae773 gisplunge.cpp

yakra commented 6 years ago

Sorting:

Highways must know how systems compare Custom CSVs don't have a single system-wide tier ~set a bool marking a system as CustomSys~ // or better yet just use System.empty()

// ChoppedRtesCSV receives a highway* from the new redesigned InclSys vector
// Here's what it passes on to BuildRte
tmsystem* tmsystem::SysPtr(std::deque<tmsystem> &SysDeq, std::string &SysCode)
{   if (System.empty()) // IE, custom system CSV
      for (unsigned int i = 0; i < SysDeq.size(); i++)
        if (SysDeq[i].System == SysCode)
          return &SysDeq[i];
        // unrecognized codes fall thru...
    return this;
}

Custom system should be Tier = 255, color = "default"; the rest shouldn't matter (new ctor, to receive new filename?) tmsystem class needs (public?) filename Add default to colors.ini

// ChoppedRtesCSV

Right now, only gets called directly from main() Boundaries will need tmsystem pointers. Set up objects (which ctor to use?)... and push (emplace?) back to the new redesigned InclSys vector. See lines 263 - 270 where they're already dealt with (for colors) in env::set

// InclSys

Change to a vector (deque?) of tmsystem (objects? pointers?) // Not quite that simple! Read on... InclSys is populated before systems are read in from CSV. ReadSysCSV must happen at the end of env::set, as it needs... • InclSys.empty() (user-specified systems/inputs) to determine whether to add every system to... • InclSys (vector of objects to process) Ergo, system object cannot exist when setting up vector of systems to include. The solution: Split InclSys into two vectors: • InclSysName to store system codes (only; not custom CSVs) slated for inclusion per user • InclSysObj to store system objects to be fed to ChoppedRtesCSV ReadSysCSV will search InclSysName, and upon finding a match, push to InclSysObj. • /TODO:/ Look out for wacky hijinks where a vector is expected to be empty & isn't or vice versa, due to splitting in two

// tmsystem

Lose second ctor; replace with new one for custom system CSVs

// on the chopping block:

GetColors all colors should be gotten via system pointer now #60 GraySystems info to be stored in tmsystem object: color = "default" #60 IsGray info to be stored in tmsystem object: color = "default" #60 BtmTier just use 255, and avoid the need to reset Tiers after systems.csv is read and BtmTier calculated, track how many systems are custom, etc... #59

Colors:

This pretty much gets sorted in the process of the above, thank God!

yakra commented 6 years ago

I could probably have saved a good bit of bloat, complication, complexity and overthinking by scrapping custom system CSVs. But I choose to keep them...

I'm going back & forth on the idea that this may be simpler, but not significantly so. Without custom system CSVs, InclSysName would still have to be populated (by user input) before InclSysObj (by scanning for system codes in InclSysName).

Let's say I wanted to eliminate adding a tmsystem pointer to the highway class altogether... Canonical systems (IE, listed in systems.csv) could be sorted before adding their contents, in order, to HwyVec. But this would require creating a list anyway, to sort() it.

Adding in custom system CSV support seems a trivial step beyond here.

Idea: Detect whether custom CSVs were used. If so, sort highway list. If not, sort system list for better speed.

yakra commented 6 years ago

Adding in custom system CSV support seems a trivial step beyond here.

Heh. Nope. Splitting InclSys into InclSysCode & InclSysObj and setting up tmsystem objects was the easy part. Getting a system pointer into the highway ctor was more of a PitA than anticipated, and involved passing a function pointer, the tmsystem object itself, and the full system object deque. Bleah. But I DID IT, by gum!

Idea: Detect whether custom CSVs were used. If so, sort highway list. If not, sort system list for better speed.

No need to bother with this. Sorting the "slow" way already takes a barely perceptible time. ~8.5 s without boundaries, ~8.8-8.9 with. With the variations introduced by whatever disk access is doing at the moment, it can sometimes take longer to process without sorting than with.

~Next up~ Done, #60: