Wednesday, October 11, 2017

Distances between Markets

So, what have I been doing?

Very boring stuff.  I finished the rebuild for the sources table, the table that describes the origins of all goods and services in my known world; I did it mainly because I was looking down the barrel of adding Great Britain and Ireland into the system and that looked like a tremendous headache.  The rebuild eliminated the need for a 14 meg excel file, drastically reducing the size of the problem ~ so well worth the effort.

Once finished, I was free to add more data.  I finished my Burma map back in October 2015; that had never been added to file.  I finished Senegal and Mauritania back in June 2016; that, along with Cape Verde, had never been added.  I finished Britain in January this year; I've already talked about having to add that.  And I finished Iceland this past July (and the map of that has since been reworked).

Altogether, these places had 169 markets.  In the past year, bit by bit, I've worked out the sea distances, worked out the land distances and added roads to the maps.  The last week I've spent adding the markets to the distance calculation program, which basically means putting in the distance and then linking it to a cell, that is in turn linked to another cell and another and so on, round and round the world.  I've talked about this before.  Just for the hell of it, however, I'll put up a screenshot of a small part of the table:


All the numbers shown indicate the number of "days" of merchanting travel.  Column A shows the markets, labeled by kingdom, province and market city.  Column B is the minimum number of the horizontal list two lines below and stretching out to the right.  For example, the Folkestone number, B377, describes the smallest number among those of C379 through O379 ~ with a +1 added as a cost for importing it into the hex.

Don't bother looking to compare the numbers ~ they won't add up.  That's because the file is in mid-calculation.  For it to work properly, one city must be given a fixed number, which all the other cities then calculate against.  The template table, however, gives the cities no fixed number; so every time they are calculated, the numbers tend to drag one calculation behind all the other circular calculations in the document. This means the minimum number calculation is one step behind the number calculations for the horizontal lines shown.  And if I keep pressing the manual calculation F9, the "minimum" numbers will just increase to infinity.

At the point where I saved this image, the numbers are all very high and incorrect because of this.

The address line shows the distance between Portsmouth and Southampton: =0.8+$B$356.  Portsmouth and Southampton are two hexes apart, and sea travel costs 0.4 "day" per hex.  What does that number mean?  It means that if the goods originating in Portsmouth were divided by 1, those goods in Southampton would be divided by 1.8, for determining their availability.

Adding these boxes is niggling work and none of it can be errored.  One error blows the whole calculation.  It really sucks if I get a value error somewhere ~ that value error will just proliferate, no matter what I do; the only thing to do is to close the document and reopen, losing all the work.

Thus, I add a city and save; add a city and save; add a city and save.  And each city added means four or six or thirteen calculations, or more.  At the end of my work this week, Copenhagen ended with 57 direct connections, more than any other city on the list.

I have a system which says that every market is not directly connected to every other market.  Large cities with high market numbers reach further than small cities; a place like Ramsgate reaches only a few other places.  Too, if the route between market A and market B passes through market C, then I record A-C and B-C but not A-B.  That reduces a lot of the possible combinations ~ and it feels right that market C moderately controls the trade between A and B.  The only real effect is that A and B are considered one extra "day" apart.

Well, I have this finished.  All told, I have 1,235 markets now, all interconnected.  The next thing is to add the goods and services from the new market cities to the rebuilt table I finished in late September.  I still have to adjust that new, rebuilt table layout to the old prices table layout, but that's a few hours work when I have the time for it.  Thankfully, I have this finicky distance-work table updated.  Nice to have it behind me.

I'll add it to Google drive for the Patrons - if you want to play with it, add a 1 to the highlighted B column of any given market and then keep pressing the manual calculation until the numbers stop changing.  The final numbers will give the accurate number of days between the market you chose and all the other markets.

It is easy to build a table like this for your own system.  I started with just 30 markets.  Those were simple days.

2 comments:

G. B. Veras said...

It just reminded me of the not-so-good ol' days of graph teory in college.
The only thing that comes to my mind is... Should be an easier way to your work. Heheh

Alexis Smolensk said...

Thanks, G.B. People keep telling me this.

However, you know that I am mostly describing simple data entry. Someone could probably build some sort of access program that would enable me to quickly add a new trade city: but the trade cities would then have to be physically added to the new program anyway. This way, the details and calculations aren't hidden. I know precisely where they all are and the table looks like an elegant construction that I can comprehend at a single glance. A program that was more user friendly would also isolate me from the direct content ... and when something went wrong, it would be hard (or impossible) for me to fix it.