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.
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.
I was also curious why some of the code Thomas' uses doubles the WTN. That was unclear to me.
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?
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?).
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 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.
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
To unsubscribe from this list please go to
http://www.simplelists.com/confirm.php?u=RDHE7iRpfwqlHvVvWBIhpJZsbTiD5NnL