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}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(32) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(6) 
3
(7) 
4
(2) 
5
(9) 
6
(14) 
7
(10) 
8
(6) 
9
(12) 
10
(1) 
11
(4) 
12
(9) 
13
(5) 
14
(18) 
15

16
(3) 
17
(3) 
18
(3) 
19
(1) 
20
(2) 
21
(5) 
22
(14) 
23
(2) 
24
(5) 
25
(1) 
26

27
(4) 
28
(8) 
29
(17) 
30
(8) 





From: SourceForge.net <noreply@so...>  20091130 20:30:27

Bugs item #2906049, was opened at 20091130 17:02 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2906049&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration failure with option integrate_use_rootsof :true Initial Comment: (%i12) integrate_use_rootsof : true; (%i13) pt*integrate((d*QA^2+2*c*QA+3*b)/(g*QA^3*R+d*QA^2+c*QA+b),QA); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091130 21:30 Message: I think the bug is in the routine integrateuserootsof: (defun integrateuserootsof (f q variable &aux qprime ff qq (dummy (makeparam)) lead) ;; p2e is squarefree polynomial in cre form, p1e is lower degree (setq lead (plc q)) < Problem (setq qprime (disrep (pderivative q (pvar q)))) (setq ff (disrep f) qq (disrep q)) `((%lsum) ((mtimes) ,(div* (mul* lead (subst dummy variable ff)) (subst dummy variable qprime)) ((%log) ,(sub* variable dummy))) ,dummy (($rootsof) ,qq))) There is no DISREP for the leading coefficient of q, but for the example of this bug report we get an CRE expression as a coefficient. When we do a DISREP (setq lead (disrep (plc q))) the integral of this bug report will work: (%i4) integrate_use_rootsof : true; (%o4) true (%i5) integrate((d*QA^2+2*c*QA+3*b)/(g*QA^3*R+d*QA^2+c*QA+b),QA); (%o5) 'lsum((%r2^2*d+2*%r2*c+3*b)*g*log(QA%r2)*R/(3*%r2^2*g*R+2*%r2*d+c),%r2, rootsof(g*QA^3*R+d*QA^2+c*QA+b)) The testsuite has no examples for this type of integrals, but the example of the documentation will work as expected with this change. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2906049&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 16:02:46

Bugs item #2906049, was opened at 20091130 16:02 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2906049&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  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration failure with option integrate_use_rootsof :true Initial Comment: (%i12) integrate_use_rootsof : true; (%i13) pt*integrate((d*QA^2+2*c*QA+3*b)/(g*QA^3*R+d*QA^2+c*QA+b),QA); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2906049&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 11:49:00

Bugs item #2905929, was opened at 20091130 05:48 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905929&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: gcdex Initial Comment: OK: (%i1) gcdex(x7,x8); (%o1) [1,1,1] Not OK: (%i2) q0[2] : 6$ (%i3) gcdex(x7,x8); (%o3) [1/6,q0[1]/6,1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905929&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 11:20:32

Bugs item #2905527, was opened at 20091128 20:22 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905527&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) >Summary: ezgcd & CRE expressions / FIX Initial Comment: OK: (%i1) apply(ezgcd,[x5,x9]); (%o1) [1,x5,x9] Not OK: (%i2) apply(ezgcd,[rat(x5),x9]); (%o2) true  >Comment By: Barton Willis (willisbl) Date: 20091130 05:20 Message: Possible fix: (defmfun $ezgcd (&rest args) (prog (pfl allvars presult flag genvar denom pfl2) ;;need if genvar doesn't shrink (when (null args) (wnaerr '$ezgcd)) (when (some #'$ratp args) (setq flag t)) ;; was (return (setq flag t)))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905527&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 00:24:44

Bugs item #2035858, was opened at 20080802 13:07 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2035858&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 Group: None >Status: Closed >Resolution: Duplicate Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: facts(noncontext) Initial Comment: (%i1) assume(x > a); (%o1) [x>a] OKlist facts about x: (%i2) facts(x); (%o2) [x>a] (%i3) assume(x > a b); (%o3) [x+ba>0] Not OK facts(x) doesn't include x + b  a > 0 (%i4) facts(x); (%o4) [x>a] Based on the user documentation, I think most readers would assume that facts(x) would include x + b  a > 0. The user documentation says: "If item is not the name of a context, facts (item) returns a list of the facts known about item in the current context" Maybe this is mostly a documentation problem; it's not clear what "item" means: (%i10) assume(x > a + b); (%o10) [xba>0] (%i11) facts(a+b); (%o11) []  >Comment By: Dieter Kaiser (crategus) Date: 20091130 01:24 Message: Closing this bug report, because it is a duplicate of the report ID: 856209  inconsistency between facts() and facts(v). This report has been added to the first bug report about this topic. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2035858&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 00:22:51

Bugs item #856209, was opened at 20031208 14:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=856209&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  Assume Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency between facts() and facts(v) Initial Comment: In a given context, facts(v) applied with various v must reproduce the entire output of the facts() command. This is not the case: (C14) facts(); (D14) [z + a > 0, b > z] (C15) facts(a); (D15) [] (C16) facts(b); (D16) [b > z] (C17) facts(z); (D17) [b > z] (C18) facts(z + a); (D18) [] It would be OK to have: facts(z); => [z + a > 0,  z + b > 0] facts(a); => [z + a > 0] facts(b); => [ z + b > 0] facts(z+a); => [z + a > 0] facts(a+z); => [z + a > 0] facts(bz); => [ z + b > 0] facts(z+b); => [ z + b > 0]  >Comment By: Dieter Kaiser (crategus) Date: 20091130 01:22 Message: Adding a copy of the posting from the bug report ID: 2035858, which has been closed, because it is a duplicate of this report.  Barton Willis ( willisbl )  20080802 13:07 (%i1) assume(x > a); (%o1) [x>a] OKlist facts about x: (%i2) facts(x); (%o2) [x>a] (%i3) assume(x > a b); (%o3) [x+ba>0] Not OK facts(x) doesn't include x + b  a > 0 (%i4) facts(x); (%o4) [x>a] Based on the user documentation, I think most readers would assume that facts(x) would include x + b  a > 0. The user documentation says: "If item is not the name of a context, facts (item) returns a list of the facts known about item in the current context" Maybe this is mostly a documentation problem; it's not clear what "item" means: (%i10) assume(x > a + b); (%o10) [xba>0] (%i11) facts(a+b); (%o11) []  Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060719 05:48 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=856209&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 00:19:33

Bugs item #2905786, was opened at 20091129 18:19 Message generated for change (Tracker Item Submitted) made by mechiscogo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905786&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: Xmaxima or other UI Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hielos (mechiscogo) Assigned to: Nobody/Anonymous (nobody) Summary: Copy doesn't work Initial Comment: I had used wxMaxima before, and I remember being able to use CTRL + C to copy text. I built maxima from source in Ubuntu 9.04, and now CTRL + C doesn't work. Even if I use the secondar mouse button to copy text, I can't paste it. If I enable the "Copy selection" option in the preferences menu, it does copy everything, but I would like to be able to select anything without erasing the clipboard contents. Thanks Maxima version: 5.19.2Maxima build date: 8:27 9/10/2009host type: x86_64unknownlinuxgnulispimplementationtype: CLISPlispimplementationversion: 2.44.1 (20080223) (built on loszerafin [127.0.1.1])  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905786&group_id=4933 
From: SourceForge.net <noreply@so...>  20091130 00:05:26

Bugs item #2299224, was opened at 20081116 16:47 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2299224&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: Includes proposed fix >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: unsimplified result from rectform Initial Comment: (%i1) logarc : true; (%o1) true (%i2) rectform(log(x + %i * y)); (%o2) log(y^2+x^2)/2+%i*atan2(y,x) (%i3) expand(%,0,0); (%o3) log(y^2+x^2)/2+(log((%i*y)/x+1)log(1(%i*y)/x))/2 Also (%o3) is wrong for x = 0 and in the left half plane.  >Comment By: Dieter Kaiser (crategus) Date: 20091130 01:05 Message: As discussed on the mailing list, rectform sets the option variable logarc to NIL to preserve the standard form x+%i*y for its result. With Maxima 5.19post we get: (%i4) rectform(log(x+%i*y)); (%o4) log(y^2+x^2)/2+%i*atan2(y,x) logarc gives the following result, which no longer has the standard form of rectform: (%i5) logarc(%); (%o5) log((%i*y+x)/sqrt(y^2+x^2))+log(y^2+x^2)/2 I think we can close this bug report. The first issue has gone. The result of rectform is correct. The second issue is the expected behavior. rectform returns a standard form, which might simplify further, when the user sets the option variable logarc to TRUE. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090508 22:45 Message: The expression does not simplify as expected because the global flag $logarc is set to nil in the routine risplit. It is possible to remove this from the routine risplit. Then we would get: (%i11) rectform(log(x+%i*y)),logarc; (%o11) log((%i*y+x)/sqrt(y^2+x^2))+log(y^2+x^2)/2 Because of revision 1.25 the result of the simplification is now correct. I have checked this with the testsuite and the share_testsuite. There are no examples which depend on the setting of $logargs in the routine risplit. Should we change the routine risplit and remove the setting of the flag $logarg? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2299224&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 23:53:14

Bugs item #1977146, was opened at 20080528 23:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977146&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: Robert Marik (robertmarik) Assigned to: Nobody/Anonymous (nobody) Summary: radexpand does not work as explained in documentation Initial Comment: >From maxima discussion list: Maxima manual states the following  When radexpand is false, certain transformations are inhibited. radcan (sqrt (1x)) remains sqrt (1x) and is not simplified to %i sqrt (x1). radcan (sqrt (x^2  2*x + 11)) remains sqrt (x^2  2*x + 1) and is not simplified to x  1.  Neglecting the typo in radcan (sqrt (x^2  2*x + 11)) which should be probably radcan (sqrt (x^2  2*x + 1)), I get the answer x1 also with radexpand:false. Moreover, sqrt(1x) remains sqrt(1x) even with radexpand:true. Is the documentation of radcan obsolete? Robert Marik reponse of Richard Fateman radexpand was inserted by someone else, after the code was written in 1970. I do not know if the documentation or the program is buggy, since I'm not sure what was intended. RJF  >Comment By: Dieter Kaiser (crategus) Date: 20091130 00:53 Message: The description of the option variable radexpand has been cut out from the documentation of radcan. radexpand has no effect on radcan. Furthermore, the description of the option variable %e_to_numlog has been cut out. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091128 23:40 Message: I think the option variable radexpand controls the simplification of the power function, but does not control the function radcan. This is wrongly documented. radexpand works for expressions like (x*y)^a and (x^a)^b. Some examples are: (%i2) radexpand:false$ (%i3) (x*y)^a; (%o3) (x*y)^a (%i4) (x*y)^a,radexpand:true; (%o4) (x*y)^a The expression simplifies, if radexpand is set to ALL: (%i5) (x*y)^a,radexpand:all; (%o5) x^a*y^a (%i6) (x^a)^b; (%o6) (x^a)^b (%i7) (x^a)^b,radexpand:true; (%o7) (x^a)^b The expression simplifies, if radexpand is set to ALL: (%i8) (x^a)^b,radexpand:all; (%o8) x^(a*b) Both expressions simplify only, if radexpand is set to ALL. Therefore, the value ALL has the effect, that all variables are assumed to be positive and real. With a value of TRUE, radexpand controls the simplifcation of the power function for even and odd rational numbers. For an even rational power we do not get a simplification: (%i12) (x*y)^(1/2); (%o12) sqrt(x*y) (%i13) (x*y)^(1/2),radexpand:true; (%o13) sqrt(x*y) But we get a simplification for an odd power, if radexpand is set to TRUE: (%i14) (x*y)^(1/3); (%o14) (x*y)^(1/3) (%i15) (x*y)^(1/3),radexpand:true; (%o15) x^(1/3)*y^(1/3) The function radcan simplifies the above expressions with power functions too, but does not depend on the flag radexpand: The flag is set to FALSE: (%i34) radexpand; (%o34) false radcan simplifies the expressions. The flag radexpand does not matter: (%i35) radcan((x*y)^a); (%o35) x^a*y^a (%i36) radcan((x^a)^b); (%o36) x^(a*b) Therefore, radcan always assumes the variables to be positive and real. In a first step, all of these should be documented more clearly. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977146&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 21:44:34

Bugs item #1551310, was opened at 20060903 05:33 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1551310&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 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: mod and floor should distribute over matrix and list Initial Comment: >From the mailing list: On 9/2/06, Stavros Macrakis <macrakis@...> wrote: > On 9/1/06, Barton Willis <willisb@...> wrote: > > To apply mod to each element of a matrix, you'll still need to use > > matrixmap and a lambda form. Doing mod(matrix([...]),10) makes a mess... > > Well, that's a bug we should fix... both mod and floor should > distribute over matrix and list. The current result is silly. Couple of random addenda: (1) Are there other functions to consider here? e.g. ceiling  maybe others? (2) Should mod, floor, ceiling, etc also distribute over sets?  >Comment By: Dieter Kaiser (crategus) Date: 20091129 22:44 Message: With revision 1.93 of simp.lisp a general mechanism for functions to map over bags has been implemented. For the function mod we get e.g. (%i7) mod(matrix([a,b],[c,d]),10); (%o7) matrix([mod(a,10),mod(b,10)],[mod(c,10),mod(d,10)]) (%i8) mod([[a,b],[c,d]],10); (%o8) [[mod(a,10),mod(b,10)],[mod(c,10),mod(d,10)]] (%i9) mod([a,b,c,d],10); (%o9) [mod(a,10),mod(b,10),mod(c,10),mod(d,10)] (%i10) mod(a=b,10); (%o10) mod(a,10) = mod(b,10) Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1551310&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:22:03

Bugs item #2905527, was opened at 20091128 20:22 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905527&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ezgcd & CRE expressions Initial Comment: OK: (%i1) apply(ezgcd,[x5,x9]); (%o1) [1,x5,x9] Not OK: (%i2) apply(ezgcd,[rat(x5),x9]); (%o2) true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905527&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:21:15

Bugs item #2905526, was opened at 20091128 20:21 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905526&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: lcm(0,6,0) > divide by zero Initial Comment: Two bugs: First, lcm(0,6,0) = 0, not a division by zero error. Second, if lcm is redefined by loading funcs.mac, we need to eliminate one definition. (%i1) lcm(0,6,0); Warning  you are redefining the Maxima function lcm Division by 0 Finally, lcm should be able to find the lcm of 200 numbers: (%i14) l : makelist(random(100)+1,i,1,200)$ (%i15) apply('lcm,l)$ Maxima encountered a Lisp error:  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905526&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:13

Bugs item #2787476, was opened at 20090505 19:41 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: iga Lenari (zigalenarcic) Assigned to: Nobody/Anonymous (nobody) Summary: 'diff() inconsistent Initial Comment: 'diff(x*y,x) gives the correct result (holds form), while 'diff(x,x) gives 1, calculates the differencial.  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 23:37 Message: 'diff(x,x) gives 1 because of simplification in the simplifying function simpderiv. We have a similar simplification for integrals: (%i9) 'integrate(1,x); (%o9) x Therefore, we can do something like (%i10) 'diff('integrate(1,x),x); (%o10) 1 Furthermore, the following simplification is build in: (%i15) 'diff(x,x,0); (%o15) x This works for an arbitrary expression too: (%i17) 'diff(sin(x),x,0); (%o17) sin(x) It might be arguable why Maxima does not do more simplifications of this type, but the implement simplifications are not wrong. I have no example, where these simplifications cause problems. So, I would suggest not to change the behavior of Maxima to simplify the examples in this bug report. Setting the status to pending and resolution "works for me". Dieter Kaiser  Comment By: iga Lenari (zigalenarcic) Date: 20090513 13:26 Message: Problem is in quoted diff, which should not evaluate, but it does in 'diff(x,x) case: (%i2) 'diff(x*y,x); d (%o2)  (x y) dx (%i3) 'diff(x,x); (%o3) 1 (%i4) 'diff(2*x,x); d (%o4)  (2 x) dx  Comment By: Nobody/Anonymous (nobody) Date: 20090513 11:27 Message: I may be stupid or blind, but I do not see the problem here. Would you like to see diff(x*x,x) resulting in x rather than 2x? May be your remark is more subtle than this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2787476&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:12

Bugs item #2897611, was opened at 20091114 09:46 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Erdmann Fricke (erdmannfricke) Assigned to: Nobody/Anonymous (nobody) Summary: wxmaxima 8.03 does not calculate a simple integral Initial Comment: wxmaxima 8.03 on my MacBook does not calculate the following integral: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4) (Mac OS 10.6; Maxima Version 5.19.2, Maxima build date: 17:49 9/1/2009; host type: i686appledarwin8.11.1; lispimplementationtype: SBCL; lispimplementationversion: 1.0.30) There were no problems with wxmaxima 8.02: integrate(1/20*(x^4+16*x^391*x^2+216*x56,x,1,4)=891/50 (Ubuntu 9.10; Maxima Version 5.17.1, Maxima build date: 14:9 7/13/2009; host type: i686pclinuxgnu; lispimplementationtype: GNU Common Lisp (GCL); lispimplementationversion: GCL 2.6.7)  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 12:18 Message: The integral works for me with wxMaxima 0.8.4, Maxima 5.19post and Ubuntu 9.10. The build info is: Maxima version: 5.19post Maxima build date: 23:36 11/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3467140630) This is the integral: (%i3) integrate(1/20*(x^4+16*x^391*x^2+216*x56),x,1,4); (%o3) 891/50 What is the error you get? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2897611&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:12

Bugs item #2609426, was opened at 20090217 15:32 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2609426&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  Integration Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: iga Lenari (zigalenarcic) Assigned to: Nobody/Anonymous (nobody) Summary: integrate( cos(a)/ sqrt((tan(a))^2 + 1), a, %pi/2, %pi/2 ); Initial Comment: Maxima can't caluculate definite integral integrate( cos(a)/ sqrt((tan(a))^2 + 1), a, %pi/2, %pi/2 ); It gives me The number 1 isn't in the domain of atanh  an error. To debug this try debugmode(true); If I calculate indefinite integral integrate( cos(a)/ sqrt((tan(a))^2 + 1), a); and manually put in integration limits, it gives the correct result %pi/2.  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 20:44 Message: Documentation for intanalysis has been added to Integration.texi revision 1.45. The integral of this bug report has been added as an example. Maxima does not give a wrong result and is able to solve the integral with the help of the option variable intanalysis. More might be possible, but this would be a feature request. Setting the status to pending and the resolution to "Works for me". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20090217 17:39 Message: FWIW, maxima is trying to find the roots of the denominator to see if there are any poles on the interval of integration. SOLVE is getting confused. A workaround would be to set intanalysis (undocumented) to false. Then integrate returns %pi/2.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2609426&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:12

Bugs item #2801819, was opened at 20090605 16:18 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2801819&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: spurious Principal Value message Initial Comment: (%i1) assume(p > 0); (%o1) [p>0] OK: (%i4) integrate(exp(p * t^2),t,minf,inf); (%o4) sqrt(%pi)/sqrt(p) OK, but not a principle value: (%i5) integrate(exp(pp * t^2),t,minf,inf); Is pp positive, negative, or zero?pos; Principal Value (%o5) sqrt(%pi)/sqrt(pp)  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 21:45 Message: This problem seems to be no longer present in Maxima 5.19post: (%i2) integrate(exp(pp * t^2),t,minf,inf); Is pp positive, negative, or zero? p; (%o2) sqrt(%pi)/sqrt(pp) Setting the status to pending and resolution to "works for me". Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20090605 18:18 Message: The difference between the two cases is in polesininterval. In the first case, there are no poles in the interval. In the second case, polesininterval thinks there are poles at minf and inf. Hence, maxima thinks we have a principal value integral.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2801819&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:11

Bugs item #2802006, was opened at 20090605 21:34 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2802006&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  Integration Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(sqrt(x)+1), x, 0, 1); Initial Comment: Maxima can't solve this integral. I'm using maxima 5.17.1  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 20:43 Message: Documentation for intanalysis has been added to Integration.texi revision 1.45. The integral of this bug report has been added as an example. Maxima does not give a wrong result and is able to solve the integral with the help of the option variable intanalysis. More might be possible, but this would be a feature request. Setting the status to pending and the resolution to "Works for me". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20090707 18:36 Message: Maxima fails because polesininterval cannot determine if there are any poles in the integrand. This is basically a failure of solve (not $solve) to find any roots of sqrt(x)+1. If intanalysis is set to false, then maxima can evaluate this integral and the value is 22*log(2). (intanalysis should probably be documented.)  Comment By: Nobody/Anonymous (nobody) Date: 20090605 21:49 Message: bug persists in the 5.18.1 release  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2802006&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:11

Bugs item #2716922, was opened at 20090327 13:42 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2716922&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: Problem not in Maxima Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: The execution hangs Initial Comment: Executing "run_testsuite (true, true)" in xmaxima takes 171 seconds. In wxMaxima after several hours it hangs. Maxima version: 5.17.1 Maxima build date: 19:10 12/18/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 18:53 Message: First, the implementation of run_testsuite has changed. Now the command will be run_testsuite(display_all=true). Furthermore, I think this is a specific problem of wxMaxima on a Windows system. The result is displayed, when Maxima has finished its work. But with display_all = true the output is very large (several thousands of lines). It might be that wxMaxima hangs while trying to display the output of Maxima. On a Linux system I do not observe this problem with wxMaxima. The display of examples from the testsuite starts immediately. I think this is not a Maxima bug, but perhaps a wxMaxima problem on a Windows system. wxMaxima has a bug tracker too. Perhaps the bug should be added to the bug tracker of wxMaxima. Setting the status to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2716922&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:10

Bugs item #2895770, was opened at 20091111 07:51 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2895770&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: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: apply(sum,...) behaves as if it is apply(sum,ev(...)) Initial Comment: Dear Developers of Maxima, This letter informs you that sum() and product() behave strangely when they are used as the first argument of apply(). The behavior actually observed for apply(sum, LIST_OF_ARGUMENTS) is not the expected one for it but coincides with the expected one for apply(sum, ev(LIST_OF_ARGUMENTS)). The same behavior is observed for apply(product, LIST_OF_ARGUMENTS). In my understanding, this is thought to be a bug for sum() and product(). Below, I will explain this behavior of sum() and product().  (1) Normal behavior of apply()  The following program demonstrates the normal behavior of apply(): ............................................................................... /* * behavior_of_apply.maxima: * * S.Adachi 2009/11/10 */ display2d:false; arg_lst:[x]; OK1:apply(sin, arg_lst); x:%pi/2; OK2:apply(sin, arg_lst); OK3:apply(sin, ev(arg_lst)); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(behavior_of_apply.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/behavior_of_apply.maxima (%i2) display2d : false (%o2) false (%i3) arg_lst:[x] (%o3) [x] (%i4) OK1:apply(sin,arg_lst) (%o4) sin(x) (%i5) x:%pi/2 (%o5) %pi/2 (%i6) OK2:apply(sin,arg_lst) (%o6) sin(x) (%i7) OK3:apply(sin,ev(arg_lst)) (%o7) 1 (%o8) "behavior_of_apply.maxima" ............................................................................... Please look at (%i6) and (%o6). At this point, arg_lst is equal to [x] and thereby the result of apply(sin, arg_lst) becomes sin(x). Even though the variable x is given the value %pi/2, this value is not used when apply() is called with the arguments sin and [x]. This is the normal expected behavior of apply(). If we want [x] to be evaluated in the current environment, we have to use ev(arg_lst) instead of arg_lst (see (%i7) and (%o7)).  (2) Strange behavior of sum() when it is used as 1st argument of apply()  The following program demonstrates the strange behavior of sum() when it is used as the first argument of apply(): ............................................................................... /* * strange_behavior_of_sum.maxima: * * S.Adachi 2009/11/10 */ display2d:false; arg_lst:[f(i), i, 1, n]; OK1:apply(sum, arg_lst); n:4; STRANGE:apply(sum, arg_lst); OK2:apply(sum, ev(arg_lst)); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(strange_behavior_of_sum.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/strange_behavior_of_sum.maxima (%i2) display2d : false (%o2) false (%i3) arg_lst:[f(i),i,1,n] (%o3) [f(i),i,1,n] (%i4) OK1:apply(sum,arg_lst) (%o4) 'sum(f(i),i,1,n) (%i5) n:4 (%o5) 4 (%i6) STRANGE:apply(sum,arg_lst) (%o6) f(4)+f(3)+f(2)+f(1) (%i7) OK2:apply(sum,ev(arg_lst)) (%o7) f(4)+f(3)+f(2)+f(1) (%o8) "strange_behavior_of_sum.maxima" ............................................................................... In this example, arg_lst is set to [f(i),i,1,n] at (%i3). After arg_lst is prepared, n is set to 4 at (%i5). At (%i6), apply(sum,arg_lst) is calculated. At (%i7), apply(sum,ev(arg_lst)) is calculated. Both results become f(4)+f(3)+f(2)+f(1) as are seen at (%o6) and (%o7). This result is expected for apply(sum,ev(arg_lst)) but is never for apply(sum,arg_lst). The result expected for apply(sum,arg_lst) is 'sum(f(i),i,1,n). Namely, apply(sum,arg_lst) actually behaves as if it is apply(sum,ev(arg_lst)). I think that this is a bug.  (3) This bug of sum() is serious for programming.  This bug of sum() when it is supplied to the first argument of apply() is very serious one for writing programs. The bug causes a serious confusion of the object language and the observation language (programming language). To demonstrate how serious this bug is, I have prepared a toy program, which traces the process of calculation for a given expression. It is as follows: ............................................................................... /* * demonstration_of_strangeness_of_sum.maxima: * * S.Adachi 2009/11/10 */ display2d:false; trace_calc(X) := trace_calc_sub(X, 0); trace_calc_sub(X, indent) := block([res], if (atom(X)) then ( print(smake(indent, " "),"[ATOM]:",X), res:X ) else ( block([n,i,arg_lst,a,b], print(smake(indent, " "),"[FUNC]: OP =",op(X)), arg_lst:[], n:length(X), for i:1 thru n do ( a:part(X,i), print(smake(indent, " "),"[FUNC]: ARG(",i,") = ",a," >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b]) ), res:apply(op(X),arg_lst), print(smake(indent, " "),"[FUNC]: RES = ",res) ) ), res); ex1_OK:a*b*F(n)+c*G(n); ex1_tr_OK:trace_calc(ex1_OK); ex2_OK:a*b*sum(f(i),i,1,n)+c*product(g(i),i,1,n); ex2_tr_BAD:trace_calc(ex2_OK); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(demonstration_of_strangeness_of_sum.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/demonstration_of_strangeness_of_sum.maxima (%i2) display2d : false (%o2) false (%i3) trace_calc(X):=trace_calc_sub(X,0) (%o3) trace_calc(X):=trace_calc_sub(X,0) (%i4) trace_calc_sub(X,indent):=block([res], if atom(X) then (print(smake(indent," "),"[ATOM]:",X),res:X) else block([n,i,arg_lst,a,b], print(smake(indent," "),"[FUNC]: OP =", op(X)),arg_lst:[],n:length(X), for i thru n do (a:part(X,i), print(smake(indent," "), "[FUNC]: ARG(",i,") = ",a, " >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b])), res:apply(op(X),arg_lst), print(smake(indent," "),"[FUNC]: RES = ", res)),res) (%o4) trace_calc_sub(X,indent):=block([res], if atom(X) then (print(smake(indent," "),"[ATOM]:",X),res:X) else block([n,i,arg_lst,a,b], print(smake(indent," "),"[FUNC]: OP =", op(X)),arg_lst:[],n:length(X), for i thru n do (a:part(X,i), print(smake(indent," "), "[FUNC]: ARG(",i,") = ",a, " >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b])), res:apply(op(X),arg_lst), print(smake(indent," "),"[FUNC]: RES = ", res)),res) (%i5) ex1_OK:a*b*F(n)+c*G(n) (%o5) c*G(n)+a*b*F(n) (%i6) ex1_tr_OK:trace_calc(ex1_OK) [FUNC]: OP = + [FUNC]: ARG( 1 ) = c*G(n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = c > [ATOM]: c [FUNC]: ARG( 2 ) = G(n) > [FUNC]: OP = G [FUNC]: ARG( 1 ) = n > [ATOM]: n [FUNC]: RES = G(n) [FUNC]: RES = c*G(n) [FUNC]: ARG( 2 ) = a*b*F(n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = a > [ATOM]: a [FUNC]: ARG( 2 ) = b > [ATOM]: b [FUNC]: ARG( 3 ) = F(n) > [FUNC]: OP = F [FUNC]: ARG( 1 ) = n > [ATOM]: n [FUNC]: RES = F(n) [FUNC]: RES = a*b*F(n) [FUNC]: RES = c*G(n)+a*b*F(n) (%o6) c*G(n)+a*b*F(n) (%i7) ex2_OK:a*b*sum(f(i),i,1,n)+c*product(g(i),i,1,n) (%o7) c*'product(g(i),i,1,n)+a*b*'sum(f(i),i,1,n) (%i8) ex2_tr_BAD:trace_calc(ex2_OK) [FUNC]: OP = + [FUNC]: ARG( 1 ) = c*'product(g(i),i,1,n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = c > [ATOM]: c [FUNC]: ARG( 2 ) = 'product(g(i),i,1,n) > [FUNC]: OP = product [FUNC]: ARG( 1 ) = g(i) > [FUNC]: OP = g [FUNC]: ARG( 1 ) = i > [ATOM]: i [FUNC]: RES = g(i) [FUNC]: ARG( 2 ) = i > [ATOM]: i [FUNC]: ARG( 3 ) = 1 > [ATOM]: 1 [FUNC]: ARG( 4 ) = n > [ATOM]: n [FUNC]: RES = 'product(g(i),i,1,4) [FUNC]: RES = c*'product(g(i),i,1,4) [FUNC]: ARG( 2 ) = a*b*'sum(f(i),i,1,n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = a > [ATOM]: a [FUNC]: ARG( 2 ) = b > [ATOM]: b [FUNC]: ARG( 3 ) = 'sum(f(i),i,1,n) > [FUNC]: OP = sum [FUNC]: ARG( 1 ) = f(i) > [FUNC]: OP = f [FUNC]: ARG( 1 ) = i > [ATOM]: i [FUNC]: RES = f(i) [FUNC]: ARG( 2 ) = i > [ATOM]: i [FUNC]: ARG( 3 ) = 1 > [ATOM]: 1 [FUNC]: ARG( 4 ) = n > [ATOM]: n [FUNC]: RES = 'sum(f(i),i,1,4) [FUNC]: RES = a*b*'sum(f(i),i,1,4) [FUNC]: RES = c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4) (%o8) c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4) (%o9) "demonstration_of_strangeness_of_sum.maxima" ............................................................................... This expected result at (%o8) is c*'product(g(i),i,1,n)+a*b*'sum(f(i),i,1,n). But the calculated result is c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4). Namely, n is accidentally replaced by 4. This strange result is caused by the coincidence of the names of the variable n in the observation language (programming language) and the variable n in the object language (given expression). The value of the variable n used in the program is accidentally transferred to the variable n in the object expression.  (4) Strange behavior of product() when it is used as 1st argument of apply()  As is seen in the demonstration of (3), product() also has the same bug as sum() when it is supplied to the first argument of apply(). I do not know when this behavior of sum() and product() was brought into the code. It might be some relatively recent time. In this case, this behavior could be called a bug. Or, the behavior might originate at a long time ago in the code. In this case, you may say that this is not a bug but is a part of ''specification'' of Maxima. Even if you may, this is a serious inconsistency in Maxima and lets programming in Maxima be more difficult and be ugly since some workaround is necessary. I hope that this bug (in my understanding) will be fixed in future. Sincerely yours, Satoshi Adachi  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 16:36 Message: The function apply allows evaluates its arguments. This is the expected and the documented behaviour. (%i1) args:[f(i),i,0,n]; (%o1) [f(i),i,0,n] The variables of the list of arguments have not values: (%i2) apply('sum,args); (%o2) 'sum(f(i),i,0,n) Set the variable n: (%i3) n:4; (%o3) 4 The variable n now evaluates to the number 4: (%i4) [f(i),i,0,n]; (%o4) [f(i),i,0,4] apply evaluates its arguments too and the function sum evaluates the expression for an upper bound n:4: (%i6) apply('sum,args); (%o6) f(4)+f(3)+f(2)+f(1)+f(0) It is not possible to quote the argument: (%i8) apply('sum,[f(i),i,0,'n]); (%o8) f(4)+f(3)+f(2)+f(1)+f(0) Setting the status of this bug report to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2895770&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:10

Bugs item #2069818, was opened at 20080823 15:25 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2069818&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: Xmaxima or other UI Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Henry Peters (henry09) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima v.5.13 crashes when changing preferences. Initial Comment: In Ubuntu 8.04.1, Maxima version 5.13.0 crashes when I try to make any change in the preference window. I downloaded & installed via the 'Add/Remove' package manager. Also, the program opens as not a full screen (perhaps there is some bug associated with (saving of preferences?)). Thanks, Henry  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 12:32 Message: I have tried xmaxima with Maxima 5.19post on Ubuntu 9.10. I do not have the observed problem. But I do not install the packages from Debian, but install from cvs. There are some known problems with the Debian packages. Perhaps this problem is related to such a problem too. Setting the status to pending and the resolution to works for me. Dieter Kaiser  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20080825 20:32 Message: Logged In: YES user_id=1270759 Originator: NO Hello, As mentioned in a previous post, I installed maxima, xmaxima and wxmaxima from the ubuntu (hardy) repository and all three work as expected. I suggest you post a message to the main maxima list describing your problem in some more detail. If others have had the same problem, perhaps you can get better answers. Mario  Comment By: Henry Peters (henry09) Date: 20080825 03:04 Message: Logged In: YES user_id=2191245 Originator: YES Hi Mario, Good to speak with an actual person with a name here! Yes, I downloaded wxmaxima & it works fine (with limited use). I am, however, trying to point my nose toward a Linux direction, & would like to stay there as much as possible, so hoping to resolve this little problem somehow. I am also wondering if there are something the equivalent in Linux to a preferences file that may have been or become corrupted (this did happen both in Windows & Macintosh)? Also, speaking of wxmaxima, I was exploring it this afternoon, & also checked my email (in Windows) & across the Maxima discussion list came an email regarding an upgrade... wondering if you know if it was for Wxmaxima or the Linux version (I believe they did not mention which). If it is Linux, perhaps the upgrade might fix my problem... of course, since I am on dialup here (*very* slow dialup!) that means a multihour down load. Oh well, I suppose I should check the downloads section. Any further suggestions would be welcome (from any perusing this bug chase). Henry  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20080824 10:08 Message: Logged In: YES user_id=1270759 Originator: NO Henry, I uninstalled Maxima from synaptic and installed it again via de Add/Remove tool. After that I made some changes in Options/Preferences (font types and sizes) and Maxima didn't crash. On the other hand, xmaxima window doesn't fill the screen when you open it, but as far as I can say, it has been always so; I think this fact is not related to your problem. Probably, you already know that you can install the wxmaxima gui too; you can give it a try. Sorry, if this answer is not of much help and for my previous anonymous post. Mario Rodriguez  Comment By: Henry Peters (henry09) Date: 20080823 23:42 Message: Logged In: YES user_id=2191245 Originator: YES To reply to the sender of the comment below (Nobody), I am working in the xmaxima mode (just got the program, so "working" is not really an apt description). & hope it is good news that someone has somehow resolved this problem... (or rather, that it doesn't appear in the first place). The program, generally, seems to work ok (like I said, very limited use so far). I do dual boot with Windows XP which Maxima version I also downloaded last evening. That version looks great (!), as well as seems to function. Henry  Comment By: Nobody/Anonymous (nobody) Date: 20080823 21:53 Message: Logged In: NO I have just installed Maxima 5.13 in Ubuntu 8.04 via synaptic and everything seems to work fine, included xmaxima and wxmaxima. Maybe the original poster could give some more details. Are you working in text mode or through graphical interfaces (xmaxima, wxmaxima)?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2069818&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:20:10

Bugs item #2815422, was opened at 20090701 20:37 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2815422&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: Xmaxima or other UI Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal point problem Initial Comment: Whenever I press the "." button on the number pad part of my keyboard wxMaxima version 0.8.2 inputs two "."s instead of just one as it should. If I press the button on the other part of the keyboard it works just fine. My keyboard is a Saitek Eclipse, my OS is Vista Ultimate x64. If you need any additional information let me know. Also, I often times am only after numerical computations so I use my number pad a lot when using wxMaxima and I would like the option to evaluate when enter is pressed to also include the enter key on the number pad.  >Comment By: SourceForge Robot (sfrobot) Date: 20091129 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20091114 16:59 Message: I think this is a very specific hardware problem which might be a problem of wxMaxima or even Vista. Furthermore, I think it is not a problem of Maxima and cannot solved within Maxima. Perhaps, this problem should be reported as a bug to the bug tracker of wxMaxima. Setting the status to pending and the resolution to "Wont fix". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2815422&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 02:08:58

Bugs item #2770575, was opened at 20090417 13:47 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2770575&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: rtestsum test 226 Initial Comment: The expected answer to test 226 in rtestsum is incorrect (it's not simplified). (%i1) sumcontract(sum(k, k, 1, 1 + n) + sum(k, k, 1, n)); (%o1) n+(sum(2*k,k,1,n))+1 (%i2) expand(%,0,0); (%o2) n+2*(sum(k,k,1,n))+1  >Comment By: Dieter Kaiser (crategus) Date: 20091129 03:08 Message: Fixed in sumcon.lisp revision 1.12. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2770575&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 01:59:17

Bugs item #1521112, was opened at 20060712 13:14 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521112&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  Solving equations Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Araceli Gárate García (agarate) Assigned to: Nobody/Anonymous (nobody) Summary: To know which are the inconsistent equations Initial Comment: Hi, I have an inconsistent equation system, I need to know which are the inconsistent equations when the linsolve command is used. I know that this is displayed when the flag solve_inconsistent_error is true, but I need to use this information in a program. For example, (%i169) linsolve([a+b=0,a+b=1,a+c=2],[a,c]); Inconsistent equations: (2)  an error. Quitting. To debug this try debugmode(true); (%i170) I need to know that 2 is the inconsistent equation, Is there any way to know that? Thank you Araceli  >Comment By: Dieter Kaiser (crategus) Date: 20091129 02:59 Message: I think this is not a bug report, but a support request. Perhaps it is a feature request. Closing this bug report as out of date. Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20070131 09:50 Message: Logged In: NO hi (%i12) linsolve([a+b=1,a+c=2],[a,c]); (%o12) [a = 1  b, c = b + 1] (%i13) linsolve([a+b=0,a+c=2],[a,c]); (%o13) [a =  b, c = b + 2] (%i14) linsolve([a+b=0,a+b=1],[a,c]); Inconsistent equations: (2)  an error. To debug this try debugmode(true); the equations [a+b=0,a+b=1] are contradictory, and if you remove one of them your system has a solution. but look at the system linsolve([a=0,c=0,a+c=1],[a,c]) these three equations are inconsistent but if you pick two of them a unique solution exists. so what are the inconsistent equations? in the common case you cannot say these equations of a systems are inconsistent and the rest is consistent. of course an inconsistent system can contain an inconsistent subsystems, but i think how to find out such inconsistent subsystems is a question for a mathematics group and not for a bug report guenter  Comment By: Barton Willis (willisbl) Date: 20060814 04:53 Message: Logged In: YES user_id=895922 Without hacking the function solvex (in src/solve), I don't think there is a way to get at this information. Of course, which equation is is inconsistent is somewhat arbitrary: in [x=3,x=6,x=7], which two equations are inconsistent? Maybe you would like to use the function rank: (%i24) load(linearalgebra)$ (%i25) rank(matrix([6,7],[6,17])); (%o25) 2(%i26) rank(matrix([6,7],[6,7])); (%o26) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521112&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 01:48:44

Bugs item #1533584, was opened at 20060803 04:03 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1533584&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  Plotting Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(sum(1/i,i,1,n),[n,1,10]) produces stack overflow Initial Comment: Executing "plot2d(sum(1/i,i,1,n), [n,1,10])" fails with "Unrecoverable error: bind stack overflow".  >Comment By: Dieter Kaiser (crategus) Date: 20091129 02:48 Message: I think the problem has gone. I have no problems to get the plot with Maxima 5.19post. Settting the status to pending and "works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060806 05:14 Message: Logged In: YES user_id=501686 plot2d assumes (unless told otherwise) that the expression to be plotted can be evaluated at any point within [1, 10]. However sum(1/i,i,1,n) is only welldefined for integer n. Perhaps you meant L1 : makelist (n, n, 1, 10); L2 : makelist (sum(1/i, i, 1, n), n, 1, 10); L2 : L2, numer; plot2d ([discrete, L1, L2]); Although "plot2d(sum(1/i,i,1,n), [n,1,10]); isn't valid, plot2d should try to do something smarter than stack overflow in that case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1533584&group_id=4933 
From: SourceForge.net <noreply@so...>  20091129 01:40:13

Bugs item #1764306, was opened at 20070731 12:47 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764306&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  Trigonometry Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Inverse Trigonometry (partial answer) Initial Comment: atan(tan(4)) gives an answer 4 (not 4  %pi) atan(tan(10)) gives an answer 10 (not 10  3*%pi) atan(tan(23)) gives an answer 23 (not 23  7*%pi)  >Comment By: Dieter Kaiser (crategus) Date: 20091129 02:40 Message: This has changed. With Maxima 5.19post we get: (%i4) atan(tan(4)); (%o4) 4  %pi (%i5) atan(tan(10)); (%o5) 10  3 %pi (%i6) atan(tan(23)); (%o6) 23  7 %pi Closing this bug report as "works for me". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20070910 17:40 Message: Logged In: YES user_id=28849 Originator: NO See the variable triginverses, which defaults to all. Maxima is doing what it's documented to do. However, I think that with integer args, maxima should do as you suggest, except I'm not sure how it should interact with triginverses.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764306&group_id=4933 