In my most recent PR concerning `solve` Oscar has suggested (and I concur)
that the varieties of output for `solve` not be changed -- though I am not
sure that we are doing so for the same. Here is a draft for the
documentation's "Explanations" section:
The output of the `solve` function can
Is there an example of when a parameter other than an integer would be
necessary?
/c
On Thursday, March 24, 2022 at 2:21:07 PM UTC-5 Aaron Meurer wrote:
> On Wed, Mar 23, 2022 at 5:52 PM Chris Smith wrote:
> >
> > Except for booleans, consider single and system output:
> >
> > If it is a
On Wed, Mar 23, 2022 at 5:52 PM Chris Smith wrote:
>
> 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
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 Wed, 9 Mar 2022 at 19:29, Chris Smith wrote:
>
> For the case of `eqs = [x+y+a, x+y+1]` you get the solution for `a = 1` if
> you give it the freedom to tell you that: `solve(eqs) -> {a: 1, x: -y - 1}`.
> This gives you the conditions for a solution: a value for `a` and a
> relationship
For the case of `eqs = [x+y+a, x+y+1]` you get the solution for `a = 1` if
you give it the freedom to tell you that: `solve(eqs) -> {a: 1, x: -y -
1}`. This gives you the conditions for a solution: a value for `a` and a
relationship between `x` and `y`.
As for extra parameters, do we ever
On Fri, 4 Mar 2022 at 22:02, Aaron Meurer wrote:
>
> It would really be a shame to give up the name solve(). Maybe we can
> put this on a list of big changes that we can do in 2.0? Although it
> would be good to have a working replacement ready before we do any
> renaming.
Let's just work on a
One sort of "Solution" structure that could be used is something like this:
Solution({a: [-1, 1], x: [2 + y], y: [4, 5]})
This structure could be iterated with backsubstitution done in JIT manner:
[{a:-1, x:6, y:4}, ...
/c
On Saturday, March 5, 2022 at 10:35:10 AM UTC-6 Chris Smith wrote:
>
Aaron mentioned:
>>> solve(sin(x)*x - y)
[{y: x*sin(x)}]
Now solving for x and y simultaneously is impossible, as is solving
for x, so solve() has just picked the one that it knows how to do and
solved for y.
---
I find this useful, especially for a system of
It would really be a shame to give up the name solve(). Maybe we can
put this on a list of big changes that we can do in 2.0? Although it
would be good to have a working replacement ready before we do any
renaming.
On Fri, Mar 4, 2022 at 8:27 AM Oscar Benjamin
wrote:
>
> On Fri, 4 Mar 2022 at
On Fri, 4 Mar 2022 at 14:57, Chris Smith wrote:
>
> We could just make a wrapper named `solved = lambda f,*s,**k: solve(f, *s,
> **k, dict=True)`
If there is to be a new API then there are a *lot* of other things
that I would want to change about it compared to solve so it
definitely wouldn't
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
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
>
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
On Thu, Mar 3, 2022 at 11:45 PM Oscar Benjamin
On Thu, 3 Mar 2022 at 20:28, Aaron Meurer wrote:
> On Thu, Mar 3, 2022 at 8:28 AM Chris Smith 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?
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
The output from solve for algebraic equations is not usable without testing
output because of the variable types of output.
CASE 1: If no variables are given we get the following from the input:
* univariate equation -> list of values
>>> solve(x**2 - 4)
[-2, 2]
* multivariate equation -> list
The output from solve for algebraic equations is not usable without testing
output because of the variable types of output.
CASE 1: If no variables are given we get the following from the input:
* univariate equation -> list of values
>>> solve(x**2 - 4)
[-2, 2]
* multivariate equation -> list
21 matches
Mail list logo
