Non-reciprocity of "LaTex" and "pprint" printings

[Gaurav Dhingra]

Hi, everyone.
One general question of `printing` and `latex`

>>> init_printing()
>>> Derivative(x**2, x)      ###  1
d ⎛ 2⎞
──⎝x ⎠
dx
   
>>> latex(Derivative(x**2, x))   ### 2
\frac{d}{d x} x^{2}

Here the `latex` (i.e 2nd) printing is not the corresponding printing of 1st printing using Unicode, since the `latex` printing doesn't contain brackets around `x**2`, while first printing does contain.

So is it okay to have such a non-reciprocity behaviour (in general)?

Gaurav Dhingra (gxyd)

[Aaron Meurer]

In general, I'd say the two ought to produce the same result, unless
there is some formatting thing that is not possible to do in Unicode
but is in LaTeX.

I've noticed that the LaTeX printer and the pretty printer have
different methods for computing parenthesization (the LaTeX method
seems to be better). This is likely the cause of this. We should unify
the two.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/9adf0b8f-e9b2-49bf-9995-fcb2e4152f9b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Francesco Bonazzi]

On Thursday, 31 March 2016 17:51:33 UTC+2, Aaron Meurer wrote:

In general, I'd say the two ought to produce the same result, unless
there is some formatting thing that is not possible to do in Unicode
but is in LaTeX.

I've noticed that the LaTeX printer and the pretty printer have
different methods for computing parenthesization (the LaTeX method
seems to be better). This is likely the cause of this. We should unify
the two.

I agree, LaTeX printer determines parenthesization from the expression node precedence, while the pretty printer uses lots of sparsely coded if-clauses.

Can anyone think of an example where parenthesization should differ between the LaTeX printer and the pretty printer?

I'd also suggest to make it a goal that all LaTeX printed expressions can be parsed back by latex2sympy.

[Aaron Meurer]

On Thu, Mar 31, 2016 at 12:34 PM, Francesco Bonazzi
<franz....@gmail.com> wrote:
>
>
> On Thursday, 31 March 2016 17:51:33 UTC+2, Aaron Meurer wrote:
>>
>> In general, I'd say the two ought to produce the same result, unless
>> there is some formatting thing that is not possible to do in Unicode
>> but is in LaTeX.
>>
>> I've noticed that the LaTeX printer and the pretty printer have
>> different methods for computing parenthesization (the LaTeX method
>> seems to be better). This is likely the cause of this. We should unify
>> the two.
>
>
> I agree, LaTeX printer determines parenthesization from the expression node
> precedence, while the pretty printer uses lots of sparsely coded if-clauses.
>
> Can anyone think of an example where parenthesization should differ between
> the LaTeX printer and the pretty printer?

The only reason to do something differently is if it's not possible to
do something with Unicode characters. For parentheses, the only limit
is that they take up an additional two columns of space, which can
admittedly make some things look too wide. For instance, we might want
to make something like f(x).diff(x, 6).subs(x, 0) print like
f^{(6)}(0) in LaTeX, but

(6)
f (0)

doesn't look so good (not that I can think of a better way to print it).

>
> I'd also suggest to make it a goal that all LaTeX printed expressions can be
> parsed back by latex2sympy.

That's a good goal, but we shouldn't sacrifice the printing of
expressions. The number 1 goal should be to make expressions print
nicely. In other words, we should improve latex2sympy rather than
change latex() if it means making the output look less nice.

Aaron Meurer

>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/cf299501-20b8-45ca-8bb3-848d14c87699%40googlegroups.com.

[Francesco Bonazzi]

On Thursday, 31 March 2016 17:51:33 UTC+2, Aaron Meurer wrote:

I've noticed that the LaTeX printer and the pretty printer have
different methods for computing parenthesization (the LaTeX method
seems to be better). This is likely the cause of this. We should unify
the two.

The problem here is that the current code is working well. I agree that there's repeating coding that could be unified and made more reliant on the precedence module.

But... why would we need to spend time to rewrite code that is already working well?

[Aaron Meurer]

But it's not working well. There are several issues with things that
don't get parenthesized correctly (I know you know about these,
because you made pull requests to fix them). How many other things are
also missing parentheses? It seems to me that any object that the
printer doesn't expect that requires parentheses won't get
parenthesized correctly.

Also, the pretty printer has tons of tests. I'm fairly confident that
any issues from small refactor like this would be caught in the tests.
We can also double check the test coverage if you're worried about
that.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/f2f1ace8-c316-49da-b766-1702aa39fa84%40googlegroups.com.

[Francesco Bonazzi]

Maybe we could add a precedence_traditional method to the precedence module, that is supposed to provide the precedence according to traditional-styled math representation (e.g. Integral in traditional precedence would have the same precedence as Mul, not as atom).

At this point, the pretty printer and the latex printer could have an abstract superclass dealing with parenthesization.

[Aaron Meurer]

Integral should probably have its own precedence, distinct from atom,
since setting it to atom seems confusing, given that a rendered
integral has many parts (the integral sign, the limits, the integrand,
and the differential). It does need to have parentheses precedence
such that it gets parenthesized when raised to a power.

I'm not really following what you mean by traditional math
representation. You can't render (∫f(x)dx)^2 using the traditional
notation with the integral sign and "dx" without using parentheses.
Even writing it in "1-D" notation like that requires parentheses. The
only way it doesn't is if you use a functional notation, like
INT(f(x), x)^2.

Aaron Meurer

On Mon, Apr 4, 2016 at 5:58 AM, Francesco Bonazzi

> https://groups.google.com/d/msgid/sympy/8fddb66c-39e6-4459-95ca-08c43378a244%40googlegroups.com.

[Francesco Bonazzi]

On Monday, 4 April 2016 20:04:04 UTC+2, Aaron Meurer wrote:

You can't render (∫f(x)dx)^2 using the traditional
notation with the integral sign and "dx" without using parentheses.

precedence_traditional(Integral) ==> same precedence as Mul, which is lower than Pow, so it gets parenthesized.
 

The only way it doesn't is if you use a functional notation, like
INT(f(x), x)^2.

precedence(Integral) ==> same precedence as Atom, which is higher than Pow, so it does not get parenthesized.