Behavior of solve
kcrisman
We have some inconsistency in solve.
sage: solve(x^5+x^3+17*x+1,x)
[x == -0.0588115172555,
x == (-1.33109991788 + 1.52241655184*I),
x == (-1.33109991788 - 1.52241655184*I),
x == (1.36050567904 + 1.5188087221*I),
x == (1.36050567904 - 1.5188087221*I)]
sage: from sage.symbolic.expression import Expression
sage: Expression.solve?
Docstring:
Analytically solve the equation ``self == 0`` for the
variable `x`.
.. warning::
This is not a numerical solver - use ``find_root`` to
solve
for self == 0 numerically on an interval.
Note that
sage: maxima.solve(x^5+x^3+17*x+1,x)
[0=x^5+x^3+17*x+1]
The reason for this is that sometime earlier this year, we added the
topoly_solver package in Maxima to our solve routines to address. See
the discussion at
http://groups.google.com/group/sage-support/browse_thread/thread/6de90b91d7cf0f75/70b437ea856ff030?#70b437ea856ff030.
I cannot find the ticket where this was added, though a few days ago I
could.
Anyway, the reason for this is that the solve routine for multiple
equations in Maxima (which to_poly_solve uses) allows non-exact
answers as output. This is documented (see algsys). In fact, trying
to solve the equation above and y==1 simultaneously will yield the
float answers.
What is the desired behavior of solve()? Since roots() uses it for
symbolic input, we already have some problems (also note that
to_poly_solve does not return multiplicities). However, getting rid
of to_poly_solve seems unpleasant too, since it does solve a lot of
equations which formerly were mysterious to Sage.
If you have an opinion, please let me know. Unfortunately, it doesn't
look easy to keep an exact-solution-only behavior here. The author of
to_poly_solve expects to fix some bugs later this fall, but probably
not this aspect, since it's not a bug in Maxima, rather in our use of
Maxima.
- kcrisman
Dirk
> We have some inconsistency in solve.
>
> sage: solve(x^5+x^3+17*x+1,x)
>
> [x == -0.0588115172555,
> x == (-1.33109991788 + 1.52241655184*I),
> x == (-1.33109991788 - 1.52241655184*I),
> x == (1.36050567904 + 1.5188087221*I),
> x == (1.36050567904 - 1.5188087221*I)]
>
solution is possible in the case of a system of more than one
equation. So make sure you have only one equation, thus:
sage: solve([x^5+x^3+17*x+1],x)
[0 == x^5 + x^3 + 17*x + 1]
By the way, the numerical answers you got are very bad, but Maxima is
not a numerical analysis package. The way to get good numerical roots
is:
sage: pari('x^5+x^3+17*[x + (0.0588115223184494 + 0.E-38*I), 1; x +
(-1.36050567903502 +
1.51880872209965*I), 1; x + (1.33109991787580 + 1.52241655183732*I),
1;
x + (-1.36050567903502 - 1.51880872209965*I), 1; x + (1.33109991787580
-
1.52241655183732*I), 1]x+1+0.*I').factor()
Dirk
Jason Grout
>
> By the way, the numerical answers you got are very bad, but Maxima is
> not a numerical analysis package. The way to get good numerical roots
> is:
> sage: pari('x^5+x^3+17*[x + (0.0588115223184494 + 0.E-38*I), 1; x +
> (-1.36050567903502 +
> 1.51880872209965*I), 1; x + (1.33109991787580 + 1.52241655183732*I),
> 1;
> x + (-1.36050567903502 - 1.51880872209965*I), 1; x + (1.33109991787580
> -
> 1.52241655183732*I), 1]x+1+0.*I').factor()
>
Or using Sage interval arithmetic:
sage: R.<x>=QQbar[]
sage: a=(x^5+x^3+17*x+1)
sage: a.roots()
[(-0.05881152231844944?, 1),
(-1.331099917875796? - 1.522416551837318?*I, 1),
(-1.331099917875796? + 1.522416551837318?*I, 1),
(1.360505679035020? - 1.518808722099650?*I, 1),
(1.360505679035020? + 1.518808722099650?*I, 1)]
Jason
--
Jason Grout
kcrisman
trouble in that sense, I would have posted on sage-support.
My question is, what behavior should Sage ALLOW from solve? I am in
the midst of fixing some solve behavior caused by the Maxima upgrade,
and want someone else's opinion. One idea I had was a keyword to
allow to_poly_solve (which allows better answers, but also inexact
ones) and very careful documentation to point out that solve with more
than one equation may return numerical answers.
<snip>
kcrisman
http://groups.google.com/group/sage-support/browse_thread/thread/6407896aab6a52cc/bfb4e85815ef94a3?show_docid=bfb4e85815ef94a3
. I now think we should definitely change to having to_poly_solve as
an option, but not default, even if we miss some solutions that way,
because it's unlikely that Maxima will be able to change its behavior
very soon, even if they wanted to.
- kcrisman
Burcin Erocal
I don't use the solve() function at all. I'm probably missing the
user's point of view completely, so please take what I say below with a
grain of salt.
Going by the "What Would Maple Do" rule, I would like solve() to remain
exact. Looking through the examples here
http://www.maplesoft.com/support/help/view.aspx?path=examples/solve
I couldn't see any cases where Maple switches to numeric results.
I think it's better to return no results if the exact methods don't
work, and point the user to the numeric solver. This is fsolve [1] in
the case of Maple. Is it find_root() in Sage?
[1] http://www.maplesoft.com/support/help/view.aspx?path=fsolve
On Thu, 17 Sep 2009 06:30:19 -0700 (PDT)
kcrisman <kcri...@gmail.com> wrote:
>
> For a frustrated user because of precisely this issue, see
> http://groups.google.com/group/sage-support/browse_thread/thread/6407896aab6a52cc/bfb4e85815ef94a3?show_docid=bfb4e85815ef94a3
> . I now think we should definitely change to having to_poly_solve as
> an option, but not default, even if we miss some solutions that way,
> because it's unlikely that Maxima will be able to change its behavior
> very soon, even if they wanted to.
In this case, I agree that we should make to_poly_solve a non-default
option.
Thanks.
Burcin
Maurizio
why do we keep the "numerical solve" function with a completely
different name? I know that "find_root" or "roots" make sense, but
wouldn't just be much better to name them "solve_numerical", or
anything like putting a postfix after the word "solve"?
I don't know whether this is generally a good thing to do, but I just
keep finding it so easy if I do "solve[Tab]" so that ALL the functions
related to solving equations are shown (both exact and numerical)
cheers
maurizio
On Sep 17, 4:52 pm, Burcin Erocal <bur...@erocal.org> wrote:
> Hi,
>
> I don't use the solve() function at all. I'm probably missing the
> user's point of view completely, so please take what I say below with a
> grain of salt.
>
> Going by the "What Would Maple Do" rule, I would like solve() to remain
> exact. Looking through the examples here
>
> http://www.maplesoft.com/support/help/view.aspx?path=examples/solve
>
> I couldn't see any cases where Maple switches to numeric results.
>
> I think it's better to return no results if the exact methods don't
> work, and point the user to the numeric solver. This is fsolve [1] in
> the case of Maple. Is it find_root() in Sage?
>
> [1]http://www.maplesoft.com/support/help/view.aspx?path=fsolve
>
> On Thu, 17 Sep 2009 06:30:19 -0700 (PDT)
>
>
> > For a frustrated user because of precisely this issue, see
Jason Grout
> My 2 cents here:
> why do we keep the "numerical solve" function with a completely
> different name? I know that "find_root" or "roots" make sense, but
> wouldn't just be much better to name them "solve_numerical", or
> anything like putting a postfix after the word "solve"?
> I don't know whether this is generally a good thing to do, but I just
> keep finding it so easy if I do "solve[Tab]" so that ALL the functions
> related to solving equations are shown (both exact and numerical)
Great idea. We can make an alias:
solve_numerical=find_root
Does find_root take general symbolic expressions (i.e., x==x^2)?
Jason
--
Jason Grout
kcrisman
> Great idea. We can make an alias:
>
> solve_numerical=find_root
>
> Does find_root take general symbolic expressions (i.e., x==x^2)?
>
must specify an interval ahead of time. That being said, you can
specify the interval to be -infinity to infinity, but that will not
always do so well! For instance, the example you give fails to
converge on that interval, while it does on the interval -10 to 10 (on
-100 to 100, it gets close to 1.0 but not quite there).
- kcrisman
Dirk
like to re-make one of my points.
sage: solve(x^5+x^3+17*x+1,x)
[x == -0.0588115172555,
x == (-1.33109991788 + 1.52241655184*I),
x == (-1.33109991788 - 1.52241655184*I),
x == (1.36050567904 + 1.5188087221*I),
x == (1.36050567904 - 1.5188087221*I)]
[0 == x^5 + x^3 + 17*x + 1]
()? Don't misunderstand me: I don't mean "can it be explained as a
Maxima quirk", I mean "is it this the behaviour intended by the SAGE
design team?"
Dirk
niels
> sage:solve(x^5+x^3+17*x+1,x) ...
I think it should at least be clear over what ring the user wants to
solve, then it is also clear which method should be used.
* If the coefficients are algebraic/transcendental over QQ then
symbolic algebraic are often preferred
* Over finite fields probably just try everything (but maybe something
better)
* Over RR or CC a numerical solver is often preferred (since already
the input coefficients are probably not precise, and more geometrical
methods are used)
I think that symbolic expressions don't mean so much if the ring is
not specified (or is it?).
This is in my opinion very confusing.
Kind regards,
Niels
kcrisman
not with one. I've already got catching that case as part of my
changes (which are, alas, not quite ready for a patch), as I noticed
it early on (and I think others did as well).
- kcrisman
kcrisman
On Sep 18, 9:42 am, niels <niels.lub...@gmail.com> wrote:
> > Does find_root take general symbolic expressions (i.e., x==x^2)? ...
> > sage:solve(x^5+x^3+17*x+1,x) ...
>
> I think it should at least be clear over what ring the user wants to
> solve, then it is also clear which method should be used.
>
> * If the coefficients are algebraic/transcendental over QQ then
> symbolic algebraic are often preferred
>
> * Over finite fields probably just try everything (but maybe something
> better)
>
> * Over RR or CC a numerical solver is often preferred (since already
> the input coefficients are probably not precise, and more geometrical
> methods are used)
over; most or even all of what you suggest is possible if you do that.
>
> I think that symbolic expressions don't mean so much if the ring is
> not specified (or is it?).
> This is in my opinion very confusing.
>
elements in SR come from; they all just become symbolic expressions.
Even with the .coeffs() method, they still end up coming out as
symbolic expressions. Burcin or others will clarify, but probably the
idea was that symbolic means just that - symbolic, with no reference
to other things. If you really want polynomials, you need to do
something like
sage: R.<x> = CC[]
sage: x^2+1
and go from there, I think. That is occasionally annoying to those of
us who primarily teach undergraduates, but essential for many of the
applications of Sage.
- kcrisman
Robert Bradshaw
I like the idea of solve(f) attempting to call f.solve(), which would
handle the finite field and numerical cases much nicer. However, it
should probably not be synonymous with roots, as I'd want a
polynomial over RR to return its complex roots as well. (Not sure
what to do about the case above, the answer is pretty useless... IIRC
some systems return an object "roots of ..." which then can be
numerically approximated.
- Robert
Burcin Erocal
kcrisman <kcri...@gmail.com> wrote:
> I don't know if there is a way to get at where coefficients of
> elements in SR come from; they all just become symbolic expressions.
> Even with the .coeffs() method, they still end up coming out as
> symbolic expressions. Burcin or others will clarify, but probably the
> idea was that symbolic means just that - symbolic, with no reference
> to other things.
Symbolic expressions keep python objects for numeric values or
coefficients. You can get at the python object wrapped by an expression
using the .pyobject() method and ask for its parent.
sage: t = Mod(3,5)
sage: t.parent()
Ring of integers modulo 5
sage: u = SR(t)
sage: u
3
sage: u.parent()
Symbolic Ring
sage: u.pyobject().parent()
Ring of integers modulo 5
Cheers,
Burcin
kcrisman
On Sep 19, 11:41 am, Burcin Erocal <bur...@erocal.org> wrote:
> On Fri, 18 Sep 2009 09:34:35 -0700 (PDT)
>
- kcrisman
x x
i am more familiar with sage and python. I am not sure whether this
belongs to sage-support or sage-devel, since i don't understand the
architecture, in particular relating to the Symbolic expressions.
That being said, i still don't understand what Symbolic expressions are.
>> sage: t = Mod(3,5)
>> sage: t.parent()
>> Ring of integers modulo 5
>> sage: u = SR(t)
>> sage: u
>> 3
>> sage: u.parent()
>> Symbolic Ring
>> sage: u.pyobject().parent()
>> Ring of integers modulo 5
In this example t is defined over "Ring of integers modulo 5", which
is great, because i heard about this before. It is wrapped in a SR,
for some reason, and afterwards the ring can be retrieved. No problem.
>> Symbolic expressions keep python objects for numeric values or coefficients.
Why is this object accessible to the user?
>Try sage: x.roots? for documentation about specifying rings to solve
>over; most or even all of what you suggest is possible if you do that.
Thanks i wasn't aware of this function, and the functionality is
indeed there. However i disagree if no ring is specified. Here is an
example (see first example x.roots)
------------------
var('x')
x.parent()
OUTPUT: Symbolic Ring
f=(x^2-1)^2
f.pyobject().parent()
OUTPUT: TypeError: self must be a numeric expression
f.parent()
OUTPUT: Symbolic Ring
f.roots()
OUTPUT: [(-1, 2), (1, 2)]
------------------
In the documentation of x.roots:
- ``ring`` - a ring (default None): if not None, convert
self to a polynomial over ring and find roots over ring
------------------
So from a mathematical point of view, it seems that a symbolic ring is
the polynomial ring with ground field determined by the coefficients
(?). Is this consistent with all the functions taking symbolic
expressions without a ring specified?
>If you really want polynomials, you need to do
>something like
>
>sage: R.<x> = CC[]
>sage: x^2+1
>
>and go from there, I think. That is occasionally annoying to those of
>us who primarily teach undergraduates, but essential for many of the
>applications of Sage.
It seems to me that not specifying the ring explicitly is even more
difficult to teach. At least i hope so, because i don't understand it
yet.
As i understand "solve" differs from "roots" in that is solves systems
of equation instead of a single equation. In solve it is not even
possible to specify a ring, and only can solve in ""Symbolic""
expressions.
Thanks,
niels
Burcin Erocal
On Sun, 20 Sep 2009 15:45:37 +0200
x x <niels....@gmail.com> wrote:
>
> Sage is a great project in my opinion, and i hope to contribute, when
> i am more familiar with sage and python. I am not sure whether this
> belongs to sage-support or sage-devel, since i don't understand the
> architecture, in particular relating to the Symbolic expressions.
>
> That being said, i still don't understand what Symbolic expressions
> are.
Symbolic expressions are where sin(x), x^y, etc. live. In systems like
Maple or MMA, everything is a symbolic expression. This let's you do
formal symbol manipulation without worrying about the mathematical
background. Sage also let's the user work with algebraic structures,
similar to Axiom, Magma, etc.
> >> sage: t = Mod(3,5)
> >> sage: t.parent()
> >> Ring of integers modulo 5
> >> sage: u = SR(t)
> >> sage: u
> >> 3
> >> sage: u.parent()
> >> Symbolic Ring
> >> sage: u.pyobject().parent()
> >> Ring of integers modulo 5
>
> In this example t is defined over "Ring of integers modulo 5", which
> is great, because i heard about this before. It is wrapped in a SR,
> for some reason, and afterwards the ring can be retrieved. No problem.
Say you want to work with t^n for some unspecified number n. You can do
this:
sage: var('n')
n
sage: u^n
3^n
After you're done computing, substituting a value for n will evaluate
the expression:
sage: (u^n).subs(n=5)
3
sage: res = (u^n).subs(n=5)
sage: res.parent()
Symbolic Ring
You can use .pyobject() on res to go back to working in Ring of
integers modulo 5.
<snip>
> So from a mathematical point of view, it seems that a symbolic ring is
> the polynomial ring with ground field determined by the coefficients
> (?).
"Symbolic ring" is an unfortunate name. It doesn't mean much from the
"mathematical point of view." It's just where all the symbolic stuff
live in Sage. Maybe we should call it symbolic parent.
> Is this consistent with all the functions taking symbolic
> expressions without a ring specified?
I don't understand this question.
> >If you really want polynomials, you need to do
> >something like
> >
> >sage: R.<x> = CC[]
> >sage: x^2+1
> >
> >and go from there, I think. That is occasionally annoying to those
> >of us who primarily teach undergraduates, but essential for many of
> >the applications of Sage.
>
> It seems to me that not specifying the ring explicitly is even more
> difficult to teach. At least i hope so, because i don't understand it
> yet.
AFAICT, most non mathematician users prefer to work with symbols
instead of using the algebraic structures directly.
> As i understand "solve" differs from "roots" in that is solves systems
> of equation instead of a single equation. In solve it is not even
> possible to specify a ring, and only can solve in ""Symbolic""
> expressions.
The function solve() is meant to correspond to the solve command in
Maple and MMA, which try to find "solutions" to whatever you throw at
them. Here is the documentation for solve in Maple:
http://www.maplesoft.com/support/help/view.aspx?path=solve
ATM, Sage calls various functions in maxima to do this. As discussed in
this thread, this doesn't work very well.
Cheers,
Burcin
x x
Thanks for the explanation!
> "Symbolic ring" is an unfortunate name. It doesn't mean much from the
> "mathematical point of view." It's just where all the symbolic stuff
> live in Sage. Maybe we should call it symbolic parent.
I agree that the naming is unfortunate. I think it would be a good
idea to add this remark in the documentation.
> AFAICT, most non mathematician users prefer to work with symbols
> instead of using the algebraic structures directly.
I hope this idea is not based on Maple and MMA having such symbolic parents.
In any case i think it should be easy to explain what is happening,
although some users are not aware.
In your example t=3 is in ZZ_5 and u is a function from ZZ_5 to ZZ_5,
mapping n to 3^n. So although some users may be not aware, they are
actually working over the ring ZZ_5.
What i do understand is that for example elements in QQBar should be
represented by symbols (sqrt(2) instead of a numerical value 1,... or
pi instead of 3.14... ).
An computer algebra system should be able to manipulate these symbols,
such that it is mathematically correct in a given algebraic structure.
I think that the output is then both for mathematicians and non
mathematicians better understandable, and such symbolic inputs are
also more human readable.
Sorry if i am stating the obvious here, the reason is that i am trying
to explain why i think it should be (either implicit or explicit)
clear over which algebraic structure is computed.
Cheers,
Niels
Nick Alexander
> to explain why i think it should be (either implicit or explicit)
> clear over which algebraic structure is computed.
Generally it is -- try parent(foo) or foo.parent() to see what
"algebraic structure" is in play.
sage: Zmod(5)(1).parent()
Ring of integers modulo 5
sage: (Zmod(5)(-1) * sin(x))
4*sin(x)
sage: (Zmod(5)(-1) * sin(x))^2
sin(x)^2
sage: (Zmod(5)(-1) * sin(x)).parent()
Symbolic Ring
Now this is irritating, perhaps, but there is no way to avoid this
given the "parents with objects" approach that Sage subscribes to:
sage: t = (Zmod(5)(3) * sin(x))^2
sage: t
4*sin(x)^2
sage: t.operands()
[sin(x)^2, 4]
sage: t.operands()[-1]
4
sage: t.operands()[-1].parent()
Symbolic Ring
sage: t.operands()[-1].pyobject().parent()
Ring of integers modulo 5
So the algebraic structure really is there, it's just that the
"Symbolic Ring" algebraic structure is very permissive: it's not
really "algebraic" in a mathematical sense.
Nick
Robert Bradshaw
The problem is that most elements of QQBar can't be represented this
way, and even if they can be it's expensive. (Maybe a printing mode
would be good..., but "Root of x^5 - x - 1 closest to 1.18... +
1.08...i" is pretty verbose).
- Robert
rjf
refined more recently than Maxima's solve, you can look at
Mathematica's
Solve, NSolve, RSolve, Reduce, and maybe some others like Eliminate.
Maxima's solve dates to 1971, but there is also linsolve, algsys,
realroots, and some other programs that you can probably find in the
documentation ... roots, newton... and there may also be numerical
rootfinders in the Fortran library. The decision as to whether
to_poly_solve does the job for you (apparently not, at least at the
moment) or not, is only one aspect.
I am pleased that you consider, at least as an option, augmenting
Maxima by loading in programs into Maxima written in the Maxima
language (to_poly_solve). Maybe someone would define what you want
Sage's "solve" to do in all cases, and feed the disambiguation
information to a short Maxima program that then calls solve,
to_poly_solve, roots, etc etc as
necessary. You might even find that your short program would be
useful to people directly using Maxima.
There is, in my experience, a gap between people who think that all
roots of a polynomial can be found [by complex rootfinders] and those
people who want exact algebraic expressions. Or those who want
rational isolating intervals for each real root, computed by Sturm
sequences.
And then there are the people who need to represent infinite sets like
the roots of sin(x)=0.
The gap between these groups is kind of cognitive. Like "what do you
mean you can't find the roots of a quintic because it is unsolvable??
It has 5 roots!"
etc
RJF
Jason Grout
>>
>> What i do understand is that for example elements in QQBar should be
>> represented by symbols (sqrt(2) instead of a numerical value 1,... or
>> pi instead of 3.14... ).
>
> The problem is that most elements of QQBar can't be represented this
> way, and even if they can be it's expensive. (Maybe a printing mode
> would be good..., but "Root of x^5 - x - 1 closest to 1.18... +
> 1.08...i" is pretty verbose).
And pi can't be represented by QQbar at all!
Jason
--
Jason Grout
x x
Thanks for the correction! What I meant was a transcendental extension over QQ.
Robert Bradshaw
Yep, we support various root numerical root finders, linear solvers,
grobner bases, and symbolic solvers (via Maxima--you're right, we
should look into exposing and using the various package here). The
non-symbolic ones are typically orders of magnitude faster, if you're
in that special case. This is one area where the idea of a domain
like Sage has is useful.
sage: x = ZZ['x'].gen()
sage: f = x^6 - 2*x^5 - x^2 + x + 2
sage: f.roots(QQ)
[(2, 1)]
sage: f.roots(QQbar) # these are exact
[(1.167303978261419?, 1), (2, 1), (-0.7648844336005847? -
0.3524715460317263?*I, 1), (-0.7648844336005847? + 0.3524715460317263?
*I, 1), (0.1812324444698754? - 1.083954101317711?*I, 1),
(0.1812324444698754? + 1.083954101317711?*I, 1)]
sage: f.roots(RR)
[(1.16730397826142, 1), (2.00000000000000, 1)]
sage: f.roots(RealField(500))
[(1.16730397826141868425604589985484218072056037152548903914008244927565
190342952705318068520504972867289535916899524104793645129596750871791336
957872256, 1),
(2.000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
00000000, 1)]
sage: f.roots(CDF)
[(1.16730397826, 1), (2.0, 1), (-0.764884433601 - 0.352471546032*I,
1), (-0.764884433601 + 0.352471546032*I, 1), (0.18123244447 -
1.08395410132*I, 1), (0.18123244447 + 1.08395410132*I, 1)]
sage: f.roots(GF(17))
[(8, 1), (6, 1), (2, 1)]
sage: sage: f.roots(Qp(17, 5))
[(8 + 17 + 2*17^2 + 17^3 + 11*17^4 + O(17^5), 1),
(6 + 17 + 8*17^2 + 14*17^3 + 7*17^4 + O(17^5), 1),
(2 + O(17^5), 1)]
Alternatively,
sage: x = RR['x'].gen()
sage: f = x^6 - 2*x^5 - x^2 + x + 2
sage: parent(f)
Univariate Polynomial Ring in x over Real Field with 53 bits of
precision
sage: f.roots()
[(1.16730397826142, 1), (2.00000000000000, 1)]
etc.
- Robert
John Cremona
So it is worth pointing out that x=polygen(ZZ), x=polygen(RR) etc do
the same and are less obfuscatory.
John
2009/9/26 Robert Bradshaw <robe...@math.washington.edu>:
Stan Schymanski
Typically, when I want to solve a complicated equation, sage throws
various questions generated by maxima at me, about whether variables
and certain terms are positive, zero, or negative. Some of them can be
answered a priori by appropriate assume() statements, others can't, so
I often run into a dead end and can't solve equations that would be
easily solved by MMA. Very frustrating.
Would it be hard to write a routine, which answers all of maxima's
questions with all possible answers and creates a new solution branch
for each answer? I think this is what MMA's Reduce does, and at the
end it presents the result as a list of nested conditions for each
solution. Would anyone else be interested in such a functionality and,
more importantly, would anyone have the know-how and time to implement
it?
Cheers
Stan
On Sep 24, 3:11 am, rjf <fate...@gmail.com> wrote:
> If you want to look at possible definitions ofsolvethat have been
> refined more recently than Maxima'ssolve, you can look at
> Mathematica'sSolve, NSolve, RSolve, Reduce, and maybe some others like Eliminate.
>
> Maxima'ssolvedates to 1971, but there is also linsolve, algsys,
William Stein
>
> I am really, really missing a function like MMA's Reduce in sage.
> Typically, when I want to solve a complicated equation, sage throws
> various questions generated by maxima at me, about whether variables
> and certain terms are positive, zero, or negative. Some of them can be
> answered a priori by appropriate assume() statements, others can't, so
> I often run into a dead end and can't solve equations that would be
> easily solved by MMA. Very frustrating.
>
> Would it be hard to write a routine, which answers all of maxima's
> questions with all possible answers and creates a new solution branch
> for each answer? I think this is what MMA's Reduce does, and at the
> end it presents the result as a list of nested conditions for each
> solution. Would anyone else be interested in such a functionality and,
> more importantly, would anyone have the know-how and time to implement
> it?
I think it would be very interesting to try to write such a function,
and there are certainly people with the appropriate knowledge...
William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Jason Grout
Carl Witty would be one person to write a real Reduce replacement.
Reduce uses CAD, which has been a personal sage project of Carl Witty's
for at least several years. That's where we have QQbar and AA from, for
example (he needed it to do CAD stuff). Carl's made a lot of progress,
and from what I understand, he's probably several months away (of
full-time work) of having a finished CAD implementation in Sage. I
might be wrong on that point, though.
Right now, we do have an interface to qepcad that can do some of the
stuff, but I don't think it's quite as powerful as Reduce. It can do a
lot, though.
Jason
--
Jason Grout
William Stein
Carl stopped working on or contributing to Sage several months ago.
William
> Right now, we do have an interface to qepcad that can do some of the
> stuff, but I don't think it's quite as powerful as Reduce. It can do a
> lot, though.
>
> Jason
>
>
> --
> Jason Grout
>
>
> >
>
kcrisman
On Oct 1, 11:36 am, William Stein <wst...@gmail.com> wrote:
>
> > I am really, really missing a function like MMA's Reduce in sage.
> > Typically, when I want to solve a complicated equation, sage throws
> > various questions generated by maxima at me, about whether variables
> > and certain terms are positive, zero, or negative. Some of them can be
> > answered a priori by appropriate assume() statements, others can't, so
> > I often run into a dead end and can't solve equations that would be
> > easily solved by MMA. Very frustrating.
>
> > Would it be hard to write a routine, which answers all of maxima's
> > questions with all possible answers and creates a new solution branch
> > for each answer? I think this is what MMA's Reduce does, and at the
> > end it presents the result as a list of nested conditions for each
> > solution. Would anyone else be interested in such a functionality and,
> > more importantly, would anyone have the know-how and time to implement
> > it?
>
> I think it would be very interesting to try to write such a function,
> and there are certainly people with the appropriate knowledge...
it probably requires a program that answers Maxima questions on the
fly and tries again and again, keeping track of the results, which I'm
not sure if pexpect would easily support (?) ... can you interact
directly with Maxima that way?
A less urgent question would be what recursion depth would be
appropriate. Another is that this will definitely not always work,
since sometimes even assuming the things Maxima asks does not result
in the answer. This isn't necessarily a limitation of Maxima, since
some of these things probably don't have a finite decision routine -
but still annoying.
Still, this idea is worth trying for others to play with. Especially
if it were first implemented with a 1 or 2 level recursion, it would
help out with a lot of integrals and limits which just need to know
x>,<,==0. How efficient is Mma's Reduce for this sort of thing?
- kcrisman
William Stein
>
>
>
> On Oct 1, 11:36 am, William Stein <wst...@gmail.com> wrote:
>> On Thu, Oct 1, 2009 at 8:33 AM, Stan Schymanski <schym...@gmail.com> wrote:
>>
>> > I am really, really missing a function like MMA's Reduce in sage.
>> > Typically, when I want to solve a complicated equation, sage throws
>> > various questions generated by maxima at me, about whether variables
>> > and certain terms are positive, zero, or negative. Some of them can be
>> > answered a priori by appropriate assume() statements, others can't, so
>> > I often run into a dead end and can't solve equations that would be
>> > easily solved by MMA. Very frustrating.
>>
>> > Would it be hard to write a routine, which answers all of maxima's
>> > questions with all possible answers and creates a new solution branch
>> > for each answer? I think this is what MMA's Reduce does, and at the
>> > end it presents the result as a list of nested conditions for each
>> > solution. Would anyone else be interested in such a functionality and,
>> > more importantly, would anyone have the know-how and time to implement
>> > it?
>>
>> I think it would be very interesting to try to write such a function,
>> and there are certainly people with the appropriate knowledge...
>
> I've thought about this... one problem I've heard about this is that
> it probably requires a program that answers Maxima questions on the
> fly and tries again and again, keeping track of the results, which I'm
> not sure if pexpect would easily support (?) ... can you interact
> directly with Maxima that way?
" Pexpect can be used for automating interactive applications such as
ssh, ftp, passwd, telnet, etc."
>
> A less urgent question would be what recursion depth would be
> appropriate.
experimentation, which can be controlled by the user. Problem solved.
> Another is that this will definitely not always work,
> since sometimes even assuming the things Maxima asks does not result
> in the answer. This isn't necessarily a limitation of Maxima, since
> some of these things probably don't have a finite decision routine -
> but still annoying.
>
> Still, this idea is worth trying for others to play with. Especially
> if it were first implemented with a 1 or 2 level recursion, it would
> help out with a lot of integrals and limits which just need to know
> x>,<,==0. How efficient is Mma's Reduce for this sort of thing?
>
> - kcrisman
> >
>
Jason Grout
> There's the small problem that as far as I can tell, unfortunately
> Carl stopped working on or contributing to Sage several months ago.
Yes, I haven't seen him around either. My guess is that someone
interested/capable of implementing CAD would get a huge headstart if
they could use the code Carl was working on. It's probably worth an
email to him, if someone was willing to take up the project.
Carl, if you're reading this still, could you comment?
Jason
--
Jason Grout
Robert Dodier
> Would it be hard to write a routine, which answers all of maxima's
> questions with all possible answers and creates a new solution branch
> for each answer?
business; the result is the "noninteractive" add-on package.
It sort of works, but it's easy to find cases for which it fails.
Some successful cases and some failures are stated in the
comment header of noninteractive.mac (in the Maxima distribution).
The general strategy was to intercept questions and generate
the alternatives and re-evaluate under each alternative.
That way it's not necessary to change the code at all of the
places at which questions are generated. I considered that
also and decided against it.
If anyone is interested, I would very much appreciate your help.
FWIW
Robert Dodier
Stan Schymanski
On Oct 1, 5:58 pm, kcrisman <kcris...@gmail.com> wrote:
[Snip]
> Still, this idea is worth trying for others to play with. Especially
> if it were first implemented with a 1 or 2 level recursion, it would
> help out with a lot of integrals and limits which just need to know
> x>,<,==0. How efficient is Mma's Reduce for this sort of thing?
>
> - kcrisman
MMA. I tried including a few assumptions to reduce the length of the
output of Reduce[], but it didn't help. Basically, every solution is a
set of conditions linked by '&&', while different solutions are
separated by '||'. I find this kind of output pretty helpful, as it
allows simple tests and then picking the right solution for each case.
Note also that MMA's Reduce[] also solves inequalities. Not sure if
maxima can do this, but it would be great.
Cheers,
Stan
Reduce[wv == (wv1 /. wb -> wb1) && p > 0 && veloc > 0 && mort > 0 &&
lwat > 0 && jbiom > 0 && rwat > 0 && av >= 0, wv, Reals]
(veloc > 0 && av > 1 && lwat == veloc/(-av + av^2) && rwat > 0 &&
p > 0 && mort > 0 &&
jbiom > 0 && (bv == -Sqrt[((
av^2 lwat^2 - av^3 lwat^2 + av lwat veloc)/(-lwat rwat +
av lwat rwat - rwat veloc))] ||
bv == Sqrt[(
av^2 lwat^2 - av^3 lwat^2 + av lwat veloc)/(-lwat rwat +
av lwat rwat - rwat veloc)])) || (veloc >
0 && ((av == 0 && lwat > 0 &&
rwat > 0 && ((bv < 0 && p > 0 && mort > 0 &&
jbiom > 0) || (bv > 0 && p > 0 && mort > 0 &&
jbiom > 0))) || (0 < av <= 1 && lwat > 0 && rwat > 0 &&
p > 0 && mort > 0 &&
jbiom > 0) || (av >
1 && ((0 < lwat < veloc/(-av + av^2) && rwat > 0 && p > 0 &&
mort > 0 && jbiom > 0) || (lwat == veloc/(-av + av^2) &&
rwat > 0 && ((bv < 0 && p > 0 && mort > 0 &&
jbiom > 0) || (bv > 0 && p > 0 && mort > 0 &&
jbiom > 0))) || (veloc/(-av + av^2) < lwat <
veloc/(-1 + av) &&
rwat > 0 && ((bv < -Sqrt[((
av^2 lwat^2 - av^3 lwat^2 +
av lwat veloc)/(-lwat rwat + av lwat rwat -
rwat veloc))] && p > 0 && mort > 0 &&
jbiom >
0) || (-Sqrt[((
av^2 lwat^2 - av^3 lwat^2 +
av lwat veloc)/(-lwat rwat + av lwat rwat -
rwat veloc))] < bv < Sqrt[(
av^2 lwat^2 - av^3 lwat^2 +
av lwat veloc)/(-lwat rwat + av lwat rwat -
rwat veloc)] && p > 0 && mort > 0 &&
jbiom > 0) || (bv > Sqrt[(
av^2 lwat^2 - av^3 lwat^2 +
av lwat veloc)/(-lwat rwat + av lwat rwat -
rwat veloc)] && p > 0 && mort > 0 &&
jbiom > 0))) || (lwat > veloc/(-1 + av) && rwat > 0 &&
p > 0 && mort > 0 && jbiom > 0)))) &&
wv == (-av^3 lwat p + av^4 lwat p - av^2 p veloc)/(-av^2 lwat^2 +
av^3 lwat^2 - bv^2 lwat rwat + av bv^2 lwat rwat -
av lwat veloc - bv^2 rwat veloc))
Stan Schymanski
This sounds great. Could this package be used from within sage, or would
it have to be run on a separate installation of maxima? If it runs from
within sage, it would probably already solve part of the problem!
Cheers,
Stan
kcrisman
remember the earlier discussion but didn't know something concrete
came out of it.
Incidentally, to Stan, I think that
sage: sage.calculus.calculus.maxima.eval('load(noninteractive);')
should do it (or some variant thereof). It's important to use the
calculus copy of maxima, so it knows about whatever you do with
symbolics.
- kcrisman
Jason Grout
>
>
> On Oct 1, 5:58 pm, kcrisman <kcris...@gmail.com> wrote:
> [Snip]
>
>> Still, this idea is worth trying for others to play with. Especially
>> if it were first implemented with a 1 or 2 level recursion, it would
>> help out with a lot of integrals and limits which just need to know
>> x>,<,==0. How efficient is Mma's Reduce for this sort of thing?
>>
>> - kcrisman
>
> Not sure if this answers your question, but here is an example from
> MMA. I tried including a few assumptions to reduce the length of the
> output of Reduce[], but it didn't help. Basically, every solution is a
> set of conditions linked by '&&', while different solutions are
> separated by '||'. I find this kind of output pretty helpful, as it
> allows simple tests and then picking the right solution for each case.
> Note also that MMA's Reduce[] also solves inequalities. Not sure if
> maxima can do this, but it would be great.
>
> Cheers,
> Stan
>
> Reduce[wv == (wv1 /. wb -> wb1) && p > 0 && veloc > 0 && mort > 0 &&
>
lwat > 0 && jbiom > 0 && rwat > 0 && av >= 0, wv, Reals]
>
Can you tell us what wv, wv1, wb, wb1, veloc, mort, lwat, jbiom, rwat,
and av are?
Thanks,
Jason
--
Jason Grout
rjf
If you want to have Maxima do the same thing as Mathematica's Reduce
program
(and, by the way I think this would be good, especially since
Mathematica's Reduce
program seems to have been improved substantially so it is a store-
house of neat things, in current Mma), then you should write a program
that implements Reduce. Probably most easily done by adding to the
Maxima code.
Patching together something that answers questions from Maxima, either
in
python, pexpect, or for that matter, lisp, doesn't seem to me to be as
worthwhile.
As for the CAD (cylindrical algebraic decomposition) stuff, Reduce
has gone far beyond that. Having a program that does only CAD is not
very useful in the general world of "solve" unless you are only
interested in polynomials and in particular, CAD.
So no trig, log, exp, etc.
Implementing CAD and a good geometry data-base for assume, and writing
a version of Reduce for Maxima and/or Sage -- sure. Someone should go
ahead and design it in detail. Write a nice paper about it, perhaps.
Then decide how to implement it, in Python/Sage or "Maxima language"
or Lisp. One nice thing about the latter two choices is that it would
improve "standalone" Maxima too.
Robert Bradshaw
> I think that some of the suggestions here pretty much miss the mark.
>
> If you want to have Maxima do the same thing as Mathematica's Reduce
> program
> (and, by the way I think this would be good, especially since
> Mathematica's Reduce
> program seems to have been improved substantially so it is a store-
> house of neat things, in current Mma), then you should write a program
> that implements Reduce. Probably most easily done by adding to the
> Maxima code.
>
> Patching together something that answers questions from Maxima, either
> in python, pexpect, or for that matter, lisp, doesn't seem to me to
> be as
> worthwhile.
I agree. However, if I wanted something less powerful but still very
useful next week, putting something together that answers questions
is feasible, and I could do that on whichever side of the pexpect
barrier is most convenient for me. Just answering questions could be
a higher return on investment until something more is needed.
> As for the CAD (cylindrical algebraic decomposition) stuff, Reduce
> has gone far beyond that. Having a program that does only CAD is not
> very useful in the general world of "solve" unless you are only
> interested in polynomials and in particular, CAD.
> So no trig, log, exp, etc.
>
> Implementing CAD and a good geometry data-base for assume, and writing
> a version of Reduce for Maxima and/or Sage -- sure. Someone should go
> ahead and design it in detail. Write a nice paper about it, perhaps.
> Then decide how to implement it, in Python/Sage or "Maxima language"
> or Lisp. One nice thing about the latter two choices is that it would
> improve "standalone" Maxima too.
I hope someone does this, but if no one has the time and expertise to
design it in detail and write a paper, I'd rather see something
instead of nothing. Even better would be to see something simple
(even if it's not super powerful) in the next release of Sage, which
eventually gets thrown out when a fuller version gets developed
(probably in standalone Maxima).
- Robert
Stan Schymanski
> Can you tell us what wv, wv1, wb, wb1, veloc, mort, lwat, jbiom, rwat,
> and av are?
>
> Thanks,
>
> Jason
>
dwaterv = (av p - esv - etv - qvb + qbv);
dwaterb = (ab p - esb + qvb - qbv);
ab = 1 - av;
qvb = veloc wv/av;
qbv = veloc wb/ab;
esv = av lwat (wv/av);
etv = av rwat (wv/av) (bv/av)^2;
esb = ab lwat wb/ab;
dbv = jbiom etv - mort bv;
Reduce[0 == dwaterv && p > 0 && veloc > 0 && mort > 0 && lwat > 0 &&
jbiom > 0 && rwat > 0 && av >= 0, wv, Reals]
veloc > 0 &&
rwat > 0 && ((0 < av < 1 && lwat > 0 && p > 0 && mort > 0 &&
jbiom > 0) || (av > 1 && lwat > 0 && p > 0 && mort > 0 &&
jbiom > 0)) &&
wv == (av^3 p - av^4 p + av^2 veloc wb)/(
av^2 lwat - av^3 lwat + bv^2 rwat - av bv^2 rwat + av veloc -
av^2 veloc)
Solve[0 == dwaterv, wv]
wv1 = %[[1, 1, 2]];
{{wv -> (av^2 (-av p + av^2 p - veloc wb))/((-1 + av) (av^2 lwat +
bv^2 rwat + av veloc))}}
...
This was my last MMA project, which I recoded and finished in sage. I had quite a bit of trouble getting sage to solve some of the equations I needed to solve, but it worked in the end. Hope it will be easier in the future. When the paper is accepted, I shall put the sage code online.
Cheers,
Stan