Neat question Matt. I recall seeing this before - the question of
whether to combine or not combine factors.
In fact, someone seems to have answered it in calculus - also saying that
SymPy actually has a way to do this using the sympy subs() method. If you
have an expression involving x and you substitute a numeric value for it
sympy will combine the factors. But if instead you substitute a variable
expression, sympy will leave the factors uncombined.
Amazingly, we can ask Google and Google has actually already catalogued
this issue and its solution using subs().
*Google writes:*
This substitution can control whether factors are combined or left
separate. For example:
- x = symbols('x')
- expr = (x + 1) * (x + 2)
- expr.subs(x, 3) will result in 12 (the factors are combined),
while expr.subs(x,
'y') will result in (y + 1) * (y + 2) (the factors are left uncombined).
I do I remember this issue - of combining or not combining coming up a
while back. HTH -- Rich
On Thu, Apr 24, 2025 at 6:32 PM Matthew Samuel <matthemat...@gmail.com>
wrote:
> Hello sympy community,
>
> I have a PhD in math and as a result of my research some unique knowledge
> that has allowed me to implement fast computations with Schubert
> polynomials. I compiled a python package in 2023 that started out as just
> console scripts, then it was suggested at a math conference that I try to
> integrate it into something like, say, Sage.
>
> I did this, but Sage is monstrous and can only be used on a linux-based
> operating system, which is not ideal. Granted, the "market" for a Schubert
> polynomials package is quite limited (I say "market" because obviously no
> one would pay for this, it's a figure of speech), and the depth of computer
> algebra capabilities that are needed for this is quite low. No offense to
> sympy, but no one would argue that compared to Sage it is quite
> lightweight, takes seconds to install, etc.
>
> Anyway my training is in math, not programming, and I do mainly program
> for a living, but I'm not a software engineer per se, and the subject of my
> job has little to do with computer algebra. Anyway I have created
> subclasses of Expr that deal with Schubert polynomials, double Schubert
> polynomials, quantum Schubert polynomials, quantum double Schubert
> polynomials, parabolic quantum (double) Schubert polynomials, and
> interplays between them.
>
> I wanted to give a link to my github project for anyone who is interested
> at looking at it. I suspect that from your perspective it is pretty much a
> dumpster fire of bad practice, and any advice you may have is welcome.
>
> https://github.com/matthematics/schubmult
>
> I'm reaching out because I'm running into issues that should be pretty
> elementary if I were doing it right. For example, the best representation
> of linear combinations of Schubert polynomials is as a dict of coefficients
> of basis elements, but there are some times when they need to be left
> uncombined, but then you should be able to add to the uncombined terms and
> combine with the cominable ones. sympy does automatically do that, for
> example,
>
> >>> DSx([3,4,1,2]) + DSx([4,1,3,2],"z")
> DSx((3, 4, 1, 2), y) + DSx((4, 1, 3, 2), z)
>
> This is sympy.Add, not a DoubleSchubertAlgebraElement, because the sets of
> coefficient variables, y and z, are different. This is what I want. When we
> do this, however,
>
> >>> DSx([3,4,1,2]) + DSx([4,1,3,2],"z") + DSx([3,4,1,2])
> 2*DSx((3, 4, 1, 2), y) + DSx((4, 1, 3, 2), z)
>
> This looks correct, however that 2*DSx((3, 4, 1, 2), y) is a sympy.Mul
> object, when what I want is for it to be internally represented as
> {(3,4,1,2): 2}, which it is not.
>
> I feel like this is similar to the Poly class being a subclass of Basic
> instead of Expr, but I don't know if I want to be that rigid. And combining
> terms as Expr alone is inefficient. These can have hundreds or thousands of
> terms after multiplying, and the hashmap of keys is the most efficient way
> to combine coefficients.
>
> I guess this is a question? What's the most elegant way to get that 2 into
> that dict? As well as an introduction and salutations.
>
> Thanks,
> Matt
>
> --
> 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 visit
> https://groups.google.com/d/msgid/sympy/fec1e0d2-a271-4cea-8cd0-ab4c216ef721n%40googlegroups.com
> <https://groups.google.com/d/msgid/sympy/fec1e0d2-a271-4cea-8cd0-ab4c216ef721n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
*Richard Katz*
pytholog...@gmail.com
(415) 336-9559
https://www.linkedin.com/in/richardkatz/
richk...@berkeley.edu
--
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 visit
https://groups.google.com/d/msgid/sympy/CAD8%2BcAC4-Pbvj5xjtvTQW55tTTSMN58e0bRQr9ybg4gmcB4Xmw%40mail.gmail.com.
