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}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(4) 
S  M  T  W  T  F  S 


1
(14) 
2
(14) 
3
(10) 
4
(11) 
5
(1) 
6

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







From: SourceForge.net <noreply@so...>  20100210 19:37:54

Bugs item #1106912, was opened at 20050121 20:07 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1106912&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  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x/sin(x)^2,x,inf) Initial Comment: limit(x/sin(x)^2,x,inf) => UND actually = inf  >Comment By: Dieter Kaiser (crategus) Date: 20100210 20:37 Message: Fixed in in limit.lisp revision 1.93. Closing this bug report as fixed. Dieter Kaiser  Comment By: https://www.google.com/accounts () Date: 20100207 15:11 Message: After 5 years it still doesn't work. Another similar limit non properly evaluated: limit(x/(a+sin(x)),x,inf) (a is a number greater or equal to 1) that returns "und" instead of "inf"  Comment By: Raymond Toy (rtoy) Date: 20061109 02:35 Message: Logged In: YES user_id=28849 Fix summary. Problem still exists in current CVS.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1106912&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 19:08:47

Bugs item #2949260, was opened at 20100210 19:06 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2949260&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Suggest link to online manual Initial Comment: A suggestion, not a bug  /usr/share/maxima/5.xx.xx/xmaxima/intro.html which is displayed in the lower window at startup refers to a "Help Menu" in xmaxima which doesn't exist (in 5.20.1 on Fedora 12, for instance). I usually edit that file so that the first item ("Maxima Reference Manual") links to /usr/share/maxima/5.xx.xx/doc/html/maxima_toc.html. I'd like to see that be the default.  Comment By: Nobody/Anonymous (nobody) Date: 20100210 19:08 Message: My bad  the Help Menu is on the right side (why?), and I missed it completely. The link would still be easy and helpful, though, if you're going to display intro.html on startup.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2949260&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 19:06:35

Bugs item #2949260, was opened at 20100210 19:06 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2949260&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Suggest link to online manual Initial Comment: A suggestion, not a bug  /usr/share/maxima/5.xx.xx/xmaxima/intro.html which is displayed in the lower window at startup refers to a "Help Menu" in xmaxima which doesn't exist (in 5.20.1 on Fedora 12, for instance). I usually edit that file so that the first item ("Maxima Reference Manual") links to /usr/share/maxima/5.xx.xx/doc/html/maxima_toc.html. I'd like to see that be the default.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2949260&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 14:17:02

Bugs item #1440286, was opened at 20060228 13:12 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1440286&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: 1 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: documentation for 'listofvars' Initial Comment: The user documentation for 'listofvars' doesn't mention the option variable 'listdummyvars.' It ought to: (%i143) sum(i^2,i,1,n); (%o143) sum(i^2,i,1,n) (%i144) listofvars(%o143), listdummyvars : true; (%o144) [i,n] (%i145) listofvars(%o143), listdummyvars : false; (%o145) [n] Barton  >Comment By: Dieter Kaiser (crategus) Date: 20100210 15:17 Message: A comment has been added to the documentation of listofvars in Expressions.text revision 1.67. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1440286&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 14:13:03

Bugs item #1440069, was opened at 20060228 03:46 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1440069&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: euler numbers & zerobern Initial Comment: The option variable 'zerobern' changes the way euler evaluates. This isn't mentioned in the user documentation. Maybe it's not intended for zerobern to make any difference, or maybe it's a documentation error. I don't know. (%i1) euler(3),zerobern : true; (%o1) 0 (%i2) euler(3),zerobern : false; (%o2) 61 Barton  >Comment By: Dieter Kaiser (crategus) Date: 20100210 15:13 Message: A comment has been added to Number.texi revision 1.32. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1440069&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 14:07:43

Bugs item #1633149, was opened at 20070111 13:58 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1633149&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: 1 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sum bug that never happens Initial Comment: In simpsum1, I see: (setq sgn ($asksign ex)) (cond ((eq sgn '$pos) '$inf) ((eq sgn '$neg) '$minf) ((eq sgn '$zero) 0) (t `((%sum simp) ,ex ,lo ,hi)))) The t clase should be `((%sum simp) ,ex ,i ,lo ,hi))). But this bug should never get triggered. Actually, I suppose the t clause should substitute back to the original sum index. Also, if it were up to me, I would change $asksign to csign.  >Comment By: Dieter Kaiser (crategus) Date: 20100210 15:07 Message: The piece of code from above is executed for an example sum(x,k,0,inf). The following is a trace of the routines which are involved: (%i2) sum(x,k,0,inf); 0: (OUTATIVE ((%SUM) $X $K 0 $INF) NIL) 1: (LINEARCONST ((%SUM) $X $K 0 $INF)) Is x positive, negative, or zero? p; 2: (SIMPSUM ((%SUM) 1 $K 0 $INF) 1 T) 3: (SIMPSUM1 1 $K 0 $INF) n = $INF 3: SIMPSUM1 returned $INF 2: SIMPSUM returned $INF 1: LINEARCONST returned $INF 0: OUTATIVE returned $INF 1. The last line of code from this bug report is never called for this example. 2. The question does not arise in simpsum1, but in linearconst. 3. In simpsum1 Maxima already knows the sign of the summand to be positive or negative. The zero case is already handled in linearconst. When we remove the property outative, the piece of code in simpsum1 is executed for all cases. With a change of $asksign to csign we get a noun form, if the sign of the summand is not known. (%i9) sum(x,k,0,inf); (%o9) 'sum(x,k,0,inf) When the sign is known we get the appropriate infinities. (%i10) assume(x>0)$ (%i11) sum(x,k,0,inf); (%o11) inf (%i12) sum(x,k,0,inf); (%o12) minf I have committed the suggested changes (revision 1.35 of asum.lisp) to get the expected results, when we remove the property outative from %sum. Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20070113 02:28 Message: Logged In: YES user_id=501686 Originator: NO If you want to make those changes, I would say go ahead.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1633149&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 01:34:27

Bugs item #2948800, was opened at 20100210 01:09 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&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: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1cos(2*x)^2)^2/x^4,x,0,inf) wrong Initial Comment: We get the following result for the function sin: (%i7) integrate((sin(2*x)^2)^2/x^4,x,0,inf); (%o7) 8*%pi/3 But not when we insert the equivalent expression 1cos(2*x)^2 for sin(2*x)^2: (%i8) integrate((1cos(2*x)^2)^2/x^4,x,0,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); It works when we have an argument x without a factor: (%i9) integrate((sin(x)^2)^2/x^4,x,0,inf); (%o9) %pi/3 (%i10) integrate((1cos(x)^2)^2/x^4,x,0,inf); (%o10) %pi/3 The error is in the routine ssp in the file defint.lisp. This routine does the substitution sin(x)^2 for 1cos(x)^2. But the function does not look at the complete argument of the trig function. It takes only into account the variable of integration. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100210 02:34 Message: Fixied in revision 1.71 of defint.lisp Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100210 01:39 Message: Now the title is complete.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 00:39:10

Bugs item #2948800, was opened at 20100210 01:09 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) >Summary: integrate((1cos(2*x)^2)^2/x^4,x,0,inf) wrong Initial Comment: We get the following result for the function sin: (%i7) integrate((sin(2*x)^2)^2/x^4,x,0,inf); (%o7) 8*%pi/3 But not when we insert the equivalent expression 1cos(2*x)^2 for sin(2*x)^2: (%i8) integrate((1cos(2*x)^2)^2/x^4,x,0,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); It works when we have an argument x without a factor: (%i9) integrate((sin(x)^2)^2/x^4,x,0,inf); (%o9) %pi/3 (%i10) integrate((1cos(x)^2)^2/x^4,x,0,inf); (%o10) %pi/3 The error is in the routine ssp in the file defint.lisp. This routine does the substitution sin(x)^2 for 1cos(x)^2. But the function does not look at the complete argument of the trig function. It takes only into account the variable of integration. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100210 01:39 Message: Now the title is complete.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 00:10:52

Bugs item #2948800, was opened at 20100210 01:09 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1cos(2*x)^2)^2/x^4 wrong Initial Comment: We get the following result for the function sin: (%i7) integrate((sin(2*x)^2)^2/x^4,x,0,inf); (%o7) 8*%pi/3 But not when we insert the equivalent expression 1cos(2*x)^2 for sin(2*x)^2: (%i8) integrate((1cos(2*x)^2)^2/x^4,x,0,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); It works when we have an argument x without a factor: (%i9) integrate((sin(x)^2)^2/x^4,x,0,inf); (%o9) %pi/3 (%i10) integrate((1cos(x)^2)^2/x^4,x,0,inf); (%o10) %pi/3 The error is in the routine ssp in the file defint.lisp. This routine does the substitution sin(x)^2 for 1cos(x)^2. But the function does not look at the complete argument of the trig function. It takes only into account the variable of integration. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&group_id=4933 
From: SourceForge.net <noreply@so...>  20100210 00:09:36

Bugs item #2948800, was opened at 20100210 01:09 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&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: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((1cos(2*x)^2)^2/x^4 wrong Initial Comment: We get the following result for the function sin: (%i7) integrate((sin(2*x)^2)^2/x^4,x,0,inf); (%o7) 8*%pi/3 But not when we insert the equivalent expression 1cos(2*x)^2 for sin(2*x)^2: (%i8) integrate((1cos(2*x)^2)^2/x^4,x,0,inf); defint: integral is divergent.  an error. To debug this try: debugmode(true); It works when we have an argument x without a factor: (%i9) integrate((sin(x)^2)^2/x^4,x,0,inf); (%o9) %pi/3 (%i10) integrate((1cos(x)^2)^2/x^4,x,0,inf); (%o10) %pi/3 The error is in the routine ssp in the file defint.lisp. This routine does the substitution sin(x)^2 for 1cos(x)^2. But the function does not look at the complete argument of the trig function. It takes only into account the variable of integration. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2948800&group_id=4933 
From: SourceForge.net <noreply@so...>  20100209 23:59:23

Bugs item #2944659, was opened at 20100202 16:07 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944659&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  Limit Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: limit(erf(sqrt(log(t))/sqrt(2)),t,0) > Lisp error Initial Comment: This example gives a Lisp error: (%i7) limit(erf(sqrt(log(t))/sqrt(2)),t,0); Maxima encountered a Lisp error: The value NIL is not of type FIXNUM. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. The constant sqrt(2) in the numerator or denominator is necessary to get the error. Without the constant the limit gives a noun form. (%i8) limit(erf(sqrt(log(t))),t,0); (%o8) 'limit(erf(sqrt(log(t))),t,0) I think the source of the error is taylim (now the constant sqrt(2) is in the numerator): (%i9) tlimit(erf(sqrt(log(t))*sqrt(2)),t,0); Maxima encountered a Lisp error: The value NIL is not of type FIXNUM. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100210 00:59 Message: I think this error has gone. We get a noun form for the examples of this bug report: (%i4) limit(erf(sqrt(log(t))*sqrt(2)),t,0); (%o4) 'limit(erf(sqrt(2)*sqrt(log(t))),t,0) (%i5) limit(erf(sqrt(log(t))/sqrt(2)),t,0); (%o5) 'limit(erf(sqrt(log(t))/sqrt(2)),t,0) This might be due to the change of the code for simplifying 0^a which has been reverted in parts. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944659&group_id=4933 
From: SourceForge.net <noreply@so...>  20100209 20:18:22

Bugs item #2941668, was opened at 20100128 08:31 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2941668&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: Works For Me Priority: 5 Private: No Submitted By: giancarlo losi (giancarlolosi) Assigned to: Nobody/Anonymous (nobody) Summary: maxima does not start  windows xp Initial Comment: I have Maxima 519.2 installed on a Dell precision 6300. I can't even run it from the command prompt (I tried). Wxmaxima crashes even when i try "report a bug". I played with Dep settings and Zonealarm, but no success. Yes, it has been downloaded from sourceforge.net. Strangely enough, I have two more Dell laptops around the house (older models, one windowsxp and one windows2000) and on those it runs fine. giancarlo, Italy  >Comment By: Robert Dodier (robert_dodier) Date: 20100209 13:18 Message: In the absence of additional information, I don't think there is anything we can do. Closing this report as "works for me". Giancarlo, if you can gather more info about the problem, feel free to open another bug report about it. Sorry we can't be more helpful in this case.  Comment By: giancarlo losi (giancarlolosi) Date: 20100131 12:12 Message: Thank you, Robert. I edited the batch file (which launches Maxima from the .bin directory) and I put a "pause" instruction at the end of it so I could see what the computer was doing, There are no error messages, the program just seems to run for a fraction of a second and then stops. The only strange things in my folder names are blank characters, such as the one between "Program" and "Files". It could be a DEP problem, but all the changes to the DEP settings I've made seem to have no effect (I've even tried cold reboot vs. restart for the DEP settings to take effect; no change). Hey, thanks anyway. I may have to use my children's notebooks. gcl  Comment By: Robert Dodier (robert_dodier) Date: 20100131 11:14 Message: What is the error message which is reported when you try to run Maxima from a command prompt? In order to see the error message, open a command prompt and then launch it from there; if you launch it from the Windows start menu I think it will open and close the command prompt so quickly you won't be able to see the error. A problem which has been reported is that characters other than 7 bit ascii in folder names causes trouble (I don't know why). Is there any such character in a folder name in the path to Maxima?  Comment By: Andrej Vodopivec (andrejv) Date: 20100130 01:24 Message: Two common problems are firewalls/antivirus programs which prevent socket communication and DEP. Read the FAQ entry: http://maximaproject.org/wiki/index.php?title=Maxima_FAQ#Windows  Comment By: giancarlo losi (giancarlolosi) Date: 20100130 01:19 Message: I installed versione 520.1. Now wxmaxima at least says "Maxima started, waiting for connection" but doesn't go beyond that point. I also tried installing Euler, which puts its own maxima in a different directory, and also that program is unable to start it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2941668&group_id=4933 
From: SourceForge.net <noreply@so...>  20100208 05:05:30

Bugs item #2945606, was opened at 20100203 17:28 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Rejected Priority: 5 Private: No Submitted By: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Robert Dodier (robert_dodier) Date: 20100207 22:05 Message: Code works OK as it stands. Closing this report without action.  Comment By: Sergei (sergeiste) Date: 20100204 18:50 Message: Sorry, but it is a bug. Here is what I quickly found: http://www.thefreedictionary.com/coefficient : " coefficient [ˌkəʊɪˈfɪʃənt] n 1. (Mathematics) Maths a. a numerical or constant factor in an algebraic term the coefficient of the term 3xyz is 3 b. the product of all the factors of a term excluding one or more specified variables the coefficient of x in 3axyz is 3ayz 2. (Physics / General Physics) Physics a value that relates one physical quantity to another [from New Latin coefficiēns, from Latin co together + efficere to effect] Collins English Dictionary – Complete and Unabridged 6th Edition 2003. © William Collins Sons & Co. Ltd 1979, 1986 © HarperCollins Publishers 1991, 1994, 1998, 2000, 2003 ". Do you see the " the product of all the factors of a term excluding one or more specified variables the coefficient of x in 3axyz is 3ayz" ? The above quote is _exactly_ my point, 'maxima' 'coeff' implementation complies with neither what I was taught nor with what a dictionary says. It is a bug to implement code for mathematical entities not basing the code on strict mathematical definition. In particular, it's a bug because expected behavior (based on school education and dictionary definition) is not the same as actual one. Unless it is proven that the expected behavior is wrong, it remains a bug.  Comment By: Raymond Toy (rtoy) Date: 20100204 13:51 Message: The bug tracker is probably not the right place to hold discussions of this type. This kind of discussion is probably best done on the mailing list.  Comment By: Sergei (sergeiste) Date: 20100204 11:46 Message: Here is another nonsense: " (%i9) coeff(x * y, y); (%o9) x (%i10) y: x * y; (%o10) x*y (%i11) coeff(x * y, y); (%o11) 0 ". The "(%o9) x" part of it is correct  this is how I was taught at school. I.e. it is correct based on the definitions I know. The "(%o11) 0" is _wrong_. In English: I have an expression : x * y. Depending on other circumstance (i.e. actual composition of y), 'coeff'' returns _different_ values (x and 0), though it should return _the_ _same_ value, which is x regardless of y.  Comment By: Sergei (sergeiste) Date: 20100204 11:31 Message: Regarding "You are apparently assuming ...". I _do_ assume that 'maxima' is a program of CAS (Computer Algebra System). I _do_ assume that algebra is part of mathematics. I _do_ assume that mathematics is based on: 1) axioms/postulates; 2) definitions; 3) theorems. I _do_ assume that expected behavior is also base on axioms/postulates, definitions, theorems. I _do_ assume that developers, claiming expected behavior, justify their claims on axioms/postulates, definitions, theorems. I _do_ assume that because of the above developers should _first_ provide a definition of coefficient. Present behavior of 'coeff' does not comply with the definition I was taught or, at least, remember. Look at the following session: " (%i3) coeff(x * y * z, x); (%o3) y*z (%i4) coeff(x * y * z, y); (%o4) x*z (%i5) coeff(x * y * z, x); (%o5) y*z "  in _all_ three cases the following identity stands: original_ product == coefficient * partial_product. However, if I try: " (%i6) coeff(x * y * z, x * y); (%o6) 0 ", I'm getting 0, so by the above identity I should assume that original_ product == coefficient * partial_produc == 0 * x * y == 0 . And the above is _nonsense_  because original_ product is not 0. So, again and again, first provide a _definition_ of coefficient  otherwise both sides (i.e. users and developers) would be able to claim whatever behavior as expected.  Comment By: Raymond Toy (rtoy) Date: 20100204 05:59 Message: You are apparently assuming v*u*v remains that. But in fact by the the time coeff gets it, maxima has already changed it to u*v^2. Hence, no v term. (You can see this if you trace(coeff).) Maybe setting simp:false will give you want you want. But this setting is known to break many other things because the expected simplification is not occurring.  Comment By: Sergei (sergeiste) Date: 20100203 23:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100203 21:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100203 18:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100208 05:01:44

Bugs item #2945609, was opened at 20100203 17:33 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945609&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: incomplete/misleading documentation of 'coeff' Initial Comment: Here is the documentation of 'coeff'' copypasred from 'maxima' session: " Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.34  Function: coeff (<expr>, <x>, <n>) Returns the coefficient of `<x>^<n>' in <expr>. <n> may be omitted if it is 1. <x> may be an atom, or complete subexpression of <expr> e.g., `sin(x)', `a[i+1]', `x + y', etc. (In the last case the expression `(x + y)' should occur in <expr>). Sometimes it may be necessary to expand or factor <expr> in order to make `<x>^<n>' explicit. This is not done automatically by `coeff'. Examples: (%i1) coeff (2*a*tan(x) + tan(x) + b = 5*tan(x) + 3, tan(x)); (%o1) 2 a + 1 = 5 (%i2) coeff (y + x*%e^x + 1, x, 0); (%o2) y + 1 ". The documentation is insufficient because: 1) it doesn't explain what the returned values can be, for example, the return value of 0 in this case: " (%i5) coeff(v * u * v, v); (%o5) 0 " looks completely unexpected to me. 2) the documentation does not give definition of "complete subexpression" and does not point to a publicly available source of information, for example, article in WikiPedia. Please extend the documentation to address these issues.  >Comment By: Robert Dodier (robert_dodier) Date: 20100207 22:01 Message: Revised and expanded documentation for "coeff" in r1.30 doc/info/Polynomials.texi. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945609&group_id=4933 
From: SourceForge.net <noreply@so...>  20100207 14:11:02

Bugs item #1106912, was opened at 20050121 20:07 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1106912&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  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x/sin(x)^2,x,inf) Initial Comment: limit(x/sin(x)^2,x,inf) => UND actually = inf  Comment By: https://www.google.com/accounts () Date: 20100207 15:11 Message: After 5 years it still doesn't work. Another similar limit non properly evaluated: limit(x/(a+sin(x)),x,inf) (a is a number greater or equal to 1) that returns "und" instead of "inf"  Comment By: Raymond Toy (rtoy) Date: 20061109 02:35 Message: Logged In: YES user_id=28849 Fix summary. Problem still exists in current CVS.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1106912&group_id=4933 
From: SourceForge.net <noreply@so...>  20100207 02:20:14

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

Bugs item #2945606, was opened at 20100204 02:28 Message generated for change (Comment added) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Sergei (sergeiste) Date: 20100205 03:50 Message: Sorry, but it is a bug. Here is what I quickly found: http://www.thefreedictionary.com/coefficient : " coefficient [ˌkəʊɪˈfɪʃənt] n 1. (Mathematics) Maths a. a numerical or constant factor in an algebraic term the coefficient of the term 3xyz is 3 b. the product of all the factors of a term excluding one or more specified variables the coefficient of x in 3axyz is 3ayz 2. (Physics / General Physics) Physics a value that relates one physical quantity to another [from New Latin coefficiēns, from Latin co together + efficere to effect] Collins English Dictionary – Complete and Unabridged 6th Edition 2003. © William Collins Sons & Co. Ltd 1979, 1986 © HarperCollins Publishers 1991, 1994, 1998, 2000, 2003 ". Do you see the " the product of all the factors of a term excluding one or more specified variables the coefficient of x in 3axyz is 3ayz" ? The above quote is _exactly_ my point, 'maxima' 'coeff' implementation complies with neither what I was taught nor with what a dictionary says. It is a bug to implement code for mathematical entities not basing the code on strict mathematical definition. In particular, it's a bug because expected behavior (based on school education and dictionary definition) is not the same as actual one. Unless it is proven that the expected behavior is wrong, it remains a bug.  Comment By: Raymond Toy (rtoy) Date: 20100204 22:51 Message: The bug tracker is probably not the right place to hold discussions of this type. This kind of discussion is probably best done on the mailing list.  Comment By: Sergei (sergeiste) Date: 20100204 20:46 Message: Here is another nonsense: " (%i9) coeff(x * y, y); (%o9) x (%i10) y: x * y; (%o10) x*y (%i11) coeff(x * y, y); (%o11) 0 ". The "(%o9) x" part of it is correct  this is how I was taught at school. I.e. it is correct based on the definitions I know. The "(%o11) 0" is _wrong_. In English: I have an expression : x * y. Depending on other circumstance (i.e. actual composition of y), 'coeff'' returns _different_ values (x and 0), though it should return _the_ _same_ value, which is x regardless of y.  Comment By: Sergei (sergeiste) Date: 20100204 20:31 Message: Regarding "You are apparently assuming ...". I _do_ assume that 'maxima' is a program of CAS (Computer Algebra System). I _do_ assume that algebra is part of mathematics. I _do_ assume that mathematics is based on: 1) axioms/postulates; 2) definitions; 3) theorems. I _do_ assume that expected behavior is also base on axioms/postulates, definitions, theorems. I _do_ assume that developers, claiming expected behavior, justify their claims on axioms/postulates, definitions, theorems. I _do_ assume that because of the above developers should _first_ provide a definition of coefficient. Present behavior of 'coeff' does not comply with the definition I was taught or, at least, remember. Look at the following session: " (%i3) coeff(x * y * z, x); (%o3) y*z (%i4) coeff(x * y * z, y); (%o4) x*z (%i5) coeff(x * y * z, x); (%o5) y*z "  in _all_ three cases the following identity stands: original_ product == coefficient * partial_product. However, if I try: " (%i6) coeff(x * y * z, x * y); (%o6) 0 ", I'm getting 0, so by the above identity I should assume that original_ product == coefficient * partial_produc == 0 * x * y == 0 . And the above is _nonsense_  because original_ product is not 0. So, again and again, first provide a _definition_ of coefficient  otherwise both sides (i.e. users and developers) would be able to claim whatever behavior as expected.  Comment By: Raymond Toy (rtoy) Date: 20100204 14:59 Message: You are apparently assuming v*u*v remains that. But in fact by the the time coeff gets it, maxima has already changed it to u*v^2. Hence, no v term. (You can see this if you trace(coeff).) Maybe setting simp:false will give you want you want. But this setting is known to break many other things because the expected simplification is not occurring.  Comment By: Sergei (sergeiste) Date: 20100204 08:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100204 06:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100204 03:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 20:51:25

Bugs item #2945606, was opened at 20100203 19:28 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Raymond Toy (rtoy) Date: 20100204 15:51 Message: The bug tracker is probably not the right place to hold discussions of this type. This kind of discussion is probably best done on the mailing list.  Comment By: Sergei (sergeiste) Date: 20100204 13:46 Message: Here is another nonsense: " (%i9) coeff(x * y, y); (%o9) x (%i10) y: x * y; (%o10) x*y (%i11) coeff(x * y, y); (%o11) 0 ". The "(%o9) x" part of it is correct  this is how I was taught at school. I.e. it is correct based on the definitions I know. The "(%o11) 0" is _wrong_. In English: I have an expression : x * y. Depending on other circumstance (i.e. actual composition of y), 'coeff'' returns _different_ values (x and 0), though it should return _the_ _same_ value, which is x regardless of y.  Comment By: Sergei (sergeiste) Date: 20100204 13:31 Message: Regarding "You are apparently assuming ...". I _do_ assume that 'maxima' is a program of CAS (Computer Algebra System). I _do_ assume that algebra is part of mathematics. I _do_ assume that mathematics is based on: 1) axioms/postulates; 2) definitions; 3) theorems. I _do_ assume that expected behavior is also base on axioms/postulates, definitions, theorems. I _do_ assume that developers, claiming expected behavior, justify their claims on axioms/postulates, definitions, theorems. I _do_ assume that because of the above developers should _first_ provide a definition of coefficient. Present behavior of 'coeff' does not comply with the definition I was taught or, at least, remember. Look at the following session: " (%i3) coeff(x * y * z, x); (%o3) y*z (%i4) coeff(x * y * z, y); (%o4) x*z (%i5) coeff(x * y * z, x); (%o5) y*z "  in _all_ three cases the following identity stands: original_ product == coefficient * partial_product. However, if I try: " (%i6) coeff(x * y * z, x * y); (%o6) 0 ", I'm getting 0, so by the above identity I should assume that original_ product == coefficient * partial_produc == 0 * x * y == 0 . And the above is _nonsense_  because original_ product is not 0. So, again and again, first provide a _definition_ of coefficient  otherwise both sides (i.e. users and developers) would be able to claim whatever behavior as expected.  Comment By: Raymond Toy (rtoy) Date: 20100204 07:59 Message: You are apparently assuming v*u*v remains that. But in fact by the the time coeff gets it, maxima has already changed it to u*v^2. Hence, no v term. (You can see this if you trace(coeff).) Maybe setting simp:false will give you want you want. But this setting is known to break many other things because the expected simplification is not occurring.  Comment By: Sergei (sergeiste) Date: 20100204 01:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100203 23:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100203 20:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 20:24:07

Bugs item #2945606, was opened at 20100203 19:28 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Raymond Toy (rtoy) Date: 20100204 07:59 Message: You are apparently assuming v*u*v remains that. But in fact by the the time coeff gets it, maxima has already changed it to u*v^2. Hence, no v term. (You can see this if you trace(coeff).) Maybe setting simp:false will give you want you want. But this setting is known to break many other things because the expected simplification is not occurring.  Comment By: Sergei (sergeiste) Date: 20100204 01:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100203 23:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100203 20:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 18:46:04

Bugs item #2945606, was opened at 20100204 02:28 Message generated for change (Comment added) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Sergei (sergeiste) Date: 20100204 20:46 Message: Here is another nonsense: " (%i9) coeff(x * y, y); (%o9) x (%i10) y: x * y; (%o10) x*y (%i11) coeff(x * y, y); (%o11) 0 ". The "(%o9) x" part of it is correct  this is how I was taught at school. I.e. it is correct based on the definitions I know. The "(%o11) 0" is _wrong_. In English: I have an expression : x * y. Depending on other circumstance (i.e. actual composition of y), 'coeff'' returns _different_ values (x and 0), though it should return _the_ _same_ value, which is x regardless of y.  Comment By: Sergei (sergeiste) Date: 20100204 20:31 Message: Regarding "You are apparently assuming ...". I _do_ assume that 'maxima' is a program of CAS (Computer Algebra System). I _do_ assume that algebra is part of mathematics. I _do_ assume that mathematics is based on: 1) axioms/postulates; 2) definitions; 3) theorems. I _do_ assume that expected behavior is also base on axioms/postulates, definitions, theorems. I _do_ assume that developers, claiming expected behavior, justify their claims on axioms/postulates, definitions, theorems. I _do_ assume that because of the above developers should _first_ provide a definition of coefficient. Present behavior of 'coeff' does not comply with the definition I was taught or, at least, remember. Look at the following session: " (%i3) coeff(x * y * z, x); (%o3) y*z (%i4) coeff(x * y * z, y); (%o4) x*z (%i5) coeff(x * y * z, x); (%o5) y*z "  in _all_ three cases the following identity stands: original_ product == coefficient * partial_product. However, if I try: " (%i6) coeff(x * y * z, x * y); (%o6) 0 ", I'm getting 0, so by the above identity I should assume that original_ product == coefficient * partial_produc == 0 * x * y == 0 . And the above is _nonsense_  because original_ product is not 0. So, again and again, first provide a _definition_ of coefficient  otherwise both sides (i.e. users and developers) would be able to claim whatever behavior as expected.  Comment By: Raymond Toy (rtoy) Date: 20100204 14:59 Message: You are apparently assuming v*u*v remains that. But in fact by the the time coeff gets it, maxima has already changed it to u*v^2. Hence, no v term. (You can see this if you trace(coeff).) Maybe setting simp:false will give you want you want. But this setting is known to break many other things because the expected simplification is not occurring.  Comment By: Sergei (sergeiste) Date: 20100204 08:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100204 06:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100204 03:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 18:31:16

Bugs item #2945606, was opened at 20100204 02:28 Message generated for change (Comment added) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Sergei (sergeiste) Date: 20100204 20:31 Message: Regarding "You are apparently assuming ...". I _do_ assume that 'maxima' is a program of CAS (Computer Algebra System). I _do_ assume that algebra is part of mathematics. I _do_ assume that mathematics is based on: 1) axioms/postulates; 2) definitions; 3) theorems. I _do_ assume that expected behavior is also base on axioms/postulates, definitions, theorems. I _do_ assume that developers, claiming expected behavior, justify their claims on axioms/postulates, definitions, theorems. I _do_ assume that because of the above developers should _first_ provide a definition of coefficient. Present behavior of 'coeff' does not comply with the definition I was taught or, at least, remember. Look at the following session: " (%i3) coeff(x * y * z, x); (%o3) y*z (%i4) coeff(x * y * z, y); (%o4) x*z (%i5) coeff(x * y * z, x); (%o5) y*z "  in _all_ three cases the following identity stands: original_ product == coefficient * partial_product. However, if I try: " (%i6) coeff(x * y * z, x * y); (%o6) 0 ", I'm getting 0, so by the above identity I should assume that original_ product == coefficient * partial_produc == 0 * x * y == 0 . And the above is _nonsense_  because original_ product is not 0. So, again and again, first provide a _definition_ of coefficient  otherwise both sides (i.e. users and developers) would be able to claim whatever behavior as expected.  Comment By: Raymond Toy (rtoy) Date: 20100204 14:59 Message: You are apparently assuming v*u*v remains that. But in fact by the the time coeff gets it, maxima has already changed it to u*v^2. Hence, no v term. (You can see this if you trace(coeff).) Maybe setting simp:false will give you want you want. But this setting is known to break many other things because the expected simplification is not occurring.  Comment By: Sergei (sergeiste) Date: 20100204 08:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100204 06:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100204 03:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 14:41:29

Bugs item #2847436, was opened at 20090830 17:27 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2847436&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: integrate(sqrt(t)*log(t)^(1/2),t,0,1) wrong sign Initial Comment: The following two integrals have the wrong sign: integrate(sqrt(t)*log(t)^(1/2),t,0,1) and integrate(sqrt(t)*log(t)^(1/2),t,0,1) It is interesting that Maxima is able to solve the more general type: (%i164) declare(s,noninteger); (%o164) done (%i165) expr:integrate(sqrt(t)*log(t)^s,t,0,1); (%o165) 3^(s1)*(1)^s*2^(s+1)*gamma_incomplete(s+1,0) For s=1/2 and s=1/2 we get the answers: (%i167) expr,s=1/2; (%o167) sqrt(2)*sqrt(%pi)*%i/(2*sqrt(3)) (%i168) expr,s=1/2; (%o168) sqrt(2)*sqrt(%pi)*%i/sqrt(3) Both solutions can be checked to be correct. Now we do it directly: (%i4) integrate(sqrt(t)*log(t)^(1/2),t,0,1); (%o4) %i*('limit(sqrt(2)*sqrt(%pi)*erf(sqrt(3)*sqrt(log(t))/sqrt(2))/3^(3/2) 2*t^(3/2)*sqrt(log(t))/3,t,0,plus)) We need an extra evaluation, but this is another problem: (%i5) %,nouns; (%o5) sqrt(2)*sqrt(%pi)*%i/3^(3/2) Now the integral for s=1/2: (%i6) integrate(sqrt(t)*log(t)^(1/2),t,0,1); (%o6) sqrt(2)*sqrt(%pi)*%i/sqrt(3) These solutions differ by the sign with the answers from above. I have checked it for a lot of other values for the parameter s. In all other cases the result of the integral and the more general solution are equal. Remark: The integral is divergent for s a negative integer. For these cases the gamma_incomplete function is not defined. Dieter Kaiser  >Comment By: Raymond Toy (rtoy) Date: 20100204 09:41 Message: The definite integral is computed by doing the indefinite integral via rischint. The limits are then taken. For some reason limit cannot evaluate the limit, which explains the noun form in the result. In addition, the limit at 0 is done by breaking the result into real and imaginary parts and taking the limit of each and putting them back together. The limit of the real part is 0, but the limit of the imaginary part has the incorrect sign. Perhaps the imaginary part is computed incorrectly?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2847436&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 13:05:31

Bugs item #2924831, was opened at 20100102 03:56 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: file_type is wrong for ccl on mac os x Initial Comment: clozure cl compiled files have the extension .dx64fls on mac os x. file_type thinks this are demo files since it only checks the first character of the extension. load therefore fails to load compiled files.  >Comment By: Raymond Toy (rtoy) Date: 20100204 08:05 Message: Perhaps file_type should be more explicit. So "max", "mac", "dem", and "demo" are maxima files; "l", "lsp", and "lisp" are lisp files, and everything else are object files. Maybe we can also let the user specify the association between the file extension and the file type?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2924831&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 06:06:54

Bugs item #2945606, was opened at 20100204 02:28 Message generated for change (Comment added) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Sergei (sergeiste) Date: 20100204 08:06 Message: Again, at high school with emphasis on mathematics and physics I was taught about coefficients this way: suppose we have a product, say, a * b * c * d . If we are to find a coefficient of any subproduct or any factor in the product, it's product of the remaining operands of the product, or just one remaining operand, i.e. coefficient of b is a * c * d, coefficient of a * c * d is b. I have already described the algorithm, which is difference list. So, the coefficient of v in v * u * v is u * v. Maybe you were taught differently, again, please show me the definition of coefficient.  Comment By: Raymond Toy (rtoy) Date: 20100204 06:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100204 03:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 04:49:00

Bugs item #2945606, was opened at 20100203 19:28 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&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: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: I'm reopening the bug. According to the original bug closing, " For example, complete subexpressions in 2*x*y are 2, x, and y, but x*y is no a complete subexpression. ". By the same toke, complete subexpressions of v * u * v should be u, v, and I presented a case which fails: " (%i5) coeff(v * u * v, v); (%o5) 0 (%i6) ". Now, from my understanding of English the word "complete" is improper here, a more appropriate word would be be atomic ? At all, where is the definition of "complete subexpression" ? ... I myself wrote a pretty complete symbolic logic package in Perl, and it dealt quite easily with similar cases. A product is a list of factors. An item for which we want to find coefficient is a strict sublist/subset of the whole list/set. So the coefficient we are looking for is the _difference_ list/set of the whole product and the item. As simple as that, done many many times by many many people.  >Comment By: Raymond Toy (rtoy) Date: 20100203 23:48 Message: Why is it wrong that coeff(v*u*v,v) returns 0? After all v*u*v = u*v^2, so I would expect the coefficient of v to be 0.  Comment By: Sergei (sergeiste) Date: 20100203 20:52 Message: And, still, I want a source in general mathematics which says that, say, 0 is a legitimate coefficient returned from an expression. I.e. if we have, say, a y = k * x + b expression, one may for certain reasons _set_ k to be 0, so the expression _becomes_ y = b and knowing in advance that originally the expression was y = k * x + b one can say that the coefficient at x is _now_ 0, but it wasn't this way in the beginning. So, a coefficient of 0 is wrong in my opinion in the context of 'maxima' 'coeff' function. If the developers think 0 is correct, in addition to clear definition of "complete subexpression" they need to provide a clear definition of "coefficient".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 