You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(58) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(2) 
2
(7) 
3

4
(4) 
5

6

7
(5) 
8

9

10
(2) 
11
(1) 
12

13

14
(1) 
15
(2) 
16
(8) 
17
(8) 
18
(2) 
19
(7) 
20
(3) 
21
(1) 
22
(2) 
23
(9) 
24
(10) 
25
(4) 
26
(3) 
27

28
(7) 
29
(2) 
30
(4) 
31
(13) 






From: SourceForge.net <noreply@so...>  20100123 22:20:05

Bugs item #2028049, was opened at 20080725 19:29 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2028049&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jerry R. Burch (jrb) Assigned to: Nobody/Anonymous (nobody) Summary: trig constants incorrectly unequal Initial Comment: For complex constants pb, pa, and pc (see below for defs) I get: (%i9) is(equal(pb,pc+pa)) (%o9) true (%i10) is(equal(realpart(pb),realpart(pc+pa))) (%o10) false Here are the defs: (%i3) b:%pi/8 (%o3) %pi/8 (%i4) a:b%pi/4 (%o4) %pi/8 (%i5) c:%pi/4+b (%o5) 3*%pi/8 (%i6) pb:sqrt(2)*%e^(%i*b) (%o6) sqrt(2)*%e^(%i*%pi/8) (%i7) pa:%e^(%i*a) (%o7) %e^(%i*%pi/8) (%i8) pc:%e^(%i*c) (%o8) %e^(3*%i*%pi/8) Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20100123 23:20 Message: This problem can be reduced to the following two expressions: (%i1) a: sqrt(2)*%e^(%i*%pi/8)$ (%i2) b: %e^(3*%i*%pi/8)+%e^(%i*%pi/8)$ (%i3) is(equal(a,b)); (%o3) true (%i6) is(equal(realpart(a),realpart(b))); (%o6) false The problem is that Maxima does not recognise the equivalence of the two expressions: (%i9) realpart(a); (%o9) sqrt(2)*cos(%pi/8) (%i10) realpart(b); (%o10) cos(3*%pi/8)+cos(%pi/8) A workaround is to load spangl.mac. This file contains more general simplifications for expressions like cos(n*%pi/m). (%i44) load(spangl)$ Now cos(3*%pi/8) simplifies: (%i47) realpart(b); (%o47) sin(%pi/8)+cos(%pi/8) But it does not help completely: (%i45) is(equal((realpart(a)),realpart(b))); (%o45) false We need an extra expand to get the expected result. (%i46) is(equal(realpart(a),realpart(b))),expand; (%o46) true I think, we do not have a bug, but a missing feature. Maxima does not simplify the involved trigonometric expressions to a canonical form which can be easier tested to be equal. I suggest to close this bug report. Perhaps we should open a feature request. Setting the status to pending. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2028049&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 21:20:20

Bugs item #2938177, was opened at 20100123 22:20 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2938177&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: simplify_sum(sum(k^n,k,1,m)) > stack overflow Initial Comment: The following example causes a crash of Maxima: (%i1) load(simplify_sum)$ (%i2) sum(k^n,k,1,m); (%o2) 'sum(k^n,k,1,m) (%i3) simplify_sum(%); INFO: Control stack guard page unprotected Control stack guard page temporarily disabled: proceed with caution Maxima encountered a Lisp error: Observed with Maxima 5.20post and SBCL 1.0.29. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2938177&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 20:40:18

Bugs item #2933882, was opened at 20100117 18:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933882&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Power function: 0^a not fully implemented Initial Comment: We assume a to be positive: (%i1) assume(a>0)$ This is correct: (%i2) 0^a; (%o2) 0 The exponent is negative. The result is not correct: (%i3) 0^a; (%o3) 0 The realpart of the exponent is positive. Therefore we should give zero as a result: (%i4) 0^(a+%i*y); 0 to a complex quantity has been generated.  an error. To debug this try: debugmode(true); (%i5) 0^(2+%i*10); 0 to a complex quantity has been generated.  an error. To debug this try: debugmode(true); Maxima simplifies all expressions which does not contain the symbol %i to zero. Furthermore, Maxima does not look at the sign of the realpart. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100123 21:40 Message: Fixed in revision 1.97 of simp.lisp. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933882&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 18:31:02

Bugs item #2938078, was opened at 20100123 13:31 Message generated for change (Tracker Item Submitted) made by jansel0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2938078&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Ansel (jansel0) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on attached input Initial Comment: Attached input file generates problems for some newer version of maxima in ubuntu/debian. The input is generated by my program. 5.13.03.1+b1 (from debian lenny/amd64) Works fine 5.17.11 (from debian squeeze/amd64) Works fine 5.17.11ubuntu1 (from ubuntu karmic/amd64) Seg Fault, no error reported $ maxima < maxima.input > /dev/null zsh: segmentation fault maxima < maxima.input > /dev/null 5.20.13 (from debian sid/amd64) Abort(), following error reported: $ maxima < maxima.input  tail (%i26) (%o26) [_r1_x >= 0] (%i27) (%o27) [n >= _r1_x] (%i28) (%o28) [equal(i, _r1_x)] (%i29) (%o29) true (%i30) (%o30) true (%i31) Maxima encountered a Lisp error: Unrecoverable error: value stack overflow. zsh: abort maxima < maxima.input  zsh: done tail  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2938078&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 16:34:34

Bugs item #2937182, was opened at 20100122 14:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Assume does not always affect ratsimp/fullratsimp result Initial Comment: First, assume that x>=0: assume(x>=0); facts(); // returns x>=0 is(fullratsimp(sqrt(x^2))=x); // returns TRUE Now, forget about x>=0 and assume x<0: forget(x>=0); assume(x<0); facts(); // returns 0>x is(fullratsimp(sqrt(x^2))=x); // returns FALSE Is the expected result here TRUE instead of FALSE? For me this result is unexpected. It was achieved using the SAGE 4.3 system which is shipped with Maxima 5.20. I'm not sure this bug is related to Maxima, but it seems so. The behavior of this Maxima 5.20 built into the SAGE system differs from behavior of Maxima 5.17.1 which was used by me previously. Because of such difference I receive not exactly incorrect, but slightly different results in the newer version of Maxima. Thus it seems to me that the results given by the latest version can be simplified at higher degree. Cheers, Dima  >Comment By: Dieter Kaiser (crategus) Date: 20100123 17:34 Message: Sorry, I have overseen that you already have given the information that you use Maxima with SAGE 4.3. I have never used used Maxima in this enviroment. Therefore, I do not know what is expected for commands like bug_report() or run_testsuite(). Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100123 15:23 Message: Thank you very much for your report. It is helpful to find problems in Maxima. First, I had a look at the implementation of the simplification of sqrt(x^2) in Maxima 5.14, 5, 15, ... 5,20post. All versions simplifies sqrt(x^2) > x if x<0, Second, in all versions sqrt(x^2) is not simplified to x if the symbol is declared to be complex in addition. That is the declaration declare(x,complex). This might be a contradiction to the assumption that x is a negative real, but Maxima does not signal a problem. Please, can you have a look if your symbol is declared to be complex. You can use the command facts() to see it. (%i2) declare(x,complex); (%o2) done (%i3) facts(); (%o3) [kind(x, complex)] Furthermore, I do not understand why you do not get information from the commands build_info() and bug_report() and no results from the testsuite. You should get something like the following: (%i1) run_testsuite(); Running tests in rtestnset: 535/535 tests passed. Running tests in rtest1: 106/106 tests passed. Running tests in rtest1a: 24/24 tests passed. Running tests in rtest2: 56/56 tests passed. Running tests in rtest4: 89/89 tests passed. Running tests in rtest5: 51/51 tests passed. Running tests in rtest6: 4/4 tests passed. Running tests in rtest6a: 52/52 tests passed. Running tests in rtest6b: 16/16 tests passed. Running tests in rtest7: 44/44 tests passed. ... Perhaps, there is specific problem with your installation of Maxima. From which place do you have got your Maxima package? What Maxima interface your are using? Dieter Kaiser  Comment By: Dmitry Kirzhanov (kirzhanov) Date: 20100123 14:07 Message: On my compilation command sequence assume(x<0); sqrt(x^2); gives output sqrt(x^2), and *not* x. Command ratsimp also does not affect this expression. Version information: Maxima 5.19.1, Using Lisp ECL 9.10.2. I could not get any output from function bug_report() or build_info(). Command run_testsuite() retuns 'done'.  Comment By: Dieter Kaiser (crategus) Date: 20100122 19:55 Message: For a negative symbol x Maxima simplifies the sqrt function the following way: (%i1) assume(x<0)$ (%i2) sqrt(x^2); (%o2) x The function fullratsimp is not needed and does not change anything for this example. We always get for this example: (%i3) is(sqrt(x^2)=x); (%o3) true The only way I have found to get the reported oberservation is to give the variable x a positive value. (Maxima does not give an error if we assign a positive value to a symbol which is assumed to be negative). (%i6) x:10; (%o6) 10 Now the sqrt function simplifies to a positive value: (%i7) sqrt(x^2); (%o7) 10 We get false for the example from above: (%i9) is(sqrt(x^2)=x); (%o9) false I think there is no real problem. Setting the status to pending and the resoltution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 14:23:14

Bugs item #2937182, was opened at 20100122 14:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Assume does not always affect ratsimp/fullratsimp result Initial Comment: First, assume that x>=0: assume(x>=0); facts(); // returns x>=0 is(fullratsimp(sqrt(x^2))=x); // returns TRUE Now, forget about x>=0 and assume x<0: forget(x>=0); assume(x<0); facts(); // returns 0>x is(fullratsimp(sqrt(x^2))=x); // returns FALSE Is the expected result here TRUE instead of FALSE? For me this result is unexpected. It was achieved using the SAGE 4.3 system which is shipped with Maxima 5.20. I'm not sure this bug is related to Maxima, but it seems so. The behavior of this Maxima 5.20 built into the SAGE system differs from behavior of Maxima 5.17.1 which was used by me previously. Because of such difference I receive not exactly incorrect, but slightly different results in the newer version of Maxima. Thus it seems to me that the results given by the latest version can be simplified at higher degree. Cheers, Dima  >Comment By: Dieter Kaiser (crategus) Date: 20100123 15:23 Message: Thank you very much for your report. It is helpful to find problems in Maxima. First, I had a look at the implementation of the simplification of sqrt(x^2) in Maxima 5.14, 5, 15, ... 5,20post. All versions simplifies sqrt(x^2) > x if x<0, Second, in all versions sqrt(x^2) is not simplified to x if the symbol is declared to be complex in addition. That is the declaration declare(x,complex). This might be a contradiction to the assumption that x is a negative real, but Maxima does not signal a problem. Please, can you have a look if your symbol is declared to be complex. You can use the command facts() to see it. (%i2) declare(x,complex); (%o2) done (%i3) facts(); (%o3) [kind(x, complex)] Furthermore, I do not understand why you do not get information from the commands build_info() and bug_report() and no results from the testsuite. You should get something like the following: (%i1) run_testsuite(); Running tests in rtestnset: 535/535 tests passed. Running tests in rtest1: 106/106 tests passed. Running tests in rtest1a: 24/24 tests passed. Running tests in rtest2: 56/56 tests passed. Running tests in rtest4: 89/89 tests passed. Running tests in rtest5: 51/51 tests passed. Running tests in rtest6: 4/4 tests passed. Running tests in rtest6a: 52/52 tests passed. Running tests in rtest6b: 16/16 tests passed. Running tests in rtest7: 44/44 tests passed. ... Perhaps, there is specific problem with your installation of Maxima. From which place do you have got your Maxima package? What Maxima interface your are using? Dieter Kaiser  Comment By: Dmitry Kirzhanov (kirzhanov) Date: 20100123 14:07 Message: On my compilation command sequence assume(x<0); sqrt(x^2); gives output sqrt(x^2), and *not* x. Command ratsimp also does not affect this expression. Version information: Maxima 5.19.1, Using Lisp ECL 9.10.2. I could not get any output from function bug_report() or build_info(). Command run_testsuite() retuns 'done'.  Comment By: Dieter Kaiser (crategus) Date: 20100122 19:55 Message: For a negative symbol x Maxima simplifies the sqrt function the following way: (%i1) assume(x<0)$ (%i2) sqrt(x^2); (%o2) x The function fullratsimp is not needed and does not change anything for this example. We always get for this example: (%i3) is(sqrt(x^2)=x); (%o3) true The only way I have found to get the reported oberservation is to give the variable x a positive value. (Maxima does not give an error if we assign a positive value to a symbol which is assumed to be negative). (%i6) x:10; (%o6) 10 Now the sqrt function simplifies to a positive value: (%i7) sqrt(x^2); (%o7) 10 We get false for the example from above: (%i9) is(sqrt(x^2)=x); (%o9) false I think there is no real problem. Setting the status to pending and the resoltution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 13:07:45

Bugs item #2937182, was opened at 20100122 16:05 Message generated for change (Comment added) made by kirzhanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Assume does not always affect ratsimp/fullratsimp result Initial Comment: First, assume that x>=0: assume(x>=0); facts(); // returns x>=0 is(fullratsimp(sqrt(x^2))=x); // returns TRUE Now, forget about x>=0 and assume x<0: forget(x>=0); assume(x<0); facts(); // returns 0>x is(fullratsimp(sqrt(x^2))=x); // returns FALSE Is the expected result here TRUE instead of FALSE? For me this result is unexpected. It was achieved using the SAGE 4.3 system which is shipped with Maxima 5.20. I'm not sure this bug is related to Maxima, but it seems so. The behavior of this Maxima 5.20 built into the SAGE system differs from behavior of Maxima 5.17.1 which was used by me previously. Because of such difference I receive not exactly incorrect, but slightly different results in the newer version of Maxima. Thus it seems to me that the results given by the latest version can be simplified at higher degree. Cheers, Dima  >Comment By: Dmitry Kirzhanov (kirzhanov) Date: 20100123 16:07 Message: On my compilation command sequence assume(x<0); sqrt(x^2); gives output sqrt(x^2), and *not* x. Command ratsimp also does not affect this expression. Version information: Maxima 5.19.1, Using Lisp ECL 9.10.2. I could not get any output from function bug_report() or build_info(). Command run_testsuite() retuns 'done'.  Comment By: Dieter Kaiser (crategus) Date: 20100122 21:55 Message: For a negative symbol x Maxima simplifies the sqrt function the following way: (%i1) assume(x<0)$ (%i2) sqrt(x^2); (%o2) x The function fullratsimp is not needed and does not change anything for this example. We always get for this example: (%i3) is(sqrt(x^2)=x); (%o3) true The only way I have found to get the reported oberservation is to give the variable x a positive value. (Maxima does not give an error if we assign a positive value to a symbol which is assumed to be negative). (%i6) x:10; (%o6) 10 Now the sqrt function simplifies to a positive value: (%i7) sqrt(x^2); (%o7) 10 We get false for the example from above: (%i9) is(sqrt(x^2)=x); (%o9) false I think there is no real problem. Setting the status to pending and the resoltution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 10:44:08

Bugs item #2937837, was opened at 20100123 11:44 Message generated for change (Tracker Item Submitted) made by dbinf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937837&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dirk Bosmans (dbinf) Assigned to: Nobody/Anonymous (nobody) Summary: find_root_error documentation incorrect Initial Comment: The documentation (5.19.2) states : "find_root expects the function in question to have a different sign at the endpoints of the search interval. If this condition is not met, the behavior of find_root is governed by find_root_error. When find_root_error is true, find_root prints an error message. Otherwise find_root returns the value of find_root_error." That last part should be something like this: "... When find_root_error is true, find_root prints an error message. Otherwise, if numberp(find_root_error) is true, find_root returns the value of find_root_error. Otherwise, find_root returns the partiallyevaluated find_root expression find_root(first_argument, false, false)" This behaviour is what is programmed in the last few lines of share/maxima/15.9.2/src/intpol.lsp, and is indeed what happens if calling find_root with for example find_root_error = false or with find_root_error:disp("Houston, we have a problem".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937837&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 09:58:20

Bugs item #2786017, was opened at 20090503 12:25 Message generated for change (Comment added) made by van_nek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2786017&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: realonly in algsys.lisp Initial Comment: The option variable realonly is quite confusing since it does not find real solutions, but only solutions which are free of %i (purely using freeof). For example, when realonly is false, algsys ([x^4 + 1], [x]); returns [[x = (1)^(1/4)], [x = (1)^(1/4)*%i], [x = (1)^(1/4)], [x = (1)^(1/4)*%i]] But when realonly is true, it returns [[x = (1)^(1/4)], [x = (1)^(1/4)]] while it is natural to expect []. Maybe it is better to modify the behavior and filter roots by checking something like is_real(x) := is(trigsimp(imagpart(x)) = 0); and not just freeof(%i, x) With the freeof approach we may also omit real roots of irreducible polynomials: sol : map ('rhs, solve (3*x^3  3*x + 1)); [(sqrt(3)*%i/21/2)/(3*(3^(3/2)*%i/21/6)^(1/3)) +(3^(3/2)*%i/21/6)^(1/3)*(sqrt(3)*%i/21/2), (3^(3/2)*%i/21/6)^(1/3)*(sqrt(3)*%i/21/2) +(sqrt(3)*%i/21/2)/(3*(3^(3/2)*%i/21/6)^(1/3)), (3^(3/2)*%i/21/6)^(1/3)+1/(3*(3^(3/2)*%i/21/6)^(1/3))] map (lambda([x], freeof(%i, x)), sol); [false,false,false] map ('is_real, sol); [true,true,true] So when realonly and algexact are set to true, algsys ([3*x^3  3*x + 1], [x]) just returns [].  >Comment By: Volker van Nek (van_nek) Date: 20100123 10:58 Message: Hi Alexey, yesterday I noticed this problem too and found your bug report. I think you are right, freeof(%i, x) is not a sufficient test to recognize nonzero imaginary parts. E.g. (1)^(1/4) passes. So I wonder why you did not fix that problem. You suggested the right thing. It is one line in src/algsys.lisp to change: 348352: (defun realonly (rootsl) (cond ((null rootsl) nil) ;; ((freeof '$%i (car rootsl)) ;; problem ((equal 0 (sratsimp ($imagpart (car rootsl)))) ;; fix ? (nconc (list (car rootsl)) (realonly (cdr rootsl)))) (t (realonly (cdr rootsl))))) This change passes the test suite. So I would commit this new line. Or do I overlook something? Why did you hesitate to commit? Volker van Nek  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2786017&group_id=4933 