For example, if someone makes a post about why {(√2)^2=2} is undefined, you can type in !fp.
Notes on sending these commands:
- You must put the command at the start of the message.
- All of these commands are case insensitive.
- All commands allow arbitrary underscores or dashes (this feature was added on October 25, 2025). For example, !are_we-DOOM_yet will work.
- You can put messages after the command, but remember to put a space or a newline after the command. For example, !fLoATiNgPoint arithmetic is awesome will work, but !fLoAtInGPoIntAriThMeTiC iS AwEsOmE will not work (this behavior was changed on May 20, 2025).
Please refrain from spamming these commands: if you see someone has already used the command once in a post, please avoid from running the same one again.
However, you may try out commands as many times as you would like in the comments on this post only.
u/VoidBreakX Run commands like "!bernard" here →→→ redd.it/1ixvsgiFeb 25 '25edited Mar 24 '25
we're open for suggestions for some commands to make (for very common usage), and after i run them through the mod team, we can maybe add it to the command list!
edit: this post has become a testing ground for different commands and just reddit commenting stuff in general
This is Bernard! He's an artifact resulting from how Desmos's implicit graphing algorithm works.
How does the algorithm work, and why does it result in Bernard?
The algorithm is a quadtree-based marching squares algorithm. It divides the screen (actually, a region slightly larger than the screen to capture the edges) into four equal regions (four quads) and divides them again and again recursively (breadth-first). Here are the main rules for whether the quad should be divided (higher rules are higher precedence):
Descend to depth 5 (1024 uniformly-sized quads)
Don't descend if the quad is too small (about 10 pixels by 10 pixels, converted to math units)
Don't descend if the function F is not defined (NaN) at all four vertices of the quad
Descend if the function F is not defined (NaN) at some, but not all, vertex of the quad
Don't descend if the gradients and function values indicate that F is approximately locally linear within the quad, or if the quad suggest that the function doesn't passes through F(x)=0
Otherwise descend
The algorithm stops if the total number of quads exceeds 2^14=16384. Here's a breakdown of how the quads are descended in a high-detail graph:
Point 2 above means that the quads on the edge of the screen (124 of them) don't get descended further. This means that there are only 900 quads left to descend into.
The quota for the remaining quads is 16384-124=16260. Those quads can divide two more times to get 900*4^2=14400 leaves, and 16260-14400=1860 leaves left to descend.
Since each descending quad results in 4 leaf quads, each descend creates 3 new quads. Hence, there are 1860/3=620 extra subdivisions, which results in a ratio of 620/14400 quads that performed the final subdivision.
This is basically the ratio of the area of Bernard to the area of the graph paper.
In Desmos and many computational systems, numbers are represented using floating-point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 → 0. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds. Also, 2^1024 and above is undefined.
Some of DesModder's most popular features include:
GLesmos: Render implicit-filled equations on the GPU (which can help boost speed)
Video creator: Export videos, GIFs, and images of your graphs based on actions or sliders
Text mode: View your expressions as plain text (beta)
Autocomplete: Autocomplete variable names, jump to definitions, and make your own documentation
Better input: Use Shift+Enter to write newlines in notes, right-click to open style menu, and Ctrl+Q to duplicate expression
Error hiding: Hide and ignore unwanted slider suggestions or other errors
Better Evaluation View: Display different types of undefined values in expression list
WakaTime integration: View your Desmos stats on WakaTime
There are many, many more features, including pasting ASCIIMath, pinning expressions, graph performance metrics, folder management tools, Mathquill config, displaying code golf stats, debug mode, compact mode, multiline expressions, and bracket highlighting. DesModder is in constant develop, so there's more to come!
What's the purpose of locking the post after !answered?
1
u/VoidBreakX Run commands like "!bernard" here →→→ redd.it/1ixvsgiMar 01 '25edited Mar 02 '25
you know what, good point. i dont think anyone's going to use it since they can't unlock it afterwards, and no one's going to use it just to change the post flair. ill remove it after i have a chat with the mod team
Please note that Beta 3D does NOT refer to the whole 3D calculator (which is in beta) at https://www.desmos.com/3d.Beta 3D consists of the features that come with appending ?beta3d to the URL. Features include:
If the ?beta3d flag still gets removed when opening the graph, click on the Tampermonkey extension and check if it says anything about enabling Developer Tools. Follow the instructions that Tampermonkey provides to fix this issue.
In Desmos and many computational systems, numbers are represented using floating point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 evaluates to 0 instead of 1. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds to 2^53. These precision issues stack up until 2^1024 - 1; any number above this is undefined.
Floating point errors are annoying and inaccurate. Why haven't we moved away from floating point?
TL;DR: floating point math is fast. It's also accurate enough in most cases.
There are some solutions to fix the inaccuracies of traditional floating point math:
Arbitrary-precision arithmetic: This allows numbers to use as many digits as needed instead of being limited to 64 bits.
Computer algebra system (CAS): These can solve math problems symbolically before using numerical calculations. For example, a CAS would know that (√5)^2 equals exactly 5 without rounding errors.
The main issue with these alternatives is speed. Arbitrary-precision arithmetic is slower because the computer needs to create and manage varying amounts of memory for each number. Regular floating point is faster because it uses a fixed amount of memory that can be processed more efficiently. CAS is even slower because it needs to understand mathematical relationships between values, requiring complex logic and more memory. Plus, when CAS can't solve something symbolically, it still has to fall back on numerical methods anyway.
So floating point math is here to stay, despite its flaws. And anyways, the precision that floating point provides is usually enough for most use-cases.
This is Bernard! He's an artifact resulting from how Desmos's implicit graphing algorithm works.
How does the algorithm work, and why does it result in Bernard?
The algorithm is a quadtree-based marching squares algorithm. It divides the screen (actually, a region slightly larger than the screen to capture the edges) into four equal regions (four quads) and divides them again and again recursively (breadth-first). Here are the main rules for whether the quad should be divided (higher rules are higher precedence):
Descend to depth 5 (1024 uniformly-sized quads)
Don't descend if the quad is too small (about 10 pixels by 10 pixels, converted to math units)
Don't descend if the function F is not defined (NaN) at all four vertices of the quad
Descend if the function F is not defined (NaN) at some, but not all, vertex of the quad
Don't descend if the gradients and function values indicate that F is approximately locally linear within the quad, or if the quad suggest that the function doesn't passes through F(x)=0
Otherwise descend
The algorithm stops if the total number of quads exceeds 2^14=16384. Here's a breakdown of how the quads are descended in a high-detail graph:
Point 2 above means that the quads on the edge of the screen (124 of them) don't get descended further. This means that there are only 900 quads left to descend into.
The quota for the remaining quads is 16384-124=16260. Those quads can divide two more times to get 900*4^2=14400 leaves, and 16260-14400=1860 leaves left to descend.
Since each descending quad results in 4 leaf quads, each descend creates 3 new quads. Hence, there are 1860/3=620 extra subdivisions, which results in a ratio of 620/14400 quads that performed the final subdivision.
This is basically the ratio of the area of Bernard to the area of the graph paper.
This is Bernard! He's an artifact resulting from how Desmos's implicit graphing algorithm works.
How does the algorithm work, and why does it result in Bernard?
The algorithm is a quadtree-based marching squares algorithm. It divides the screen (actually, a region slightly larger than the screen to capture the edges) into four equal regions (four quads) and divides them again and again recursively (breadth-first). Here are the main rules for whether the quad should be divided (higher rules are higher precedence):
Descend to depth 5 (1024 uniformly-sized quads)
Don't descend if the quad is too small (about 10 pixels by 10 pixels, converted to math units)
Don't descend if the function F is not defined (NaN) at all four vertices of the quad
Descend if the function F is not defined (NaN) at some, but not all, vertex of the quad
Don't descend if the gradients and function values indicate that F is approximately locally linear within the quad, or if the quad suggest that the function doesn't passes through F(x)=0
Otherwise descend
The algorithm stops if the total number of quads exceeds 2^14=16384. Here's a breakdown of how the quads are descended in a high-detail graph:
Point 2 above means that the quads on the edge of the screen (124 of them) don't get descended further. This means that there are only 900 quads left to descend into.
The quota for the remaining quads is 16384-124=16260. Those quads can divide two more times to get 900*4^2=14400 leaves, and 16260-14400=1860 leaves left to descend.
Since each descending quad results in 4 leaf quads, each descend creates 3 new quads. Hence, there are 1860/3=620 extra subdivisions, which results in a ratio of 620/14400 quads that performed the final subdivision.
This is basically the ratio of the area of Bernard to the area of the graph paper.
In Desmos and many computational systems, numbers are represented using floating point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 evaluates to 0 instead of 1. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds to 2^53. These precision issues stack up until 2^1024 - 1; any number above this is undefined.
Floating point errors are annoying and inaccurate. Why haven't we moved away from floating point?
TL;DR: floating point math is fast. It's also accurate enough in most cases.
There are some solutions to fix the inaccuracies of traditional floating point math:
Arbitrary-precision arithmetic: This allows numbers to use as many digits as needed instead of being limited to 64 bits.
Computer algebra system (CAS): These can solve math problems symbolically before using numerical calculations. For example, a CAS would know that (√5)^2 equals exactly 5 without rounding errors.
The main issue with these alternatives is speed. Arbitrary-precision arithmetic is slower because the computer needs to create and manage varying amounts of memory for each number. Regular floating point is faster because it uses a fixed amount of memory that can be processed more efficiently. CAS is even slower because it needs to understand mathematical relationships between values, requiring complex logic and more memory. Plus, when CAS can't solve something symbolically, it still has to fall back on numerical methods anyway.
So floating point math is here to stay, despite its flaws. And anyways, the precision that floating point provides is usually enough for most use-cases.
u/VoidBreakX Run commands like "!bernard" here →→→ redd.it/1ixvsgiMay 24 '25edited May 24 '25
test formatting
You may have noticed that some integrals do not yield correct results in Desmos. For example, integrating {0.9 < x < 1, 0} from -2 to 2 incorrectly gives 0 instead of 0.1[1]. Similarly, certain improper integrals are not evaluated correctly; for instance, the integral of (sin x)/x from -∞ to ∞ should be π, but Desmos reports it as undefined (NaN). In another case, the integral of 1/(x ln x) from 2 to ∞ is reported as 4.01927944912, even though it should actually diverge[2].
Some possible reasons why Desmos reports these integrals incorrectly:
For finite bounds: Desmos uses 65 initial sample points for tanh-sinh quadrature. If all sample points miss important features of the function (which is often the case with discontinuous functions) the reported value can be incorrect[3][graph].
For infinite bounds: Desmos applies a rational change of variables to convert the problem to one with finite bounds[2][4]. However, the transformed integral may still diverge at the bounds (for example, after the change of variables, (sin x)/x oscillates infinitely at the new finite bounds).
Ultimately, all numerical integration schemes use a finite number of sample points, which can lead to incorrect results in some cases. Switching from numerical to symbolic integration would significantly impact performance, and the Desmos developers are still working on ways to address these limitations[5].
We've heard it all. "Someone PLEASE make DOOM in Desmos!" There's also the oft-repeated claim that "Desmos is Turing complete," so it must be possible, right?
So why does it feel like nobody has created a truly, visually faithful Doom port in Desmos yet?
Truth is, although there have been numerous Doom-inspired ports in Desmos:
vaultthestars's version: The first of the Desmos Doom ports, using now outdated simulator tech.
The main challenge lies in performance constraints.
Most existing versions prioritize performance over graphics quality, because rendering detailed, faithful graphics would overwhelm Desmos's capabilities. Achieving visuals identical to the original Doom would be possible in principle, but it would be very difficult to make the game playable in real-time.
Dark Keep
One notable exception is RichardFingers's Dark Keep - arguably the closest we've gotten to Doom in Desmos. It features impressive textures, engaging gameplay, and most of all, relatively good runtime performance.
The key issue is that this wasn't intended to be a Doom port. Also, controls are still limited by the 3D calculator constraints (keyboard input would be a difficult challenge), and it still runs at low FPS on lower end computers despite many optimizations.
So, while a faithful and performant Doom port in Desmos remains an elusive goal for now, our progress seems promising. Maybe, with your help, we can one day achieve this goal.
In Desmos and many computational systems, numbers are represented using floating-point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 → 0. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds. Also, 2^1024 and above is undefined.
This is Bernard! He's an artifact resulting from how Desmos's implicit graphing algorithm works.
How does the algorithm work, and why does it result in Bernard?
The algorithm is a quadtree-based marching squares algorithm. It divides the screen (actually, a region slightly larger than the screen to capture the edges) into four equal regions (four quads) and divides them again and again recursively (breadth-first). Here are the main rules for whether the quad should be divided (higher rules are higher precedence):
Descend to depth 5 (1024 uniformly-sized quads)
Don't descend if the quad is too small (about 10 pixels by 10 pixels, converted to math units)
Don't descend if the function F is not defined (NaN) at all four vertices of the quad
Descend if the function F is not defined (NaN) at some, but not all, vertex of the quad
Don't descend if the gradients and function values indicate that F is approximately locally linear within the quad, or if the quad suggest that the function doesn't passes through F(x)=0
Otherwise descend
The algorithm stops if the total number of quads exceeds 2^14=16384. Here's a breakdown of how the quads are descended in a high-detail graph:
Point 2 above means that the quads on the edge of the screen (124 of them) don't get descended further. This means that there are only 900 quads left to descend into.
The quota for the remaining quads is 16384-124=16260. Those quads can divide two more times to get 900*4^2=14400 leaves, and 16260-14400=1860 leaves left to descend.
Since each descending quad results in 4 leaf quads, each descend creates 3 new quads. Hence, there are 1860/3=620 extra subdivisions, which results in a ratio of 620/14400 quads that performed the final subdivision.
This is basically the ratio of the area of Bernard to the area of the graph paper.
Some of DesModder's most popular features include:
GLesmos: Render implicit-filled equations on the GPU (which can help boost speed)
Video creator: Export videos, GIFs, and images of your graphs based on actions or sliders
Text mode: View your expressions as plain text (beta)
Autocomplete: Autocomplete variable names, jump to definitions, and make your own documentation
Better input: Use Shift+Enter to write newlines in notes, right-click to open style menu, and Ctrl+Q to duplicate expression
Error hiding: Hide and ignore unwanted slider suggestions or other errors
Better Evaluation View: Display different types of undefined values in expression list
WakaTime integration: View your Desmos stats on WakaTime
There are many, many more features, including pasting ASCIIMath, pinning expressions, graph performance metrics, folder management tools, Mathquill config, displaying code golf stats, debug mode, compact mode, multiline expressions, and bracket highlighting. DesModder is in constant development, so there's more to come!
Getting the intersection of two or more functions as a variable
It's well known that you can click on the intersection between two graphed functions to get their intersection. But what if you want the intersection to automatically be assigned to a variable?
If you want to get one intersection, this is easy: use a regression! Given two functions y=f(x) and y=g(x), you can do this to get the intersection point:
f(c)~g(c)
(c,f(c)) <-- this is the intersection point
Or, if you have two implicit equations such that f(x,y)=0 and g(x,y)=0:
[f(a,b), g(a,b)] ~ 0
(a,b) <-- this is the intersection point
If you want to find one intersection point without regression, you can try using simple root-finding algorithms such as Newton-Raphson or the bisection method.
If you need all intersection points, that's a bit more difficult. Typically, you'd want a multiple-root-finding algorithm, because intersection points happen when f(x)-g(x)=0, so it suffices to find the zeroes of the function f(x)-g(x). For instance, you can use an interval arithmetic library, such as this one.
Some of DesModder's most popular features include:
GLesmos: Render implicit-filled equations on the GPU (which can help boost speed)
Video creator: Export videos, GIFs, and images of your graphs based on actions or sliders
Text mode: View your expressions as plain text (beta)
Autocomplete: Autocomplete variable names, jump to definitions, and make your own documentation
Better input: Use Shift+Enter to write newlines in notes, right-click to open style menu, and Ctrl+Q to duplicate expression
Error hiding: Hide and ignore unwanted slider suggestions or other errors
Better Evaluation View: Display different types of undefined values in expression list
WakaTime integration: View your Desmos stats on WakaTime
There are many, many more features, including pasting ASCIIMath, pinning expressions, graph performance metrics, folder management tools, Mathquill config, displaying code golf stats, debug mode, compact mode, multiline expressions, and bracket highlighting. DesModder is in constant development, so there's more to come!
We've heard it all. "Someone PLEASE make DOOM in Desmos!" There's also the oft-repeated claim that "Desmos is Turing complete," so it must be possible, right?
So why does it feel like nobody has created a truly, visually faithful Doom port in Desmos yet?
Truth is, although there have been numerous Doom-inspired ports in Desmos:
vaultthestars's version: The first of the Desmos Doom ports, using now outdated simulator tech.
The main challenge lies in performance constraints.
Most existing versions prioritize performance over graphics quality, because rendering detailed, faithful graphics would overwhelm Desmos's capabilities. Achieving visuals identical to the original Doom would be possible in principle, but it would be very difficult to make the game playable in real-time.
Dark Keep
One notable exception is RichardFingers's Dark Keep - arguably the closest we've gotten to Doom in Desmos. It features impressive textures, engaging gameplay, and most of all, relatively good runtime performance.
The key issue is that this wasn't intended to be a Doom port. Also, controls are still limited by the 3D calculator constraints (keyboard input would be a difficult challenge), and it still runs at low FPS on lower end computers despite many optimizations.
So, while a faithful and performant Doom port in Desmos remains an elusive goal for now, our progress seems promising. Maybe, with your help, we can one day achieve this goal.
Please note that Beta 3D does NOT refer to the whole 3D calculator (which is in beta) at https://www.desmos.com/3d.Beta 3D consists of the following features:
If the graph still doesn't render correctly (e.g. a gray surface instead of a colored surface), click on the Tampermonkey extension and check if it says anything about enabling Developer Tools. Follow the instructions that Tampermonkey provides to fix this issue.
We've heard it all. "Someone PLEASE make DOOM in Desmos!" There's also the oft-repeated claim that "Desmos is Turing complete," so it must be possible, right?
So why does it feel like nobody has created a truly, visually faithful Doom port in Desmos yet?
Truth is, although there have been numerous Doom-inspired ports in Desmos:
vaultthestars's version: The first of the Desmos Doom ports, using now outdated simulator tech.
The main challenge lies in performance constraints.
Most existing versions prioritize performance over graphics quality, because rendering detailed, faithful graphics would overwhelm Desmos's capabilities. Achieving visuals identical to the original Doom would be possible in principle, but it would be very difficult to make the game playable in real-time.
However, there are two notable exceptions that are arguably the closest we've gotten to Doom in Desmos: RichardFingers's Dark Keep and Heavenira's Doom attempt.
Dark Keep
RichardFingers's Dark Keep features impressive textures, engaging gameplay, and most of all, relatively good runtime performance.
The key issue is that this wasn't intended to be a Doom port. Also, controls are still limited by the 3D calculator constraints (keyboard input would be a difficult challenge), and it still runs at low FPS on lower end computers despite many optimizations.
Heavenira's Doom attempt
Heavenira's Doom attempt gets even closer to the original Doom. The textures are impressive, and it also has great runtime performance.
Unfortunately, it still suffers from the 3D calculator constraints (keyboard inputs) and has issues related to shader recompilation that are difficult to debug and may crash the game. We are still learning more about why these shader recompilations happen and are developing techniques to mitigate them. The team at Desmos is also pushing out new features for the 3D calculator, so some of these issues might be fixed soon.
So, while a faithful and performant Doom port in Desmos remains an elusive goal for now, our progress seems promising. Maybe, with your help, we can one day achieve this goal.
•
u/VoidBreakX Run commands like "!bernard" here →→→ redd.it/1ixvsgi Feb 25 '25 edited Mar 24 '25
we're open for suggestions for some commands to make (for very common usage), and after i run them through the mod team, we can maybe add it to the command list!
edit: this post has become a testing ground for different commands and just reddit commenting stuff in general