Menu
▾
▴
#3575 solve_rec not looking inside brackets or ...
(load("solve_rec"),ans:solve(ratsimp(a[k]*(4*L*k+ 5*k+k*(2*k-1)-2*j^2-4*(L+1)*j)+a[k+1] *(-2*(L+1)*(k+1)-(k+1)*(2*k+1))),a[k]) , solve_rec(ans,a[k]) );
gives false but if use instead solve_rec(ans,a[k]) it gives an answer. The whole gist of the error
seems to be it's not solving what's inside the [...]. This one got me because all other commands DO look inside brackets and one just expects this always. Eg (ans:[x-y], solve(ans,y)) gives y=x
But (ans:[a[k]=a[k+1] ],solve_rec(ans,a[k])); gives false. Instead to get an answer must use part(ans,1)
or (ans:a[k]=a[k+1] ,solve_rec(ans,a[k])) ; It should not matter that it was within brackets as most if not all other commands and solvers ignore the brackets.
And besides in programs one often uses the results of previous computations so one must assume it is going to look inside brackets and not have to use part(....,....,....) for all single answer results anyway so all should be consistent in that respect as many functions don't have to look inside and perhaps for them even part(...,1) would be an error. And i am not talking about functions that give multiple answers for that would be different story and one would have to know to look inside brackets. Otherwise have to use a different rule for every computation of different...
Diff:
Yea and with solve I don't have to write part(....,1) esp when it returns only one result so why unlike everything else is one expected to know you have to write(part,....,1) when using recurrence when you don't have to do that for anything else- at least most everything else.
Diff:
--- old
+++ new
@@ -1,6 +1,8 @@
+~~~
(load("solve_rec"),ans:solve(ratsimp(a[k](4Lk+ 5k+k(2k-1)-2j^2-4(L+1)j)+a[k+1]
-(-2(L+1)(k+1)-(k+1)(2k+1))),a[k]) , solve_rec(ans,a[k]) ); gives false
-but if use instead solve_rec(ans,a[k]) it gives an answer. The whole gist of the error
+(-2(L+1)(k+1)-(k+1)(2*k+1))),a[k]) , solve_rec(ans,a[k]) );
+~~~
+gives false but if use instead solve_rec(ans,a[k]) it gives an answer. The whole gist of the error
seems to be it's not solving what's inside the [...]. This one got me because all other commands DO look inside brackets and one just expects this always. Eg (ans:[x-y], solve(ans,y)) gives y=x
But (ans:[a[k]=a[k+1] ],solve_rec(ans,a[k])); gives false. Instead to get an answer must use part(ans,1)
or (ans:a[k]=a[k+1] ,solve_rec(ans,a[k])) ; It should not matter that it was within brackets as most if not all other commands and solvers ignore the brackets.
The idea behind maxima's behavior is that solve() and similar programs return a list of results. Lists are demarked using brackets ([])... ...and one can either use something like first(%), last(%) or %[1] for exstracting the solution one needs. In order to keep things consistent solve() returns only a list even if it found only one result.
If solve_rec() would accept a list of equations as its first argument I would expect it to accept a list of variables that after solving this system of equations can be found on the left side of the equations that make up the resulting list of solutions.
[bugs:#3575] solve_rec not looking inside brackets or ...
Status: open
Group: None
Created: Wed Jul 31, 2019 06:58 PM UTC by dan hayes
Last Updated: Wed Sep 18, 2019 02:47 PM UTC
Owner: nobody
(load("solve_rec"),ans:solve(ratsimp(a[k](4Lk+ 5k+k(2k-1)-2j^2-4(L+1)j)+a[k+1]
(-2(L+1)(k+1)-(k+1)(2k+1))),a[k]) , solve_rec(ans,a[k]) );
gives false but if use instead solve_rec(ans,a[k]) it gives an answer. The whole gist of the error
seems to be it's not solving what's inside the [...]. This one got me because all other commands DO look inside brackets and one just expects this always. Eg (ans:[x-y], solve(ans,y)) gives y=x
But (ans:[a[k]=a[k+1] ],solve_rec(ans,a[k])); gives false. Instead to get an answer must use part(ans,1)
or (ans:a[k]=a[k+1] ,solve_rec(ans,a[k])) ; It should not matter that it was within brackets as most if not all other commands and solvers ignore the brackets.
Sent from sourceforge.net because maxima-bugs@lists.sourceforge.net is subscribed to https://sourceforge.net/p/maxima/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Maxima-bugs mailing list
Maxima-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/maxima-bugs
Related
Bugs:
#3575The idea behind maxima's behavior is that solve() and similar programs return a list of results. Lists are demarked using brackets ([])... ...and one can either use something like first(%), last(%) or %[1] for exstracting the solution one needs. In order to keep things consistent solve() returns only a list even if it found only one result.
If solve_rec() would accept a list of equations as its first argument I would expect it to accept a list of variables that after solving this system of equations can be found on the left side of the equations that make up the resulting list of solutions.
Yes it should be a standard so that one can use it in programming without having to guess what is going to happen- one uses the results of one operation to be put in another. Like calling a subroutine it is always a standard as what parameters to put in and get out rather than unexpected non-uniform behavior. Like this one particular does NOT look inside brackets while the exact same of other operations does as one should expect.
I don't think it's reasonable to expect solve_rec to guess what to do with the list of solutions returned by solve, so I don't think solve_rec should be changed as suggested here. Marking this item as "won't fix".
[bugs:#3575] solve_rec not looking inside brackets or ...
Status: wont-fix
Group: None
Labels: solve solve_rec
Created: Wed Jul 31, 2019 06:58 PM UTC by dan hayes
Last Updated: Thu Sep 19, 2019 05:37 PM UTC
Owner: nobody
(load("solve_rec"),ans:solve(ratsimp(a[k](4Lk+ 5k+k(2k-1)-2j^2-4(L+1)j)+a[k+1]
(-2(L+1)(k+1)-(k+1)(2k+1))),a[k]) , solve_rec(ans,a[k]) );
gives false but if use instead solve_rec(ans,a[k]) it gives an answer. The whole gist of the error
seems to be it's not solving what's inside the [...]. This one got me because all other commands DO look inside brackets and one just expects this always. Eg (ans:[x-y], solve(ans,y)) gives y=x
But (ans:[a[k]=a[k+1] ],solve_rec(ans,a[k])); gives false. Instead to get an answer must use part(ans,1)
or (ans:a[k]=a[k+1] ,solve_rec(ans,a[k])) ; It should not matter that it was within brackets as most if not all other commands and solvers ignore the brackets.
Sent from sourceforge.net because maxima-bugs@lists.sourceforge.net is subscribed to https://sourceforge.net/p/maxima/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Maxima-bugs mailing list
Maxima-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/maxima-bugs
Related
Bugs:
#3575I don't think it's reasonable to expect
solve_recto guess what to do with the list of solutions returned bysolve, so I don't thinksolve_recshould be changed as suggested here. Marking this item as "won't fix".