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}
(28) 
_{Oct}

_{Nov}

_{Dec}

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...>  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 
From: SourceForge.net <noreply@so...>  20100204 02:30:48

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 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 00:33:50

Bugs item #2945609, was opened at 20100204 02:33 Message generated for change (Tracker Item Submitted) made by sergeiste 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: Open Resolution: None 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.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945609&group_id=4933 
From: SourceForge.net <noreply@so...>  20100204 00:28:10

Bugs item #2945606, was opened at 20100204 02:28 Message generated for change (Tracker Item Submitted) 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.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2945606&group_id=4933 