u/Circumpunctilious

When assigned a Step size, sliders remember their original values but take on a variance. That variance from original (or, from the slider's "seed" value) is plotted in this graph.

https://www.desmos.com/calculator/gkdlz5k6n8

An easy-to-explore (but less intuitive) Action is included at the end if you just want to slide things because TL;DR.

This is related to my earlier "Jitterstep" post, using the same effect, linked in this graph.

This is just an animation showing that updating a slider's "Step" results in Desmos adjusting the value of the slider itself. I'm not suggesting this is a bug (rather expecting it's just a rescale).

This graph shows the last 10 values (as points in a polygon) that two sliders move to when their "Step" variable "s" is udpated.

https://www.desmos.com/calculator/z5igjgk64o

Note that when Actions update sliders, their "Step" field is wiped, so if you hit Action R_ESET you must manually restore "Step = s" for sliders "a" and "b"

(Manual crosspost because rules: original has a screenshot of the title fractions. Mainly to share something helpful to learn about these fractions, I am adding that I had a couple minor “answer + 1” errors that I mitigated / didn’t see why it was happening, and will gladly accept corrections. At the moment, I wasn’t thinking these greatly affect the learning and exploration. The first mitigated “off-by-1” glitch is in trying to use a generated Engle Expansion, the second in the Pascal’s Triangle “Triangular Numbers” equivalent sum, for denominators = 2^n…see OEIS references)

Origin-post text in r/Desmos: This work was prompted by a post a week (or so) ago that included a "rising continued fraction" for "e".

This graph: https://www.desmos.com/calculator/pj3uuvzahh

Contains a breakdown of equivalent recursive forms to generate "e", recursive Desmos functions for "nested" and "rising fraction" representations, and separated "improved" recursions to add flexibility to the "rising fraction" recursions. It is my hope that this helps people understand the fractions.

Also contains Engle Expansion (another recursive function) to get the simple list of rising denominators for any number (like pi, phi, gamma, terminating decimals, etc).

A couple extras (powers of a number as denominators, ...) + references collected at bottom.

Origin post: https://www.reddit.com/r/desmos/s/bes0cAb0mP

*Note: Open to precision of speech corrections too*

Prompted by a post a week (or so) ago that included a "rising continued fraction" for "e".

This graph: https://www.desmos.com/calculator/pj3uuvzahh

Contains a breakdown of equivalent recursive forms to generate "e", recursive Desmos functions for "nested" and "rising fraction" representations, and separated "improved" recursions to add flexibility to the "rising fraction" recursions. It is my hope that this helps people understand the fractions.

Also contains Engle Expansion (another recursive function) to get the simple list of rising denominators for any number (like pi, phi, gamma, terminating decimals, etc).

A couple extras (powers of a number as denominators, ...) + references collected at bottom.

An earlier post: https://www.reddit.com/r/desmos/s/4OMYNQFJAE showed that Apple WebKit (Safari) has engine-engine float inaccuracy / variance of up to 4*epsilon when a (large) value is set using Actions.

Desmos support reviewed + reflected that different engines can vary (here, I think that's "base Desmos engine" vs "Actions engine") and--reading this as a "wontfix" (that is: "within expected parameters")--I wrote an Actions float patch.

For Apple Safari / WebKit ONLY, this demo: https://www.desmos.com/calculator/1sncrw4nyb shows the problem, a runaway self-assignment bug, the comparison problem, and finally that a wrapper function fixes float inaccuracy (and so also: runaway values and missed comparisons).

A "basic use case" (not filled with demo junk) version here: https://www.desmos.com/calculator/mmk2dgqc9f

This may not be the best solution--of 4 ideas--but it appears to work (using these functions in the original post, the output is flat at variance=0 for all tests, so Apple Actions should now act like everyone else's).

Copyable line: y=nCr(u, (x + u/2))

All this does is graph the peak (“center”) value of binomial triangle rows and keeps it centered at zero.

At (apparently) u=14 and above, zooming out reveals an intermittent diagonal from the peak to the viewport’s left extremity, instead of the (expected) oscillation around y=0.

I’m hoping it isn’t just floating point but u=14+ (when nCr base is 0) makes me suspicious.