The Desmos graphing calculator, commonly referred to as just Desmos1, has been used for a number of answers, by me as well as others. However, scoring (as well as I/O, but that's for another post) expressions2 has never been really well standardized. Let's review some of the functionality of them first:

  • Desmos accepts input from the keyboard, automatically converting it to TeX-like code. For example, typing s q r t 5 gets converted to \sqrt{5}, stylized as \$\sqrt{5}\$, as soon as the t is typed.

  • Desmos allows you to copy text out of the input boxes. For example, copying out the above code will put \sqrt{5} on your clipboard.

  • Desmos allow you to copy input from your clipboard, as long as it comes close to conforming with the stylized code that will be output. For example, if \sqrt{5} is on your clipboard, you can paste it in to get \$\sqrt{5}\$.

This answer formalized Desmos as a language and stated that "the string you get from copying the program out of Desmos is the most reproducible/verifiable option for measuring program size." This is all fine and good for the \sqrt{5} example, it seems clear that the code is not s q r t 5 and so the code should be \sqrt{5}. However, there are some more complications:

  • Arrays such as [1,4,7,2] are copied out as \left[1,4,7,2\right], but can be copied in as [1,4,7,2].
  • Instances of functions using a simple argument, like sin 42, are copied out like \sin42 but can be copied in like sin42.
  • Simple functions, like sin(42), are copied out like \sin\left(42\right), but can be copied in like sin\left(42\right), \sin(42), or sin(42). Note that these are not all exactly the same: when the \left and \right are excluded, the functionality is the same, but the ( are literal (s instead of formatted \$(\$s, which mean that changing the code once it's pasted in like such sometimes requires replacing all those (s with \$(\$s by manually re-typing them to make it work.
  • More unusual functions, like mod(45,4), are copied out as \operatorname{mod}\left(45,4\right) (yikes, those bytes!), but can be copied in as mod(45,4) (with the \left/\right note above still applying)
  • Some things can be copied out, but not typed in. For example, typing in y / x gives \$\frac{y}{x}\$, encoded as \frac{y}{x}. However, pasting in y/x gives \$y/x\$, which copies out as y/x and functions the same as \frac{y}{x}. <= has similar functionality, being converted to \$\le\$, encoded as \le, but can be copied in and then out as just <=.
  • As a side note, when using restrictions like {y>1} in x>1{y>1}, they're encoded as x>1\left\{y>1\right\}, and can't be simplified.

Because of all these differences, code copied out is always larger or equal to code copied in in size, so I've been using the latter for my answers. However, this seems to go against the wording of that answer. I would argue that the intent of that wording as to clarify that it's the code text, not the keystrokes that determines byte count, making the whole thing ambiguous. Furthermore, I believe the examples I've shown make it clear that the code copied in is the most simplest, most reproducible, and, for what it's worth, most golf-y version of the code. Requiring that the code copied out be used would sometimes add an extra step: Code your program is Desmos, copy it out and manually golf it in a text editor to fix /s and <=/>=s (among potentially some other things that I haven't investigated yet), copy it back into Desmos, and then copy that result out (normally, you'd end with copying it in to make sure it works).

I'd also like to make a more fundamental argument for this: when one refers to "code" in the general sense (i.e., excluding particularly strange cases like Minecraft redstone), you're generally referring to text that is then fed to a compiler/interpreter/magic box, which either runs it or produces a binary file that can be run. In this sense, the "code" of Desmos must be what you input to the program.

So here's my proposal: Desmos expressions should be scored as the number of bytes in the text which is pasted into the equation box to produce the program. Feel free to disagree or comment with alternate proposals.

2This is referring specifically to what you get when typing into one of the boxes on the left (which is what almost all of the Desmos answers here are). Things like notes, tables, folders, images, colors, styles, viewboxes, radians/degrees mode, axes, reverse contrast mode, braille mode, and anything else is beyond the scope of this question. There's enough here as it is.

1Note that there are some other tools that Desmos provides, such as a matrix calculator, a scientific calculator, and a geometry tool, but I've never seen an answer using any of these and they don't seem especially interesting from a coding perspective.


1 Answer 1


Mostly agree with the proposal, but let's make it more formal

Here is a more formal version of the proposal:

  • A valid Desmos program is a piece of code that works when copy-pasted into the equation box (the "code area") as plain text without further modification (such as manually correcting the parens).
  • The score of the program is the number of bytes in its original plain text form - in OP's words, the copy in version.

Some reasons to accept the "valid program" condition:

  • Some answers in Excel (and possibly some other languages) use its auto-correction feature to omit closing parentheses. Desmos auto-correcting sin42 to \sin 42 can be considered the same way.

  • As the OP already pointed out,

    when one refers to "code" in the general sense (i.e., excluding particularly strange cases like Minecraft redstone), you're generally referring to text that is then fed to a compiler/interpreter/magic box, which either runs it or produces a binary file that can be run.

    The only way to feed whole code (as opposed to character-by-character) into Desmos interpreter is copy-pasting it into the equation box.

  • \$\begingroup\$ This meta post is a little old, but I would like for something to get clarified. In many of my recent Desmos answers, the code has to be copied expression by expression in order for the entire code to function; otherwise, if you feed in the entire code at once, the code just breaks(not sure why this happens, but it may have to do with some of the golfing tricks I used). What is the consensus in this situation? \$\endgroup\$
    – Aiden Chow
    Commented Jul 20, 2021 at 20:54
  • 1
    \$\begingroup\$ @AidenChow Considering that each expression goes into its own expression box, I believe this consensus for multi-file submissions applies. Since it counts file boundaries as 1 byte each, you can simply use your multi-line answer format to count bytes (newline = 1 byte = file boundary). \$\endgroup\$
    – Bubbler
    Commented Jul 21, 2021 at 0:05

You must log in to answer this question.

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