FactorHistogram overhaul for alpha

[gwhitney]

This is one of a series of issues, one for each visualizer, to make sure they are "alpha-ready". The main aspects of this overhaul are:

Does the visualizer handle/request canvas size/aspect ratio gracefully and appropriately for the new ui?

Is the visualizer pushing as much validation down to the per-parameter checks as possible?

Is it doing the appropriate level of resetting/recomputation in presketch vs setup?

Is it using descriptions, warnings, and errors appropriately, and not changing the user's input out from under their keystrokes? (Note that if a human interaction entails a change in another parameter -- for example, if you were binning terms and there were 10K terms then setting bin size to 10 might change number of bins to 1000, while changing the number of bins to 100 would change the bin size to100 -- that's OK; we just don't want to seem to be ignoring or contradicting their immediate keystrokes; instead, we inform the person what's at issue with what they entered.

Is it sufficiently and appropriately responsive to events and input? Does it handle resizes as gracefully as can be in the current scheme?

In some cases, there are accumulated small previously-existing issues that should be addressed as well.

[gwhitney]

Consider resolving #296

[gwhitney]

Not sure what has gone wrong, but visualizing a Random sequence with FactorHistogram and changing the maximum value attainable is not redrawing the graph :( -- whereas it does with other visualizers like Turtle. Most likely this is some bug in the infrastructure, not with FactorHistogram itself, but it should be debugged and fixed along with this overhaul.

[katestange]

With PR #420 there will be some changes to the FactorHistogram, notably that it runs with webGL and has zoom/pan. There are still a few corner cases of resulting weirdness dubbed low priority, if we wish to revisit when overhauling.

[gwhitney]

visualizing a Random sequence with FactorHistogram and changing the maximum value attainable is not redrawing the graph

I think it is again working correctly in ui2 at the moment, but should definitely be checked in the overhaul. Except for Turtle in progress, these overhauls should probably be left to the end in terms of fixing issues for alpha release.

[gwhitney]

There is a problem in that when Histogram is rotated (e.g. by 90 degrees), the mouseovers no longer correspond to the bar positions. (This is from #404.) The solution we agreed on is to disable rolling the camera for Histogram -- it's not really useful for anything.

[gwhitney]

Notes to whomever works on this:

1. Don't forget to rename to FactorHistogram
2. When you use a formula or random sequence that has infinitely many terms, the visualization is of course actually using some finite number of terms, but there is no indication of the situation or of how many terms it is actually using.
3. If you explicitly request e.g. 1000000 terms, your browser just hangs. Maybe it should use the same cutoff and warning (to be implemented) as for infinitely many terms, or display a progress bar, or after a while post a warning and provide the opportunity to cut down the number of terms... In any case, it shouldn't just block the browser. It could progressively update the histogram as it computes more and more terms, for example; ie., add N terms per frame.

[gwhitney]

3. In any case, it shouldn't just block the browser.

P.S. This is particularly important because if there is a sequence in the history that has a million terms, and the current visualization is FactorHistogram, the browser then also freezes if you just hit the sequence switcher, creating a very broken feel. I am adding an item about this sort of thing to the visualizer writing docs.