Revisit the restriction to integer-valued sequences?

[gwhitney]

The entry for A007442 includes the exhortation

Graph this divided by A122803

and indeed the result is curious. From this I conclude that one goal for Numberscope should be to be able to reproduce this graph, only prettier/more flexibly.

But this is the graph of a function from the natural numbers to rational numbers, not integers. So in our current setup, supposing that it were extended to allow OEIS sequence references in formulas and had a basic graph plotting visualizer added, we might enter the formula A007442(n)/A122803(n+1). But these formula values are rational numbers, between ±1, so the way things are, the automatic floor that is applied would produce a sequence of values each of which would be 0 or -1, and the interesting structure would be lost.

But there is a problem in that right now the return type of sequences is bigint. So if we just turned off the automatic floor()ing, the JavaScript entities coming out of mathjs would be the wrong type and the code would go haywire.

What are some ways we could respond to this?

1. Just let this putative graphing visualizer be special, and directly accept a formula or formulas, and call mathjs itself expecting
   perhaps to get back IEEE doubles (JavaScript numbers) and/or rational numbers. It might feel a bit weird in terms of the UI though if this one visualizer ignores the Sequence setting altogether...

2. Wait until we go to multiple sequences allowed, and have an option in the graphing visualizer to plot the ratio of two sequences. This is the current OEIS website solution. Feels too special-purpose to me; what if you want to graph the logs of something?

3. The mathjs package already has an arbitrary-precision rational number class. We could switch to all of our sequences being rational sequences, since every integer sequence is a rational sequence. This neatly solves the A0074429(n)/A122803(n+1) problem, but doesn't naturally solve the log problem (like that pun?) unless we choose some arbitrary precision for a rational approximation of log (which of course is really what is happening anyway with log on a computer, since a floating-point number in reality is a rational approximation). Then we would extend all of our visualizers to handle rational numbers where possible, and politely decline to deal with a non-integer rational sequence if that doesn't make sense. We might add functions for numerator and denominator of a rational number in lowest terms.

4. Turn off automatic flooring altogether, let users know they have to put floor() in their formulas if they want it, and let mathjs formulas return whatever type they inherently will (which could be any of a host of types, ranging from complex numbers and matrices to higher-precision floats than IEEE doubles). If any visualizer can't handle a given return type, it will presumably throw some sort of recognizable error, which we will try to catch and display a useful message for. Or, we could try to create a way for each visualizer to specify what value types it can handle, and if the a person specifies a sequence that produces values of the "wrong" type there would be a message at validation time, which is nice and early; they could correct it then, especially with some gentle guidance. These things might get a bit complicated, especially the TypeScript type handling of a whole bunch of different possible types.

5. Other ideas?

Anyway, I don't think there is a clear dominant solution here, so I definitely think we should brainstorm and discuss on this topic when we can.

[gwhitney]

After some time and reflection, I have a concrete proposal for discussion:

• We maintain for simplicity and thematic fidelity that there be one specific sequence at a time that is being visualized. When that sequence is a mathjs formula, it is automatically wrapped in floor and conversion to bigint. (As a small positive side effect of this, it would then be possible for the sequence formula sqrt(n) to automatically be converted to floorSqrt(n) by the formula engine for you.)
• To the extent practical in all other formulas (used in visualizers as opposed to the sequence), we allow at least the variables n for the current index in the sequence, a for the current entry of the sequence, and A as a function symbol that computes entries of the sequence (so that a == A(n) would generally hold).
• To the extent practical in all other formulas, we allow them to take on any mathjs type (as extended in Numberscope), and the visualizers using those formulas should handle as many types as practical and check for any it can't handle and warn appropriately.
• In particular, to deal with the plotting issue above, a putative Plot visualizer should have formulas Data1, Data2, ..., DataN for the different items to display in the graph. These should be allowed to end up as any numeric type, and Data1 should default to a, but in the case study for A007442 described above, it could be changed to a/A122803(n+1). In particular, this arrangement of parameters and their semantics more or less corresponds perfectly to the exhortation in the notes for sequence A007442: the sequence A007442 is still the subject of the Plot, just we are graphing "this" (i.e. a = A007442(n)) divided by A122803.