We could just make a wrapper named `solved = lambda f,*s,**k: solve(f, *s,
**k, dict=True)`
/c
On Friday, March 4, 2022 at 7:22:05 AM UTC-6 gu...@uwosh.edu wrote:
> I think the name should be something like "solve2" and provide a couple
> year deprecation warning after which "solve" points to "solve2".
>
> Jonathan
>
> On Friday, March 4, 2022 at 1:40:58 AM UTC-6 moore...@gmail.com wrote:
>
>> I think changing this will break tons of code in the wild. Isnt it best
>> make a new "solve_new" and then leave solve be (maybe with a deprecation
>> warning. You could call it `solve_equations` or something.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Thu, Mar 3, 2022 at 11:45 PM Oscar Benjamin <oscar.j....@gmail.com>
>> wrote:
>>
>>> On Thu, 3 Mar 2022 at 20:28, Aaron Meurer <asme...@gmail.com> wrote:
>>> > On Thu, Mar 3, 2022 at 8:28 AM Chris Smith <smi...@gmail.com> wrote:
>>> > >
>>> > > Although the dict=True or set=True will give a standard output, can
>>> we at least unify the case for when variables are given so we always get a
>>> list of one or more dictionaries? So the above would be `[{x: -sqrt(y)},
>>> {x: sqrt(y)}]` and `[{x: y}]`, respectively. This would then make `solve`
>>> always give a list of a) values for a univariate expression, b) a list of
>>> one or more dictionaries for every other case. (Case (a) will give a list
>>> of dictionaries if `dict=True`.)
>>> >
>>> > Changing the output type could break code that solves a specific
>>> > equation. I am doubtful whether any users actually understand the
>>> > output type behavior of solve without the dict=True flag. So
>>> > personally I think we should clean it up. We already recommend using
>>> > dict=True to get consistent output types, and this would only affect
>>> > users who aren't doing that.
>>>
>>> It would be much better if solve always worked like that but obviously
>>> that's not a backwards compatible change and I'm not sure what would
>>> break. I don't think that the type of the output should depend on the
>>> number of solutions although it could depend on the type of the
>>> arguments (e.g a single equation vs a list of equations). At the
>>> moment the type of the output can depend on the equations themselves
>>> which is wildly awkward:
>>>
>>> In [3]: solve([x-1], [x])
>>> Out[3]: {x: 1}
>>>
>>> In [4]: solve([x**2-1], [x])
>>> Out[4]: [(-1,), (1,)]
>>>
>>> The ideal output for solve is absolutely a list of dicts though and it
>>> would be good to make that the default at least when given a list of
>>> equations. I guarantee that a lot of notebooks or other little bits of
>>> code will depend on each of these random special cases though.
>>>
>>> --
>>> 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/CAHVvXxROqs0CpGmSX2%3Dk8xJgTos9FPpP1x0GYP0aHCdiYErDnA%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/efd39707-84af-468b-b045-96b98bc8a7dcn%40googlegroups.com.
