search

rtoy / maxima

A Clone of Maxima's repo
Other
0 stars 0 forks source link

solve_rec not looking inside brackets or ... #1684

Open rtoy opened 2 months ago

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:12 Created by zmth on 2019-07-31 18:58:38 Original: https://sourceforge.net/p/maxima/bugs/3575

(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.

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:13 Created by zmth on 2019-09-18 14:47:32 Original: https://sourceforge.net/p/maxima/bugs/3575/#4f4e

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...

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:17 Created by peterpall on 2019-09-19 17:37:44 Original: https://sourceforge.net/p/maxima/bugs/3575/#13f0

Diff:


--- old
+++ new
@@ -1,6 +1,8 @@
+~~~
 (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
+*(-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.
rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:20 Created by peterpall on 2019-09-19 17:37:44 Original: https://sourceforge.net/p/maxima/bugs/3575/#a15f

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.

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:24 Created by zmth on 2019-10-02 03:26:31 Original: https://sourceforge.net/p/maxima/bugs/3575/#13f0/9c37

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.

On Thursday, September 19, 2019, 12:37:50 PM CDT, Gunter Ku00F6nigsmann" via Maxima-bugs <maxima-bugs@lists.sourceforge.net> wrote:

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

Attachments:

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:27 Created by robert_dodier on 2021-01-18 00:23:52 Original: https://sourceforge.net/p/maxima/bugs/3575/#16e1

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:31 Created by robert_dodier on 2021-01-18 00:23:52 Original: https://sourceforge.net/p/maxima/bugs/3575/#160d

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".

rtoy commented 2 months ago

Imported from SourceForge on 2024-07-04 23:15:34 Created by zmth on 2021-01-21 07:12:21 Original: https://sourceforge.net/p/maxima/bugs/3575/#16e1/ef28

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.

On Sunday, January 17, 2021, 6:23:57 PM CST, Robert Dodier via Maxima-bugs <maxima-bugs@lists.sourceforge.net> wrote:

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

Attachments: