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}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}

_{Jul}

_{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...>  20080629 19:42:14

Bugs item #679435, was opened at 20030203 04:50 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=679435&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: David Billinghurst (billingd) Assigned to: Robert Dodier (robert_dodier) Summary: local(func) should be emphasised in the documentation Initial Comment: >From http://www.math.utexas.edu/pipermail/maxima/2002/002 789.html local(func) should be emphasised in the documentation, i.e., it wasn't intuitively clear to me that block([func],func(x):=x^2); defines func globally, and it takes some time to find out.  >Comment By: Robert Dodier (robert_dodier) Date: 20080629 13:42 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.50 doc/info/Operators.texi, r1.53 doc/info/Function.texi. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20060701 20:19 Message: Logged In: YES user_id=501686 Need to touch the following doc items: block: there is text which mentions using local, but it's not very clear. Probably should cut it and try explaining again local: duplicate whatever text is pasted into block define: mention that local makes a local function definition := : duplicate whatever text is pasted into define. Also needs general expansion  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=679435&group_id=4933 
From: SourceForge.net <noreply@so...>  20080628 19:15:14

Bugs item #635549, was opened at 20021108 08:44 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635549&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: Xmaxima or other UI Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: Xmaxima does not display system output Initial Comment: Under CMUCL, I think the output of system goes to /dev/null. I changed this by changing the $system to [in macsys.lisp] #+cmu (defun $system (&rest args) (ext:runprogram "/bin/sh" (list "c" (apply '$sconcat args)) :output t)) Now, things like system("ls") work fine for me using maxima in a Xemacs shell, but under xmaxima I still don't get any output from system. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20080628 13:15 Message: Logged In: YES user_id=501686 Originator: NO Fixed about as well as it can be by r1.67 src/macsys.lisp: see if *SOCKETCONNECTION* is bound, and if so, direct output into *SOCKETCONNECTION*. Apparently GCL and Clisp cannot redirect output into an alreadyopen stream. So this new patch won't have any effect on them. Closing this report as fixed anyway; there's nothing we can do for GCL or Clisp. Verified that new patch has desired effect for CMUCL and SBCL. Hope it works for SCL, Allegro, OpenMCL, and ABCL.  Comment By: Robert Dodier (robert_dodier) Date: 20070602 13:40 Message: Logged In: YES user_id=501686 Originator: NO Same behavior (system output OK w/ command line Maxima, no output shown in XMaxima) observed with Maxima 5.12.0 + GCL 2.6.8 + Windows Vista.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 17:02 Message: Logged In: YES user_id=501686 system function seems to work OK with cmucl (5.9.1 / cmucl 19a on linux), but system in Xmaxima still shows nothing (probably Xmaxima fails to capture the output stream or something). Changing the title to focus on Xmaxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635549&group_id=4933 
From: SourceForge.net <noreply@so...>  20080628 16:43:08

Bugs item #686819, was opened at 20030214 15:16 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=686819&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: genmatrix bug / fix Initial Comment: GCL (GNU Common Lisp) Version(2.5.0) Sun Nov 17 15:58:09 CET 2002 Licensed under GNU Library General Public License Contains Enhancements by W. Schelter Maxima 5.9.0rc3 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) z:make_array('any,3,3); (D1) {Array: #2A((NIL NIL NIL) (NIL NIL NIL) (NIL NIL NIL))} (C2) genmatrix(z,2,2,0,0); Improper argument to GENMATRIX: {Array: #2A((NIL NIL NIL) (NIL NIL NIL) (NIL NIL NIL))}  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C3) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Submit New' link on that page. Please include the following build information with your bug report:  Maxima version: 5.9.0rc3 Maxima build date: 21:0 11/26/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  The above information is also available from the Maxima function build_info(). (D3) in fact, it is sufficient to add arrayp to the argument test of genmatrix, but I'm not sure whether this is safe... *** comm2.lisp Fri Feb 14 23:04:24 2003  comm2.lisp.~1.1.1.1.~ Mon May 8 08:09:41 2000 *************** *** 606,612 **** (HASHTABLEP (CAR ARGS)) (AND (NOT (ATOM (CAR ARGS))) ! (EQ (CAAAR ARGS) 'LAMBDA)) ! ; kratt5 ! (arrayp (car args)))) (IMPROPERARGERR (CAR ARGS) '$GENMATRIX)) ;(MEMQ NIL (MAPCAR #'(LAMBDA (U) (EQ (TYPEP U) 'FIXNUM)) (CDR ARGS)))  606,610  (HASHTABLEP (CAR ARGS)) (AND (NOT (ATOM (CAR ARGS))) ! (EQ (CAAAR ARGS) 'LAMBDA)))) (IMPROPERARGERR (CAR ARGS) '$GENMATRIX)) ;(MEMQ NIL (MAPCAR #'(LAMBDA (U) (EQ (TYPEP U) 'FIXNUM)) (CDR ARGS))) Martin  >Comment By: Robert Dodier (robert_dodier) Date: 20080628 10:43 Message: Logged In: YES user_id=501686 Originator: NO Not observed in 5.15.0cvs + CMUCL or GCL. Closing this report as fixed per previous comment.  Comment By: Barton Willis (willisbl) Date: 20080307 16:24 Message: Logged In: YES user_id=895922 Originator: NO see comm2.lisp cvs revision 1.20  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=686819&group_id=4933 
From: SourceForge.net <noreply@so...>  20080628 16:38:57

Bugs item #690055, was opened at 20030220 07:13 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=690055&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: Xmaxima or other UI Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yadin Goldschmidt (yadin) Assigned to: Nobody/Anonymous (nobody) Summary: can not mark for eval in lower window in maxima Initial Comment: When typing an expression in the lower (html) window of Xmaxima, and then going to edit, change program to 'maxima' and click "mark for eval", one gets an error message: "list element in quotes followed by "]" instead of space." The expression is not marked for evaluation. It worked fine in 5.5. BTW it would also be nice if the File/save to file in the lower window would save the file in html format. Right now it exports it to text even if the file is in html.  >Comment By: Robert Dodier (robert_dodier) Date: 20080628 10:38 Message: Logged In: YES user_id=501686 Originator: NO With Maxima 5.15.0cvs + CMUCL + Linux: After selecting "Maxima" from the list of programs on the "Edit" button on the middle bar in XMaxima, I can highlight some text and select "mark for eval" from "Edit", and a "RESULT" box is displayed. But when I doubleclick on the selected expression, I get an error message, "wrong # args". Doubleclicking on predefined expressions sucessfully causes the result to be displayed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=690055&group_id=4933 
From: SourceForge.net <noreply@so...>  20080628 15:44:19

Bugs item #683327, was opened at 20030209 02:34 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=683327&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: Xmaxima or other UI Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Interaction with CMUCL Initial Comment: from frido@... Accoding to the docs I can leave maxima with to_lisp(); and in fact I got a CMUCL prompt but now the following happens if I typ in a Lisp form I can not simply write (+ 1 2) but (+ 1 2);< trailing semicolon. Another problem I do not come back to Maxima if I type (run) or (run); I got this error message: Error in function EXTENSIONS:CONNECTTOINETSOCKET: Error connecting socket to [localhost:4008]: No such file or directory Restarts: 0: [MACSYMAQUIT] Macsyma toplevel 1: [ABORT ] Return to TopLevel. Debug (type H for help) (EXTENSIONS:CONNECTTOINETSOCKET "localhost" 4008 :STREAM) Source: Error finding source: Error in function DEBUG::GETFILETOPLEVELFORM: Source file no longer exists: target:code/internet.lisp. I'm running Maxima on Debian/Linux unstable with CMUCL MU Common Lisp 18d+ 20020813, running on fbigm Regards Friedrich  >Comment By: Robert Dodier (robert_dodier) Date: 20080628 09:44 Message: Logged In: YES user_id=501686 Originator: NO 2 items reported above. (1) Lisp evaluation after to_lisp() requires trailing semicolon: not observed in 5.15.0cvs + CMUCL. (2) (run) after to_lisp() complains about port 4008: observed, but (tomaxima) is the way to return to the Maxima prompt. Not going to change that. Closing this report as "won't fix".  Comment By: Nobody/Anonymous (nobody) Date: 20030209 02:48 Message: Logged In: NO Sorry for that followup. The stuff runs in Emacs but fails in Xmaxima Regards Friedrich  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=683327&group_id=4933 
From: SourceForge.net <noreply@so...>  20080626 18:49:03

Bugs item #2003386, was opened at 20080626 14:49 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=2003386&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: float(elliptic_kc(1)) causes Lisp error Initial Comment: float(elliptic_kc(1)) signals a Lisp error. I think it should do something else. Perhaps return inf since elliptic_kc(x) > inf as x > 1, so elliptic_kc(1) might return inf instead of a noun form.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2003386&group_id=4933 
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 
From: SourceForge.net <noreply@so...>  20080622 22:13:47

Bugs item #1959214, was opened at 20080506 22:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&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 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate() and array having lisp style name Initial Comment: Dear Developer of Maxima, I found that integrate() returns a wrong result if an array that has a lisp name ``?...'' is used in the argument of integrate(). Here is a demonstration program:  /* * integrate_and_array_of_lisp_name.maxima: * * S.Adachi 2008/05/06 */ display2d:false; integrate(1,?a[1],0,?a[2]); /* Maxima result ?a[1][2] should be ?a[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(integrate_and_array_of_lisp_name.maxima) batching #p/Volumes/HFS+2/home/adachi/work/294/integrate_and_array_of_lisp_name.maxima (%i2) display2d : false (%o2) false (%i3) integrate(1,?a[1],0,?a[2]) (%o3) ?a[1][2] (%o4) "integrate_and_array_of_lisp_name.maxima"  The correct value of this integration is ?a[2]. But Maxima returns ?a[1][2], which is wrong. I think that this is a bug of Maxima. In the following, I want to explain the situation in which I met the above bug of Maxima in order to motivate the kind Maxima developers to take the action to actually fix this bug. When I am writing a program in Maxima, I sometimes need an array that has some name which is unique and is dynamically determined in execution. In such a situation, I write a code like A:?gensym(), apply('array, [A,n]), ... < Work with dynamical array A > .. apply('remarray, [A]) The variable A stores a name ``?g....'' of the dynamical array that is generated. This name ``?g....'' is a lisp style name. In the present case, the work is to prepare a function of elements of the dynamical array and integrate the function. Then, when the written program is executed, it tells me that Maxima has the bug that I am now reporting. I hope that any variable in Maxima should not be discreminated by the reason that the variable simply has a lisp name. If it is so, what I am now reporting is truely a bug of Maxima, which is serious for people who write Maxima programs. Please fix this bug of Maxima. Sincerely yours, Satoshi Adachi P.S. (i) As a temporal workaround to write Maxima programs, I replace the line "A:?gensym()," in the above example by a line "A:eval_string(substring(string(?gensym()),2))," to use a Maxima style name "g...." instead of a lisp style name "?g...." (and keep being carefull not to use any name "g...." for other Maxima variables). This is an ugry workaround. (ii) If there is a better or standard way in Maxima to prepare some dynamical array that has a unique name on fly, please let me know. If someone tells me it, I will be happy.  >Comment By: Robert Dodier (robert_dodier) Date: 20080622 16:13 Message: Logged In: YES user_id=501686 Originator: NO Here is a slightly different workaround. :lisp (defun $gensym () (cadr (dollarify (list (gensym))))) Then you can write A:gensym() instead of A:?gensym() and the generated symbols are Maxima identifiers (because they have the leading $ in the name).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 21:55:41

Bugs item #1954693, was opened at 20080429 23:26 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&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 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: 2D display of long denominator of nested fractional Initial Comment: Dear Developers of Maxima, I think that I met a bug of Maxima to display nested fractionals in the 2D style. If the denominator of a nested fractional is long, it is not displayed correctly. The display width controll based on the variable LINEL seems to be not effective in the denominator. Compared to this, the numerator of a nested fractional causes no such problem to be displayed even when the numerator is long. Here, I have prepared a program for demonstration:  /* * denominator_of_nested_fractional_is_not_displayed_correctly.maxima: * * The line length, which is usually controlled by the variable LINEL, * is not recognized in the denominator of a nested fractional, if the * nested fractional has a long denominator. * * S.Adachi 2008/04/29 */ /* Do not use ``display2d:false;'', since this is a problem in displaying a mathematical expression in the 2D style. */ X:product(f(i+1/2),i,0,20); Y:product(g(i+1/2),i,0,20); Z:X/Y; /* A nested fractional; its denominator is not displayed correctly. */ /* END */  This is a problem in displaying mathematical expressions in the 2D style. Accordingly, I cannot attach here the log list that is obtained by running the above program. (If I include in a bug report the mathematical expressions that are displayed in the 2D style by Maxima, the posted bug report becomes a disordered gabage in appearance.) So, please execute the above program by the command maxima b denominator_of_nested_fractional_is_not_displayed_correctly.maxima to see the phenomenon that I am reporting in this letter. I am using a console terminal with line width 80 to run the above program. It is essential for Maxima to display any mathematical expression in a correct mannar. If it is not, we cannot read the output from Maxima. So, please fix this bug. Sincerely yours, Satoshi Adachi  >Comment By: Robert Dodier (robert_dodier) Date: 20080622 15:55 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core.  Comment By: Robert Dodier (robert_dodier) Date: 20080503 23:55 Message: Logged In: YES user_id=501686 Originator: NO Observed in Maxima 5.15.0cvs. NOT observed in 5.9.0  so I guess the display code was modified incorrectly at some point. I can try some different versions, but it will be a while. The line width doesn't appear to be important  I get incorrect output when linel:65, or linel:70, or linel:80.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 17:34:05

Bugs item #1951128, was opened at 20080424 14:18 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951128&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  Polynomials Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Volker van Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: curious warning from allroots(x=0) Initial Comment: (%i4) allroots(x=0); Unexpected error. Treat results with caution. (%o4) [x = 0.0] (%i5) allroots(x=1); (%o5) [x = 1.0] x=0 isn't so special, or?  >Comment By: Robert Dodier (robert_dodier) Date: 20080622 11:34 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.13 src/cpoly.lisp. Closing this report as fixed. Error originates in SCALESL because it tries to divide by degree of polynomial. RPOLYSL and CPOLYSL strip off zero roots before calling SCALESL, decreasing the degree by 1 for each zero root. However, if there are only roots at zero (e.g. x^n = 0 for some n) then SCALESL fails. So avoid calling SCALESL when reduced degree = 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951128&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 11:33:48

Bugs item #1949337, was opened at 20080422 20:51 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1949337&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: complexnumberp test for floatp Initial Comment: (%i1) x : 3.1 + %i * 1.7; (%o1) 1.7*%i+3.1 This is wrong: (%i2) :lisp(complexnumberp (meval $x) 'floatp); NIL Thi is OK (%i2) :lisp(complexnumberp (meval $x) 'mnump); T I think this is due to the (N 1) check in complexnumberp. Maxima version: 5.14.99rc1 Maxima build date: 11:38 4/12/2008  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1949337&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 11:33:47

Bugs item #1941682, was opened at 20080413 20:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1941682&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: Xmaxima or other UI Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: After a while i get the message "Starting maxima timed out" Initial Comment: After a while I get the message "Starting maxima timed out. Wait longer?" and xmaxima doesn't connect to maxima. Maxima works fine, but it doesn't connect to xmaxima neither wxmaxima (this last gets the message "") I use Ubuntu 7.10, and maxima 5.10.0 and wxmaxima 0.7.1  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 19:13 Message: Logged In: YES user_id=501686 Originator: NO Not enough information to resolve the problem, and no contact info. Closing this report as "won't fix".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1941682&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 10:43:00

Bugs item #1995531, was opened at 20080616 16:49 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeta errors near 0.0 / 0.0b0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  >Comment By: Barton Willis (willisbl) Date: 20080622 05:42 Message: Logged In: YES user_id=895922 Originator: NO Also try makelist(bfloat(bfzeta(1.0b7,20 + 10 * k)),k,1,40). The bug doesn't seem to be just a case of subtractive cancellation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 10:23:42

Bugs item #1954846, was opened at 20080430 10:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Raymond Toy (rtoy) Date: 20080620 15:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 15:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 15:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 14:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 10:10:11

Bugs item #1954846, was opened at 20080430 10:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Raymond Toy (rtoy) Date: 20080620 15:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 14:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 09:45:24

Bugs item #1954846, was opened at 20080430 10:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&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 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Raymond Toy (rtoy) Date: 20080620 15:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 15:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 14:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 09:01:55

Bugs item #1995595, was opened at 20080616 17:27 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995595&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: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sign(max(7,x)  max(6,x)) > error Initial Comment: (%i1) sign(max(7,x)  max(6,x)); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: MACSYMATOPLEVEL [or a callee] requires less than seven arguments.  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 13:52 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.25 src/nset.lisp, r1.40 src/clmacs.lisp (move macro DOMERGEASYM from nset to clmacs). Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995595&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 09:00:19

Bugs item #1927346, was opened at 20080327 12:31 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1927346&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: Closed Resolution: Duplicate Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(2) ./ 2 vs 1/sqrt(2) Initial Comment: It's not wrong, but it's not right either: (%i3) integrate(sin(t),t,%pi/4,3*%pi/4); (%o3) sqrt(2)/2+1/sqrt(2)  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 18:48 Message: Logged In: YES user_id=501686 Originator: NO Closing this report  was marked a duplicate before but not closed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1927346&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 08:47:29

Bugs item #1891216, was opened at 20080211 08:38 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891216&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is(if a>0 and a>0 and a>0 ...) => internal error Initial Comment: is(if a>0 and a>0 then 1) => unknown (OK) is(if a>0 and a>0 and a>0 then 1) => Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ((MGREATERP $A (0 DATA (((MGRP ... Same for is(if a>0 and a>0 and a>0 then true else false) i.e. it is not because the return value is a nonboolean Maxima 5.13.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891216&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 08:36:41

Bugs item #1891911, was opened at 20080212 06:03 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891911&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: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(f(a+b+c)) > Lisp error Initial Comment: OK: (%i1) is(f(a)); (%o1) unknown OK: (%i2) is(f(a+b)); (%o2) unknown Not OK (%i3) is(f(a+b+c)); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ($A $B $C) (%i4) build_info();Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  Comment By: Barton Willis (willisbl) Date: 20080214 06:01 Message: Logged In: YES user_id=895922 Originator: YES This might help find the bug: OK (%i1) notequal((a*z)/10,0)$ (%i2) maybe(%); (%o2) unknown Not OK (%i3) unk((a*z)/10,0)$ (%i4) maybe(%); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ((RAT  Comment By: Barton Willis (willisbl) Date: 20080212 06:11 Message: Logged In: YES user_id=895922 Originator: YES See also SF bug 1726550 "not bugs." These bugs might be the same.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891911&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 08:23:17

Bugs item #1916517, was opened at 20080317 03:40 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1916517&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: (F=0 and G=0) and (F=0 and FG=0) have different solutions. Initial Comment: Dear Developers of Maxima, I met a set of two albebraic equations F = 0 and G = 0 of two variables x and y such that (i) solve([F=0,G=0],[x,y]) returns no solution [] (this is wrong), whereas (ii) solve([F=0,FG=0],[x,y]) returns true solutions. This is strange, since the first set of equations F=0 and G=0 should have the same solutions of the second set of equations F=0 and FG=0. (1) The Maxima program to solve F=0 and FG=0 is  /* * solve_system_of_algebraic_equations_OK.maxima: * * F is a polynomial of x and y, which is degree 3 in x and 2 in y. * G is a polynomial of x and y, which is degree 3 in x and 2 in y. * * solve() and algsys() can solve the system equations F=0 and FG=0. */ display2d:false; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; solutions:solve([F=0,FG=0],[x,y]); /* OK: solutions are found. */  The result is  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(solve_system_of_algebraic_equations_OK.maxima) batching #p/Volumes/HFS+2/home/adachi/work/285/solve_system_of_algebraic_equations_OK.maxima (%i2) display2d : false (%o2) false (%i3) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o3) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i4) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o4) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i5) solutions:solve([F = 0,FG = 0],[x,y]) (%o5) [[x = (sqrt(a)*(a^24*a)+sqrt(a4)*(2*aa^2))/(2*sqrt(a4)), y = 1/(a*sqrt(a^24*a))], [x = (sqrt(a4)*(a^22*a)+sqrt(a)*(a^24*a))/(2*sqrt(a4)), y = 1/(a*sqrt(a^24*a))]] (%o6) "solve_system_of_algebraic_equations_OK.maxima"  =============================================================================== (2) The Maxima program to solve F=0 and G=0 is  /* * solve_system_of_algebraic_equations_NG.maxima: * * F is a polynomial of x and y, which is degree 3 in x and 2 in y. * G is a polynomial of x and y, which is degree 3 in x and 2 in y. * * solve() and algsys() can NOT solve the system equations F=0 and G=0. */ display2d:false; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; solutions:solve([F=0,G=0],[x,y]); /* NG: solutions are NOT found! */  The result is  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(solve_system_of_algebraic_equations_NG.maxima) batching #p/Volumes/HFS+2/home/adachi/work/285/solve_system_of_algebraic_equations_NG.maxima (%i2) display2d : false (%o2) false (%i3) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o3) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i4) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o4) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i5) solutions:solve([F = 0,G = 0],[x,y]) (%o5) [] (%o6) "solve_system_of_algebraic_equations_NG.maxima"  =============================================================================== (3) I also tried algebraic:true to solve F=0 and G=0. The program is  /* * solve_system_of_algebraic_equations_with_algebraic_NG.maxima: * * F is a polynomial of x and y, which is degree 3 in x and 2 in y. * G is a polynomial of x and y, which is degree 3 in x and 2 in y. * * solve() and algsys() can NOT solve the system equations F=0 and G=0. */ display2d:false; algebraic:true; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; solutions:solve([F=0,G=0],[x,y]); /* NG: internal error! */  The result is further strange for me as  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(solve_system_of_algebraic_equations_with_algebraic.maxima) batching #p/Volumes/HFS+2/home/adachi/work/285/solve_system_of_algebraic_equations_with_algebraic.maxima (%i2) display2d : false (%o2) false (%i3) algebraic:true (%o3) true (%i4) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o4) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i5) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o5) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i6) solutions:solve([F = 0,G = 0],[x,y]) Polynomial quotient is not exact  an error. To debug this try debugmode(true);  Sincerely yours, Satoshi Adachi  Comment By: Satoshi Adachi (satoshi_adachi) Date: 20080411 01:01 Message: Logged In: YES user_id=1953419 Originator: YES Dear Mr.Barton Willis (willisbl), Thank you very much for educating me to know how the decifiancy of algsys() that was described in my previous bug report can be overcome. Your information is very helpful! At first, I am sorry to be late in writing this letter of thanks. I had been occupied by duty works until yesterday. Today, I wrote a wrapper routine of algsys(), which is based fully on your suggestion and is named algsys_willisbl(), as follows:  /* * algsys_willisbl.maxima: * * better algsys() suggested by willisbl. * * [Remark] To use algsys_willisbl(), the following preparation is necessary: * * load("topoly"); // for elim() * algebraic:true; * * S.Adachi 2008/04/10 */ algsys_willisbl(eqns_lst, vars_lst) := block([eqns1_lst,eqns2_lst,sols_cand_lst,sols_lst], eqns1_lst:map(lambda([e], if (not atom(e) and operatorp(e,"=")) then lhs(e)rhs(e) else e), eqns_lst), eqns2_lst:first(rest(elim(eqns1_lst, vars_lst))), sols_cand_lst:algsys(eqns2_lst, vars_lst), sols_lst:listify(subset(setify(sols_cand_lst), lambda([sc], every(lambda([a], is(equal(a,0))), ratsimp(subst(sc, eqns1_lst)))))), sols_lst); /* END */  I also wrote a test program for algsys_willisbl() by using the same system of algebraic equations that was described in my previous bug report of algsys() as  /* * test_algsys_willisbl.maxima: * * test algsys_willisbl() by applying it to a system of two algebraic * equations F=0 and G=0, which cannot be solved by algsys(). * * S.Adachi 2008/04/10 */ load(topoly); load("algsys_willisbl.maxima"); algebraic:true; display2d:false; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; sols1:algsys_willisbl([F,G], [x,y]); sols2:algsys_willisbl([F=0,G=0], [x,y]); sols3:algsys_willisbl([F+1=1,G+2=2], [x,y]); /* END */  The result of executation is as follows:  [Macintosh:~/work/288:1] adachi% maxima b test_algsys_willisbl.maxima 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(test_algsys_willisbl.maxima) batching #p/Volumes/HFS+2/home/adachi/work/288/test_algsys_willisbl.maxima (%i2) load(topoly) (%o2) /usr/local/share/maxima/5.14.0cvs/share/contrib/topoly.lisp (%i3) load(algsys_willisbl.maxima) (%o3) algsys_willisbl.maxima (%i4) algebraic : true (%o4) true (%i5) display2d : false (%o5) false (%i6) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o6) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i7) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o7) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i8) sols1:algsys_willisbl([F,G],[x,y]) (%o8) [[x = (a*sqrt(a^24*a)a^2+2*a)/2,y = sqrt(a^24*a)/(a^34*a^2)], [x = (a*sqrt(a^24*a)+a^22*a)/2,y = sqrt(a^24*a)/(a^34*a^2)]] (%i9) sols2:algsys_willisbl([F = 0,G = 0],[x,y]) (%o9) [[x = (a*sqrt(a^24*a)a^2+2*a)/2,y = sqrt(a^24*a)/(a^34*a^2)], [x = (a*sqrt(a^24*a)+a^22*a)/2,y = sqrt(a^24*a)/(a^34*a^2)]] (%i10) sols3:algsys_willisbl([1+F = 1,2+G = 2],[x,y]) (%o10) [[x = (a*sqrt(a^24*a)a^2+2*a)/2,y = sqrt(a^24*a)/(a^34*a^2)], [x = (a*sqrt(a^24*a)+a^22*a)/2,y = sqrt(a^24*a)/(a^34*a^2)]] (%o11) "test_algsys_willisbl.maxima" [Macintosh:~/work/288:2] adachi%  I did not apply algsys_willisbl() to any other examples, yet. So, it may have still bugs. Anyway, I become now able to advance my study again without the annoyance caused by algsys(). The knowledge that you gave me is very essential to use algsys() in a better way. Thank you very much. Sincerely yours, Satoshi Adachi  Comment By: Barton Willis (willisbl) Date: 20080317 06:05 Message: Logged In: YES user_id=895922 Originator: NO Thanks for reporting this bug. The function algsys isn't nearly as good as we would like. The best I can offer is my favorite workaround (that might work); it's something like: (%i92) load(topoly)$ (%i93) algebraic : true$ Use 'elim' to triangularize the equationsthis can create spurious solutions: (%i94) elim([F,G],[x,y]); (%o94) [[],[x^4+a^2*x^3a*x^3+a^3*x^2a^2*x^2+a^3*x,x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1]] Use algsys to solve these equations: (%i95) sol : algsys(first(rest(%)),[x,y])$ Try to reject the spurious solutions: (%i96) true_sol : set()$ (%i97) for si in sol do if every(lambda([a], is(equal(a,0))), ratsimp(subst(si,[F,G]))) then true_sol : adjoin(si, true_sol); (%o97) done (%i98) true_sol; (%o98) {[x=(a*sqrt(a^24*a)a^2+2*a)/2,y=sqrt(a^24*a)/(a^34*a^2)], [x=(a*sqrt(a^24*a)+a^22*a)/2,y=sqrt(a^24*a)/(a^34*a^2)]} Two solutions *might* be spurious and two checked out OK. You'll need to inspect the two rejected solutions to see if they are really spurious. And a = 0 and a = 4 might be special cases that need to be checked. Of course, all this should be automatic; unfortunately, algsys isn't there yet. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1916517&group_id=4933 