Open stefnotch opened 3 years ago
Those are excellent test cases, thank you!
x_{1,2}
is a particularly interesting one: the comma is a valid inter-digit separator (as in "1,234.56") but of course I should be a bit more rigorous when considering it as a digit separator. Still, I suppose that x_{123,456}
would be ambiguous... Hmmm..
That's true, that makes this test case surprisingly tricky. It doesn't help that countries and standards can't agree on which decimal separator to use https://en.wikipedia.org/wiki/Decimal_separator (My preferred one is grouping digits into groups of 3. Simple spacing rules and no funky, ambiguous extra characters.)
For what it's worth, I personally have never seen a ,
decimal separator in a mathematical equation. However, it does appear somewhat frequently in tables of numbers and other cases where it's mostly just a number.
Another interesting thing that I just found out is that by default, a comma has a small space after it.
Yes, it's considered a punctuation character and so has a small padding on its right.
Note also that you can configure which character (or rather which LaTeX command sequence) is used with the groupSeparator
option.
That said, some people have very strong opinions about this: http://wordpress.mrreid.org/2014/05/27/stop-putting-commas-in-your-numbers/
Maybe I should reconsider the default value for groupSeparator
... :)
Oh nice, I didn't know that there was configuration option for that :)
I like the idea of changing the default value for groupSeparator
, but it doesn't matter very much to me either way.
I found another case where the compute-engine doesn't quite work: Logarithms.
For example \begin{equation*} \log_3(7) \end{equation*}
gets parsed as
[
"Multiply",
["Subscript", "\\log", 3],
["Parentheses",
{num: "7"}]
]
@phcreery
I went through some mathematics notes and found the following interesting equations. I tested them on the compute engine demo page https://cortexjs.io/compute-engine/demo/
(Information for myself: Page 1 of ANA_UE_SS_21_Mo_1.pdf , meaning there are a few more testcases)
[x]
\begin{equation*} N(\varepsilon)\coloneq\lceil\frac{4}{\varepsilon^2}\rceil \end{equation*}
turns into"" syntax-error
[x]
\begin{equation*} x_{1,2}=1,2 \end{equation*}
turns into["Equal", ["Subscript", "x", {num: "12"}], {num: "12"}]
. Notice how the comma is missing[x]
\begin{equation*} \{1,2\} \end{equation*}
turns into["Multiply", "\\{", {num: "12"}, "\\}"]
. I assume this happens because sets haven't been implemented yet[x]
\begin{equation*} [1,2] \end{equation*}
turns into"" syntax-error
. I assume this happens because vectors/matrices and the like haven't been implemented yet.\begin{equation*} \frac{2}{\sqrt{n}}\Leftrightarrow n>\frac{5}{n^2} \end{equation*}
turns into the following, notice how\\Leftrightarrow
doesn't have a special meaning and its precedence is off[x]
\begin{equation*} |a_n|\le\frac{2}{\sqrt{n}}\Rightarrow a_n\to0=0 \end{equation*}
turns into the following, notice how\\Rightarrow
doesn't have a special meaning (implies) and its precedence is off.[x]
\begin{equation*} 3\equiv5\mod7 \end{equation*}
or also\begin{equation*} 3\equiv 5 (\mod 7) \end{equation*}
This is a congruence relation. I assume this is simply something that hasn't been implemented yet. Hopefully it's a good test case for round-tripping[ ]
\begin{equation*} a={\displaystyle \lim_{n\to\infin}a_n} \end{equation*}
turns into[ ]
\begin{equation*} \forall x\in\C^2:|x|<0 \end{equation*}
turns into the following[ ]
\begin{equation*} \forall n\colon a_n\le c_n\le b_n\implies\lim_{n\to\infin}c_n=a \end{equation*}
turns into the following, note how a few operators aren't parsed and how the precedences for other operators are slightly off. I think the correct order of operations in this case would start at the:
, then the=>
and then the normal rules. Another interesting tidbit here are the two<=
signs. While a comparison would usually return a boolean value (true/false), here the comparisons are more like a range. The expression is a part of the squeeze theorem.