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 On Thu, Apr 21, 2022 at 11:28 AM Andre Bolle <[email protected]> wrote: > > I would assume such a feature would only be part of the final printing stage. > On Thursday, April 21, 2022 at 11:51:20 AM UTC+1 [email protected] wrote: >> >> 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 >> >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/4163dc15-164d-4130-bc58-32cc10fd5eafn%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J%3DGqGf5y3_dMLSkj77rRsTX_hzs9VYdHPhYP5r%2B%3DR2kQ%40mail.gmail.com.
