Closed GarkGarcia closed 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]
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 \left
and right
in the expression x^2
, would it?
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).
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.
I think I'll wait for the conclusion of #30 to start working on this.
@davidfarmer As previously discussed, I belive the question of whether or not we should output \left
and \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?
Of course there might be cases where s is "small" and P(s) does not hold, but those cases would be difficult to prove.
We could also include some standard AsciiMath operator, such as hat
and vec
.
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?
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]
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.
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.
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.
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, anda*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.
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.
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.
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.
for which I am putting together more details
Cool! I long for those details.
A follow up to #25. As stated by @davidfarmer:
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\right
should be used.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?