search

asciimath / asciimathml

A new home for asciimathml
http://asciimath.org/
MIT License
958 stars 184 forks source link

Parenthesis in 'u_(-)' to avoid unexpected rendering #114

Closed sebi5361 closed 3 years ago

sebi5361 commented 3 years ago

u_- needs to be written u_(-)to be rendered as thought whereas u_+ can be written as is to be rendered correctly

Indeed u_- + 2 + u_+ + 3 is rendered such a way

and needs to be written u_(-) + 2 + u_+ + 3 to be rendered as expected (by me only?)

drlippman commented 3 years ago

I think what's happening is that u_-2 displays as u_(-2), so the code is written to expect something to follow a negative in a subscript. I think that is causing the + to be attached to the - and end up in the subscript. This is the same code that gets helps 3/-4 be displayed properly. I suppose this could be considered a bug.

The easiest "fix" would be to have a space after the negative break that connection, so u_- 3 would be handled differently than u_-3. But that would be a departure from the normal asciimath standard where spaces between symbols are ignored and don't impact the display.

The alternative would be to come up with a list of things that should or shouldn't stay attached to a negative in a sub/superscript and in a denominator without needing parens. I'm looking at ways this could be addressed in the code, and am struggling since there's no clear delineation in terms of tag or ttype for what should be kept attached to the negative and what shouldn't be.

Peter @jipsen, do you have any thoughts? In particular about whether treating a space as meaningful in this case would be problematic.

I suppose spaces can be used to break apart symbols, so that x x will be treated differently than xx, so maybe using a space here to indicate the symbols should be separated is appropriate.

sebi5361 commented 3 years ago

But that would be a departure from the normal asciimath standard where spaces between symbols are ignored and don't impact the display.

I believe spaces are useful to avoid some confusions in daily mathematical writing. E.g. it helps to distinguish between a (b+c) representing a times b+c from a(b+c) meaning function a of arguments b+c. Currently \ allows to make the distinction, but I believe using a standard space would make the writing easier.

davidfarmer commented 3 years ago

My dormant project "Space Math" has as its premise that white space can do a lot to disambiguate the meaning of what a person types.

Previous discussions indicated that Space Math is not viable as an extension of AsciiMath, but would have to be its own separate thing.

But maybe this discussion is suggesting those markup languages can be compatible?

Some information here:

https://github.com/asciidoctor/asciimath/issues/32

On Sun, 8 Nov 2020, sebi wrote:

  But that would be a departure from the normal asciimath standard where spaces between
  symbols are ignored and don't impact the display.
  • Indeed could "spaces between symbols being ignored" be reconsidered or is it too disruptive with the current AsciiMath standard?

I believe spaces are useful to avoid some confusions in daily mathematical writing. E.g. it helps to distinguish between a (b+c) representing a times b+c from a(b+c) meaning function a of arguments b+c. Currently \ allows to make the distinction, but I believe using a standard space would make the writing easier.

  • Is this evolution for AsciiMath conceivable?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, orunsubscribe.[AABTULHEY6VWGN5TUNDWLO3SO23LVA5CNFSM4SL74PKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJK TDN5WW2ZLOORPWSZGOFMQSXMA.gif]

sebi5361 commented 3 years ago

Previous discussions indicated that Space Math is not viable as an extension of AsciiMath, but would have to be its own separate thing.

Indeed this conclusion might be justified as backward compatibility would be affected. Backward compatibility might be really important for the AsciiMath aficionados out there, and the alternative Space Math would be a good solution to see this alternative syntax. I think only the creator of AsciiMath @jipsen together with the AsciiMath repository maintainer @drlippman can decide for such a disruptive modification.

I will continue my discussion on asciidoctor/asciimath#32 as I think it is more relevant there. I would love to see Space Math!

I would like to point out a last aspect in this thread, that, I think, is really import to gain in acceptance for AsciiMath among the MarkUp (Markdown) community: there should be a unified way to trigger AsciiMath rendering defined together with the AsciiMath standard (or mentioned as "prefered" way). Hence currently there is no consensus which doesn't play in favor of AsciiMath being accepted as a standard. As I have encountered many ways to trigger AsciiMath rendering, the most of which relying on specific delimiters, my conclusion is that this is not the best approach. The best option would be $@cosx$. Hence the odds for a Latex equation starting with an @ are minimal, and one can always escape AsciiMath rendering by prepending a space.

jipsen commented 3 years ago

Yes, the unary - is treated as a prefix function symbol that first parses its argument and then is processed by the preceding subscript (or superscript) binary operation. Similar parsing can be noticed with u_-f(x) and u_f(x) (since f is also a unary prefix function symbol). This was mostly motivated by wanting to allow x^-1 and x^-y as simple-to-type expressions, and then deciding to treat subscripts in the analogous way.

Prefix + is not a unary function symbol because it is rarely considered as such in basic math, but this causes the asymmetry between u+1 and u-1. My preferred way of typing the expression u(-)-1+u++3 would be to rather type u(-)-1+u(+)+3.

Note that it is not really the case that spaces are always ignored by asciimath. E.g. +-3 and + -3 parse differently since +- is the equivalent of \pm in LaTeX. So spaces are significant when they occur in the middle of a token, since such spaces are breaking the token into two parts.

It is an interesting idea to modify the syntax so that unary prefix function symbols have to occur immediately before their argument, and that a space would prevent them from behaving like unary function symbols. However, some careful testing would have to be done to see whether such a change causes significant problems with backwards compatibility.

Regards, Peter

Dr. Peter Jipsen Professor of Mathematics Chapman University Chapman.edu/sciencehttp://Chapman.edu/science www1.chapman.edu/~jipsenhttp://www1.chapman.edu/~jipsen

On Nov 7, 2020, at 11:36 AM, David Lippman notifications@github.com<mailto:notifications@github.com> wrote:

External Message

I think what's happening is that u-2 displays as u(-2), so the code is written to expect something to follow a negative in a subscript. I think that is causing the + to be attached to the - and end up in the subscript. This is the same code that gets helps 3/-4 be displayed properly. I suppose this could be considered a bug.

The easiest "fix" would be to have a space after the negative break that connection, so u- 3 would be handled differently than u-3. But that would be a departure from the normal asciimath standard where spaces are ignored and don't impact the display.

The alternative would be to come up with a list of things that should or shouldn't stay attached to a negative in a sub/superscript and in a denominator without needing parens. I'm looking at ways this could be addressed in the code, and am struggling since there's no clear delineation in terms of tag or ttype for what should be kept attached to the negative and what shouldn't be.

Peter @jipsenhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjipsen&data=04%7C01%7Cjipsen%40chapman.edu%7C4245e7728db24d83ab1e08d883547a63%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637403746145391203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=66r%2F8atNfifAUoWU4S7Jjm3w7hgYQRRSchIG1%2FavCNM%3D&reserved=0, do you have any thoughts? In particular about whether treating a space as meaningful in this case would be problematic.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fasciimath%2Fasciimathml%2Fissues%2F114%23issuecomment-723485749&data=04%7C01%7Cjipsen%40chapman.edu%7C4245e7728db24d83ab1e08d883547a63%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637403746145401196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ttfYS9eKksepbJlBkoEamqlzqKWS3nH18d%2FWRiF%2FDd0%3D&reserved=0, or unsubscribehttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAP5CDFJVWUBR5K6HMOOVWLSOWOVHANCNFSM4SL74PKA&data=04%7C01%7Cjipsen%40chapman.edu%7C4245e7728db24d83ab1e08d883547a63%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637403746145401196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=huRT9UF%2BRgG%2FwNOdDL7F6OLWekvt1zmTrk53X%2BMUMSY%3D&reserved=0.

NOTE: This email originated from outside Chapman’s network. Do not click links or open attachments unless you recognize the sender and know content is safe.

drlippman commented 3 years ago

It is an interesting idea to modify the syntax so that unary prefix function symbols have to occur immediately before their argument, and that a space would prevent them from behaving like unary function symbols. However, some careful testing would have to be done to see whether such a change causes significant problems with backwards compatibility.

Agreed. I think it makes reasonable sense in the case being discussed, to separate - being used as a standalone character from the use as a unary negation. I'd imagine people don't usually put a space after a negation -, and the unary behavior only applies to - if it's used following an INFIX symbol. It probably does not make sense to do in general, though, as I'm pretty sure it would cause significant backwards compatibility issues. The one that comes to mind is sin x / 3 which currently gets rendered as (sin x)/3.

FWIW, when I ran the unit tests on my proposed PR #116, it didn't break anything in the existing test suite, but it did fix something else previously broken: 2^- +3, which is currently rendering as 2^(-+) 3 and the PR fixes to 2^(-) +3

jipsen commented 3 years ago

I agree that it would be best to make such a change only for the unary minus after a binary operation. It’s still likely to change the rendering of some existing websites, at least if they upgrade to the latest version, but it should be quite rare.

The test suite is great, but it mostly contains correct expressions and not enough edge cases. Random asciimath syntax can produce some weird effects, and it is likely that only a few of them have been observed. I don’t have any new ones to contribute to the test suite, but it would be good to study this at some point rather than address issues as they come up one-at-a-time.

I did notice that unicode can now be mixed with asciimath and this works almost flawlessly (at least in the asciimath.orghttp://asciimath.org textbox). Does the asciimath.orghttp://asciimath.org site use the latest version of MathJax?

There are a few unicode characters that do not display correctly (on a MacBook using Chrome): 𝔹 𝔽 𝕋 𝔸 𝐀 𝔄 𝕬 𝐴 𝑨 𝖠 𝗔 𝘈 𝘼 𝒜 𝓐 𝙰 Some of them can be generated by asciimath syntax and then display fine, e.g., bbbB and frA so this does not appear to be a display issue. Perhaps the unicode characters from the extended pane are not processed correctly by the asciimath/MathJax pipeline.

Regards, Peter

Dr. Peter Jipsen Professor of Mathematics Chapman University Chapman.edu/sciencehttp://Chapman.edu/science www1.chapman.edu/~jipsenhttp://www1.chapman.edu/~jipsen

On Nov 8, 2020, at 11:18 PM, David Lippman notifications@github.com<mailto:notifications@github.com> wrote:

External Message

It is an interesting idea to modify the syntax so that unary prefix function symbols have to occur immediately before their argument, and that a space would prevent them from behaving like unary function symbols. However, some careful testing would have to be done to see whether such a change causes significant problems with backwards compatibility.

Agreed. I think it makes reasonable sense in the case being discussed, to separate - being used as a standalone character from the use as a unary negation. I'd imagine people don't usually put a space after a negation -, and the unary behavior only applies to - if it's used following an INFIX symbol. It probably does not make sense to do in general, though, as I'm pretty sure it would cause significant backwards compatibility issues. The one that comes to mind is sin x / 3 which currently gets rendered as (sin x)/3.

FWIW, when I ran the unit tests on my proposed PR #116https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fasciimath%2Fasciimathml%2Fpull%2F116&data=04%7C01%7Cjipsen%40chapman.edu%7Cf30d6bedfc0b401a6e9608d8847fa0f5%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637405030986537957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cTo734SBjB8HHNJWfp5y9gugl4Wv65k8%2BrNMRNnd8Jw%3D&reserved=0, it didn't break anything in the existing test suite, but it did fix something else previously broken: 2^- +3, which is currently rendering as 2^(-+) 3 and the PR fixes to 2^(-) +3

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fasciimath%2Fasciimathml%2Fissues%2F114%23issuecomment-723813804&data=04%7C01%7Cjipsen%40chapman.edu%7Cf30d6bedfc0b401a6e9608d8847fa0f5%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637405030986537957%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sHNvUHfXPGVXrH8nMu%2BVxk9Fp0EsMIOSaIwu%2FGOuG%2Fs%3D&reserved=0, or unsubscribehttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAP5CDBGZ2725RAJ55C7BD3SO6JTRANCNFSM4SL74PKA&data=04%7C01%7Cjipsen%40chapman.edu%7Cf30d6bedfc0b401a6e9608d8847fa0f5%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637405030986547953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gPsvcHhORIVszSQcAxSPpQ8j34JxbMtpfrjDs6Wqqo8%3D&reserved=0.

NOTE: This email originated from outside Chapman’s network. Do not click links or open attachments unless you recognize the sender and know content is safe.

drlippman commented 3 years ago

Yes, I agree it'd be nice to expand the test suite. Hopefully some contributors will make PRs with some additions ;)

It sounds like PR #116 should be safe enough, and I'll merge it soon.

I think the unicode that works is coincidental, with asciimath just passing it through. The asciimath.org site is using MathJax 2.7.4 right now.

sebi5361 commented 3 years ago

I think the unicode that works is coincidental, with asciimath just passing it through. The asciimath.org site is using MathJax 2.7.4 right now.

It seems the latest MathJax version renders properly most unicode characters (tested with 𝕬). Note that if you were using the asciimath/katex pipeline this wouldn't work throwing error Font metrics not found for font: . Being able to render all (most of) unicode characters would be a must!

Yes, I agree it'd be nice to expand the test suite. Hopefully some contributors will make PRs with some additions ;)

I can help improving the test suit. However most errors I encounter are due to inconsistent matching brackets. Does this count as test candidates?