1
\$\begingroup\$

The Desmos Graphing Calculator, or Desmos, has sliders, which can run, animating a graph.
Also, they can have multiple animation modes: (default) loop forwards an backwards, repeat in one direction, play once, play indefinitely.
In addition, they can have multiple playback speeds, ranging from 0.05x to 20x (a total of 16).
But, as it currently is, people are reluctant to use this great tool in code-golf answers, as the scoring of an active slider is yet undecided.

So, what do you guys think? How many bytes/bits should it be to have a running slider, different animation mode, or different playback speed (if they should be allowed)

\$\endgroup\$
2
  • \$\begingroup\$ I suggest that this question should describe the slider issue, and request proposals for solutions. You can post your own proposal as a first answer, and users can vote on it and on any other proposals (such as counting sliders as one byte, or forbidding them altogether, and so on). \$\endgroup\$
    – Dominic van Essen
    Jun 26 at 7:40
  • 1
    \$\begingroup\$ This answer (to a question asking for a scoring method of another Desmos feature) seems to apply here as well. \$\endgroup\$
    – Bubbler
    Jun 26 at 8:04

4 Answers 4

Reset to default
3
\$\begingroup\$

If it can't be coded, it isn't valid as an answer to a coding challenge

If the positions of the sliders (or buttons, or whatever) can be encoded so that they don't need to be manually slid, then just count the bytes of code needed. If they can't be written as code, then they probably aren't very well suited to a coding challenge, and their use shouldn't be allowed.

See also this answer which similarly tackles the issue of setting colours.

Note that using sliders (or buttons, or whatever) is probably Ok as input (since the input isn't part of the code).

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I don't think using sliders as input is ok, as it breaks one of our many rules that variable input is disallowed. By this I mean that to set up a slider, you have to first create a variable like a=0, which then automatically creates a slider for that variable. You can then use that slider to change the value of that variable. Instead, the normal I/O method in Desmos is to use a function like f(x)=x+2, which is both easy to test and follows the code golf rules. \$\endgroup\$
    – Aiden Chow
    Jun 26 at 18:35
  • \$\begingroup\$ Im not talling about encoding the slidedness of the slider (how far it's slid), but whether it is sliding in the first place \$\endgroup\$
    – Dadsdy
    Nov 17 at 3:04
1
\$\begingroup\$

Using graph states (not recommended, would cost huge amounts of bytes)

As this would cost a lot of bytes if this were to be implemented, I would not recommend this unless there is no other way found.

In Desmos, you can obtain the state of the graph by going into the console (this can be achieved by pressed control + shift + i on Chrome, for instance), and typing Calc.getState() into the console. This will return the json of every single customizable setting in a Desmos graph, including slider settings, colors, tables, graph settings such as min and max bounds and gridline patterns, and much more.

Then, you can utilize the Calc.setState() function in the console and inputting the json corresponding to your desired graph, which will change the current graph you have to match the specifications of the json inputted into the setState() function.

While this is a reproducible and easy way to encode any sort of Desmos graph, this would cost a huge amount of bytes to existing answers which use sliders, colors, and other similar functionalities, as these json are HUGE. I have messed around with Calc.setState() a bit and have realized that portions of the json outputted from Calc.getState() aren't required to get it working in Calc.setState(), but it would still cost a lot of bytes compared to existing answers.

I do have to mention that there is a Calc.getExpressions() and a Calc.setExpressions() as well, and they seem to cover most of the things like sliders, colors, tables, etc., but not graph settings like min and max bounds. Even then, it costs a lot of bytes just for one expression.

Another issue I have with this is that using the json won't really be "pure" Desmos anymore, as it requires the usage of the console in order to set everything up. But the Calc.setState(), Calc.getState(), and the other functions are technically specified in the Desmos API, even though they probably weren't intended to be accessed through the console on the website itself. With that in mind, if this were to be implemented, I think the language won't really be just plain Desmos anymore, but instead something like Desmos + Javascript, or Desmos API, or Desmos + JSON, or something else entirely.

\$\endgroup\$
2
  • \$\begingroup\$ Shouldn't the expression JSON only be what has to be used to make the expression work? \$\endgroup\$
    – Dadsdy
    Jun 26 at 18:54
  • 1
    \$\begingroup\$ @Dadsdy Yes, but I was covering the more general case of graph settings and such. Obviously sliders would be included in Calc.getExpressions() as well. \$\endgroup\$
    – Aiden Chow
    Jun 26 at 19:04
0
\$\begingroup\$

No extra cost

Just like flags in many languages!

\$\endgroup\$
-2
\$\begingroup\$

My proposal is thus: having a slider run is one bit, because each slider is either running not. Also, having a non-default animation mode is 2 bits, because there are four modes. In addition, having a non-default playback speed is 4 bits, as there is 16 possibilities.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .