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}
(34) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

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

9
(1) 
10
(1) 
11
(2) 
12

13
(1) 
14
(2) 
15
(17) 
16
(5) 
17
(2) 
18
(4) 
19

20
(1) 
21

22
(22) 
23
(5) 
24

25

26
(1) 
27

28
(4) 
29
(1) 
30






From: SourceForge.net <noreply@so...>  20080623 14:34:11

Bugs item #1955976, was opened at 20080502 03:33 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955976&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrej Vodopivec (andrejv) Assigned to: Barton Willis (willisbl) Summary: opproperties Initial Comment: This is a bug from share_testsuite: (%i1) load(multiadditive)$ (%i2) declare(myabs, idempotent, myabs, multiplicative)$ (%i3) myabs(xp * myabs(z)); (%o3) myabs(xp)*myabs(myabs(z)) (%o3) should be myabs(xp)*myabs(z) Andrej  >Comment By: Barton Willis (willisbl) Date: 20080623 09:34 Message: Logged In: YES user_id=895922 Originator: NO There are other problems with the ordering of *operslist: (%i1) declare(f, multiplicative, f, additive)$ Not OK: (%i2) f(a*b+c); (%o2) f(c)+f(a*b) (%i3) expand(%,0,0); (%o3) f(c)+f(a)*f(b) Change the order of *operslist  no more bug: (%i4) :lisp(setq *operslist (reverse *operslist)); (%i4) f(a*b+c); (%o4) f(c)+f(a)*f(b)  Comment By: Barton Willis (willisbl) Date: 20080623 05:50 Message: Logged In: YES user_id=895922 Originator: NO Yes, I did try the wrong example. Changing the order of *operslist fixes this problem. Specifically, in contrib/multiadditive.lisp, change (setq opers (cons '$idempotent opers) *operslist (cons '($idempotent . idempotent) *operslist)) to (setq opers (cons '$idempotent opers) *operslist `(,@*operslist ($idempotent . idempotent))) Then (%i10) declare(myabs, multiplicative, myabs,idempotent)$ (%i11) myabs(xp * myabs(z)); (%o11) myabs(xp)*myabs(z) After testing and collecting comments, I'll commit this fix. It's unfortunate that the *operslist scheme is order dependent. But that's the way it is intended to work, I think.  Comment By: Robert Dodier (robert_dodier) Date: 20080513 19:15 Message: Logged In: YES user_id=501686 Originator: NO Barton, I think you have tried the wrong example. You have myabs(xp)*myabs(myabs(z)) as the test case, but the original report has myabs(xp * myabs(z)). I see the bug when I try the original test case with GCL (on Windows). How about you?  Comment By: Barton Willis (willisbl) Date: 20080507 05:12 Message: Logged In: YES user_id=895922 Originator: NO Try this experiment with nonGCL Maxima (%i7) :lisp(trace eq idempotent); Warning: EQ is being redefined. Warning: EQ is being redefined. (EQ IDEMPOTENT) myabs(xp)*myabs(myabs(z)); <junk> 1> (IDEMPOTENT (($MYABS) $XP) NIL) <1 (IDEMPOTENT (($MYABS SIMP) $XP)) 1> (IDEMPOTENT (($MYABS) $Z) NIL) <1 (IDEMPOTENT (($MYABS SIMP) $Z)) 1> (IDEMPOTENT (($MYABS) (($MYABS SIMP) $Z)) NIL) 2> (EQ $MYABS $MYABS) <2 (EQ T) <1 (IDEMPOTENT (($MYABS SIMP) $Z))  Comment By: Barton Willis (willisbl) Date: 20080507 05:03 Message: Logged In: YES user_id=895922 Originator: NO ...with GCL it's OK: (%i1) load(multiadditive); (%o1) C:/PROGRA~1/MAXIMA~2.0/share/maxima/5.15.0/share/contrib/multiadditive.lisp (%i2) declare(myabs, idempotent, myabs, multiplicative); (%o2) done (%i3) myabs(xp)*myabs(myabs(z)); (%o3) myabs(xp)*myabs(z) (%i4) build_info(); Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 Is this a noun / verb problem?  Comment By: Robert Dodier (robert_dodier) Date: 20080504 00:50 Message: Logged In: YES user_id=501686 Originator: NO Looks like the result is not maximally simplified  reevaluating %o3 => myabs(xp)*myabs(z) as expected.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955976&group_id=4933 
From: SourceForge.net <noreply@so...>  20080623 14:28:07

Bugs item #1996354, was opened at 20080617 12:12 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1996354&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  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: unsimplifed result from expand Initial Comment: (%i52) (%e^(2*sqrt(2))*(%e^(2*sqrt(2))+2*%e^sqrt(2)+1)^2)/16+(%e^(2*sqrt(2))*(%e^(2*sqrt(2)) 2*%e^sqrt(2)+1)^2)/16(%e^(2*sqrt(2))*(%e^(2*sqrt(2))1)^2)/8$ /* should be 1 */ (%i53) expand(%); (%o53) %e^(2^(3/2)2*sqrt(2))/2+1/2 (%i54) expand(%,0,0); (%o54) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1996354&group_id=4933 
From: SourceForge.net <noreply@so...>  20080623 14:27:40

Bugs item #1981628, was opened at 20080601 21:45 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&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  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: a bug of radcan() and radexpand Initial Comment: Dear Developers of Maxima, radcan() does not behave in the correct way. In the online desription of radcan() with the correction of a misprint, which is informed in a separate report by me, it is written that  Function: radcan (<expr>) ... ... When `radexpand' is `false', certain transformations are inhibited. `radcan (sqrt (1x))' remains `sqrt (1x)' and is not simplified to `%i sqrt (x1)'. `radcan (sqrt (x^2  2*x + 1))' remains `sqrt (x^2  2*x + 1)' and is not simplified to `x  1'. ... ... The control by the variable `radexpand' does not work in the present Maxima. A demonstration program is as follows:  /* * a_bug_of_radcan.maxima: * * S.Adachi 2008/06/01 */ display2d:false; radexpand; /* Inspect the value of `radexpand' */ radcan(sqrt(x^22*x+1)); /* expected to reduce to x1 */ radexpand:false; radcan(sqrt(x^22*x+1)); /* expected to remain sqrt(x^22*x+1) */ /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(a_bug_of_radcan.maxima) batching #p/Volumes/HFS+2/home/adachi/work/301/a_bug_of_radcan.maxima (%i2) display2d : false (%o2) false (%i3) radexpand (%o3) true (%i4) radcan(sqrt(12*x+x^2)) (%o4) x1 (%i5) radexpand:false (%o5) false (%i6) radcan(sqrt(12*x+x^2)) (%o6) x1 (%o7) "a_bug_of_radcan.maxima"  If `radexpand' is `false', `radcan(sqrt(x^22*x+1))' is expected to remain `sqrt(x^22*x+1)'. However, Maxima returns `x1' in reality. This is a bug. I think that this is a very serious bug of radcan(). Please fix it. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&group_id=4933 
From: SourceForge.net <noreply@so...>  20080623 14:26:39

Bugs item #1981623, was opened at 20080601 21: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=1981623&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  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: wrong sign of sqrt() Initial Comment: Dear Developers of Maxima, I found that sqrt() returns the incorrect expression that has the sign opposite to the ture expression when some certain argument is given to sqrt(). Namely, sqrt() interprets incorrectly the database that is prepared by assume(). Here is an demonstration program:  /* * wrong_sign_of_sqrt.maxima * * S.Adachi 2008/06/01 */ display2d:false; assume(x >= 0, x <= 1); correct_result_1:sqrt((x1)^2); correct_result_2:sqrt(1/(x1)^2); correct_result_3:sqrt(a*(x1)^2); incorrect_result_1:sqrt(a/(x1)^2); incorrect_result_2:sqrt(a^2/(x1)^2); incorrect_result_3:sqrt(x^2/(x1)^2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(wrong_sign_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/299/wrong_sign_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) assume(x >= 0,x <= 1) (%o3) [x >= 0,x <= 1] (%i4) correct_result_1:sqrt((x1)^2) (%o4) 1x (%i5) correct_result_2:sqrt(1/(x1)^2) (%o5) 1/(1x) (%i6) correct_result_3:sqrt(a*(x1)^2) (%o6) sqrt(a)*(1x) (%i7) incorrect_result_1:sqrt(a/(x1)^2) (%o7) sqrt(a)/(x1) (%i8) incorrect_result_2:sqrt(a^2/(x1)^2) (%o8) abs(a)/(x1) (%i9) incorrect_result_3:sqrt(x^2/(x1)^2) (%o9) x/(x1) (%o10) "wrong_sign_of_sqrt.maxima"  I wonder why sqrt() returns the wrong expression if sqrt((x1)^2) appears in the denominator of some fraction in the argument that is more complex than some threshold (e.g. the numerator is not a simple number or something like that). I think that this is a very severe bug of sqrt() and the database that is prepared by assume(). This bug puts many user programs to the state producing many wrong results. Please fix this severe bug. Sincerely yours, Satoshi Adachi  >Comment By: Robert Dodier (robert_dodier) Date: 20080623 08:26 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core / simplification.  Comment By: Satoshi Adachi (satoshi_adachi) Date: 20080611 00:50 Message: Logged In: YES user_id=1953419 Originator: YES Thank you for your suggestion. But, your suggestion just forbids Maxima to simplify certain expressions in order not to produce wrong results. Is someone trying to fix this bug now? If not yet, I will read lisp source code in some future (maybe, several months later) to try to fix the problem...  Comment By: Barton Willis (willisbl) Date: 20080604 05:20 Message: Logged In: YES user_id=895922 Originator: NO As a workaround, you might try setting radexpand to false: (%i1) assume(0 < x, x <= 1)$ (%i2) sqrt(a/(x1)^2); (%o2) sqrt(a)/(x1) (%i3) sqrt(a/(x1)^2), radexpand : false; (%o3) sqrt(a/(x1)^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&group_id=4933 
From: SourceForge.net <noreply@so...>  20080623 10:50:22

Bugs item #1955976, was opened at 20080502 03:33 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955976&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrej Vodopivec (andrejv) >Assigned to: Barton Willis (willisbl) Summary: opproperties Initial Comment: This is a bug from share_testsuite: (%i1) load(multiadditive)$ (%i2) declare(myabs, idempotent, myabs, multiplicative)$ (%i3) myabs(xp * myabs(z)); (%o3) myabs(xp)*myabs(myabs(z)) (%o3) should be myabs(xp)*myabs(z) Andrej  >Comment By: Barton Willis (willisbl) Date: 20080623 05:50 Message: Logged In: YES user_id=895922 Originator: NO Yes, I did try the wrong example. Changing the order of *operslist fixes this problem. Specifically, in contrib/multiadditive.lisp, change (setq opers (cons '$idempotent opers) *operslist (cons '($idempotent . idempotent) *operslist)) to (setq opers (cons '$idempotent opers) *operslist `(,@*operslist ($idempotent . idempotent))) Then (%i10) declare(myabs, multiplicative, myabs,idempotent)$ (%i11) myabs(xp * myabs(z)); (%o11) myabs(xp)*myabs(z) After testing and collecting comments, I'll commit this fix. It's unfortunate that the *operslist scheme is order dependent. But that's the way it is intended to work, I think.  Comment By: Robert Dodier (robert_dodier) Date: 20080513 19:15 Message: Logged In: YES user_id=501686 Originator: NO Barton, I think you have tried the wrong example. You have myabs(xp)*myabs(myabs(z)) as the test case, but the original report has myabs(xp * myabs(z)). I see the bug when I try the original test case with GCL (on Windows). How about you?  Comment By: Barton Willis (willisbl) Date: 20080507 05:12 Message: Logged In: YES user_id=895922 Originator: NO Try this experiment with nonGCL Maxima (%i7) :lisp(trace eq idempotent); Warning: EQ is being redefined. Warning: EQ is being redefined. (EQ IDEMPOTENT) myabs(xp)*myabs(myabs(z)); <junk> 1> (IDEMPOTENT (($MYABS) $XP) NIL) <1 (IDEMPOTENT (($MYABS SIMP) $XP)) 1> (IDEMPOTENT (($MYABS) $Z) NIL) <1 (IDEMPOTENT (($MYABS SIMP) $Z)) 1> (IDEMPOTENT (($MYABS) (($MYABS SIMP) $Z)) NIL) 2> (EQ $MYABS $MYABS) <2 (EQ T) <1 (IDEMPOTENT (($MYABS SIMP) $Z))  Comment By: Barton Willis (willisbl) Date: 20080507 05:03 Message: Logged In: YES user_id=895922 Originator: NO ...with GCL it's OK: (%i1) load(multiadditive); (%o1) C:/PROGRA~1/MAXIMA~2.0/share/maxima/5.15.0/share/contrib/multiadditive.lisp (%i2) declare(myabs, idempotent, myabs, multiplicative); (%o2) done (%i3) myabs(xp)*myabs(myabs(z)); (%o3) myabs(xp)*myabs(z) (%i4) build_info(); Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 Is this a noun / verb problem?  Comment By: Robert Dodier (robert_dodier) Date: 20080504 00:50 Message: Logged In: YES user_id=501686 Originator: NO Looks like the result is not maximally simplified  reevaluating %o3 => myabs(xp)*myabs(z) as expected.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1955976&group_id=4933 