asciidoctor / asciimath

Asciimath parser
MIT License
24 stars 16 forks source link

Avoid using \left and \right in the LaTeX output whenever possible #28

Closed GarkGarcia closed 4 years ago

GarkGarcia commented 4 years ago

A follow up to #25. As stated by @davidfarmer:

Writing f\left( x \right) in latex does not look good. If you compare that to f(x) you will see that the version with the right and left has too much space after the "f". (It seems tricky to decide when the object in parentheses is large, so that the left and right are needed. I'm interested to hear if you have a way to deal with that.)

I mostly agree. This is definitively a thing we could improve. We'll just have to establish a set of rules to decide weather or not \left and \rightshould be used.

There are at least some cases where you don't need the left and right around function arguments: one character, multiple characters with only +, -, and multiplication between them. Not obvious to me if the default should be to have left and right, or the default should be to no have those.

This is definitively a case we're \left and \right could be avoided. I personally think it's easier to think about this in terms of when should \left and \right be avoided instead of when should \left and \right be used. So yes, \left and \right should be the default.

@davidfarmer Would the case mentioned above be sufficient for you?

davidfarmer commented 4 years ago

I personally don't think there should be a left and right in g(x^2). There are two reasons. First, the space after the g still looks bad, and the x^2 argument is not that large. Second, if you have f(x)g(x^2) then the left and right in the second function makes the two sets of parentheses different size, which is not good.

Similarly for f(x_j) .

So, I would avoid the left and right in more cases.

On Sun, 3 May 2020, Gark Garcia wrote:

A follow up to #25. As stated by @davidfarmer:

  Writing f\left( x \right) in latex does not look good. If you compare that to f(x)
  you will see that the version with the right and left has too much space after the "f".
  (It seems tricky to decide when the object in parentheses is large,
  so that the left and right are needed. I'm interested to hear if you have
  a way to deal with that.)

I mostly agree. This is definitively a thing we could improve. We'll just have to establish a set of rules to decide weather or not \left and \rightshould be used.

  There are at least some cases where you don't need the left and right around
  function arguments: one character, multiple characters with only +, -, and multiplication
  between them. Not obvious to me if the default should
  be to have left and right, or the default should be to no have those.

This is definitively a case we're \left and \right could be avoided. I personally think it's easier to think about this in terms of when should \left and \right be avoided instead of when should \left and \right be used. So yes, \left and \right should be the default.

@davidfarmer Would the case mentioned above be sufficient for you?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, orunsubscribe.[AABTULB7SQFUNMNQX5WURVLRPWUKVA5CNFSM4MYG7FE2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NF SM4JDSHZEA.gif]

GarkGarcia commented 4 years ago

I personally don't think there should be a left and right in g(x^2)

I agree, \left and \right are not necessary in this case. We could include this in the should we avoid using \left and \right bag. We could use a criterion similar to the one described in #27.

Second, if you have f(x)g(x^2) then the left and right in the second function makes the two sets of parentheses different size, which is not good.

I see. I think this wouldn't be an issue if we were to omit \leftand right in the expression x^2, would it?

davidfarmer commented 4 years ago
  Second, if you have f(x)g(x^2) then the left and right in the second function makes the two
  sets of parentheses different size, which is not good.

I see. I think this wouldn't be an issue if we were to omit \leftand right in the expression x^2, would it?

Correct. I was just giving multiple reasons for not using left and right for g(x^2).

GarkGarcia commented 4 years ago

Second, if you have f(x)g(x^2) then the left and right in the second function makes the two sets of parentheses different size, which is not good. I see. I think this wouldn't be an issue if we were to omit \leftand right in the expression x^2, would it? Correct. I was just giving multiple reasons for not using left and right for g(x^2).

Makes sense. I'll start working on this as soon as #27 is closed.

GarkGarcia commented 4 years ago

I think I'll wait for the conclusion of #30 to start working on this.

GarkGarcia commented 4 years ago

@davidfarmer As previously discussed, I belive the question of whether or not we should output \leftand \right is a question of whether or not we can prove that and expression doesn't need \left and \right.

I came up with the following recursive predicate:

Let s be an AsciiMath expression and P be a predicate that determines whether or not s is "small". Then:

  • If s is a single character or digit, P(s) holds.
  • If s = a + b, where P(a) and P(b) hold, P(s) holds.
  • If s = a - b, where P(a) and P(b) hold, P(s) holds.
  • If s = a * b, where P(a) and P(b) hold, P(s) holds.
  • If s = a_b, where a is whether a single character, a single digit or an expression of the form c + d - where P(c) and P(d) hold - and b is a single character or digit, then P(s) holds.
  • If s = a_b, where a is whether a single character, a single digit or an expression of the form c + d - where P(c) and P(d) hold - and b is a single character or digit, then P(s) holds.
  • If s = a_b^c, where a is whether a single character, a single digit or an expression of the form d + e - where P(d) and P(e) hold - and b and c are single characters or digits, then P(s) holds.
  • Otherwise, P(s) does not hold.

What do you think?

GarkGarcia commented 4 years ago

Of course there might be cases where s is "small" and P(s) does not hold, but those cases would be difficult to prove.

GarkGarcia commented 4 years ago

We could also include some standard AsciiMath operator, such as hat and vec.

GarkGarcia commented 4 years ago

Also, if we consider the expression s1(s2), I don't believe knowing whether or not s1 is a function application or simply the result of an implicit multiplication would impact the LaTeX output.

For example, the expression f(a/b) needs \left and \right, despite the fact that f represent a function application.

@davidfarmer Do you agree?

davidfarmer commented 4 years ago

The issue of \left and \right is more subtle than I originally indicated. In some sense, this is a design flaw in LaTeX: when you put the \left and \right, it typesets it as if it was implied multiplication. You have to do a bunch of extra markup (which I am having difficulty locating right now) to get big parentheses without extra space.

With perfect markup, there is a small space to indicate implied multiplication and no space for function application. Math usually does not use two-letter variables, but ideally the two-letter variable xy looks different than x times y where the multiplication is implied. But it is less than a full space.

I think I answered your question, but please clarify if I did not.

On Wed, 6 May 2020, Gark Garcia wrote:

Also, if we consider the expression s1(s2), I don't believe knowing whether or not s1 is a function application or simply the result of an implicit multiplication would impact the LaTeX output. @davidfarmer Do you agree?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, orunsubscribe.[AABTULBLQJNXHS4JQJAJ4WDRQHK27A5CNFSM4MYG7FE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5 WW2ZLOORPWSZGOEU7VIEA.gif]

GarkGarcia commented 4 years ago

In some sense, this is a design flaw in LaTeX

Indeed, and it's a mistake that could be easily fixed (by not inserting a space at the start of the \left macro).

The issue of \left and \right is more subtle than I originally indicated.

I agree. There are a lot of edge cases.

You have to do a bunch of extra markup (which I am having difficulty locating right now) to get big parentheses without extra space.

This is an issue. Keep in mind we want to output human-readable LaTeX code, so using low-level TeX hacks is out of picture.

I think I answered your question, but please clarify if I did not.

I'm not sure. I didn't quite understand if you approve the predicate I proposed or not.

GarkGarcia commented 4 years ago

This is an issue. Keep in mind we want to output human-readable LaTeX code, so using low-level TeX hacks is out of picture.

If, by any change, amsmath exposes a macro that deals with parenthesis in the appropriate way, we could simply use it.

davidfarmer commented 4 years ago

Your description of what is "small" does not include e^{x + 1}, but that should be considered small.

Maybe something like:
all single characters and digits are "very small". If a and b are very small, then so is a+b, a-b, and a*b. If a, b and c are very small then the following things are small: a_b, a^c, and a_b^c. If a and b are small, then so is a+b, a-b, and a*b. Don't use \left and \right on things that are small or very small.

GarkGarcia commented 4 years ago

Your description of what is "small" does not include e^{x + 1}, but that should be considered small.

Maybe something like: all single characters and digits are "very small". If a and b are very small, then so is a+b, a-b, and a*b. If a, b and c are very small then the following things are small: a_b, a^c, and a_b^c. If a and b are small, then so is a+b, a-b, and a*b. Don't use \left and \right on things that are small or very small.

Makes sense to me. I'll start working on the implementation.

davidfarmer commented 4 years ago

You can either output human-readable LaTeX, or you can output LaTeX that correctly puts no space after the "f" in f\left(whatever\right) . There is a design flaw in TeX, or an error in how left and right are implemented, that messes up that spacing.

Basically, TeX does not have a natural way to distinguish between implied multiplication and function application (as well as numerous other shortcomings: basically every time you have to type \! or \,). That is because TeX is a typesetting language, not a markup language for mathematical content. That is an important distinction, and I do not mean to imply that there is something wrong with TeX: its just not the tool most of us need for authoring mathematics. That is why I started working on Space Math (for which I am putting together more details).

A possibility is a second version of LaTeX output, which no human is supposed to see or edit, to be used for final production.

GarkGarcia commented 4 years ago

You can either output human-readable LaTeX, or you can output LaTeX that correctly puts no space after the "f" in f\left(whatever\right) . There is a design flaw in TeX, or an error in how left and right are implemented, that messes up that spacing.

As you've just pointed out, we could output a \! between f and \left <whatever>. I believe the MathML render already does something similar with &FunctionApplication (or something like that).

It would be simply an issue of disambiguating between implicit multiplication and function application, which is another topic we've been discussing.

For now, I'll close this issue, since the unnecessary \left and \right thing was fixed in #36.

GarkGarcia commented 4 years ago

That is because TeX is a typesetting language, not a markup language for mathematical content. That is an important distinction, and I do not mean to imply that there is something wrong with TeX: its just not the tool most of us need for authoring mathematics. That is why I started working on Space Math (for which I am putting together more details).

Interesting. I've never though about it in this way. Makes a lot of sense to me, looks like a good explanation for many of the shortcomings of LaTeX.

A possibility is a second version of LaTeX output, which no human is supposed to see or edit, to be used for final production.

It's another possibility too. As of now, I don't think we've encountered an issue that couldn't be resolved with human-readable code, but it'd certainly be a nice addition.

GarkGarcia commented 4 years ago

for which I am putting together more details

Cool! I long for those details.