Fixed issue with E not parsing in preview, when using LaTeX

[m-messer]

Problem:
When using handrawing (or LaTeX) and multi-character symbols with E in, would not parse.
This was due to the latex2sympy handling for the symbols not handling the E.

Fix:
The main fixes were in preview_utilities.py.

• Line 40 - 61 - Adjusted regex to handle both E and e replacements, and captured which is replace E or e.
• Line 64 - 74 - Adjusted the post processing stage of the E replacement to replace with the character that was captured during preprocessing
• Line 133 - 144: Added using the pre/post processing of E that we use later in the preview, also for the input symbols
• Line 151 and 152 - Changes to support the character replacement update

Other changes

• preview_tests.py - Added relevant tests
• evaluation_tests.py - Added relevant tests

[peterbjohnson]

Great summary thanks.

For my benefit of understanding, it will be good to explain what happens to multi-character symbols containing, but not beginning with, E.

[m-messer]

Thanks for that idea.

I have updated the preview.

• preview_tests.py - added tests for mutlicharacters with E but not starting withe
• preview_utilities.py - switched the function preprocess_E to return a replaced string and a dictionary of the characters mapped to their placeholders. For example, e will be mapped to b and E will be mapped to c, allowing them to be mapped back to the correct case.

Question:
Currently, the LaTeX parsing for preview does not support the aliases. Is this something we want to support?
(See line 160 in preview_utilities.py, you can see that the only string that is parsed to substitute is the string provided in latex. The commented-out examples of what fails are in the updated test preview_utilities.py.

[peterbjohnson]

On the point of parsing aliases in the preview, I don't totally understand the question, or the code (or the requirements!!). So I'll try and answer but apologies if I'm missing the point:

• In the app, an 'input symbol' has three components: symbol (one), code (one), alternatives (many)
• All three components are strings, with the latter a comma-separated list
• I think in the code and in your comments here, 'aliases' corresponds to 'alternatives' in the app (?)

As a reference, the current behaviour for typed input is desirable:

• If a character is typed that is in the list of alternatives, the preview displays the 'symbol' for that 'input symbol' (not the alternative)
• Example:
  • define symbol $bc$, code bc, and alternatives Bc,bC,BC.
  • Typing in B will preview as $B$, but typing in Bc will preview as $bc$.
  • This is the concept of recognising an alias, but showing the user how it was interpreted, i.e. as the primary symbol for that quantity

The current behaviour for writing is different. We parse inputs to check that they work, but we display the MathPix latex. This is primarily because parsing and re-rendering as LaTeX may introduce errors in the LaTeX preview. Sympy-to-LaTeX is poor in complex cases (LLMs are probably quite good though!).

So currently in writing/draw mode we can't make any changes to the preview LaTeX can we? I think that's the answer to your question?

In terms of requirements, we could/should revisit this, as it would be good to augment the preview. Augmenting in the short term would be as the example above; but in the long term we can do a lot more e.g.:

• Input: bcd, input symbols as above
• Preview: $bc \cdot d$, where $bc$ is the energy and $d$ is the velocity [meaningless physics, just an example; note the elaborate string that was generated to give richer feedback]

[m-messer]

Thanks Peter.

Yes in the code aliases are the alternatives in the app.

Currently, these alternatives are not being used in the LaTeX preview. I'll add them to the backlog and merge these changes.