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}
(8) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(4) 
2
(1) 
3
(1) 
4
(2) 
5
(7) 
6
(7) 
7
(1) 
8
(6) 
9

10
(3) 
11
(1) 
12
(2) 
13
(11) 
14
(1) 
15
(5) 
16

17

18
(2) 
19
(10) 
20
(2) 
21
(2) 
22
(3) 
23
(2) 
24
(6) 
25
(2) 
26
(6) 
27
(2) 
28
(10) 
29
(1) 
30

31
(3) 






From: SourceForge.net <noreply@so...>  20090508 22:52:48

Bugs item #1023931, was opened at 20040907 21:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1023931&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: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: logabs not a defmvar Initial Comment: We should append (defmvar $logabs nil) to (not sure of best place). Currently, reset doesn't work on logabs because of the missing defmvar. Barton  >Comment By: Dieter Kaiser (crategus) Date: 20090509 00:52 Message: The definition (defmvar $logabs nil) has been added in the file simp.lisp. reset() now works for the option variable logabs; (%i3) logabs; (%o3) false (%i4) logabs:true; (%o4) true (%i5) reset(); (%o1) [lispdisp, display2d, linenum, %, __, _, logabs, error] Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1023931&group_id=4933 
From: SourceForge.net <noreply@so...>  20090508 21:05:20

Bugs item #1860420, was opened at 20071229 16:09 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860420&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: beta_args_sum_to_integer doc Initial Comment: The option variable beta_args_sum_to_integer is undocumented. Actually, we should consider getting rid of this option variable.  >Comment By: Dieter Kaiser (crategus) Date: 20090508 23:05 Message: The variable beta_args_sums_to_integer now is documented. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090309 21:09 Message: Documentation for $beta_args_sum_to_integer is added. This flag controls simplification when the arguments of the beta function sums to an integer. The default value is false. I think this is a useful option, but should not switched on by default. When we set beta_args_sum_to_integer by default true, we get one error with the testsuite in file rtest16.mac: ********************** Problem 14 *************** Input: powerseries(x^n+1,x,0) Result: Division by 0 ?error\catch This differed from the expected result: ('sum(x^(i3*n)/beta(2i3,1+i3),i3,0,inf))/2 ********************************************* For this example the beta functions simplifies to an expression which generates a division by zero. I am not sure why we should remove this option variable. Perhaps we could use the flag $beta_expand to switch on this simplification too. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080615 03:48 Message: Logged In: YES user_id=501686 Originator: NO Agreed that we should cut out this option flag. Reference to $BETA_ARGS_SUM_TO_INTEGER probably should be replaced by a call to askprop or featurep or something like that.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860420&group_id=4933 
From: SourceForge.net <noreply@so...>  20090508 20:45:35

Bugs item #2299224, was opened at 20081116 16:47 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2299224&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: None >Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: unsimplified result from rectform Initial Comment: (%i1) logarc : true; (%o1) true (%i2) rectform(log(x + %i * y)); (%o2) log(y^2+x^2)/2+%i*atan2(y,x) (%i3) expand(%,0,0); (%o3) log(y^2+x^2)/2+(log((%i*y)/x+1)log(1(%i*y)/x))/2 Also (%o3) is wrong for x = 0 and in the left half plane.  >Comment By: Dieter Kaiser (crategus) Date: 20090508 22:45 Message: The expression does not simplify as expected because the global flag $logarc is set to nil in the routine risplit. It is possible to remove this from the routine risplit. Then we would get: (%i11) rectform(log(x+%i*y)),logarc; (%o11) log((%i*y+x)/sqrt(y^2+x^2))+log(y^2+x^2)/2 Because of revision 1.25 the result of the simplification is now correct. I have checked this with the testsuite and the share_testsuite. There are no examples which depend on the setting of $logargs in the routine risplit. Should we change the routine risplit and remove the setting of the flag $logarg? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2299224&group_id=4933 
From: SourceForge.net <noreply@so...>  20090508 16:40:51

Bugs item #2789110, was opened at 20090508 16:40 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2789110&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  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve, tan and atan depend on order of variables Initial Comment: solve(tan(x  atan(c1/c2)) = 0, x); returns [x=atan(c1/c2)] corretly, but solve(tan(x  atan(c2/c1)) = 0, x); returns [ ].  Maxima version: 5.18.1 Maxima build date: 14:34 4/18/2009 host type: i686appledarwin8.11.1 lispimplementationtype: CMU Common Lisp lispimplementationversion: 19f (19F)   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2789110&group_id=4933 
From: SourceForge.net <noreply@so...>  20090508 16:13:05

Bugs item #1041570, was opened at 20041006 18:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1041570&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume(abs(x)<1) should imply x<1 and x>1 Initial Comment: assume(abs(x)<1)$ sign(x1) => doesn't know (should be NEG) sign(1x) => doesn't know (should be POS) assume(x>1) => doesn't notice contradiction The easy fix is of course to make the original assumption add x<1 and x>1 to the database, but how do you ensure that they get *removed* if you remove (forget) the original assertion. And what if x<1 has been explicitly added in the meantime? Same problem in the reverse direction: assume(y<1,y>1)$ sign(abs(y)1) => PNZ (should be NEG)  >Comment By: Dieter Kaiser (crategus) Date: 20090508 18:13 Message: I think the handling of the abs funtion is a missing feature of assume. This would be some code to add this feature in a way assume can handle it: ;; This function is like isinop, but returns in addition ;; the expression with the operator and not only T or NIL (defmfun isopinexprp (exp var) (let ((tmp nil)) (cond ((atom exp) nil) ((and (eq (caar exp) var) (not (member 'array (cdar exp) :test #'eq))) (setq tmp exp)) (t (do ((exp (cdr exp) (cdr exp))) ((null exp)) (cond ((setq tmp (isopinexprp (car exp) var)) (return tmp)))))))) ;; The modified routine assume (defmfun assume (pat) (if (and (not (atom pat)) (eq (caar pat) 'mnot) (eq (caaadr pat) '$equal)) (setq pat `(($notequal) ,@(cdadr pat)))) (let (tmp) ;; Look for mabs in the expression, check the bounds and substitute ;; accordingly, e. g. abs(x)<1 > x<1 and x<1 (when (and (setq tmp (isopinexprp pat 'mabs)) (or (and (eq (caar pat) 'mlessp) (isopinexprp (cadr pat) 'mabs) (member ($sign (caddr pat)) '($pos $pz))) (and (eq (caar pat) 'mgreaterp) (member ($sign (cadr pat)) '($pos $pz)) (isopinexprp (caddr pat) 'mabs)))) (let ((pat1 ($substitute (cadr tmp) tmp pat)) (pat2 ($substitute (mul 1 (cadr tmp)) tmp pat))) (assume pat1) (assume pat2)))) (let ((dummy (let ($assume_pos) (car (mevalp1 pat))))) (cond ((eq dummy t) '$redundant) ((null dummy) '$inconsistent) ((atom dummy) '$meaningless) (t (learn pat t))))) ;; The modified routine forget (defmfun forget (pat) (cond (($listp pat) (cons '(mlist simp) (mapcar #'forget1 (cdr pat)))) (t (let (tmp) (when (setq tmp (isopinexprp pat 'mabs)) (let ((pat1 ($substitute (cadr tmp) tmp pat)) (pat2 ($substitute (mul 1 (cadr tmp)) tmp pat))) (forget1 pat1) (forget1 pat2)))) (forget1 pat)))) With this extension we get: (%i3) assume(abs(x)<1); (%o3) [abs(x) < 1] (%i4) facts(); (%o4) [1 > x,x > 1,1 > abs(x)] (%i5) sign(x1); (%o5) neg (%i6) sign(1x); (%o6) pos An example with a positive symbol as an upper bound: (%i1) assume(y>0); (%o1) [y > 0] (%i2) assume(abs(x)<y); (%o2) [y > abs(x)] (%i3) facts(); (%o3) [y > 0,y > x,y+x > 0,y > abs(x)] (%i4) sign(yx); (%o4) pos (%i5) sign(x+y); (%o5) pos (%i6) sign(xy); (%o6) neg (%i7) sign(xy); (%o7) neg This will work together with forget: (%i2) assume(abs(x)<1)$ (%i3) facts(); (%o3) [1 > x,x > 1,1 > abs(x)] (%i4) forget(abs(x)<1)$ (%i5) facts(); (%o5) [] The bound has to be a positive value: (%i6) assume(abs(x)<1); (%o6) [inconsistent] This does not sovlve the problem for the reverse direction. This feature might be added to the $signfunction. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1041570&group_id=4933 
From: David Chappaz <david.chappaz@fr...>  20090508 15:16:16

Hi, There seem to be a number of problems with the "residue" function, which may or may not be related, I don't really know. I've tried the following: (%i1) set_display('ascii)$ domain : complex $ declare(N, integer) $ H : 1 / (x*(xx0)*(1  x^N/y)) $ Problem #1: (%i5) residue(H, x, 0); y (%o5)   N x0 y  x x0 This should not depend on x, but it does... However the residue at x0 does not suffer from the same problem. (%i6) residue(H, x, x0); y (%o6)  N + 1 x0 y  x0 Problem #2: (%i8) declare(k, integer) $ Hk : x^(k1) / ((x  x0)*(1  x^N/y)) $ (%i10) declare(p, integer) $ residue(subst(k=+p, Hk), x, 0); residue(subst(k=p, Hk), x, 0); (%o11) 0 y (%o12)   p N + p x x0 y  x x0 Funnily enough, the result actually is different, depending on the sign affected to the parameter... Answer #2 suffers from problem #1, but both are wrong anyway. Problem #3: (%i13) residue(Hk, x, 0); (%o13) 0 I believe Maxima should ask if k is positive (which makes 0 a zero of order k1) or negative (which makes 0 a pole of order 1k). The residue is 0 only if k > 0. 