Could the color value of the map's background also be displayed there, since it's another type of cell just like the periodic cells? (Either that, or it, as well as maybe the grid, could be made customizable, since they remain constant regardless of the oscillator being identified.)
Another thing: ever since the period map functionality was implemented, LifeViewer has been able to produce all of the information about a pattern that Oscillizer was able to,
except for the minimum and maximum rule that a given pattern works in. Would it be possible to add this for range-1 outer-totalistic rules? Catagolue does this on object pages already - I believe
this is the code responsible, which also handles isotropic non-totalistic rules.
----
Since we've been testing the map feature regularly since it was first implemented a month ago, an idea sprang to mind recently: it's entirely likely that for high-period oscillators, the period itself will be known, but other aspects of its behaviour that Identify can output will not be. Filling in information on the wiki, checking out crazy high period oscillators on Catagolue, and generally testing out Identify and its behaviour are three situations I've found myself in. Would it be possible to implement into LifeViewer a way to input an expected period for a given oscillator or spaceship, such that LifeViewer doesn't first need to take the time to check the pattern for periodicity?
For example, here's the p46-based pRNG oscillator. We already know it has a period of 40894, but LifeViewer doesn't. So it has to run this pattern until it goes a bit over that value, which, given the fact it's a rather large pattern in terms of bounding box, takes 23 whole seconds:
Code: Select all
x = 156, y = 75, rule = B3/S23
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!
But say we had a way to immediately tell LifeViewer "this pattern right here is a period-40894 oscillator, or ancestor thereof". So all LifeViewer needs to do now is immediately skip to generation 40894, without having to keep track of any previous phases besides the starting one, the one at 40894, and perhaps the one at 81788 if 0 and 40894 don't match. Once it can confirm that yes, this pattern indeed is the period that was specified, it can immediately get to calculating all of those other statistics that we're after. (If the wrong period is specified, there's always the cancel button, though I suppose that for very high periods it'll probably reach 1048576 quite fast anyway and cancel itself automatically. It might be advisable to display the provided period next to the "Identifying..." text to allow users to notice any input mistakes if desired.)
----
Back to the small suggestions: for oscillators, if a map/periods table cannot be displayed due to the period being too high, could the buttons on the right hand side be left there, but grayed out, similarly to how N/A is displayed for strict volatility in such cases?
