We memoize the checksum of the x first models, and we check that one of
these models is still present when the graph view appears. If so, we do
not reload the range, other wise we reload it.
Scenario:
f(t) = [t^2 t+1] in parametric
Display the graph
f(x) = 1 on ]-inf;0]
g(x) = 2 on [0;inf[
Display the graph -> the range did not change
There was a lot of code duplication.
I removed the initialization of xLabel{} and yLabels{} because those are
scratch buffers that shouldn't be accessed before being written to
anyway.
Fixes the following bug:
In the graph tab of the Sequence app, compute the sum of the terms of
a sequence from 1 to 9 and then from 1 to 10. The Layout is memoized
after the first time and mispositioned the second time since it is
not recomputed.
selectRegressionCurve is only called from GoToParameterController and is
part of the GraphController's API for updating the model. It should not
update the view. viewWillAppear does.
In the graph controller, selectRegressionCurve is only called at one
place (in moveCursorVertically). In general, setRoundCrossCursorView is
called and *m_selectedDotIndex is updated. There is no reason at all to
do things differently.
Though selectRegressionCurve is called from GoToParameterController.
Scenario : f(x)=8x, scroll to the right until the window range has
changed, then set the preadjustment to default -> the x change had no
impact on the yRange because we did not set the yAuto before doing the
changes.
Merge the language-specific definitions of these mathematical constants
into one definition. Note that the definitions were in fact inconsistent
across languages.
scroll "smartly" when scrolling to a too-big-to-be-displayed rect
This fixes calculation history navigation on big cells (that are bigger
than the displayed table)
This fixes crashes: indeed, in the way it was done before, we called
scrollToSubviewOfTypeOfCellAtLocation after setting the new selected subtype
and before reloading the data. However, selecting a new subtype might expand
the selected cell which can temper with the cell repartition. If so, we need to
reload the data to be able to call 'selectedCell' for instance.
table. Otherwise, the Poincare pool store useless layouts for cells that
aren't displayed.
This fixes the following issue: input "(transpose([1 2 3 4 5 6][1 2 3 4 5
6])^8", the computation works, clear the history, input the same
calculation again, it fails with a memory error.
