Wasn't the point that the map wasn't labelled? They just had some unlabelled stars, not necessarily all unknown ones. That's what the dialogue said - that they didn't know where these particular stars were, nothing about them being unknown or unexplored.
ICBR, but the "rest of the galaxy map" provided by R2
had a huge gap.
The way I understood it, they couldn't fit the piece to any map they had. I think I'm supposed to believe that it needed the "obvious gap map" to know where it fit because it would be impossible without the clue, but I have to dismiss that, because the problem of fitting to a full-chart is simple enough for the processing power within any technically-minded droid (not just
that rather special R2 unit, with the Power Of Plot running through it) or mapping system.
Here's how I would do it. Even assuming the clue-chunk is of unknown scale and orientation.
1) Pick the two closest stars in the chunk, and the third star that is the next closest to either of them.
2) Cycle through every star in the galaxy and its closest registered neighbour (an O(n) function, rather than the worst-case scenario of O(!n) that you might expect), which can be simplified further if the chunk has more details, such as relative sizes of the two chunk-stars chosen, to rule out some pairs immediately.
3) Scale and rotate the chunk so that the chunk-pair sit over the galaxy-pair (both directions if it
doesn't have size-info... doubling the operations, but still order-'n') and then check for rotations so that chunk star 3 sits on a suitable galaxy star 3. Again, just a multiplier, so still O(n) to rule out all obviously wrong types.
4) If not ruled out, you now have a chunk fixed to a scale and angle upon the galaxy map whereupon you can quickly test a fourth star for a match, a fifth star to match, etc, at each stage shedding 99.99...% of the coincidences up until that point (at which point you try your next third-star search-angle, star-pair directionality (if relevant) and then first star of a new pair, reversing back out of each level of checking).
There are two immediate problems with this approach, that I'd anticipate:
a) Inaccuracies/time-wise positional differences in either (i.e. both) of the maps - solution is to allow an error-bar, letting a few more 'possibles' through (and perhaps some scale/angle jiggling iterations, still linear) before being ruled out.
b) Further Kominos, or (conversley) some stellar form of an Argleton, featuring within either pairing or incorrectly ruling out third+ star matching - solution being to double the effort and choose a second (unrelated) pair to have a go at, and allow at least one negative-match without discarding the general chunk-on-reality cross-referencing process, which could also solve point (a) when it's a single fast-moving star (or small number of them!) without clarified time-indexing that causes the inaccuracies.
...that one estimated number of operations to search the true location of (say) a chunk of 50 stars within the body of an otherwise sufficiently explored and mapped Milky Way is to identigy stars 'A' and 'B' from the chunk (50x49=2450 spacial comparisons, to choose the mutually closest two), then 400 billion (could be double that, but hey!) cross-references (each star, 'C'), obtaining the nearest neighbour (star 'D', and for the sake of argument not bothering to check that 'C' is also the closest neighbour to 'D'), try both directions (double up), twist a third chunk reference (B2) around at 5-degree increments (say, although you can probably do it with more) looking for near matches (D2) on the galaxy-map, and adjust to any nearby match, generously allow for five 'possibles', take a B3 from the chunk and try to match to a D3 in the galaxy (1/100th chance of a further, match would be generous) and again (a further, i.e. 1%*1%, more possible matches), and again, quickly being insignificant except in the case of the one true match...
Operations: a tad over 700 quadrillion for worst-case, or going through the whole lot just in case there are multiple candidates. A mere gigaflop computer, assuming a trio of flops (and enough memory-access bandwidth enough to service such a search ability) comes out as 24 days. The human brain is an exaflop device and the droids/computers available to the Resistance are probably petaflop at worse (given their level of Turin-capable AI), to keep up reasonably with the demands put upon them. And also have the inhuman optimisation capable of actually using that search power in a structured way, so that's... working back down again...
...so about 2 seconds? If I haven't missed a power of 10 or three in the wrong direction through error or wrongly-generous assumptions, along the way; but even if it's 2000 seconds that's half an hour of work.
But I didn't even read
that idea into the film, when I saw it... As far as I'm concerned the R2-projection (into which the BB8-held data is inserted) is just the latest
actual map as of the point in time he decided to also withdraw from the world, into his electronic stupor. But, if I'm mistaken (possible), it still seems too Deus-ex-R2 to require 'all but the clue' to answer the problem.
Author
Topic: Star Wars: The Force Awakens Discussion Thread (spoilers, obviously) (Read 58226 times)