On 13/4/20 10:31 am, xxxxxx@gmail.com wrote:
>
>
> Having said that, to the trade maps:
>
> There was some mention of 330 parsec trade routes. I submit that there
> is no good or commodity (exception perhaps Ancient artifacts or a Star
> Trigger) that could justify that sort of trade distance. (I'm
> realizing you don't mean that necessarily, but I want to put that out
> there).
>
> In fact, a lot of potential trade off-planet may be *not profitable*
> on many worlds which would mean what does go has to be high value and
> not too huge. Most planets won't be able to afford to bring in vastly
> overpriced basic resources or simple goods.
>
> I would be skeptical if much trade went further than J-6. Most might
> never be economical beyond J1-J3 (of the list that is economical at all).
>
> The diminishing % of trade and its aggregate value as a function of
> distance must have a sharp drop off. That would mean you could likely
> ignore a lot of other systems above J6 or maybe even J3.
>
> Sure, that won't cover 'how far away am I likely to find a shipyard'
> because you might be able to order a new ship from across the sector
> so you don't need many shipyards to crank them out. But that's a rare
> and small % of a total economy (that and other trade that does make
> sense over 10, 20 or 30 parsecs. MOST trade would fall within 3
> parsecs in many cases.
>
> Does that not reduce the scope of calculation?
>
> I don't have my GT handy so I could be off in left field. It seems
> like 24 hours of compute time seems... overdone. I think there must be
> a lot of very minimal contributions being calculated that could be
> wiped out and not too much change the overall value of the result. I'm
> thinking an 80/20 sort of scenario here.
>
> Or am I really missing something?
>
> You could write it in something like Java where you could setup worker
> threads, but you don't want to tie up an internet server with other
> people's work. I agree that a lot of the compute power for doing big
> spaces should come from a user's computer. That's a good argument for
> either a stand alone tool - JS may not be the best tool - maybe
> someone has to run a tool in something else (C/Java/Ruby/I dunno) on
> the map data, get an output file and if they want that mapped, submit
> that map to the map tool with the sector data.
>
> I'd try to separate the map presentation (like Traveller Map) and
> generation of data so that you have a tool chain and you can rehome
> various parts of the tool chain for performance reasons or so you
> could sub in/out different variations of parts of tool chain.
>
> Of course, nobody is paying us for this stuff... maybe we need a
> Patreon or Kickstarter .... lol.
>
> Tom B
>
>
>
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.

The Python running time is partly, as Thomas Jones-Low has said, Python
essentially can't run multi-threaded (which is a fairly standard way to
speed up these sort of tasks), and, I suspect, how the sheer number of
objects poorly interacts with how Python manages RAM.  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.

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

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.

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.

GT:FT assumes that freight's value density is between KCr10/dton and
KCr50/dton.

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

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.

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

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.

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.

--