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
On Monday, April 25, 2022 at 4:07:30 AM UTC+1 asme...@gmail.com wrote:
> 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
>
> >
> > On Sunday, April 24, 2022 at 5:01:49 AM UTC+1 asme...@gmail.com wrote:
> >>
> >> 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)
> >> > On Thursday, April 21, 2022 at 8:23:51 PM UTC+1 Andre Bolle wrote:
> >> >>
> >> >> I think mathematicians prefer the order of symbols preserved.
> >> >>
> >> >> On Thursday, April 21, 2022 at 7:54:20 PM UTC+1 asme...@gmail.com
> wrote:
> >> >>>
> >> >>> On Thu, Apr 21, 2022 at 12:16 PM Oscar Benjamin
> >> >>> <oscar.j....@gmail.com> wrote:
> >> >>> >
> >> >>> > 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.
> >> >>>
> >> >>> 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
> .
> >> >
> >> > --
> >> > 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/4a04c3f8-881e-4e80-a00e-a01c4b280a52n%40googlegroups.com
> .
> >
> > --
> > 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/759013c4-2e98-41ac-b231-dce084baa112n%40googlegroups.com
> .
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/23096ad2-f159-4fc9-8f8b-6ef2efeb6efbn%40googlegroups.com.
