home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1993 #2 / Image.iso / comm / twft099b.zip / MAPPING.TXT < prev    next >
Text File  |  1993-06-07  |  15KB  |  308 lines

  1. Area Tradewar, Msg#396, May-30-93 14:27:18
  2.    From: Woody Weaver                         
  3.      To: Albin Gersich                        
  4. Subject: mapping the universe from sector 1
  5.  
  6. The new twassist feature has piqued my mathematical curiousity.  For those
  7. who just want TW tips, space bar now.  For developers or those who might be
  8. interested in the algorithms of mapping the universe, keep going.
  9.  
  10. The problem, of course, is to generate the directed graph that is a trade
  11. wars universe.  Currently, the number of nodes in the graph is 1000, the
  12. graph is sparse, with at most six outgoing edges and average between two and
  13. three outgoing edges, and is mostly strongly connected (i.e. a path between
  14. any two nodes in either direction).  What we have going for us is an oracle
  15. that will display the shortest path between two nodes.  The time it takes to
  16. get a response from the oracle is a function of the actual distance, but
  17. appears to be more than a tenth but less than a second if the path actually
  18. exists.
  19.  
  20. Let's talk undirected graphs, then modify things later.  (In particular, for
  21. practical results, assuming all edges are two-way is probably useful; it
  22. doesn't solve the problem of finding the star dock, as Joel's findsga does,
  23. but for general trading/combat issues its a good first approximation.)
  24.  
  25. The level diagram of a graph rooted at r is an ordering of the nodes of the
  26. graph by distance from r; i.e. r, then all its neighbors, then all nodes at
  27. distance 2 from r, then all nodes at distance three, etc.  An edge (u,v) is
  28. an external i-edge if u is at distance i from r, and v is at distance i+1;
  29. the edge is an internal i-edge if u and v are both at distance i.  (Note
  30. that EVERY edge is either an external i-edge or internal i-edge for some i.)
  31.  
  32. Okay, here is an algorithm.  The first pass is to pick up all the external
  33. edges rooted at 1.  Set a bit for each node as an extreme vertex.  Set a bit
  34. for each node as unattached, set the bit for sector 1 as attached, then run
  35. s from 2 to 1000 with
  36.  
  37. if s is not attached,
  38.   plot the course from 1 to s
  39.   parse the course to get v0=1, - v1 - v2 - ... - vn = s
  40.   store the edge (vi, vi+1), i=0..n-1
  41.   set vi as attached, i=1..n
  42.   turn off the bit for vi as extreme, i=1..n-1.
  43.  
  44. How many course plots do we have to make?  A priori, I don't have an answer;
  45. if the graph were pathological and we were unlucky, it could be as much as
  46. the size of the graph.  Note that we have to at least attach each dead end, 
  47. this is a lower bound.  Let's estimate that we have to make 500 course plots
  48. at a 0.75 sec each, or around 7 minutes.
  49.  
  50. At this point, we have ALL the external edges.  Moreover, we also know that
  51. any edge we are missing MUST be between a pair of nodes at the same distance
  52. from 1.
  53.  
  54. Here is some data: the format is "number at distance(internal/external edges)"
  55.  
  56. St.Marys bbs, stellar dispersion from sector 1:
  57.     1(  0/  6)     6( 12/ 21)    14(  2/ 43)    27(  2/ 77)    51(  2/146)
  58.    97( 19/290)   177( 47/450)   233( 91/487)   198( 51/345)   112( 15/179)
  59.    50(  2/ 75)    20(  0/ 30)     9(  0/ 12)     3(  0/  4)     1(  0/  2)
  60.     1(  0/  1)     0(  0/  0)     0(  0/  0)     0(  0/  0)     0(  0/  0)
  61. There are 0 unreachable sectors, 1000 reachable sectors.
  62. Average number of warps in reachable sectors: 2.411
  63. Average distance to (known) sectors: 6.99
  64.  
  65. diogenes.club bbs, stellar dispersion from sector 1:
  66.     1(  0/  6)     6( 12/ 22)    16(  2/ 49)    33(  2/102)    75(  6/221)
  67.   140( 36/393)   225( 91/512)   224( 65/436)   152( 19/245)    73( 13/110)
  68.    36(  2/ 46)     9(  0/ 17)     7(  0/  9)     3(  0/  3)     0(  0/  0)
  69. There are 0 unreachable sectors, 1000 reachable sectors.
  70. Average number of warps in reachable sectors: 2.419
  71. Average distance to (known) sectors: 6.51
  72.  
  73. grateful.med bbs, stellar dispersion from sector 1:
  74.     1(  0/  6)     6( 12/ 20)    13(  2/ 35)    22(  0/ 71)    51( 10/142) 
  75.    92( 10/250)   150( 43/375)   191( 66/424)   183( 63/362)   142( 22/247) 
  76.    83( 10/127)    35(  2/ 57)    16(  0/ 25)     7(  0/  9)     2(  0/  4) 
  77.     2(  0/  2)     0(  0/  0)     0(  0/  0)     0(  0/  0)     0(  0/  0) 
  78. There are 0 unreachable sectors, 996 reachable sectors.
  79. Average number of warps in reachable sectors: 2.406
  80. Average distance to (known) sectors: 7.33
  81.  
  82. The numbers are pretty consistent. The point is that this is fairly effective.
  83. For SMC, there are 243 internal edges that would be missed, 2168 external
  84. edges, so 90% of the internal edges.
  85.  
  86. Now consider the one-way character.  Just reverse the procedure!  I.e. here,
  87. we first clear all the attached bits, then plot courses back from s to 1.
  88. We won't have to do as many course plots this time: start with all the
  89. "extreme" sectors (since you have to do that anyway) and that will cover
  90. everything except sectors with back doors.  Just pick up the remaining, and
  91. you will have developed the entire level diagram.
  92.  
  93. Now what is missing?  The internal edges, since they won't have been seen in
  94. any shortest course plot.  Its likely that this is a sufficient place to
  95. stop: we've used up ten or twelve minutes of bbs time, and we've got 90% of
  96. the edges, and we certainly have a good picture of the stellar dispersion
  97. from sector 1.  (Actually, because you want to buy etherprobes at the
  98. stardock and fire them off from there, it might be nice to do all this from
  99. the stardock rather than 1.)  This seems to meet all the tactical issues,
  100. and then if you fire etherprobes at all the extreme nodes and parse the
  101. reports back, you will have a valid map (because you've passed through every
  102. sector).
  103.  
  104. What if you don't want to spend the money on the four hundred etherprobes?
  105. Because of one-way warps, the level diagram of the opposite directed edges
  106. rooted at 1 will have a slightly different structure in terms of nodes at a
  107. fixed distance, you can actually gain more negative information about where
  108. the internal edges are *not* located.  At this point, one could do two
  109. things: as you are developing the original sector scans, build the sets of
  110. nodes at the same distance, and then do course plots between pairs to see if
  111. the edges exist.  (These course plots would run very fast, as most of the
  112. time the paths would be of length 1 or 2.)  Alternatively, one could just
  113. repeat the above process of generating the level diagram rooted at another
  114. node.  Now, the edge would have to be internal to both level diagrams to be
  115. hidden; if r and s are your two nodes, and (u,v) is the hidden edge, then u,
  116. v have to be the same distance from r *and* the same distance from s, in
  117. *both* directions, which should be rather unlikely in these random graphs.
  118. Probably best is a hybrid: for each level diagram rooted at r, you get a
  119. partition of the nodes (by distance).  Combining level diagrams, you simply
  120. refine the partitions.  Repeat until the size of each partition is one or
  121. two, then directly course plot between the nodes to determine if the
  122. internal edge exists.
  123.  
  124. Interesting.  I first thought about using the silly oracle several years ago
  125. -- it is absurd that you don't have direct information about warps, but you
  126. can plot all of the warps leaving a node -- but didn't think very hard about
  127. it.  It easy to see that you can get a complete set of information by
  128. plotting 1000*999 course pairs, but a million course plots is clearly a
  129. waste of time.  Albin, it was very insightful to recognize that this can be
  130. quickly done.  The other reason that I didn't write the routine is that it
  131. would (I thought) take all the fun out of exploration.
  132.  
  133. Now, I find that exploration is rather boring, and that knowledge of the
  134. warps is not as important as knowing the location of the ports and whether
  135. or not the port has been visited/blocked -- i.e. the etherprobe
  136. information.  What would perhaps make the most sense is to have readily
  137. available the "map" of the universe, i.e. the warps, but that we can't have
  138. set up contacts at a port (i.e. visited it) unless we pay a fee to contact
  139. the port administrator, or have an etherprobe pass by (and deposit a
  140. permanent transmitter, aka "visiting").  It seems to me that this feature of
  141. TWASSIST is very useful and very sensible.
  142.  
  143.  
  144. ... "42? 7 and a half million years and all you can come up with is 42?!"
  145. --- Blue Wave/TG v2.12 [NR]
  146.  * Origin: Grateful Med BBS;Concord, CA.(510)-689-0347 (1:161/63.0)
  147. ------------------------------------------------------------------------------
  148.  
  149. Area Tradewar, Msg#399, Jun-04-93 12:57:10
  150.    From: David Myers                          
  151.      To: Joel Downer                          
  152. Subject: Mapping The Universe
  153.  
  154.  JD> Give me 100% explored on day 1, and I can optimize my ether-probing and
  155.  JD> find planets very early.  
  156.  
  157.      I'm not certain 100% is possible.  Please see a followup to Woody's
  158.      post on level diagrams that explains why.
  159.  
  160.  JD> And I'm just talking about my conventional
  161.  JD> way of optimizing ether probing, never mind the *optimal* approaches
  162.  JD> that should be available with 100% explored.  I'm not sure whether
  163.  JD> you've added a feature like this to TWAssist yet, but it should be
  164.  JD> possible to do scary things with 100% explored, 50-75 ether probes, and
  165.  JD> the avoids feature in the game.  An analysis program that can duplicate
  166.  JD> Gary's course-plotting results could figure out a list of avoids to
  167.  JD> set, base locations, regions to density-scan, and targets to use to
  168.  JD> ether probe and/or density-scan all 1,000 sectors at extremely low cost.
  169.  
  170.      What Gary is probably using is a breadth first search on an 
  171.      adjacency list; an adjacency list is how he stores his warp data on 
  172.      disk.  If so, the particulars of which courses he plots are dependent 
  173.      on the order of warps in the game's list, and that order probably 
  174.      cannot be matched in 15 minutes of course plotting online.
  175.  
  176.      David.
  177.  
  178.  
  179. --- Maximus 2.01wb
  180.  * Origin: Isolated Pawn * TW UTILS in NC * 919-471-1440 * 14.4K (1:3641/281)
  181. ------------------------------------------------------------------------------
  182.  
  183. Area Tradewar, Msg#324, Jun-04-93 13:03:14
  184.    From: David Myers                          
  185.      To: Woody Weaver                         
  186. Subject: Level Diags <--> Ext Edges !??
  187.  
  188. Ok, this has been driving me batty at work:
  189.  
  190. In your recent post to Albin, you assert that a level diagram 
  191. (and by this I mean the adjacency list that results from plotting courses 
  192. from a root r to all other nodes, and then from all extreme nodes back to r)
  193. contains all external edges of the graph.
  194.  
  195. This simply isn't true.  I can demonstrate a graph, with a reasonable
  196. course plotter, whose level diagram misses an external edge.
  197.  
  198. Consider the graph defined by the following adjacency list (in a 
  199. pseudo .SCT format):
  200.  
  201. 1  2  5
  202. 2  1  3
  203. 3  2  4
  204. 4  3  6
  205. 5  1  6
  206. 6  4  5
  207.  
  208. Assume that the course plotter is a breadth-first search(BFS), and that the
  209. BFS visits nodes on this list from left to right.
  210.  
  211. Then the level diagram rooted at 1 obtained from this graph will miss
  212. the external edge (4,6).
  213.  
  214. It is important to note that topologically this graph is a cycle, and
  215. that imbedded cycles in a larger graph G could generate the same problem.
  216. The existence of the problem *does* depend on the ordering of the
  217. edges in the adjacency list, in this case if the nodes in sector 4
  218. are reversed, the problem goes away.
  219.  
  220. Now if the above graph G is a subgraph of a larger graph H (say a TW
  221. game), and G is singly connected to H through the node 1, then the
  222. whole graph will suffer the same problem that a level diagram rooted
  223. at 1 does, and the only way to eliminate the problem would be to
  224. trace courses internally in the loop.  Even Albin's protocol will
  225. suffer from this problem if it does not take explicit measures to
  226. check for potential cycles on the periphery of the TW universe.
  227.  
  228. I don't think the assumption that Gary uses a breadth first search
  229. is a problem, since the data structure saved to disk is an adjacency
  230. list, and a breadth-first search is a good way to determine either
  231. the distance to a node, or the shortest possible path to a node using an 
  232. adjacency list, and it is simple to code.
  233.  
  234. David (workin' on TWFT 099, whose alpha version does level diagrams BTW).
  235.  
  236.  
  237.  
  238.  
  239. --- Maximus 2.01wb
  240.  * Origin: Isolated Pawn * TW UTILS in NC * 919-471-1440 * 14.4K (1:3641/281)
  241. ------------------------------------------------------------------------------
  242.  
  243. Area Tradewar, Msg#305, Jun-05-93 16:36:46
  244.    From: David Myers                          
  245.      To: Woody Weaver                         
  246. Subject: Level Diagrams in Reality..
  247.  
  248. Ok, I recently collected 3 level diagrams in files called mytest2.ast,
  249. mytest3.ast, and mytest4.ast respectively.  I then merged these 3
  250. files into a single file called mymerge.ast.  I then collected a
  251. CIM file and compared the CIM data to these actual level diagrams:
  252.  
  253.  
  254. -------------------------------------------------------
  255.  
  256.  When mytest2.ast is compared to the CIM File mycim.ast
  257.  There are 1497 Total Warps in the CIM File
  258.  And 354 Total missing and/or extra warps.
  259.  With 491 sectors out of 1000 compared, then the 
  260.  Efficiency of mytest2.ast is:   76.35
  261.  
  262. -------------------------------------------------------
  263.  
  264.  When mytest3.ast is compared to the CIM File mycim.ast
  265.  There are 1497 Total Warps in the CIM File
  266.  And 347 Total missing and/or extra warps.
  267.  With 491 sectors out of 1000 compared, then the 
  268.  Efficiency of mytest3.ast is:   76.82
  269.  
  270. -------------------------------------------------------
  271.  
  272.  When mytest4.ast is compared to the CIM File mycim.ast
  273.  There are 1497 Total Warps in the CIM File
  274.  And 345 Total missing and/or extra warps.
  275.  With 491 sectors out of 1000 compared, then the 
  276.  Efficiency of mytest4.ast is:   76.95
  277.  
  278. -------------------------------------------------------
  279.  
  280.  When mymerge.ast is compared to the CIM File mycim.ast
  281.  There are 1497 Total Warps in the CIM File
  282.  And 64 Total missing and/or extra warps.
  283.  With 491 sectors out of 1000 compared, then the 
  284.  Efficiency of mymerge.ast is:   95.72
  285.  
  286. Now I'll leave it to the pundits here to ponder what would happen
  287. to these efficiencies if all of the sectors had been collected
  288. in my CIM (Would efficiencies go up? down?).  My belief is that
  289. these are a *good* estimate of coverage but probably an underestimate
  290. of coverage since many of the missing sectors are undoubtedly dead-ends
  291. and known in detail by any of the LDs.  Nonetheless, the final efficiency
  292. of the merged diagrams is approaching the 99% efficiency I had predicted
  293. based on Woody's theoretical calculations.  That *single* LDs fail
  294. as often as they do is probably due to cycle effects, since with
  295. ordinary single cycles, you lose an external edge 50% of the time, a
  296. bicycle can lose either 1 or 2 edges, a tricycle will lose 2 or 3
  297. edges, and so on.  Since cycle-based edge losses are highly root 
  298. dependent, then multiple LDs tend to pick up these hanging external edges.
  299.  
  300. David Myers.
  301.  
  302.  
  303.  
  304. --- Maximus 2.01wb
  305.  * Origin: Isolated Pawn * TW UTILS in NC * 919-471-1440 * 14.4K (1:3641/281)
  306. ------------------------------------------------------------------------------
  307.  
  308.