`\rightarrow` should become `\to` in limits

[jgm]

`\rightarrow` should become `\to` in limits

[mpickering]

As far as I'm aware \to and \rightarrow are exactly the same character?

http://tex.stackexchange.com/questions/19185/which-one-should-be-used-in-limit-rightarrow-or-to

Attached is a picture of them both rendered on my system.

On Mon, Jul 21, 2014 at 11:04 AM, Jesse Rosenthal [email protected]
wrote:

ping @mpickering https://github.com/mpickering

ESymbol Rel \8594 is interpreted as \rightarrow in limits. But for the
LaTeX to be typeset correctly, it should be translated to \to:

let Right x = readTeXMath "\lim_{x \to \infty} y"
x
[EDown (EMathOperator "lim") (EGrouped [EIdentifier "x",ESymbol Rel "\8594",ESymbol Ord "\8734"]),EIdentifier "y"]
toTeXMath DisplayInline x
"{\lim}_{{x}\rightarrow \infty }{y}"

This probably only needs to be implemented for

EDown (EMathOperator "lim") ...

although there might be some uses for implementing it for

EDown (EMathOperator s) ... | s elem ["lim", "max", "min"]

(That would take care of the main things that should be typeset like that,
even if off the top of my head I can't make any useful sense of "max as n
approaches...")

I'd submit a pull request, but I'm not sure of the workflow here. @jgm
https://github.com/jgm -- would you prefer these things go through your
pr queue, or to maintainer and then up to you, kernel style?

—
Reply to this email directly or view it on GitHub
#32.

[jkr]

Yes -- you're quite right. I'd been laboring under a misapprehension for a while (thought they were the same char, but the TeX functions behaved differently in this case). Apologies.

That being said, I think there is a problem here. The way that toTexMath wraps the EMathOperator "\lim" in braces makes it not do the correct thing with the arrow underneath. That's what I had mistakenly attributed to the wrong character

Compare the output here

\documentclass{article}

\begin{document}

$${\lim}_{x \rightarrow 2} y$$

$$\lim_{x \rightarrow 2} y$$

\end{document}

[jkr]

Oh -- and I've been so busy switching over to it that I forgot to mention -- awesome work!

[mpickering]

Ok, I'm unsure about the best way to fix this easily. The problem without
the braces is that if \lim is followed by any alphaNum character (for
example \lima) then the command isn't recognised. Adding a space afterwards
doesn't work either for obvious reasons. Maybe it would be worth checking
for the special case when a math operator is part of a super/subscript?
Would that work?

On Mon, Jul 21, 2014 at 2:10 PM, Jesse Rosenthal [email protected]
wrote:

Yes -- you're quite right. I'd been laboring under a misapprehension for a
while (thought they were the same char, but the TeX functions behaved
differently in this case). Apologies.

That being said, I think there is a problem here. The way that toTexMath
wraps the EMathOperator "\lim" in braces makes it not do the correct thing
with the arrow underneath. That's what I had mistakenly attributed to the
wrong character

Compare the output here http://commonmeasure.org/%7Ejkr/foo.pdf

\documentclass{article}

\begin{document}

$${\lim}_{x \rightarrow 2} y$$

$$\lim_{x \rightarrow 2} y$$

\end{document}

—
Reply to this email directly or view it on GitHub
#32 (comment).

[jkr]

Hmm... well, it looks like it goes beyond EMathOperator. \sum (and prod and so on, I'd imagine) produce the same issue with ESymbol Op .... So, yeah, it does seem to need to be something in the way you handle EDown, EUp and EDownup. Maybe have a special braceless version that these functions call out to? Or a "wrap" bool or something? (I haven't looked closely enough to see how it's done.) There should always only be a _ or a ^ after the operator in the output of these types, so it shouldn't be a problem.

[jgm]

+++ Jesse Rosenthal [Jul 21 14 03:04 ]:

I'd submit a pull request, but I'm not sure of the workflow here.
[2]@jgm -- would you prefer these things go through your pr queue, or
to maintainer and then up to you, kernel style?

Best to go through @mpickering first. He's the one who really knows
this code.