-
Notifications
You must be signed in to change notification settings - Fork 391
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback From a User #173
Comments
Hi @Liskelleo , thanks for reporting many suggestions! As several features you suggested is already supported in the
It is possible to increase the number of examples. Showing "all" formulas is somewhat unable because it is essentially equal to representing the all rules in this library in another format. I think it is feasible to add only examples of supported functions, operators, and some special functionalities.
Yes. The objective of this library is to show the given Python snippet as a "formula", and the inner behavior is strictly depending on the Python's syntax. Supporting all math is not the scope of this library at this point. I think it should be another project as it eventually requires us to develop another language. Replies for enumerated questions (according to the newest implementation):
Tracked by #142 where we are discussing about supporting (only) definite integrals.
Supported by #143
These forms require discussion. Specifically, we need to handle several ambiguity (e.g., is
These operators can't be basically expressed in Python without extra syntax and/or other library support.
Could you provide what is the desired output of
Good catch, we could support this syntax as an option.
|
@odashi Thank you for your reply^^
Personally, I think this should be judged according to the brackets in user's expression. For example,
This is correct, and what I found later is that differential (derivative), integral and limit can be calculated in SymPy library and converted to latex expression to display. Even the functions of the matrices can be found in the SymPy library.
For this question, I think that the required output of sqrt(sum(x**2 for x in coordinates)) should be
I don't think we can distinguish superscript from power here. Consider that some special superscripts are not used for calculation, but just a sign, such as x' or x*. Even
Sorry, I remember wrong, but there is an "angle ()" method in NumPy. In fact, I want to propose ideas on how to switch radians and angles through this point. Generally, the radian system is used as the default setting, but what if the user want to enter an angle? P.S.: Have you considered using a universal parameter to access most or all of the functions? In this way, the formula editor I am completing can be operated in an integrated way, instead of adjusting the parameter as needed. |
We couldn't express this in Python because this is out of the correct syntax. As I commented above, this library doesn't aim to introduce any additional syntax on the level of the Python interpreter.
SymPy is a library that constructs their own syntax object on Python, and it requires executing the code to construct the syntax tree. Latexify is a library that converts the existing Python code to a corresponding expression, and there is a difference of the supported domains between these libraries. Latexify can also provide some functionality to parse SymPy objects as a plugin, but it requires a bunch of development IMO.
It doesn't fully make sense to me, could you provide some examples?
This is not a correct representation of the original expression.
It looks (if we provide some support) |
It's weird that the library can convert "f=x[ab]" to "\mathrm{f} = {x_{ab}}" but "x[ab]" is out of the correct syntax in Python and because so it cannot appear in function name but only in the expression of the function. So why not let "(x_y)_bar" or "x[y]_bar" exist in the expression? |
|
More specifically:
|
This is still ambiguous as it can be interpreted as both In the newest implementation of this library, we removed automatic subscripting too for the same reason. Now every identifier is converted to either:
and the library doesn't have any other intelligent behavior anymore. We already have a functionality of substituting identifiers into another identifier before processing the codegen. I thought it is better to implement a similar functionality that replaces the specified identifiers with the final LaTeX.
I don't plan to provide a way to write user-defined superscripts for the same reason. Btw, we are also discussing to introduce the capability of plugins in #165 . Although we haven't determined any designs yet, this feature may introduce an ability to apply user-defined conversion rules. I guessed most features in this thread could be implemented as such, but it is not desirable to introduce them as the default behavior of this library. |
How come? Can you explain it? |
Ah sorry, your explanation above covers all cases if there are only 2 variables in the same identifier. At a glance there's no ambiguity, but there are 2 essential points:
|
Actually, x_{y_z} can be written as "x_y_z" and x_\bar{y_z} can be written as "x__y_z__bar", where "__bar" could be interpreted as a header of the whole part behind the last symbol "__" that parser recognize. P.S.: Is this a new "grammar"? To be honest, I'd rather think this is more like a rule of the definition of some formular identifiers in this library instead of a "new syntax", because people use it only when they use this library and this so called "rule" (as from my perspective) can actually be recognized by parser. Unlike the "[ ]-grammar of the subscript", this so called "rule" doesn't need any other rules to convert this to the LaTeX syntax and don't raise any error when being interpreted individually. What do you think of the things above? Btw, it's interesting for me to think about all these things. Thank for answering patiently. |
Anyway, I think that compared to the subscript, the superscript is harder to be expressed as an identifier within the scope of correct python syntax because python legal identifiers include only alphanumeric or underscores, which means we should actually introduce a new syntax by default to convert superscript to LaTeX code. But in order to express subscript correctly, we may just make a rule about the underscores like above. @odashi |
As I noted above, we wouldn't introduce any other default rules than I mentioned in #173 (comment) , and we already avoided even subscripting from the newest implementation (except the syntax of indexing). This is because (1) users eventually need to learn about unnecessary knowledge to use this library, and (2) it doesn't work with existing code. The current implementation aims to convert every function into LaTeX through It is more suitable to introduce such functionality as an optional plugin. If you are interested in implementing such mechanism, feel free to fork this library and try to make a pull request. |
Alright then. Thank you. |
Hello author, I am a sophomore and I have made a simple formula editor based on your library. I'm not major in computer science, so I only have some ideas and cannot put these thoughts into practice. I think that version 0.2.0 of this library has a great improvement over the previous versions, but I think there are still something need to be improved. The following items are feedback based on my experience as a user and I wish you will take them into consideration.
1 The inability to convert integral expressions
2 The inability to display matrices
3 The inability to display some special types of letters (such as x_hat, x_tilde, x_bar, etc.)
4 The inability to display some special symbols (such as mod, Hamiltonian operator, partial differential operator, etc.)
5 Some strange output (pictured), where the "∈" symbol does not conform to the specification
6 Only the power form can be written, not the superscript (what if I want to write this symbol: "$x^{b}$")
7 It is unable to display the n-th root sign, maybe we can let "$\sqrt[n]{x}$" be represented as "pow(x, 1/n)"
8 Why not add expressions in "math" library to this library, like "exp()", "angle()", "log(m, n)", etc., which can make it more functional?
P.S. Can you provide a complete user manual, showing all formulas available in the current version? I think there are too few examples provided in documents on GitHub.
From my perspective, the difficulty lies in how to enable the input expression to be executed by Python on the one hand and displayed correctly on the other (I mean successfully converted to LaTex formular).
I have seen some of the above points in the issue section, and the above points are the main ones I want to mention.
Best wishes and marry Christmas^^
The text was updated successfully, but these errors were encountered: