3 ms·

FWIW, comparing my experiences with several different "graphical equation editors" (fundamentally a flavor of tree-editor) versus editing LaTeX code directly, t

by al2o3cr 10y ago

FWIW, comparing my experiences with several different "graphical equation editors" (fundamentally a flavor of tree-editor) versus editing LaTeX code directly, the tree editor loses every time. Yes, the tree editor is capable of providing an amazingly efficient interface for modifying parts of an existing expression - but when you start restructuring the whole expression things get messy fast. The plain code method is a bit rougher to read / enter in simple cases, but since it's just text in a text editor it doesn't have the same complexity escalation when doing unusual reorganizations.

jessriedel 10y ago
This sounds like something that can only be true for equations below some size. If you're trying to manipulate a sufficiently large equation, it has to be automated, so directly editing text is bound to lose (however clunky the automated method may be). So maybe your experience is just that equations rarely get large enough to make it worth it to use a graphical editor? For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? Even if one only needs to use one or two functions with a very obvious tree interpretation (e.g., distributing multiplication over addition), Mathematica beats TeX for large enough equations. What graphical equation editors have you used? This was what turned up when I searched google: http://equalx.sourceforge.net http://equalx.sourceforge.net
- leni536 10y ago
  I regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines. \begin{equation} H_n(i) = \begin{cases} \left( H_{n-1}(i)_2, H_{n-1}(i)_1 \right) & 0 \le i < 2^{2(n-1)} \\ \left( H_{n-1}(i-2^{2(n-1)})_1, H_{n-1}(i-2^{2(n-1)})_2 + 2^{n-1} \right) & 2^{2(n-1)} \le i < 2 \cdot 2^{2(n-1)} \\ \left( H_{n-1}(i-2\cdot2^{2(n-1)})_1 + 2^{n-1}, H_{n-1}(i-2\cdot2^{2(n-1)})_2 + 2^{n-1} \right) & 2 \cdot 2^{2(n-1)} \le i < 3 \cdot 2^{2(n-1)} \\ \left( - H_{n-1}(i-3\cdot2^{2(n-1)})_2 + 2^{n}-1, - H_{n-1}(i-3\cdot2^{2(n-1)})_1 + 2^{n-1}-1 \right) & 3 \cdot 2^{2(n-1)} \le i < 4 \cdot 2^{2(n-1)} \\ \end{cases} \end{equation} > For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? I use Mathematica, and I just use the plaintext Mathematica syntax for large equations too. I also break these into multiple lines.
  - jessriedel 10y ago
    > regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines. I understand how to indent TeX, but when you have a hundred algebraic terms it's very unwieldly, and Mathematica becomes clearly superior (for me) just to visualize it. Anyways, it sounds like you're just saying you haven't found the graphical visualization for equation trees to be useful, so you stick with the linear representation, but the manipulations of those trees (by mathematica, or some other dedicated editor) is still useful. In this case I would add that we would probably still need some sort of visualization aid for sufficiently large equations, and that the tools are just not good right now. After all, much/most code is written in normal (linear) text editors, but some people still do find it useful to "collapse" sections of code, corresponding to branches of the tree structure induced by indentation. Many people don't bother with this right now because it can cause headaches that simple scrolling does not, but better tools may change this.
m_mueller 10y ago
But is this due to text being the most efficient way of editing or are our tools simply inadequate? Let's imagine a world that has standardized on certain UIs - just like TextMate/sublime style hotkeys are common in graphical editors, let's say we had iWorks[1] style table editing hotkeys everywhere and a TBD standard for tree operations that you could learn once and then apply everywhere. Basically you need 'sibling', 'union' and 'splice', right? That really wouldn't be more difficult than text operations IMO. I could see this for all sorts of purposes, starting with a standard configuration GUI for json / xml config files. [1] because damnit these are still the only sane and consistent table hotkeys.
- TeMPOraL 10y ago
  Based on Paredit keybindings, I don't think 'sibling', 'union' and 'splice' would be enough for convenient editing; you'd at least need a set of keys to move nodes (with their subtrees) around.
  - m_mueller 10y ago
    I'm thinking it would if you also had good selection keybindings. click on node -> select-family -> command-x (family gets highlighted similar to Excel) -> select target node -> use sibling or append-child (implicitely moves the family in the clipboard) The only other special move you need is a switch-position between siblings. for the insert actions it would be best to have next-sibling and previous-sibling (alt-arrow left/right like iWorks tables?) and last/first child.

by al2o3cr 10y ago

jessriedel 10y ago

This sounds like something that can only be true for equations below some size. If you're trying to manipulate a sufficiently large equation, it has to be automated, so directly editing text is bound to lose (however clunky the automated method may be). So maybe your experience is just that equations rarely get large enough to make it worth it to use a graphical editor? For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? Even if one only needs to use one or two functions with a very obvious tree interpretation (e.g., distributing multiplication over addition), Mathematica beats TeX for large enough equations. What graphical equation editors have you used? This was what turned up when I searched google: http://equalx.sourceforge.net http://equalx.sourceforge.net

leni536 10y ago
I regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines. \begin{equation} H_n(i) = \begin{cases} \left( H_{n-1}(i)_2, H_{n-1}(i)_1 \right) & 0 \le i < 2^{2(n-1)} \\ \left( H_{n-1}(i-2^{2(n-1)})_1, H_{n-1}(i-2^{2(n-1)})_2 + 2^{n-1} \right) & 2^{2(n-1)} \le i < 2 \cdot 2^{2(n-1)} \\ \left( H_{n-1}(i-2\cdot2^{2(n-1)})_1 + 2^{n-1}, H_{n-1}(i-2\cdot2^{2(n-1)})_2 + 2^{n-1} \right) & 2 \cdot 2^{2(n-1)} \le i < 3 \cdot 2^{2(n-1)} \\ \left( - H_{n-1}(i-3\cdot2^{2(n-1)})_2 + 2^{n}-1, - H_{n-1}(i-3\cdot2^{2(n-1)})_1 + 2^{n-1}-1 \right) & 3 \cdot 2^{2(n-1)} \le i < 4 \cdot 2^{2(n-1)} \\ \end{cases} \end{equation} > For instance, doesn't the fact that people do pure algebra with Mathematica (forgetting about all the numerics, integrals, etc.) demonstrate that TeX loses for sufficiently large equations? I use Mathematica, and I just use the plaintext Mathematica syntax for large equations too. I also break these into multiple lines.
- jessriedel 10y ago
  > regularly edit large equations in LaTeX. I don't see how it's not manageable, just break your equations into multiple lines. I understand how to indent TeX, but when you have a hundred algebraic terms it's very unwieldly, and Mathematica becomes clearly superior (for me) just to visualize it. Anyways, it sounds like you're just saying you haven't found the graphical visualization for equation trees to be useful, so you stick with the linear representation, but the manipulations of those trees (by mathematica, or some other dedicated editor) is still useful. In this case I would add that we would probably still need some sort of visualization aid for sufficiently large equations, and that the tools are just not good right now. After all, much/most code is written in normal (linear) text editors, but some people still do find it useful to "collapse" sections of code, corresponding to branches of the tree structure induced by indentation. Many people don't bother with this right now because it can cause headaches that simple scrolling does not, but better tools may change this.

m_mueller 10y ago

But is this due to text being the most efficient way of editing or are our tools simply inadequate? Let's imagine a world that has standardized on certain UIs - just like TextMate/sublime style hotkeys are common in graphical editors, let's say we had iWorks[1] style table editing hotkeys everywhere and a TBD standard for tree operations that you could learn once and then apply everywhere. Basically you need 'sibling', 'union' and 'splice', right? That really wouldn't be more difficult than text operations IMO. I could see this for all sorts of purposes, starting with a standard configuration GUI for json / xml config files. [1] because damnit these are still the only sane and consistent table hotkeys.

TeMPOraL 10y ago
Based on Paredit keybindings, I don't think 'sibling', 'union' and 'splice' would be enough for convenient editing; you'd at least need a set of keys to move nodes (with their subtrees) around.
- m_mueller 10y ago
  I'm thinking it would if you also had good selection keybindings. click on node -> select-family -> command-x (family gets highlighted similar to Excel) -> select target node -> use sibling or append-child (implicitely moves the family in the clipboard) The only other special move you need is a switch-position between siblings. for the insert actions it would be best to have next-sibling and previous-sibling (alt-arrow left/right like iWorks tables?) and last/first child.