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}
(27) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{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...>  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 