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}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

4
(26) 
5
(3) 
6
(10) 
7
(25) 
8
(20) 
9

10
(21) 
11
(10) 
12
(3) 
13
(10) 
14
(7) 
15
(1) 
16
(1) 
17
(1) 
18

19
(15) 
20

21
(1) 
22
(7) 
23
(10) 
24
(10) 
25

26
(1) 
27
(1) 
28
(5) 
29
(26) 
30

31
(30) 





From: SourceForge.net <noreply@so...>  20060722 16:00:13

Bugs item #886392, was opened at 20040128 11:34 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886392&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ('[a,b,c])[2] and ('v)[2] Initial Comment: arrayapply('[a,b],[2]) => b OK ('[a,b])[2] => Illegal form  SIMPLIFYA: ((((MLIST) $a $b)) 2) cf bug 866706: ('m)[1] => m(2), not v[2] What is going on here is that Maxima wants to treat ('f)(x) == funmake('f,[x]) == apply('('f),[x]) which I find a very poor convention, because it means that the (...)(...) construction is noncompositional. After all, ('f+0)(x) == apply('f,[x]) So, ... how do you explain this? Do you consider ('...)() == ('(...))() to be a special *syntactic* construction, even though the parser doesn't parse it into any sort of special internal form? Yuck, yuck, yuck. The fact that apply('('f),...) is specialcased is less problematic, but still weird, since apply('('f+0),...) does the same thing, though apply('(factor('fff)),[x]) gives an error. More yuck. Ayway it doesn't use funmake to construct the result, so screws up the error. I am not sure what the best fix is. I am tempted to completely eliminate ('f)(x) and apply('('f)...) as special cases. Then everything "just works". True, you need to use funmake to avoid evaluating, but that should be OK.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886392&group_id=4933 
From: SourceForge.net <noreply@so...>  20060722 15:57:55

Bugs item #885795, was opened at 20040127 14:02 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=885795&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Assume Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: f(i)==f(j) where i==j (is/equal fails) Initial Comment: As a shorthand in this note, I'll use a==b to mean is (equal(a,b)). assume(equal(i,j)) x[i] == x[j] => Unknown NO! f(i) == f(j) => Unknown NO! sin(i) == sin(j) => Unknown NO! sinh(i) == sinh(j) => True OK!!!! It turns out that it has to do with the Increasing property, even though of course that is completely irrelevant: declare(g,increasing) g(i) == g(j) => true OK Strangely, Decreasing doesn't work: declare(h,decreasing) h(i) == h(j) => Unknown ??? I guess that technically this is an enhancement request (Unknown is always a valid way to give up), but....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=885795&group_id=4933 
From: SourceForge.net <noreply@so...>  20060722 15:56:46

Bugs item #884947, was opened at 20040126 11:34 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Is/equal doesn't work for [], matrix, etc./FIX Initial Comment: Currently, IS doesn't understand semanticequality of bags (lists, matrices, sets) at all: is(equal([1],[1])) => true OK is(equal([0],[1])) => Unknown NO The first case only works because the two expressions are syntactically equal (is/= or ?like). The problem is that meqp uses compare, which compares x and y by comparing xy to (scalar) 0, obviously irrelevant here. The solution is to explicitly add bags to meqp and mnqp. See code attached. With this code, we have: is(equal([1],[1])) => true is(equal([0],[1])) => false is(equal([a,0],[a,1])) => false is(equal([a,b],[a,c])) => unknown HOWEVER: a) this code ignores doscmxplus, so lists are never considered equal to matrices; b) the assume database is not consulted in cases like equal(x,[a,b]), because compar thinks this is the same as equal([xa,x b],0). I considered also adding ordering inequalities (< etc.), but I don't think it's worth it right now given the limited capabilities of compar. Also, it's not clear whether lexicographic ([a,b]<[c,d] iff (a<c or (a=c and b<d)) or dominating order (a<c and b<d  nontrichotomic) is more useful. This was originally reported by Robert Dodier in email.  Comment By: Stavros Macrakis (macrakis) Date: 20040127 13:48 Message: Logged In: YES user_id=588346 These are some design notes I posted to the Maxima mailing list on this subject. Robert Dodier said: > is(equal([1],[[1]]))) => UNKNOWN. > I would expect that different structures are always not > equal, unless they're equivalent (i.e., you could substitute > one for the other in any expression and get the same result). > So either TRUE or FALSE seems possible here, but not UNKNOWN. I had written code to assume that objects of differing dimensions were different (in particular, that nonscalars can never be equal to scalars), but ran into a whole bunch of inconsistencies in Maxima semantics. These are not accidental inconsistencies, they are not bugs; they are in fact design features to make the use of Maxima more convenient. But as is often the case, convenience conflicts with consistency. Clearly is(1=[1]) is false; remember, = performs structural (syntactic) comparison. However, it is not at all clear whether is(equal(1,[1])) is false. (And whether it is False or True depends not only on various flag settings, but also the context of use.) Consider: Lists, 1xn, and nx1 matrices are coerced into each other in various ways and with Scalarmatrixp=True (the default), a 1x1 matrix is converted to a scalar: [1,2] . matrix([3],[4]) => 11 [1,2] . matrix([3,4]) => 11 matrix([1,2]).matrix([3,4]) => 11 matrix([1],[2]).matrix([3],[4]) => 11 So perhaps 11 == [11] and [1,2] == matrix([1,2]) == matrix ([1],[2]) ? On the other hand, matrix([11]) by itself does not automatically simplify to 11 and 11[11]=>[0], not 0. Of course, outside the context of vector/matrix operations, lists, 1xn matrices, and nx1 matrices are completely distinct: after all, member(a,[a,b]) => true and member(a,matrix([a,b])) => false. Now consider symbolic expressions. You might think that a==b must be false if nonscalar(a) and scalar(b). But that's not true. If you declare(vec,nonscalar), then nonscalar (vec.vec) => True, though in fact the .product of two vectors is a scalar (nonscalar is a *syntactic* check for the presence of nonscalar objects within the expression tree). So it is wrong to assume that is(equal(vec1.vec2,0)) is false because nonscalar(vec1.vec2)=True and nonscalar(0)=False. This is not theoretical. I think it perfectly reasonable that a user might check whether q and r are perpendicular by checking is(equal(q.r,0)), where q and r are sometimes concrete vectors  in which case you might well get a valid True or False , sometimes symbols (in which case the answer should be Unknown, not False). There is another simple case that has nothing to do with vector/matrix semantics. To do bag comparisons correctly, you need to solve conjunctions: [x,x] =? [1,2] is equivalent to (x==1 and x==2), which is clearly false, but Is doesn't know it. Similarly for [x,1] =? [1,x+1]. Another limitation on the power of is/equal/bag: the compar subsystem is not currently terribly useful for vectors etc. For example, assume(equal(q,[a,b])), is(equal(q,[a,b+1])) => Unknown. I think there are several possible conclusions for all this: 1) Make Maxima more rigorous. Distinguish between lists, vectors, and 1xn matrices everywhere. Distinguish between scalars, 1vectors, and 1x1 matrices everywhere. In that case, the correct results for is/equal are much clearer. But pragmatism is one of the central characteristics of Maxima; there are certainly other systems which emphasize rigor, with its advantages and disadvantages. 2) Decide that is/equal/bag always refers to .product semantics (not list semantics and not + or * semantics): if two objects act the same in the context of a .product, then they are the same. 2ay) The result of is/equal depends on the various switches controlling vector/matrix operations. So if Scalarmatrixp and Listarith are true, then 1 == [1] == matrix([1]). 2by) Assume default settings for the various switches. 2xa) Consider an nlist, an nrow, and an ncolumn equal (with appropriate switches set), even though they don't act equally in all contexts. 2xb) Consider an nlist and an nrow equal, but not an n column. 3) Decide that is/equal/bag is true iff there is NO context in which the objects can be distinguished. This emphasizes the programmingtype aspect of Maxima over the mathematical aspect. But 'equal' is supposed to be about mathematical equality. After all, is/equal considers 1/2, 0.5, and 0.5b0 to be equal, even though 1/2 is an exact number and 0.5 and 0.5b0 are approximate. 3a) Assume that nonscalar *identifiers* (but not nonscalar expressions) are never equal to scalars. 3b) Do not take into account the nonscalar property of identifiers. 4) Maintain the current behavior, which gives Unknown for all the difficult cases. What I had started out trying to program was 2aa, but it was too messy (because when I started, I was also trying to take into account the behavior of + and *). Now that I've written out this design note, it seems like the two reasonable alternatives are 3a and 2ax (not sure whether 2aa or 2ab is better). But I suspect that in actual fact, I have already spent too much time on this, that no one but Robert will ever care, and that 4 is just fine....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&group_id=4933 
From: SourceForge.net <noreply@so...>  20060722 15:50:53

Bugs item #884300, was opened at 20040125 11:57 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve and ALL Initial Comment: Solve/algsys is inconsistent in how it represents the solution "all values satisfy the equation": solve([x=x],x) returns ALL solve([y=y],x) returns ALL solve([x=x],[x]) returns ALL solve([x=x],[x,y]) returns [[x = %R10, y = %R9]] solve([],[x]) returns [] First of all, the last case is simply wrong. The solution to "find all x such that the empty set of constraints is satisfied" is "all x", not "no x" (which is what [] means). After all, the y=y case above includes an equation which doesn't even mention x. The other cases are inconsistent. We should use one or the other. The %R10 approach (from algsys) seems better, because it is completely consistent with the non all case. Any program using Solve will have to make a special case for ALL otherwise. I would also argue that SOLVE_INCONSISTENT_ERROR should default to FALSE. That is, inconsistent systems should return [], not give an error.  Comment By: Stavros Macrakis (macrakis) Date: 20040419 13:49 Message: Logged In: YES user_id=588346 A similar problem: solve( (x1)^2 = (1x)^2 , x) returns [x=x] and not ALL. This is actually worse than an inconsistency: since x appears on both sides of the solution, a calling program will assume that Solve failed to find a solution.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&group_id=4933 
From: SourceForge.net <noreply@so...>  20060722 15:49:39

Bugs item #875089, was opened at 20040111 14:36 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875089&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 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: defint(f(x)=g(x),x,0,1) > false = false Initial Comment: (C1) defint(f(x)=g(x),x,0,1); (D1) FALSE = FALSE Here is proposed fix (DEFUN $DEFINT (EXP VAR LL UL) (let ((globaldefintassumptions ()) (integerinfo ()) (integerl integerl) (nonintegerl nonintegerl)) (withnewcontext (context) (unwindprotect (let ((defintassumptions ()) (*def2* ()) (rad polyrecur ()) (sincosrecur ()) (dintexprecur ()) (dintlogrecur 0.) (ans nil) (origexp exp) (origvar var) (origll ll) (origul ul) (pcprntd nil) (*NODIVerg nil) ($logabs t) (limitp t) (rppolylogp ()) ($domain '$real) ($m1pbranch ())) ;Try this out. (FINDFUNCTION '$LIMIT) (makeglobalassumptions) ;sets global defintassumptions (FINDFUNCTION '$RESIDUE) (SETQ EXP (RATDISREP EXP)) (SETQ VAR (RATDISREP VAR)) (SETQ LL (RATDISREP LL)) (SETQ UL (RATDISREP UL)) (COND (($CONSTANTP VAR) (merror "Variable of integration not a variable: ~M" VAR)) (($SUBVARP VAR) (SETQ VAR (STRIPDOLLAR (CAAR VAR))) (SETQ EXP ($SUBSTITUTE VAR orig VAR EXP)))) (COND ((NOT (ATOM VAR)) (merror "Improper variable of integration: ~M" VAR)) ((OR (AMONG VAR UL) (AMONG VAR LL)) (SETQ VAR (STRIPDOLLAR VAR)) (SETQ EXP ($SUBSTITUTE VAR orig VAR EXP)))) (cond ((not (equal ($ratsimp ($imagpart ll)) 0)) (merror "Defint: Lower limit of integration must be real")) ((not (equal ($ratsimp ($imagpart ul)) 0)) (merror "Defint: Upper limit of integration must be real"))) ;; fix starts here (COND ((mbagp exp) (simplify `((,(mop exp)) ,@(mapcar #'(lambda (e) ($defint e var ll ul)) (margs exp))))) ;; fix ends here ((SETQ ANS (DEFINT EXP VAR LL UL)) (SETQ ANS (SUBST origVAR VAR ANS)) (COND ((atom ans) ans) ((and (free ans '%limit) (free ans '%integrate) (OR (not (free ans '$INF)) (not (free ans '$MINF)) (not (free ans '$INFINITY)))) (diverg)) ((not (free ans '$und)) `((%integrate) ,orig exp ,origvar ,origll ,origul)) (t ANS))) (t `((%integrate) ,origexp ,orig var ,origll ,origul)))) (forgetglobalassumptions)))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875089&group_id=4933 
From: SourceForge.net <noreply@so...>  20060722 15:48:51

Bugs item #873301, was opened at 20040108 13:39 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Gradef doesn't understand diff (workaround) Initial Comment: Suppose that f(x)=exp(g(x)). Then f'(x)=f(x)*g'(x). So how do we define this using gradef? Let's try the obvious solution: gradef( f(x), f(x) * diff(g(x),x) ) Now diff(f(x^2),x) => f(x1)*'DIFF(g(x1),x1,1) Oops! That isn't right! It is substituting x1 for x in the *second* argument of diff as well as the first! So we have to work around this doing something like gradef( f(x), f(x) * g1(x) ) gradef( g(x), g1(x) )  >Comment By: Robert Dodier (robert_dodier) Date: 20060722 09:48 Message: Logged In: YES user_id=501686 In 5.9.3cvs, I'm seeing a different wrong answer. gradef( f(x), f(x) * diff(g(x),x) ); diff(f(x^2),x) ; => 2*x*f(x^2)*'?%diff(g(x^2),x^2,1) Should be 2*x*f(x^2)*at('?%diff(g(u),u,1),[u=x^2]) or something like that (i.e., distinguish point of evaluation x^2 from variable of differentiation). <rant> Maxima adopts numerous mathematical conventions, mostly successfully, but this customary sloppiness with differentials is something I wish we could clean up. </rant> Not sure how the proposed workaround is supposed to work. It turns out g1(x) = bessel_i(1,x)*%e^x  surprise!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&group_id=4933 
From: SourceForge.net <noreply@so...>  20060722 15:04:46

Bugs item #866706, was opened at 20031228 10:00 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866706&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ('m)[1] (meval) Initial Comment: ('m)[1] currently returns m(1). It should return m[1].  >Comment By: Robert Dodier (robert_dodier) Date: 20060722 09:04 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. A few more notes. display2d:false; ('m)[1]; :lisp $_ => ((MQAPPLY ARRAY) ((MQUOTE) $M) 1) :lisp (displa $_) => 'm[1] :lisp (meval $_) => (($M SIMP) 1)  Comment By: Stavros Macrakis (macrakis) Date: 20040128 11:36 Message: Logged In: YES user_id=588346 cf bug 866706  Comment By: Stavros Macrakis (macrakis) Date: 20040108 12:59 Message: Logged In: YES user_id=588346 Peculiarly, (m)[1] => m[1]  actually parses as m[1] (1,'m)[1] => m[1] (0+'m)[1] => m[1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866706&group_id=4933 