On Wed, Mar 23, 2022 at 4:39 PM Oscar Benjamin
wrote:
>
> On Wed, 23 Mar 2022 at 19:42, Aaron Meurer wrote:
> >
> > So I'm starting to wonder if the real fix here isn't so much to "fix
> > solve" (although solve() should definitely be improved and cleaned
> > up), but rather to treat solve() as
Except for booleans, consider single and system output:
If it is a single equation the output depends on whether symbols are given
or not:
* list of expressions if a single variable is given (or the expression is
univariate and no symbol is given)
* if multiple variables are given and the
On Wed, 23 Mar 2022 at 19:42, Aaron Meurer wrote:
>
> So I'm starting to wonder if the real fix here isn't so much to "fix
> solve" (although solve() should definitely be improved and cleaned
> up), but rather to treat solve() as the "interactive only" function
> for equation solving, just as
I think the problem is that solve() is designed as an interactive
function. If you are sitting down in an interactive session and using
solve(), then its output makes sense. It has different return types,
but that's fine if you are just passing it something and looking
directly at the solution. It
On Thu, Mar 10, 2022 at 12:25 AM Ian Xul Belaustegui wrote:
>
> Hello! My name is Ian Xul, I am a Mathematics major at UNAM in Mexico. I am
> very excited to participate in GSoC, it sounds like a great opportunity to
> meet interesting people and learn about good coding practices and working in
There isn't really. SymPy's summation code uses a suite of algorithms
that match a wide array of expressions. It would be difficult to make
a list because it is more than just matching against a list of known
sums.
Pattern matching against known summations is something that could be
added (a la
