search

josdejong / mathjs

An extensive math library for JavaScript and Node.js
https://mathjs.org
Apache License 2.0
14.32k stars 1.24k forks source link

Restructuring util/latex.js #307

Closed FSMaxB closed 8 years ago

FSMaxB commented 9 years ago

I've started restructuring util/latex.js (https://github.com/FSMaxB/mathjs/tree/latex-restructure-prototype).

Things I'm doing:

It's kind of a hard process to decide how to present something in LaTeX because I have to decide on a particular notation.

There is one fundamental question remaining right now:

Maybe I can get rid of util/latex.js entirely.

Lakedaemon commented 9 years ago

On 03/23/2015 08:36 AM, Max Bruckner wrote:

I've started restructuring |util/latex.js|.

Things I'm doing:

  • remove dependencies on nodes ( done )
  • Write tests for every single function ( in progress )
  • Remove unnecessarily complex stuff ( mostly done )
  • Implement the LaTeX generation of functions ( for FunctionNodes ) as callback functions so they can be moved to the definition of the respective function in v2. (done)
  • Define LaTeX output for stuff that has been missing (in progress) o the more uncommon operators for example o also many of the functions

It's kind of a hard process to decide how to present something in LaTeX because I have to decide on a particular notation.

There is one fundamental question remaining right now:

  • How should I LaTeX a function that represents an operator? Like 'add' for example. o |\mathrm{add}\left({a},{b}\right)| o or |\left({a}+{b}\right)| (the parenthesis is necessary because I don't have any information about precedence in that case (not for now at least ) )

in my opinion, you have 2 choices : 1) a dumb, fast, safe, ugly implementation where you put parenthesis everywhere

2) a smart, slower, beautiful, hard to get right implementation where you only put parenthesis where they are needed (needs traversing the whole tree to decide that)

have sane defaults (in english) fro the operators The user, depending their national way of writing maths, will want to override them anyway

(In france, we use ch instead of cosh, arctan instead of atan...)

*

— Reply to this email directly or view it on GitHub https://github.com/josdejong/mathjs/issues/307.

FSMaxB commented 9 years ago

I already did the 'smart, slower, beautiful' implementation for OperatorNodes but that doesn't work for functions at the moment ( but it's possible to do this in the future, hence the "not for now at least" ). My question is of a fundamental nature. Should a function that represents an operator ( but a FunctionNode was used, not an OperatorNode) be texified as function call or in operator notation? I tend to the latter.

Lakedaemon commented 9 years ago

The latter is harder. If you do the first, isn't there a way to get both working at the same time ?

Say you export to \add{a}{b} and eventually overload this later with different implementations like \def\add#1#2{a+b} (with eventuall check for parenthesis)

In the kotlin language, they parse the user input and then turns it into add(), mult(), sub() calls that are overridable. It adds much flexibility to the language. Isn't a similar approach possible there ?

It also depends on what you want to achieve : 1) (output) you only want to display equations for humans 2) (input, idempotence) you want to be able to parse TeX back to the same node tree (might be easier with the function calls) 3) flexibility, extensibility...

FSMaxB commented 9 years ago

Your comments aren't helpful!

The primary purpose of mathjs' LaTeX export feature is to be able to display expressions with something like MathJaX. Being able to parse back LaTeX is utopic and isn't a goal right now, not even remotely. Flexibility and extensibility is already covered in my last pull request enabling you to pass custom handlers for toTex.

Also getting both at the same time doesn't answer my question, because one of them has to be the default --> same problem. Also the latter isn't harder because getting the parenthesis right isn't that important for now, there's OperatorNodes for that (this doesn't mean that they aren't right mathematically, but more than necessary).

Lakedaemon commented 9 years ago

I'll gladly acknowledge that my comments aren't helpfull.

Now, I hope I won't make you angry, this isn't the point. At this time, if I'm not wrong understand math.js has some transformations : math.js string expression -> math.js node tree (with the parser) math.js node tree -> math.js string expression (with toString)

math.js node tree -> TeX string (thanks for that, this is one of the features that made me chose math.js to implement one app)

Now, I understand that parsing a subset of TeX is not a goal right now or even remotely (also, it isn't utopic as mathJax manages it quite well and might be used for this purpose). That doesn't mean that it shouldn't considered as a possible features in a far away future. There are a few interesting things that could be done with that : 1) Checking that the toTeX functions are working correctly (testing, round trip) 2) input from users that are proficient with TeX but not with math.js expressions 3) automatic parsing of TeX snipets into math.js node tree 4) who knows...

I have started implementing an android app that displays math with MathJax and that handles math with math.js. At one point, I will want to let the user interact with math.js node trees graphically in a WebView. That might mean that I will have to convert mathJax/mathml/html/svg/TeX code back to math.js node tree at one point (I'm not sure, I have not started implementing that part yet, so there might be better/simpler ways to do it)

But as you said, for now, the toTeX functions are mostly for displaying things. The trouble with TeX being that it is a layout/display language, with an emphasis on letting the user choose exactly how he wants it, and that there are gazillons ways to display the same math expression.

It's also quite subjective to decide what way is more appropriate / visually pleasing.

Now, in my opinion (for display purposes) \mathrm{add}\left({a},{b}\right) == ugly

\left({a}+{b}\right) == better (it would be even nicer if the unneeded {} were removed (or at least all but one))

Also, please, pretty please : if possible export to TeX and not to LaTeX export to TeX = code that can be used (out of the box) by TeX users, LaTeX users and Context users export to LaTeX = code that can only be used by LaTeX users

FSMaxB commented 9 years ago

I'm new to mathjs myself, I started contributing one or two months ago. I was looking at toTex and it was in an almost unusable state, to the point where it produced mathematically incorrect output. For now I'm just trying to clean up the code and make this feature actually useful, because it isn't too useful right now in my opinion.

I understand the usefulness of your suggestions, but it's utopic in the context of what I'm attempting to do here. What you're suggesting requires deep changes to the expression parser, so this is something you should suggest in a different Github-Issue so Jos de Jong can tell you if this is something he wants to do in the near future.

Lakedaemon commented 9 years ago

Well. I agree with you (sorry to have abused this thread :/). I had also noticed that the toTeX function was broken (and reported it) but I didn't have the time and the skills to fix it ,(I'm not a javascript developer). I'm really glad and very grateful that you did.

josdejong commented 9 years ago

@FSMaxB Sounds good, thanks beforehand!

How should I LaTeX a function that represents an operator?

I think it's good when toTex "normalizes" and cleans up the user's input (like removing unnecessary parentheses). It's all about trying to represent the users intent as good as possible in the maths language. Operations like add, sum, permutations, etc. have a special notation in maths (+, ∑, etc). I think it's best to respect these as much as possible. So I agree with you that it would be nicest to replace functions like add with their maths operator.

For the implementation it may be easiest when you detect such a case, to temporarily instantiate an OperatorNode for this, which can take care of adding parentheses or not (utilizing the work you did last weeks :) ).

It's perfectly fine with me when the util/latex.js file becomes completely redundant. Maybe it could still serve as a central place where you list all known operators/functions/symbols, and could easily add new ones or override some if you want it different. But I think all logic will move to the nodes.

@Lakedaemon thanks for your input. Parsing TeX expressions is indeed not an goal of math.js right now, but you can put this as a new feature request. It would be awesome, but isn't trivial to implement. There may be parsers out there to parse Tex into JSON or something, if that's the case we could utilize that. Can you open a separate issue for this?

FSMaxB commented 9 years ago

@Lakedaemon I'm sorry for being rude to you. It wasn't my intention to scare you off xD. But it seems like the misunderstanding is solved.

Lakedaemon commented 9 years ago

No worries. No harm here. ^^ Besides, You were right and professionnal about it. :) Just keep up the good work ! :)

josdejong commented 9 years ago

@FSMaxB I think we can close this issue, right?

FSMaxB commented 9 years ago

I'm still not statisfied with the way that the LaTeX output for FunctionNodes is created (LaTeX output in operator notation doesn't respect the parenthesis settings and is still ugly. Also some notations aren't perfect).

I don't have the time right now to work on this but it's not done.

josdejong commented 9 years ago

Ok let's keep the issue open, thanks for your devotion :)

josdejong commented 8 years ago

@FSMaxB do you still want to keep this issue open or shall we close it?

FSMaxB commented 8 years ago

It's unrealistic that I will find the time to do this. So let's close it.