On 4/13/2020 6:10 AM, xxxxxx@gmail.com wrote:
>
>
> On Mon, Apr 13, 2020 at 3:56 AM Alex Goodwin <xxxxxx@multitel.com.au
> <mailto:xxxxxx@multitel.com.au>> wrote:
>
>
>     On 13/4/20 10:31 am, xxxxxx@gmail.com <mailto:xxxxxx@gmail.com> wrote:
>      >
>      >
>      >
>      >
>     I suspect you might be assuming a different scale of trade than the
>     travellermap data and the GT:FT trade route rules imply.  ISTR the core
>     Imperial sectors having more trade _transiting_ them (so at least 32 pc)
>     than originating and terminating wholly within each one.
>
>
> I was looking at the routes Thomas' code calculated. It seemed to be pairwise
> between planets. I am a bit unclear as to how far afield from one another the
> system bothers to calculate.

	It generates a list with every possible pair of the 55,000+ worlds in charted
space (1,947,112 routes), calculates the BTN based on direct line distance, then
processes routes for worlds where the BTN exceeds a defined threshold. The
default ends up being BTN 7.5.
>
> I was also curious why some of the code Thomas' uses doubles the WTN. That was
> unclear to me.

	It was a programming trick to keep the WTN/BTN calculations as integers. For
python this isn't really needed. The original code (written in C) used this as
an optimization, and I kept it when I originally ported the code to Python.
>
> And if this model says the core has more traffic spanning at least 32 parsecs,
> which means it is in transit at least 20 months (jump 3, jump every second week
> assumed) than what occurs internally, I find that not sensible. That would be
> like saying the majority traffic at Canadian Harbours on the West Coast is going
> between China and Western Europe. It's a bit hard to believe.
>
> As I said, most goods would not make sense to carry that far or that long, so
> what would make that sort of long distance trading distance make sense? Not many
> goods.
>
> Or am I totally missing some key aspect here?
>
	I think this ends up being a conflict between the underlying assumptions in the
GT:FT rules and the common sense you are applying. If you are using a gravity
trade model with a 1/r^2 and order of magnitude trade level, the sphere of
influence of a High population world is very impressive. When you get two high
population worlds, their spheres overlap at an even longer distance.

	Your critique of the trade system is one. Another is the communication time. If
it takes 20 months to make the trip one-way, the order for the goods needs to
take 20 months to get to the factory, then another 20 months to get back. And it
becomes hard to believe there isn't another world in all that distance that can
fufil that order in a shorter time. And shipping would be cheaper too.

> My point was a bilateral trade valuation between any two planets should have a
> scaling factor based on separation. That would effectively reduce contributions
> even from big players further out than 6-10 parsecs away to negligible values.
> That would vastly reduce the massive matrix you'd build if you did a full
> imperium and surrounds (15-20K x 15-20K entries?).
>

	There is a table for this (GT:FT p.15, the headers on the tables are reversed).
This is where you get the 1/r^2 fall off of the trade. I'm assuming you think
this should be a more linear fall off. I may sit down and try that to see what
the trade flows looks like.

> That's what I'm getting at, if you see where I'm coming from. In the real world,
> there is some transient trade but it would have to be for very valuable things
> and the sheer cost of long distance travel for an item means that the prices of
> the objects would be very high by the time it reached its destination and the
> equation for that may indicate a maximum practical trade radius.
>
> That's not done justice to simply by a BTN based on pop and starport.
>
>
>     and, I suspect, how the sheer number of
>     objects poorly interacts with how Python manages RAM.
>
>
> I like Python, from my brief exposures. Plan to teach it to my daughter once I
> learn it. BUT I wouldn't have picked it for fast or efficient.. :)
>
	I picked it because it was easy to write in. At work I needed to learn more
python for various projects. So I did this as a learning experience and it had
several existing libraries to solve the hard problems.

	I've had several people at work recommend using Go or Rust for internal
projects and this would be an interesting project to port as a learning
experience. But I've not done the search for the relevant libraries. Which means
if they don't exist for the chosen languages I'll need to re-implement them.

	As part of the process I dump out the internal data structures, including the
final routing data. If I have a way of sending you a 35MB file I could send you
the full data set. This would be the list of world pairs being considered, and
the pairs of worlds where the trade takes place. It would be interesting to see
what the statistics about the trade is actually like, not just the extreme cases.

>     I know of another
>     project, reposurgeon, that slammed into this wall last year (while
>     trying to convert the entire GCC source history to Git, approx 280,000
>     commits) and had to jump ship to Go to make it feasible, even on a
>     machine with a half-terabyte of RAM.
>
>
> Yes, if you are going to do this sort of thing and it isn't critical to hold
> everything in RAM (you can swap it out), you need to still be efficient and have
> good algorithms that don't waste time. (Or system calls that do the same)
>
>
>     The Zhdant-Glea route was me trying to make a point that run times are
>     disproportionately influenced by longer (ie, more number of jumps)
>     routes,
>
>
> I get that I think, the scaling seems non-linear.
>
>
>     and those two systems were easy to eyeball on travellermap.
>     This started out as a software engineering concern, by the way.
>     Assuming I've read the front page of traveller-pyroute correctly, a
>     route 2N jumps long takes _more than 4_ times as long to find, all else
>     equal, as a route N jumps long.
>
>
> Sounds about right, though close to 4 times would be what I expect.
>
>
>     My proposal to take route-finding bidirectional was to roughly halve
>     that exponent, so a 2N jump route takes between twice and 4 times as
>     long, ceteris fnordibus, as an N jump route.
>
> I followed that part.
>
>
>     If, after the algorithmic fix, things are still too slow, then yes, port
>     to a language without Python's apparently-crippling-for-this-case
>     shortfalls ("Pyroute's Excellent Adventure and Python's Bogus Journey",
>     anyone?).  On its own, a roughly 40x speedup from jumping from Python to
>     a compiled language like Go would not deliver the 1000x speedup wanted.
>
> No, sometimes the problem is the size of the data and the approach.
>
> I worked on a local PBX for a US manufacturer. They had a small one for 100-300
> users. The management interface for office staff was designed for 100, then
> stretched to 300. It worked, a bit slower, but it worked.
>
> The presentation had 4 list controls (grids) but you had to insert into each.
> And it sorted on insertion. So you parsed a directory file one entry at a time
> into a list, then you passed it up the software layers, then you examined each
> one and put it in 1 to 4 different lists which did insertion sorts.
>
> Then they handed it to me and said 'We want to use the same tools for the 10K
> user enterprise version'. That load that took a about 3 minutes with 300 users
> went to 3.5 hours. (Note 2 minutes of that was an security layer being setup so
> really from 1.5 minutes to about 3.5 hours roughly.
> The fixes were:
> 1) parse single entries and pass up
> 2) Use a data bound control that used one set of data to populate the various
> view grids (so one insertion)
> So we went from the average insertion into the original list to pass up being 5K
> sort operations and then 5K more to insert x up to 4 lists to 1 single 5K sort.
> And I think the underlying implementation in the databound grid was actually a
> hash table so it was faster than a single 5K sort.
>
> In the end: 10K users loaded in 4 minutes (2 of which were security setup). A
> bit better than 3.5 hours (210 minutes) - down to 2 minutes basically. That was
> about a 100 fold increase and I thought that was amazing.
>
> 1000x is a HARD thing to reach.
>
>
>     GT:FT assumes that freight's value density is between KCr10/dton and
>     KCr50/dton.
>
>
> 10 K to 50K... I have no basis to disagree at the moment.. ;)
>
>
>     Per the bottom of p 16 of GT:FT, there's a table explicitly reducing the
>     _volume_ (but not _value_) of long-haul trade.  For the cases I examine
>     below, that's a 10-fold reduction, so 100-500pc long-haul freight
>     averages out to a value density between Kcr100/dton and KCr500/dton.
>     *That would mean (off top of head and IIRC GT pricing), jump drive
>     gubbins, for example, would have sufficient value density to be worth
>     shipping up to 500 pc*.
>
>
> Um... maybe. Yet shipyards exist in most sectors and I'm assuming all the
> gubbins don't come from one source or even 5 of them. I have trouble imagining
> much trade at that level. Even 1/10th might be unreasonable.
>
> I'd have expected J-3 as about the max normal trade goes, because beyond that we
> get into expensive ships and costs, so every multiple of 3 parsecs I'd expect
> maybe a halving of trade to pull a figure out of thin air as a doubling of jump
> fuel costs. it might be maybe a 25% reduction. In any event, by the time you've
> covered 30 parsecs (a sector), even with a 25% reduction, you'd be seeing a
> reduction to about 6%. If it was halving, it would be 0.1% if my calculator was
> cooperating. So if we assume that, then we assume the cost of that shipping is
> likely at least 10 to 100x. 10 is a very generous number in my opinion. 100x
> might be closer.
>
> So I doubt anything short of priceless would be shipped more than a Sector.
>
> Now, note, to figure the actual amount of cost increase and commensurate trade
> reduction, you probably would have to look at ship costs (purchase, amortization
> period, wear and tear functions, maintenance, crewing over the time mentioned
> including promotions and replacements, food, fuel, updates and repairs,
> insurance, berthing fees while in transit, legal fees/port fees/etc) by the
> sorts of ships which would run given legs of the route and how fast. I suspect
> the costs would be ridiculous. The 10x number for reduction at 500 parsecs seems
> way too low but I don't have all the math at hand to back that up, but it feels
> that way.
>
>
>     To actually answer your question about the along-route-distances which
>     encompass half of all trade (by either volume or value, which will
>     differ thanks to the value density increase I mentioned above), I'd have
>     to modify pyroute to do so and re-run it.
>
>
> Sure. I can see that. I'm not suggesting I know what some of the numbers should
> be, but I think the numbers you tell me it spits out now are infeasible (though
> likely correct to the material you are drawing from).
>
>
>
>     Actually having a shufti, we have (per GT:FT and travmap):
>     Glea: GTL 12, Class A/V port, pop digit of 8, rich, garden and polity
>     capital. WTN (world trade number) works out to 5.5.
>
>     Zhdant: GTL 12, Class A/V port, pop digit of 7, agricultural, polity
>     capital.  WTN works out to 5.
>
>     For _freight_, that works out to a BTN (bilateral trade #) of 10 (sum of
>     WTN less 0.5 for different political allegiance) less a distance mod of
>     5 (GT:FT p 15, assuming my 330 pc eyeball), or a net BTN of 5, which on
>     its own is too small to support even a small route (needing BTN 8).
>
> That distance mod comes from a table but I'm not convinced it's accurate or
> reasonable.
>
>     For _passengers_, things work out to the base freight BTN, + 1 for each
>     polity capital, + 0.5 for Glea being a rich world.  Passenger BTN works
>     out to 7.5, which _just_ falls short of a long-haul passenger trade route.
>
>     Ok, now trying hi-pop subsector capitals near to those two:
>
>     Lyonskfomox (Centrax 2208): GTL 10, Class A/V port, pop digit of 10,
>     high pop.  WTN works out to 6.
>
>     Zdefrients (Zhdant 2025): GTL 11, Class A/V port, pop digit of 9, water
>     world, industrialised, hi pop.  WTN works out to to 5.5.
>
>     Freight WTN works out to 6 + 5.5 - 0.5 - 5 = 6 - again, not sufficient
>     to support a small route.
>
>     Passenger WTN works out to 6 + 0.5 for each subsector capital = 7.
>
>     These would fall afoul of the heuristic cutoff that Thomas (being a
>     smarter developer than I am) has programmed into pyroute, but I'm trying
>     to point out your assumptions may well be an order of magnitude, or an
>     order and a half of magnitude, low.
>
>     Adding the 3I's capital to the intercapital mix that I started with:
>
>     Capital: GTL 12, Class A/V port, pop digit of 10, polity capital.  WTN
>     works out to 6.5.
>
>     Eyeballing Travmap again, I estimate a 210 pc distance between Zhdant
>     and Capital, and a 120 pc distance between Glea and Capital.  Distance
>     mods become 4.5 and 4, respectively.
>
>     Freight BTN, Zhdant-Capital: sum of WTN ( 11.5 ) less 0.5 for different
>     polities less 4.5 for distance = 6.5
>
>     Freight BTN, Glea-Capital: sum of WTN (12) less 0.5 for different
>     polities less 4 for distance = 7.5.
>
>     Again, freight doesn't quite make the cut.  Looking at _passengers_:
>
>     Passenger BTN, Zhdant-Capital: freight BTN (6.5) + 1 for each polity
>     capital = 8.5.  On these figures, there is a small, long-haul, passenger
>     route (with scheduled service, even) between Zhdant and Capital,
>     carrying somewhere between 50-100 sophonts per week per direction.  This
>     does not take into account non-commercial traffic, either, such as
>     diplomatic couriers.
>
>     Passenger BTN, Glea-Capital: freight BTN (7.5) + 1 for each polity
>     capital + 0.5 for Glea being a rich world = 10.  Somewhere between 1,000
>     and 5,000 sophonts per week sod off from each end, en route to the other.
>
> That seems like a lot but may be reasonable. Mind you, the cost of that travel
> should be epic. The trip could well take 60-80 weeks. That's more than a year.
> You have to have supply of life support plus food plus presumably other things
> and a crew taking care of you unless you go as a frozen fish stick (which you
> may). But if you didn't go as a fish stick, that's a darn big bill. Your
> rationale would have to be pretty compelling to spend that.
>
>
>     For long-haul high-volume _intranational_ trade, Vland to Terra.
>
>     Vland:
>
>     Terra: GTL 12, Class A/V port, pop digit 10, hi pop, garden world.  WTN
>     of 6.5.
>
>     Vland: As above, except for not garden world and is sector capital.  WTN
>     of 6.5.
>
>     Eyeballing as 120 pc apart (a full-up calculation would probably swing
>     thru Capital, but am leaving that out for simplicity), we get a BTN 9
>     route for freight.  GCr 1-5 value per annum, and 10k -50k dton per annum.
>
>     Passenger BTN works out to 10 - so would have a similar volume as
>     Glea-Capital.
>
>
> The calculation is simple using pop and starport type, but one could easily
> argue the numeric rating of either. One could expect tech level differences,
> other differences may impact things. And for the longer term travel, in addition
> to the cost rising, the time rises and that time is an opportunity cost to the
> sorts of travellers who can afford long distance travel.
>
> To show this in real world terms: A friend who used to fly for USCG now flies
> for a private company who ferries CEOs and Paul McCartney, etc. Their rate is
> $3000 US/hr. Holy! But why? Because people who have a high net worth consider
> getting from NY or NJ airports to the Hamptons fast to be far cheaper at $3000
> round trip than driving in a limo or car. Their time is worth so much. So
> sending these folk on year long trips has a huge opportunity cost because it
> would be hard to do what they do while they travel (in terms of managing big
> enterprises). So that too would vastly reduce the long distance passengers.
> I think GT took some reasonable swings at making something that isn't all bad
> for a game. But if you look close, lots of the numbers were created for
> simplicity of calculation rather than the complexity of real factors.
>
> And I think the notion of 10x reduction in trade at 330 pc is way too low. :)
>
>
>     --
>
>     -----
>     The Traveller Mailing List
>     Archives at http://archives.simplelists.com/tml
>     Report problems to xxxxxx@simplelists.com
>     <mailto:xxxxxx@simplelists.com>
>     To unsubscribe from this list please go to
>     http://archives.simplelists.com
>
> -----
> The Traveller Mailing List
> Archives at http://archives.simplelists.com/tml
> Report problems to xxxxxx@simplelists.com
> To unsubscribe from this list please go to
> http://www.simplelists.com/confirm.php?u=QWmJ5KKpHa3MBU63jjs3knG6o9jLMkSu
>

--
         Thomas Jones-Low
Work:	xxxxxx@softstart.com
Home:   xxxxxx@gmail.com