Respecting Tradition

[Andre Bolle]

We all know F=ma. But when doing a "Eqn(F, m * a)" one gets "𝐹=𝑎𝑚 ". Is there a hinting system? i.e. If there's both an "a" and an "m" in a term, put the m before the a.

before(m,a)

André

[Jonathan Gutow]

Sympy orders symbols in ASCII order in equations. That is something I too would like to have changed, but have not had the time to determine if any of sympy depends on this canonical ordering. I suspect it is taken advantage of in substitution and other related operations.

On Apr 20, 2022, at 10:15 AM, Andre Bolle <andre...@gmail.com> wrote:

You don't often get email from andre...@gmail.com. Learn why this is important

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

We all know F=ma. But when doing a "Eqn(F, m * a)" one gets "𝐹=𝑎𝑚 ". Is there a hinting system? i.e. If there's both an "a" and an "m" in a term, put the m before the a.

before(m,a)

André

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/dbb81668-ffaf-46bc-8e5a-02e262de49e1n%40googlegroups.com.

[Aaron Meurer]

Removing the ordering is not a straightforward thing to do. There is
an important detail that depends on the ordering, which is that
something like x*y == y*x works because it assumes that the terms are
in canonical order, so it just compares them directly. And even
outside of __eq__ itself there may be other places that implicitly
make use of this fact. There's also a further complication which is
that for Add and Mul, any purely numeric part (i.e., the Rational or
Float term if it is nonzero) is always the first term in the args, and
many things rely on this fact.

This is a laudable change to make though. If we can somehow remove the
ordering from the core entirely (although I'm not even sure if that's
doable from a backwards compatibility point of view), it would also
improve the performance, since right now every Add and Mul that gets
created has to call sort() its arguments, which not only has to do the
sorting algorithm but it has to compute a canonical sort key for each
term. A good place to start is to look at And and Or, which go sort of
half way and don't sort their args until you actually request .args
(they also have ._argset which is a frozenset of the args).

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/26DC4101-67E2-45A7-94A6-EA9CC094C2CE%40uwosh.edu.

[David Bailey]

On 20/04/2022 21:18, Aaron Meurer wrote:
> Removing the ordering is not a straightforward thing to do. There is
> an important detail that depends on the ordering, which is that
> something like x*y == y*x works because it assumes that the terms are
> in canonical order, so it just compares them directly. And even
> outside of __eq__ itself there may be other places that implicitly
> make use of this fact. There's also a further complication which is
> that for Add and Mul, any purely numeric part (i.e., the Rational or
> Float term if it is nonzero) is always the first term in the args, and
> many things rely on this fact.
>
> This is a laudable change to make though. If we can somehow remove the
> ordering from the core entirely (although I'm not even sure if that's
> doable from a backwards compatibility point of view), it would also
> improve the performance, since right now every Add and Mul that gets
> created has to call sort() its arguments, which not only has to do the
> sorting algorithm but it has to compute a canonical sort key for each
> term. A good place to start is to look at And and Or, which go sort of
> half way and don't sort their args until you actually request .args
> (they also have ._argset which is a frozenset of the args).

I quite like the fact that every expression gets ordered as it goes
through SymPy (and Mathematica did the same the last time I used it). I
mean people look at expressions as well as computers, and I think that
in complicated nested expressions it would be potentially confusing if
the same expression could appear with different ordering.

Also, every time an algorithm was improved in SymPy, I imagine there
would be the possibility that results would differ from the earlier
version just because of ordering.

Anyone who wanted a specific ordering could presumably write something
that would convert an expression to string and order it as desired.

David

[Andre Bolle]

I would assume such a feature would only be part of the final printing stage.

[Aaron Meurer]

If you want the expression to print in the same way that it was
originally entered, then it needs to keep track of that information
when it is created. That's not something that currently happens.

If you just want the printers to have more options in how they sort
things, that is technically already possible, although it's not
particularly straightforward and not very well documented.

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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/4163dc15-164d-4130-bc58-32cc10fd5eafn%40googlegroups.com.

[Oscar Benjamin]

On Thu, 21 Apr 2022 at 18:53, Aaron Meurer <asme...@gmail.com> wrote:
>
> If you want the expression to print in the same way that it was
> originally entered, then it needs to keep track of that information
> when it is created. That's not something that currently happens.
>
> If you just want the printers to have more options in how they sort
> things, that is technically already possible, although it's not
> particularly straightforward and not very well documented.

It should be easier to do each of these things. At the moment you can
create an Add(y, x, evaluate=False) and the printers do have an
"order" setting (for init_printing) but there isn't a value for the
order parameter that just prints the terms in the exact order that
they appear in the Add.

This is a very commonly requested option on StackOverflow etc. It
would be good to fix it so that the printers can just print in args
order.

--
Oscar

[Aaron Meurer]

The order flag needs to be documented much better. Also I think it
would be useful if you could just pass a sort key function directly to
the printer, with some examples of how to do that.

Aaron Meurer

>
> --
> Oscar

>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQU5MSP45UFe1ioztrW6%3DJF1TPEdVXC3o9qOROMFw9_cw%40mail.gmail.com.

[Andre Bolle]

I think mathematicians prefer the order of symbols preserved.

[Aaron Meurer]

I would only do that just for the printing. Telling SymPy that two
symbols don't commute means that it will no longer do any
simplifications on it that aren't valid without commuting them.

Aaron Meurer

On Sat, Apr 23, 2022 at 3:32 AM Andre Bolle <andre...@gmail.com> wrote:
>
> You can always tell Sympy that as far as I am concerned "a" is non-commutative. Then tradition is preserved.
>
> >>> var('F m')
> (F, m)
> >>> var('a')
> a
> >>> print(Eq(F,m*a))
> Eq(F, a*m)
> >>> var('a', commutative=False)
> a
> >>> print(Eq(F,m*a))
> Eq(F, m*a)

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/4a04c3f8-881e-4e80-a00e-a01c4b280a52n%40googlegroups.com.

[Andre Bolle]

So true. I deleted my post soon after I posted it, in case anyone took it seriously. But it was intended as a cosmetic work-around. I presume a var('a', commutative=True) immediately after would remedy that.

[Andre Bolle]

To preserve symbol order, or not to preserve symbol order. That is the question. Personally, I would like it preserved (if I want), as it would naturally be on paper as per tradition.

[Aaron Meurer]

On Sun, Apr 24, 2022 at 2:28 AM Andre Bolle <andre...@gmail.com> wrote:
>
> So true. I deleted my post soon after I posted it, in case anyone took it seriously. But it was intended as a cosmetic work-around. I presume a var('a', commutative=True) immediately after would remedy that.

Not quite. Symbols aren't global in SymPy (nothing in SymPy works
globally). If you do

F = symbols('F')
m, a = symbols('m a', commutative=False)
eqn = Eq(F, m*a)
m, a = symbols('m a')

then what would happen is that the expression in eqn would have the
noncommutative symbols and the Python variables 'm' and 'a' would
reference new, separate symbols.
A symbol in SymPy is determined by its name and assumptions, and
commutative is an assumption, so the m and a defined in line 2 would
be different from the m and a defined in line 4.

For example:

>>> m, a = symbols('m a', commutative=False)
>>> expr = m*a
>>> m, a = symbols('m a')
>>> expr == m*a
False

If you wanted to "fix" the expression to not have noncommutatives,
you'd have to keep track of the symbols you wanted to swap out and use
subs, like

>>> m_nc, a_nc = symbols('m a', commutative=False)
>>> m, a = symbols('m a')
>>> expr = m_nc*a_nc
>>> expr.subs({m_nc: m, a_nc: a})
a*m

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/759013c4-2e98-41ac-b231-dce084baa112n%40googlegroups.com.

[Andre Bolle]

Thanks for sharing that knowledge. I have no show-stopping problem with the limitation on symbol order and I understand it is cosmetic. The change in order was merely something I noticed and wanted to point out.

Thanks one and all for your contribution and help.

Andre