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}
(41) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3
(2) 
4

5

6

7
(1) 
8
(3) 
9

10
(1) 
11
(4) 
12
(4) 
13
(1) 
14

15
(1) 
16

17

18

19

20
(1) 
21
(4) 
22
(5) 
23
(1) 
24

25

26
(2) 
27
(4) 
28
(4) 
29
(3) 
30
(6) 
31
(1) 
From: SourceForge.net <noreply@so...>  20040127 21:38:36

Bugs item #549226, was opened at 20020426 09:31 Message generated for change (Comment added) made by fjoliveira You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=549226&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with user input Initial Comment:  Some remarks on Userinput of GPL Maxima/Win. (W. Lindner)  Problems with TSETUP(), METRIC(), ENTERTENSOR(), TTRANSFORM() etc.: 1. Studying a Log session of Valerij Pipin, the following behaviour seems intended: (C16) PRINT( Please input tensor name and others,like, name : A; covariant indices: [I,J]; contravariant indices: K; derivative indices: [];, ENTERTENSOR()) Enter tensor name: A; Enter a list of the covariant indices: [I,J]; Enter a list of the contravariant indices: K; Enter a list of the derivative indices: []; K (D16) A I/J Please input tensor name and others,like, name : A; covariant indices: [I,J]; contravariant indices: K; derivative indices: []; A([I, J], [K]) 2. BUT actually it goes like this: (C16) PRINT( Please input tensor name and others,like, name : A; covariant indices: contravariant indices: derivative indices: , ENTERTENSOR()) A; [I,J]; K; [];Enter tensor name: Enter a list of the covariant indices: Enter a list of the contravariant indices: Enter a list of the derivative indices: K (D16) A I J Please input tensor name and others,like, name : A; covariant indices: [I,J]; contravariant indices: K; derivative indices: []; A([I, J], [K]) 3. To sum up, a. ENTERTENSOR() does not make an dialog with the user, but is SEEMS hanging in a loop. Giving the input 'A; [I,J]; K; [];' nevertheless at demo prompt _; (bug in maximal help page: space don't work  use _; !), the input is taken correctly by ENTERTENSOR, and AT THE END all dialog text is shipped out, what makes now no sense, see above. b. Similar behavier found in METRIC(), TTRANSFORM(), TSETUP(): After input METRIC()$, the system seems hanging; giving y; (for YES), the output comes with user query appended (! instead of coming first).  OStR Wolfgang Lindner Tel : +49 (0203) 3791326 GerhardMercatorUniversität Duisburg Fax : +49 (0203) 3792528 Fakultät 4  Naturwissenschaften eMail: Lindner@... Institut fuer Mathematik, LE 424 Lotharstr. 65 D 47048 Duisburg (Germany)  Comment By: Firmin Joseph Oliveira (fjoliveira) Date: 20040127 11:38 Message: Logged In: YES user_id=961659 Maxima version: 5.9.0 Maxima build date: 13:50 4/15/2003 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18e Problem with CTENSR package: TSETUP(); I did not get any prompting for input (such as "Enter the dimension...", or "Do you wish to change the coordinate names?", etc. However I was able to get things to work by entering the expected input information along with a carriage return after each input item. For example, what worked was the following: tsetup();<cr>4;<cr>[r,h,p,t];<cr>1;<cr>1;<cr>A;<cr>r^2;<cr>r^2*sin(h)^2;<cr>D;<cr>depends([A,D],r);<cr>y;<cr>y;<cr> after which the metric tensor and it's inverse were displayed and I could proceed. Upon initial start up of 'xmaximalocal' the following error messages were reported:  maia:maxima5.9.0> Maxima 5.9.0 http://maxima.sourceforge.net Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (C1) ; ; Warning: These variables are undefined: ; *SOCKETCONNECTION* ME ; ; ; Warning: These functions are undefined: ; HOSTENTNAME RESOLVEHOSTIPADDR maia:maxima5.9.0>  User comment: it may be that the problem is with the socket errors above?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=549226&group_id=4933 
From: SourceForge.net <noreply@so...>  20040127 21:02:51

Bugs item #885795, was opened at 20040127 16:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=885795&group_id=4933 Category: None 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...>  20040127 20:48:41

Bugs item #884947, was opened at 20040126 13:34 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&group_id=4933 Category: None 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 15: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...>  20040127 14:20:30

Bugs item #875102, was opened at 20040111 16:43 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875102&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrands involving false Initial Comment: When ?defint isn't able to find the value of a definite integral, it returns false, and it's the job of $defint to return a correct noun form. Maxima allows false to be used as an identifer  this allows $defint to get mixed up; for example (C1) defint(false,x,0,1); (D1) 'INTEGRATE(FALSE,x,0,1) (C2) defint(false,x,0,2); (D2) 2*FALSE (C3) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 This bug may not be worth fixing; it might be better to disallow true, false, und, ... to be used this way. Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040125 14:11 Message: Logged In: YES user_id=588346 The true/false and ind/und/inf cases are different. integrate(true,...) doesn't make sense, because true is a boolean constant, and there is no good reason to arbitrarily convert boolean functions to real functions (e.g. false=0). So either a noun form or an error or even (ba)*true seem like perfectly OK (non)results. Sure, it would be nice if it were perfectly consistent, but.... The ind/und/inf cases, on the other hand, are not even Integrate issues. Integrate(nnn,x,a,b) where nnn is one of those is = (ba)*nnn. If the simplifier gets that right, then Integrate will get that right. So integrate(inf,a,0,1)=>inf, integrate(inf,a,0,0)=inf*0=und, integrate(ind,a,0,1) =ind*1=ind, integrate(ind,a,0,0)=ind*0=0, integrate (ind,a,0,inf)=ind*inf=und, etc. But currently the simplifier does NOT get simplifications involving nonstandard numbers (inf, minf, infinity, ind, und) right.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875102&group_id=4933 