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}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(12) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2

3
(10) 
4
(1) 
5
(3) 
6
(1) 
7

8
(1) 
9

10

11
(1) 
12
(6) 
13
(4) 
14
(6) 
15

16
(1) 
17
(8) 
18
(4) 
19
(6) 
20
(3) 
21
(3) 
22
(1) 
23
(3) 
24

25
(1) 
26

27

28

29
(3) 
30

31
(6) 




From: SourceForge.net <noreply@so...>  20070719 00:13:37

Bugs item #1490397, was opened at 20060517 13:12 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1490397&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  Polynomials Group: None >Status: Pending >Resolution: Fixed Priority: 8 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: subres gcd wrong Initial Comment: Here is an example of where subres produces the wrong result but spmod is ok. p:(x^3+1)/(2*x^5+2); q:(sqrt(5)+5)/(20*x^2+(10*sqrt(5)10)*x+20); gcd:subres; ratsimp(p+q); => ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/(80*x^5+80) But now see what happens with spmod: gcd:spmod; ratsimp(p+q); => ((sqrt(5)+5)*x^5+(5*sqrt(5)5)*x^4+10*x^310*x^2+(5*sqrt(5)+5)*x +sqrt(5)15) /(20*x^7+(10*sqrt(5)10)*x^6+20*x^5+20*x^2+(10*sqrt(5)10)*x+20) factor(%): => (sqrt(5)*x^5+5*x^55*sqrt(5)*x^45*x^4+10*x^310*x^2+5*sqrt(5)*x+5*x +sqrt(5)15) /(10*(x+1)*(2*x^2sqrt(5)*xx+2)*(x^4x^3+x^2x+1)) Maxima doesn't notice but the numerator has the factor 2*x^2sqrt(5)*xx+2: divide((sqrt(5)*x^5+5*x^55*sqrt(5)*x^45*x^4+10*x^310*x^2+5*sqrt(5)*x+5*x +sqrt(5)15), (2*x^2sqrt(5)*xx+2)); => [((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/2,0] So the final result of ratsimp is ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/2/(10*(x+1)*(x^4x^3+x^2x+1)); Notice that the numerator matches the numerator for the subres result, but the denominator is off by a factor of 4!  >Comment By: Dan Gildea (dgildea) Date: 20070718 20:13 Message: Logged In: YES user_id=1797506 Originator: NO Fix to routine ratsum in cvs, new behavior: (%i2) gcd:subres; (%i3) p:(x^3+1)/(2*x^5+2); (%i4) q:(sqrt(5)+5)/(20*x^2+(10*sqrt(5)10)*x+20); (%i5) ratsimp(p+q); => ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/(20*x^5+20)  Comment By: Dan Gildea (dgildea) Date: 20070718 20:13 Message: Logged In: YES user_id=1797506 Originator: NO The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  Comment By: Robert Dodier (robert_dodier) Date: 20060826 15:33 Message: Logged In: YES user_id=501686 Increasing the priority. GCD problems are widely reported. We really need to clean this up.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1490397&group_id=4933 
From: SourceForge.net <noreply@so...>  20070718 10:43:20

Bugs item #716508, was opened at 20030406 22:50 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=716508&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  Polynomials Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: GCD/subres problem using Partfrac Initial Comment: expr: 1/ ( (x+(SQRT(3)1)^(1/3)) *(x+(SQRT(3)1)^(4/3)) *(x(SQRT(3)+1)^(1/3)) *(x(SQRT(3)1)^(1/3)*(SQRT(3)+1)) *(x+(SQRT(3)+1)^(4/3))) partfrac(expr,x) takes forever (infinite loop?). However, with nondefault GCD's, it works fine: partfrac(expr,x),gcd:ez // spmod // algebraic  >Comment By: Dan Gildea (dgildea) Date: 20070718 06:43 Message: Logged In: YES user_id=1797506 Originator: NO seems to work in 5.12.0 and current cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=716508&group_id=4933 
From: SourceForge.net <noreply@so...>  20070718 10:34:09

Bugs item #1730044, was opened at 20070602 16:01 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1730044&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: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: powerseries(1+x^n,x,0) wrong Initial Comment: powerseries(1+x^n,x,0) => 'sum((1)^i1*x^(i1*n),i1,0,inf) but this is actually the series for 1/(1+x^n) Conversely, powerseries(1/(1+x^n),x,0) => Unable to expand This might be a simple mixup somewhere in the code.... Maxima 5.11.0 GCL 2.6.8 Cygwin  >Comment By: Dan Gildea (dgildea) Date: 20070718 06:34 Message: Logged In: YES user_id=1797506 Originator: NO sign problem fixed in series.lisp rev 1.13. new behavior: (%i2) powerseries(1+x^n,x,0); (%o2) ('sum(x^(i1*n)/beta(2i1,i1+1),i1,0,inf))/2 (%i3) powerseries(1/(1+x^n),x,0); (%o3) "Unable to expand" (%i4) declare(n, integer); (%o4) done (%i5) powerseries(1+x^n,x,0); (%o5) ('sum(x^(i3*n)/beta(2i3,i3+1),i3,0,inf))/2 (%i6) powerseries(1/(1+x^n),x,0); (%o6) 'sum((1)^i4*x^(i4*n),i4,0,inf) I suppose ideally %o6 should only happen in n is known to be a positive integer.  Comment By: Dan Gildea (dgildea) Date: 20070718 06:34 Message: Logged In: YES user_id=1797506 Originator: NO The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1730044&group_id=4933 
From: SourceForge.net <noreply@so...>  20070718 08:22:29

Bugs item #1725549, was opened at 20070525 14:42 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1725549&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: mnewton does not work Initial Comment: Maxima 5.12.0 http://maxima.sourceforge.net Using Lisp CLISP 2.39 (20060716) ... The example for usage of mnewton from the manual returns: (%i2) mnewton([x1+3*log(x1)x2^2, 2*x1^2x1*x25*x1+1], [x1, x2], [5, 5]); (%o2) [[x1 = 3.822890025575447, x2 = 2.807544757033248]] instead of [[x1 = 3.756834008012769, x2 = 2.779849592817897]], as given in the manual. Another example is: (%i9) mnewton([2*(x11.1234),3*(x22.2345)], [x1, x2], [1,2]); (%o9) [[x1 = 1.0, x2 = 2.166666666666667]] and probably not what one expects.  >Comment By: Andrej Vodopivec (andrejv) Date: 20070718 10:22 Message: Logged In: YES user_id=1179910 Originator: NO Fixed in cvs by replacing the call to linsolve with linsolve_by_lu. In current cvs: (%i1) load(mnewton)$ (%i2) mnewton([x1+3*log(x1)x2^2, 2*x1^2x1*x25*x1+1], [x1, x2], [5, 5]); (%o2) [[x1=3.7568340080128,x2=2.7798495928179]] (%i3) mnewton([2*(x11.1234),3*(x22.2345)], [x1, x2], [1,2]); (%o3) [[x1=1.1234,x2=2.2345]] Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1725549&group_id=4933 
From: SourceForge.net <noreply@so...>  20070718 08:20:59

Bugs item #1666011, was opened at 20070222 12:12 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1666011&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: mnewton & Polynomial quotient is not exact Initial Comment: (%i1) load(mnewton); (%i2) mnewton([x^y  %i,x+y2],[x,y],[1,1.5]); Polynomial quotient is not exact I can't eliminate the error by setting gcd : spmod.  >Comment By: Andrej Vodopivec (andrejv) Date: 20070718 10:20 Message: Logged In: YES user_id=1179910 Originator: NO Fixed in cvs by replacing the call to linsolve with linsolve_by_lu. In current cvs: (%i1) load(mnewton)$ (%i2) mnewton([x^y  %i,x+y2],[x,y],[1,1.5]); (%o2) [[x=0.563519172421*%i+0.451201761049,y=1.54879823895050.563519172421*%i]] (%i3) abs(rectform(subst(%o2[1], part(%i2, 1)))); (%o3) [5.58478238525471*10^16,0.0] Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1666011&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 21:57:23

Bugs item #1755550, was opened at 20070717 18:03 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755550&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: Open Resolution: None Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: trig inconsistent about periodicity rules Initial Comment: OK  use perodicity to simplify to zero: (%i5) cos(2*%pi + %e^2)  cos(%e^2); (%o5) 0 Not so OK: (%i6) cos(2*%pi + %pi^2)  cos(%pi^2); (%o6) cos(%pi^2+2*%pi)cos(%pi^2) Sure, we can apply trigexpand: (%i7) trigexpand(%); (%o7) 0 This isn't a bug, I suppose. But we could do better.  >Comment By: Harald Geyer (hgeyer) Date: 20070717 23:57 Message: Logged In: YES user_id=929336 Originator: NO I think the problem is, that %piargs only touches expressions that are linear in %pi. Compare this with Bug #1553866.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755550&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 20:10:38

Bugs item #1731624, was opened at 20070605 13:05 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1731624&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: Sanjoy Mahajan (sm324) Assigned to: Nobody/Anonymous (nobody) Summary: asked about sign of yx in integral containing only z Initial Comment: Entering integrate(exp(sqrt(z^3)),z,0,1); produces Is yx positive or negative? But there is no yx in the integrand. I thought maxima might have an implicit rule about z = x + iy, so I tried the integral using q as the variable instead of z, but the same question was asked. Maxima version: 5.12.0 Maxima build date: 3:18 5/23/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (it's the Ubuntu 5.12.01ubuntu1 package from the upcoming release of Ubuntu recompiled on my Ubuntu feisty system).  >Comment By: Robert Dodier (robert_dodier) Date: 20070717 14:10 Message: Logged In: YES user_id=501686 Originator: NO Another example (from the mailing list): integrate( exp( sqrt(x) ), x, 1, 5); => Is yx positive or negative?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1731624&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 16:07:49

Bugs item #1753971, was opened at 20070714 08:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1753971&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: specint gives lisp error Initial Comment: (%i1) specint(t^(5/2)*bessel_y(a,t^(1/2))^2*%e^(p*t),t); Is p positive, negative, or zero? pos; Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: $A is not of type LIST.  >Comment By: Raymond Toy (rtoy) Date: 20070717 12:07 Message: Logged In: YES user_id=28849 Originator: NO This fails in fractest where it assumes the index of the Bessel Y function is a rational number. Changing this to check for listp before doing caar fixes the immediate issue. However, the result is then productofywithnofractindices. I'm not sure under what conditions fractest is supposed to work for Bessel Y functions.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1753971&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 16:03:57

Bugs item #1755550, was opened at 20070717 11:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755550&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: Open Resolution: None Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: trig inconsistent about periodicity rules Initial Comment: OK  use perodicity to simplify to zero: (%i5) cos(2*%pi + %e^2)  cos(%e^2); (%o5) 0 Not so OK: (%i6) cos(2*%pi + %pi^2)  cos(%pi^2); (%o6) cos(%pi^2+2*%pi)cos(%pi^2) Sure, we can apply trigexpand: (%i7) trigexpand(%); (%o7) 0 This isn't a bug, I suppose. But we could do better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755550&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 10:31:22

Bugs item #1755392, was opened at 20070717 05:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755392&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: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: trig with xxx[%pi] arguments Initial Comment: The trig functions have trouble with some arguments that involve xxx[%pi] or xxx[%pi + 1], or ... ; for example (%i1) cos(2*%pi + a[%pi]); (%o1) 1 (%i2) sin(2*%pi + a[%pi]); (%o2) 0 (%i3) tan(2*%pi + a[%pi]); (%o3) 0 (%i15) cos(2*%pi + a[%pi+1]); (%o15) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755392&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 05:01:47

Bugs item #1755262, was opened at 20070716 22:22 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755262&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: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Chris Samuel (chrissamuel) Assigned to: Nobody/Anonymous (nobody) Summary: Website has wrong date for release of Maxima 5.12.0 Initial Comment: The News section on the front page of the Maxima website currently has the date of the announcement of the 5.12.0 release as "May 2, 2006" rather than 2007..  >Comment By: Robert Dodier (robert_dodier) Date: 20070716 23:01 Message: Logged In: YES user_id=501686 Originator: NO Date corrected to 2007. Thanks for pointing it out. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755262&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 04:22:21

Bugs item #1755262, was opened at 20070717 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755262&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Samuel (chrissamuel) Assigned to: Nobody/Anonymous (nobody) Summary: Website has wrong date for release of Maxima 5.12.0 Initial Comment: The News section on the front page of the Maxima website currently has the date of the announcement of the 5.12.0 release as "May 2, 2006" rather than 2007..  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1755262&group_id=4933 
From: SourceForge.net <noreply@so...>  20070717 00:36:42

Bugs item #1742275, was opened at 20070623 17:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1742275&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: Harald Geyer (hgeyer) Assigned to: Nobody/Anonymous (nobody) Summary: featurep(false, 'complex) Initial Comment: Currently featurep(false, 'complex) returns true. This is not what I would expect. After looking at the definition of featurep() it becomes obvious, that it returns always true for complex. This test is pointless. I'm not sure in which cases besides true/false this test should be negative. I'm not sure in which cases this test is useful at all. Perhaps this should just be removed from maxima?  >Comment By: Robert Dodier (robert_dodier) Date: 20070716 18:36 Message: Logged In: YES user_id=501686 Originator: NO For the record, here is a message I posted to the mailing list: On 7/14/07, Harald Geyer <Harald.Geyer@...> wrote: > I have thought about bug 1742275 "featurep(false, 'complex) > true" > a bit and i basically see two possible solutions: Well, featurep has evolved toward evaluating predicates of the form is(x in S) where S is a set; I think featurep recognizes integers, rationals, reals, complex, and pure imaginary, maybe some others. That is a useful idea, but at present featurep is not a very good implementation of it. In that spirit, feature(false, 'complex) should return false because false is a Boolean literal and therefore demonstrably not an element of set of complex numbers. Likewise featurep(true, 'complex) and featurep("foo", 'complex) should return false. featurep(A, 'complex) where A is a matrix, list, or set should return false (or maybe featurep should distribute over aggregate objects; dunno if I'm for or against that). > a) > Just remove the condition ((eq ind '$complex) t) from $featurep. > With this we would get > declare(z, 'complex); featurep(z, 'complex); > true > because of the generic condition for symbol properties. But > featurep(1+%i, 'complex); > false Hmm. I guess I don't like this one. > b) > Change the condition to > ((eq ind '$complex) > (let ((ris (trisplit e))) > (not (or (zerop1 (car ris)) (zerop1 (cdr ris)))))) > which is equivalent to realpart(expr) != 0 and imagpart(expr) != 0 At present featurep seems to embody the notion that featurep(X, S) => featurep(X, T) when S is a subset of T. That makes sense to me and I don't want to change it at the moment. Requiring that realpart and imagpart be nonzero makes featurep true isn't consistent with that. So I guess I don't like this one either. As mentioned by others, featurep has accumulated some baggage over the years and probably we're best off separating the stuff which has only to do with declared properties of symbols, and potentiallyinferred properties of symbols or expressions. For the moment I think changing featurep(foo, complex) to return false when foo is a Boolean or string literal is a step forward. In the long run, I would like to see declarations expanded to expressions as well as symbols, which would allow stuff like: declare (x in Z); declare (matrixp (y)); declare (z in R and z > 0); I'd like to merge the declare and assume stuff  these could equally well be assume(x in Z), assume(matrixp(y)), etc. For the moment this is just a daydream. FWIW Robert  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1742275&group_id=4933 
From: SourceForge.net <noreply@so...>  20070716 13:29:33

Bugs item #1754781, was opened at 20070716 06:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754781&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot doesn't work with special characters in Username Initial Comment: (%i2) f(x):=x; (%o2) f(x):=x (%i3) wxplot2d([%o2], [x,5,5]) $Maxima encountered a Lisp error: Error in APPLY [or a callee]: Cannot create the file C:/Dokumente und Einstellungen/blubb/maxout.gnuplot.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.(%i4) The Username is not correct. It must be b^l^u^b^b. It seems that special characters are ignored.  Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754781&group_id=4933 
From: SourceForge.net <noreply@so...>  20070714 23:36:34

Bugs item #902290, was opened at 20040222 22:11 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Harald Geyer (hgeyer) Date: 20070715 01:36 Message: Logged In: YES user_id=929336 Originator: NO >> Yes, I know that nouns usually have simplifications, but IMHO these >> should do different things than the verb operation and avoid code >> duplication. > > What are the "different things" you have in mind here? For example: the program: integrate(cos(x),x) > sin(x) simplification: integrate(f(x),x,a,b)+integrate(f(x),x,b,c) > integrate(f(x),x,a,c) Unfortunately this isn't implemented ... :( > Much of Maxima simplification deals with cases where there is no clear > line. I don't consider that a valid reason to make it worse. :) > Why does x/x simplify to 1, but (x^2x)/(x1) not simplify to x? The second problem involves the distributive law and the core simplifier (rightly) doesn't touch it, because you can't (gnerally) tell which side of the distributive law is more useful. I.e. it depends on what you want to do with the result. > In the case of rectform or integrate or limit, I think normal users would > find it strange for the constantargument case not to simplify, and of > course this is easy to implement. This I don't believe. In my experience, users fit into three classes: a) unexperienced: Don't know the difference between evaluation and simplification. They will get confused whenever these behave differently. b) semiexperienced: They will wonder why the quote operator doesn't work in 'integrate(q,x). Actually this is the only complaint I remember to have heard by a user. c) experienced: They don't care as long as it is easy to predict what maxima will do. >> I'm not against convenience features. I only think these should be >> clearly encapsulated rather than mixed with the core functionality. > Why is sin(x)+sin(x)=>0 "core functionality" but > 'realpart(x)+'realpart(x)=>0 a "convenience feature"? Because there is no program sin(). >> Actually I'm quite happy with subst(), even if it returns things like >> 'abs(1). > But it *doesn't* return 'abs(1). Sorry for the lapsus, I meant 'realpart(1) of course. But I wouldn't mind if it *did* return 'abs(1) in the appropriate case. I do mind if I get subst(1,z,'realpart(z)) > 'abs(1). ;) >> It should do the same as if I had typed in the expression with >> all substitutions in the first place. > Simplification does exactly that. Only if you implement the full logic of the program into the simplifier! In case this isn't clear from my previous posts: I'm not on a crusade against simplification, I'm just concerned with a) code duplication leading to less maintainable code b) confusing our users with inconsistent behaviour of nouns and verbs. After looking at the code a bit, I can follow up on my last post: I think the reason why realpart() and imagpart() are programs is because you get them for free (one liners) after implementing rectform(). But perhaps the same code could be used in the simplifier or the simplifier could just convert nouns into verbs whenever resimplification is due? Do you think such an approach is reasonable and feasible?  Comment By: Stavros Macrakis (macrakis) Date: 20070714 22:24 Message: Logged In: YES user_id=588346 Originator: YES > Yes, I know that nouns usually have simplifications, but IMHO these > should do different things than the verb operation and avoid code > duplication. What are the "different things" you have in mind here? > As you say yourself there is no clear line. Much of Maxima simplification deals with cases where there is no clear line. Why does x/x simplify to 1, but (x^2x)/(x1) not simplify to x? Why does tan(%pi/4) simplify to 1, but tan(%pi/16) not simplify to sqrt(sqrt(2)1)*(2^(3/4)+(sqrt(2)+1)^(3/2)2*2^(1/4))? The answer is a combination of a) what the user might find reasonable and useful; what causes the rest of simplification to produce reasonable results; and c) what can be implemented to run reasonably fast. In the case of rectform or integrate or limit, I think normal users would find it strange for the constantargument case not to simplify, and of course this is easy to implement. > I think adding simplification for simple cases just because > they can be done efficiently is a cosmetic (or annoying  depending on > your POV) enhancement without adding functionality. Then what exactly would simplification handle? Surely you want x+0 and 2*xx to simplify to x, sin(0), cos(%pi/2), sin(x)+sin(x), and cos(1x)cos(x1) to simplify to 0, and gamma(1) to simplify to 1. I would think you would analogously want 'realpart(0) and 'realpart(x)+'realpart(x) to simplify to 0. > I'm not against convenience features. I only think these should be > clearly encapsulated rather than mixed with the core functionality. Why is sin(x)+sin(x)=>0 "core functionality" but 'realpart(x)+'realpart(x)=>0 a "convenience feature"? > Actually I'm quite happy with subst(), even if it returns things like 'abs(1). But it *doesn't* return 'abs(1). > It should do the same as if I had typed in the expression with > all substitutions in the first place. Simplification does exactly that. s  Comment By: Harald Geyer (hgeyer) Date: 20070713 11:28 Message: Logged In: YES user_id=929336 Originator: NO It is not a problem per se, but I see two issues: 1) It will make the code less maintainable if the same functionality is implemented twice in different places. For example I know three different implementations of testing whether an expression is integer valued. All have different capablities, because nobody keeps them in sync. 2) It's potentially confusing if there is no clear line between how a noun behaves and what a verb does. It's easier to explain to new users, that 'realpart(1) doesn't evaluate because 'abs is a noun than to explain why 'realpart(1) is simplified but 'realpart(sin(z)) isn't. Of course the above could be avoided if realpart() and co would get entirely converted to nouns as is done with sin(). I wonder why this wasn't done in the first place? BTW, why do you think that 'realpart(1) is more a problem (bug) than 'realpart(sin(z)) or even 'realpart(very_complicated_expr)?  Comment By: Robert Dodier (robert_dodier) Date: 20070713 03:13 Message: Logged In: YES user_id=501686 Originator: NO For my part, I am convinced that failing to simplify 'realpart(1) and 'imagpart(1) is very definitely a bug. Harald, a simplification is just the application of some identity. If the same identity is applied by both a verb and simplification of a noun, that is no problem.  Comment By: Harald Geyer (hgeyer) Date: 20070713 02:04 Message: Logged In: YES user_id=929336 Originator: NO Yes, I know that nouns usually have simplifications, but IMHO these should do different things than the verb operation and avoid code duplication. As you say yourself there is no clear line. Why is 'integrate(sin(x),x) ok? Why 'integrate(q,x) not? Why 'rectform(1) not? I think adding simplification for simple cases just because they can be done efficiently is a cosmetic (or annoying  depending on your POV) enhancement without adding functionality. Actually this makes the line less clear and maxima more confusing. I'm not against convenience features. I only think these should be clearly encapsulated rather than mixed with the core functionality. I.e. specify() would be such a function. On what specify() should do: I'm not sure. Actually I'm quite happy with subst(), even if it returns things like 'abs(1). It should do the same as if I had typed in the expression with all substitutions in the first place. I guess the minimum requirement would be to replace certain nouns by their corresponding verbs. But probably somebody has a better idea. Some examples: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) specify(sin, f, %); (%o4)  cos(x); (%i1) declare(z1, complex, z2, complex); (%o1) done (%i2) realpart(z1); (%o2) realpart(z1) (%i3) specify(sin(z2), z1, %); (%o3) cosh(imagpart(z2)) sin(realpart(z2))  Comment By: Stavros Macrakis (macrakis) Date: 20070712 23:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 23:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 19:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 12:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 20:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070714 20:24:27

Bugs item #902290, was opened at 20040222 16:11 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Stavros Macrakis (macrakis) Date: 20070714 16:24 Message: Logged In: YES user_id=588346 Originator: YES > Yes, I know that nouns usually have simplifications, but IMHO these > should do different things than the verb operation and avoid code > duplication. What are the "different things" you have in mind here? > As you say yourself there is no clear line. Much of Maxima simplification deals with cases where there is no clear line. Why does x/x simplify to 1, but (x^2x)/(x1) not simplify to x? Why does tan(%pi/4) simplify to 1, but tan(%pi/16) not simplify to sqrt(sqrt(2)1)*(2^(3/4)+(sqrt(2)+1)^(3/2)2*2^(1/4))? The answer is a combination of a) what the user might find reasonable and useful; what causes the rest of simplification to produce reasonable results; and c) what can be implemented to run reasonably fast. In the case of rectform or integrate or limit, I think normal users would find it strange for the constantargument case not to simplify, and of course this is easy to implement. > I think adding simplification for simple cases just because > they can be done efficiently is a cosmetic (or annoying  depending on > your POV) enhancement without adding functionality. Then what exactly would simplification handle? Surely you want x+0 and 2*xx to simplify to x, sin(0), cos(%pi/2), sin(x)+sin(x), and cos(1x)cos(x1) to simplify to 0, and gamma(1) to simplify to 1. I would think you would analogously want 'realpart(0) and 'realpart(x)+'realpart(x) to simplify to 0. > I'm not against convenience features. I only think these should be > clearly encapsulated rather than mixed with the core functionality. Why is sin(x)+sin(x)=>0 "core functionality" but 'realpart(x)+'realpart(x)=>0 a "convenience feature"? > Actually I'm quite happy with subst(), even if it returns things like 'abs(1). But it *doesn't* return 'abs(1). > It should do the same as if I had typed in the expression with > all substitutions in the first place. Simplification does exactly that. s  Comment By: Harald Geyer (hgeyer) Date: 20070713 05:28 Message: Logged In: YES user_id=929336 Originator: NO It is not a problem per se, but I see two issues: 1) It will make the code less maintainable if the same functionality is implemented twice in different places. For example I know three different implementations of testing whether an expression is integer valued. All have different capablities, because nobody keeps them in sync. 2) It's potentially confusing if there is no clear line between how a noun behaves and what a verb does. It's easier to explain to new users, that 'realpart(1) doesn't evaluate because 'abs is a noun than to explain why 'realpart(1) is simplified but 'realpart(sin(z)) isn't. Of course the above could be avoided if realpart() and co would get entirely converted to nouns as is done with sin(). I wonder why this wasn't done in the first place? BTW, why do you think that 'realpart(1) is more a problem (bug) than 'realpart(sin(z)) or even 'realpart(very_complicated_expr)?  Comment By: Robert Dodier (robert_dodier) Date: 20070712 21:13 Message: Logged In: YES user_id=501686 Originator: NO For my part, I am convinced that failing to simplify 'realpart(1) and 'imagpart(1) is very definitely a bug. Harald, a simplification is just the application of some identity. If the same identity is applied by both a verb and simplification of a noun, that is no problem.  Comment By: Harald Geyer (hgeyer) Date: 20070712 20:04 Message: Logged In: YES user_id=929336 Originator: NO Yes, I know that nouns usually have simplifications, but IMHO these should do different things than the verb operation and avoid code duplication. As you say yourself there is no clear line. Why is 'integrate(sin(x),x) ok? Why 'integrate(q,x) not? Why 'rectform(1) not? I think adding simplification for simple cases just because they can be done efficiently is a cosmetic (or annoying  depending on your POV) enhancement without adding functionality. Actually this makes the line less clear and maxima more confusing. I'm not against convenience features. I only think these should be clearly encapsulated rather than mixed with the core functionality. I.e. specify() would be such a function. On what specify() should do: I'm not sure. Actually I'm quite happy with subst(), even if it returns things like 'abs(1). It should do the same as if I had typed in the expression with all substitutions in the first place. I guess the minimum requirement would be to replace certain nouns by their corresponding verbs. But probably somebody has a better idea. Some examples: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) specify(sin, f, %); (%o4)  cos(x); (%i1) declare(z1, complex, z2, complex); (%o1) done (%i2) realpart(z1); (%o2) realpart(z1) (%i3) specify(sin(z2), z1, %); (%o3) cosh(imagpart(z2)) sin(realpart(z2))  Comment By: Stavros Macrakis (macrakis) Date: 20070712 17:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 17:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 13:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 06:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 14:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070714 19:58:52

Bugs item #1751951, was opened at 20070711 09:51 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1751951&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: 4 Private: No Submitted By: Miguel Aguado (maguado) >Assigned to: Barton Willis (willisbl) Summary: diag_matrix() with block matrices gets offdiag boxes wrong Initial Comment: Hello, I couldn't find this bug among the reports, sorry if I didn't search hard enough. The problem is related to "linearalgebra," concretely to function diag_matrix, which is said in the documentation to create appropriate offdiagonal zero blocks when its arguments are matrices. This is not so, as in the following example: (%i2) b1 : matrix( [ 1 ] ); (%o2) [ 1 ] (%i3) b2 : matrix( [ 0, 1 ], [ 7, 9 ] ); [ 0 1 ] (%o3) [ ] [ 7 9 ] (%i4) dma : diag_matrix( b1, b2 ); [ 0 1 ] (%o4) diag_matrix([ 1 ], [ ]) [ 7 9 ] (%i5) load("linearalgebra"); (%o5) /usr/share/maxima/5.10.0/share/linearalgebra/linearalgebra.mac (%i6) dma : diag_matrix( b1, b2 ); [ [ 1 ] [ 0 ] ] [ ] (%o6) [ [ 0 0 ] [ 0 1 ] ] [ [ ] [ ] ] [ [ 0 0 ] [ 7 9 ] ] Obviously, mat_unblocker fails to handle this output. Thanks in advance, Miguel  \; Maxima version: 5.10.0 Maxima build date: 14:57 10/18/2006 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 \;   >Comment By: Barton Willis (willisbl) Date: 20070714 14:58 Message: Logged In: YES user_id=895922 Originator: NO Oh, I think that you are suggesting that size of the zero matrices in the offdiagonal entries be adjusted so that mat_unblocker will work. OK. I'll try to do that. Thanks for the bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1751951&group_id=4933 
From: SourceForge.net <noreply@so...>  20070714 19:26:24

Bugs item #1754072, was opened at 20070714 14:05 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754072&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: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) >Assigned to: Barton Willis (willisbl) Summary: $piargs bug Initial Comment: (%i7) declare(n,integer)$ (%i8) cos(%pi * n * 31/37); (%o8) (1)^((31*n)/37)  >Comment By: Barton Willis (willisbl) Date: 20070714 14:26 Message: Logged In: YES user_id=895922 Originator: YES fixed by trigi cvs revision 1.28.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754072&group_id=4933 
From: SourceForge.net <noreply@so...>  20070714 19:05:29

Bugs item #1754072, was opened at 20070714 14:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754072&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: $piargs bug Initial Comment: (%i7) declare(n,integer)$ (%i8) cos(%pi * n * 31/37); (%o8) (1)^((31*n)/37)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754072&group_id=4933 
From: SourceForge.net <noreply@so...>  20070714 12:01:58

Bugs item #1753971, was opened at 20070714 07:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1753971&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: specint gives lisp error Initial Comment: (%i1) specint(t^(5/2)*bessel_y(a,t^(1/2))^2*%e^(p*t),t); Is p positive, negative, or zero? pos; Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: $A is not of type LIST.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1753971&group_id=4933 
From: SourceForge.net <noreply@so...>  20070713 09:28:59

Bugs item #902290, was opened at 20040222 22:11 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Harald Geyer (hgeyer) Date: 20070713 11:28 Message: Logged In: YES user_id=929336 Originator: NO It is not a problem per se, but I see two issues: 1) It will make the code less maintainable if the same functionality is implemented twice in different places. For example I know three different implementations of testing whether an expression is integer valued. All have different capablities, because nobody keeps them in sync. 2) It's potentially confusing if there is no clear line between how a noun behaves and what a verb does. It's easier to explain to new users, that 'realpart(1) doesn't evaluate because 'abs is a noun than to explain why 'realpart(1) is simplified but 'realpart(sin(z)) isn't. Of course the above could be avoided if realpart() and co would get entirely converted to nouns as is done with sin(). I wonder why this wasn't done in the first place? BTW, why do you think that 'realpart(1) is more a problem (bug) than 'realpart(sin(z)) or even 'realpart(very_complicated_expr)?  Comment By: Robert Dodier (robert_dodier) Date: 20070713 03:13 Message: Logged In: YES user_id=501686 Originator: NO For my part, I am convinced that failing to simplify 'realpart(1) and 'imagpart(1) is very definitely a bug. Harald, a simplification is just the application of some identity. If the same identity is applied by both a verb and simplification of a noun, that is no problem.  Comment By: Harald Geyer (hgeyer) Date: 20070713 02:04 Message: Logged In: YES user_id=929336 Originator: NO Yes, I know that nouns usually have simplifications, but IMHO these should do different things than the verb operation and avoid code duplication. As you say yourself there is no clear line. Why is 'integrate(sin(x),x) ok? Why 'integrate(q,x) not? Why 'rectform(1) not? I think adding simplification for simple cases just because they can be done efficiently is a cosmetic (or annoying  depending on your POV) enhancement without adding functionality. Actually this makes the line less clear and maxima more confusing. I'm not against convenience features. I only think these should be clearly encapsulated rather than mixed with the core functionality. I.e. specify() would be such a function. On what specify() should do: I'm not sure. Actually I'm quite happy with subst(), even if it returns things like 'abs(1). It should do the same as if I had typed in the expression with all substitutions in the first place. I guess the minimum requirement would be to replace certain nouns by their corresponding verbs. But probably somebody has a better idea. Some examples: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) specify(sin, f, %); (%o4)  cos(x); (%i1) declare(z1, complex, z2, complex); (%o1) done (%i2) realpart(z1); (%o2) realpart(z1) (%i3) specify(sin(z2), z1, %); (%o3) cosh(imagpart(z2)) sin(realpart(z2))  Comment By: Stavros Macrakis (macrakis) Date: 20070712 23:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 23:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 19:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 12:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 20:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070713 01:19:13

Bugs item #1710774, was opened at 20070501 13:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1710774&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: Installation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Troy Henderson (tlhiv) Assigned to: Vadim V. Zhytnikov (vvzhy) Summary: Windows + space in install directory Initial Comment: The default installation directory for Maxima in Windows is C:\Program Files\Maxima... which contains a space " " in the filename. Maxima will not run from the command line or from wxMaxima. Installing in, say, C:\maxima seems to work just fine.  >Comment By: Robert Dodier (robert_dodier) Date: 20070712 19:19 Message: Logged In: YES user_id=501686 Originator: NO OK, from the IRC log I gather that the bug can't be reproduced and the default install now works OK. Closing this report as "Invalid" accordingly.  Comment By: Harald Geyer (hgeyer) Date: 20070712 15:07 Message: Logged In: YES user_id=929336 Originator: NO Further information about this problem can be found in the IRC logs of a discussion between tlhiv (the submitter) and myself in #maxima: http://rerun.lefant.net/~harald/maximalogs/20070501.txt http://rerun.lefant.net/~harald/maximalogs/20070618.txt I guess this bug report can be closed unless vvzhy has some additional ideas how to track this down.  Comment By: Robert Dodier (robert_dodier) Date: 20070702 18:43 Message: Logged In: YES user_id=501686 Originator: NO This doesn't look like a bug to me. Maybe someone can convince me it is a bug. I have run Maxima from a Windows command prompt many times. It is necessary to enclose the path in quote marks e.g "c:\program files\maxima\..." but this is nothing peculiar to Maxima. To the original poster: maybe something else is preventing Maxima from running. Feel free to post additional details here.  Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20070506 13:03 Message: Logged In: YES user_id=366498 Originator: NO Strange, nobody reported problems with spaces in installation path for very long time. On the other hand I do know situation in which the problem could arise but newer observed it in practice before. Please post your Windows version and contents of maxima.bat file in the case when maxima instelled in C:\Program Files\Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1710774&group_id=4933 
From: SourceForge.net <noreply@so...>  20070713 01:13:09

Bugs item #902290, was opened at 20040222 14:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Robert Dodier (robert_dodier) Date: 20070712 19:13 Message: Logged In: YES user_id=501686 Originator: NO For my part, I am convinced that failing to simplify 'realpart(1) and 'imagpart(1) is very definitely a bug. Harald, a simplification is just the application of some identity. If the same identity is applied by both a verb and simplification of a noun, that is no problem.  Comment By: Harald Geyer (hgeyer) Date: 20070712 18:04 Message: Logged In: YES user_id=929336 Originator: NO Yes, I know that nouns usually have simplifications, but IMHO these should do different things than the verb operation and avoid code duplication. As you say yourself there is no clear line. Why is 'integrate(sin(x),x) ok? Why 'integrate(q,x) not? Why 'rectform(1) not? I think adding simplification for simple cases just because they can be done efficiently is a cosmetic (or annoying  depending on your POV) enhancement without adding functionality. Actually this makes the line less clear and maxima more confusing. I'm not against convenience features. I only think these should be clearly encapsulated rather than mixed with the core functionality. I.e. specify() would be such a function. On what specify() should do: I'm not sure. Actually I'm quite happy with subst(), even if it returns things like 'abs(1). It should do the same as if I had typed in the expression with all substitutions in the first place. I guess the minimum requirement would be to replace certain nouns by their corresponding verbs. But probably somebody has a better idea. Some examples: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) specify(sin, f, %); (%o4)  cos(x); (%i1) declare(z1, complex, z2, complex); (%o1) done (%i2) realpart(z1); (%o2) realpart(z1) (%i3) specify(sin(z2), z1, %); (%o3) cosh(imagpart(z2)) sin(realpart(z2))  Comment By: Stavros Macrakis (macrakis) Date: 20070712 15:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 15:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 11:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 04:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 12:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070713 00:04:11

Bugs item #902290, was opened at 20040222 22:11 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Harald Geyer (hgeyer) Date: 20070713 02:04 Message: Logged In: YES user_id=929336 Originator: NO Yes, I know that nouns usually have simplifications, but IMHO these should do different things than the verb operation and avoid code duplication. As you say yourself there is no clear line. Why is 'integrate(sin(x),x) ok? Why 'integrate(q,x) not? Why 'rectform(1) not? I think adding simplification for simple cases just because they can be done efficiently is a cosmetic (or annoying  depending on your POV) enhancement without adding functionality. Actually this makes the line less clear and maxima more confusing. I'm not against convenience features. I only think these should be clearly encapsulated rather than mixed with the core functionality. I.e. specify() would be such a function. On what specify() should do: I'm not sure. Actually I'm quite happy with subst(), even if it returns things like 'abs(1). It should do the same as if I had typed in the expression with all substitutions in the first place. I guess the minimum requirement would be to replace certain nouns by their corresponding verbs. But probably somebody has a better idea. Some examples: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) specify(sin, f, %); (%o4)  cos(x); (%i1) declare(z1, complex, z2, complex); (%o1) done (%i2) realpart(z1); (%o2) realpart(z1) (%i3) specify(sin(z2), z1, %); (%o3) cosh(imagpart(z2)) sin(realpart(z2))  Comment By: Stavros Macrakis (macrakis) Date: 20070712 23:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 23:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 19:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 12:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 20:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20070712 22:00:00

Bugs item #902290, was opened at 20040222 16:11 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&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: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Stavros Macrakis (macrakis) Date: 20070712 17:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 17:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 13:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 06:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 14:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 