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}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(3) 
S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

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

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

19
(15) 
20

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

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

31
(30) 





From: SourceForge.net <noreply@so...>  20060708 18:56:26

Bugs item #1515063, was opened at 20060630 05:37 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515063&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaime E. Villate (villate) Assigned to: Nobody/Anonymous (nobody) Summary: display2d should use parenthesis for limits Initial Comment: 'limit(b*x+a*x+x,x,3); produces: limit b x + a x + x x > 3 which is misleading. It should better give: limit ( b x + a x + x ) x > 3  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:56 Message: Logged In: YES user_id=501686 OK, I understand now that the question is raised wrt display2d : true. I don't know that the given display is ambiguous. When limit is displayed alone, the parentheses are absent, it is true. However, when there are other terms, limit is displayed in parentheses. So I am inclined to close this item as "won't fix". (%i8) FOO * 'limit(b*x+a*x+x,x,3); (%o8) (limit b x + a x + x) FOO x > 3 (%i9) foo * FOO * 'limit(b*x+a*x+x,x,3); (%o9) foo (limit b x + a x + x) FOO x > 3 (%i10) foo * 'limit(b*x+a*x+x,x,3); (%o10) foo (limit b x + a x + x) x > 3 (%i12) FOO + 'limit(b*x+a*x+x,x,3); (%o12) FOO + (limit b x + a x + x) x > 3 (%i13) foo + FOO + 'limit(b*x+a*x+x,x,3); (%o13) FOO + (limit b x + a x + x) + foo x > 3 (%i14) foo + 'limit(b*x+a*x+x,x,3); (%o14) (limit b x + a x + x) + foo x > 3  Comment By: Robert Dodier (robert_dodier) Date: 20060630 09:16 Message: Logged In: YES user_id=501686 Jaime, what is the Maxima version? I see (%i1) display2d:false; (%o1) false (%i2) 'limit(b*x+a*x+x,x,3); (%o2) 'limit(b*x+a*x+x,x,3) with 5.9.3 & 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515063&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:47:21

Bugs item #1517061, was opened at 20060704 11:05 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517061&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 Submitted By: Stas Fomin (sfomin) Assigned to: Nobody/Anonymous (nobody) Summary: sumcontract failed: "The function $MAX is undefined" Initial Comment: Consider an example from tutorial: http://maxima.sourceforge.net/docs/tutorial/en/gaertnertutorialrevision/Pages/sum01.htm sum1: sum(1/x^2, x, 1, inf); sum2: sum(1/x^3, x, 1, inf); sum1 + sum2; sumcontract(%);  Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: The function $MAX is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  Maxima 5.9.3, Windows.  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:47 Message: Logged In: YES user_id=501686 This bug is fixed by r1.4 src/sumcon.lisp (dated 2006/04/06) which is in current cvs version but not 5.9.3 official release (circa 2006/03/01). Closing this bug as fixed; the fix will be in the next release (scheduled for latter part of 2006/08). Thanks very much for making this report, we appreciate your help.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517061&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:42:38

Bugs item #1517077, was opened at 20060704 11:32 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517077&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: Open Resolution: None Priority: 5 Submitted By: Stas Fomin (sfomin) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: "Polynomial Arithmetic with Rests" Initial Comment: Consider example from tutorial: http://maxima.sourceforge.net/docs/tutorial/en/gaertnertutorialrevision/Pages/PArithRests0001.htm Maxima 5.9.1:  (%i9) poly: x^6 +19*x^5 + x^4  14*x^3  x^2  3*x + 1; 6 5 4 3 2 (%o9) x + 19 x + x  14 x  x  3 x + 1 (%i10) mod(poly, 11); 6 5 4 3 2 (%o10) x  3 x + x  3 x  x  3 x + 1  This agree with the manual. Maxima 5.9.3:  (%i1) poly: x^6 +19*x^5 + x^4  14*x^3  x^2  3*x + 1; 6 5 4 3 2 (%o1) x + 19 x + x  14 x  x  3 x + 1 (%i2) mod(poly, 11); 6 5 4 3 2 (%o2) mod(x + 19 x + x  14 x  x  3 x + 1, 11)  This conflicts with the documentation.  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:42 Message: Logged In: YES user_id=501686 Function mod was renamed to polymod. Document needs to be updated accordingly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517077&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:40:24

Bugs item #1502633, was opened at 20060607 20:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1502633&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 >Group: To be reviewed Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Gnuplot dumb terminal output not captured by xmaxima Initial Comment: In Xmaxima (5.9.3cvs / GCL 2.6.7, SBCL 0.9.9, Clisp 2.34 / Linux, and *maybe* also 5.9.3 / GCL 2.6.7 / Win XP), Gnuplot dumb terminal output is not captured. plot2d (sin(x), [x, 0, %pi], [gnuplot_term, dumb]); shows nothing in Xmaxima, and on Linux at least, the xterm from which Xmaxima was launched shows the output. Running Maxima from an xterm shows the dumb terminal output in the xterm as expected (an ascii art sine wave). Dunno for sure if this same problem is exhibited by Xmaxima 5.9.3 / GCL 2.6.7 / Win XP. The dumb terminal output goes missing, but I don't know if that is the same bug or a different one, because dumb terminal output is lost in a Maxima command prompt window. Fixing the gnuplot dumb terminal output is no pressing problem, but I'm pretty sure that the problem is that gnuplot is writing an output stream which is not redirected by Xmaxima; that seems like a somewhat more general problem.  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:40 Message: Logged In: YES user_id=501686 Some changes have been committed to src/plot.lisp recently which might address this problem. I have already retested on Linux and behavior is unchanged. Need to verify on Windows.  Comment By: Volker van Nek (van_nek) Date: 20060610 05:01 Message: Logged In: YES user_id=1269745 Robert, I want to be more precise concerning the last point. If I type in wgnuplot set term dumb pl [0:1] x the dumb plot appears in the wgnuplot console itself. In a batch process this is not possible, because the in batch mode the gnuplot console doesn't pop up. I wonder why it works in Linux. It seems that gnuplot itself behaves different in Windows and Linux and so we need a slightly different conception for dumb plotting with gnuplot from Maxima. Practically a Windows user must define an out file to get the dumb plot. So the else clause in (if gnuplotoutfile must return an error message.  Comment By: Volker van Nek (van_nek) Date: 20060610 02:00 Message: Logged In: YES user_id=1269745 Here Robert, here is what i have written to the mailing list yesterday. this is specially for Windows. 1. terminal 'dumb' already works in Windows console maxima plot2d( sin(x), [x,0,2*%pi], [gnuplot_term,dumb], [gnuplot_out_file, "D:/test.txt"] ); > dumb plot Remark: The dumb plot character is $, with using gnuplot directly it is a *. Reason? 2. with xmaxima system("type D:/test.txt"); > NO dumb plot (from the formerly created file) system("type D:\\test.txt"); > NO dumb plot 3. with console maxima and xmaxima printfile("D:/test.txt"); > dumb plot 4. plot.lisp lines 1122 ... ($dumb (if gnuplotoutfile ;;($system (format nil $viewtext_command viewfile)) ($printfile viewfile) ;; fix ;;($system (format nil "~a \"~a\"" $gnuplot_command file)))))) ;; should be replaced by (merror ... ) (print (format nil "~a \"~a\"" $gnuplot_command file)))))) ;; for testing which WORKS in console maxima and xmaxima plot2d( sin(x), [x,0,2*%pi], [gnuplot_term,dumb], [gnuplot_out_file, "D:/test.txt"] ); > dumb plot 5. plot2d( sin(x), [x,0,2*%pi], [gnuplot_term,dumb] ); > "wgnuplot \"C:/Dokumente und Einstellungen/van Nek/maxout.gnuplot\"" system("wgnuplot \"C:/Dokumente und Einstellungen/van Nek/maxout.gnuplot\""); doesn't work, because maxout.gnuplot misses a line for the out file (set out 'myfile') Suggestion: If [gnuplot_term,dumb] is set, there should be an error message if there is no output file. Volker  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1502633&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:37:52

Bugs item #789048, was opened at 20030814 21:00 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789048&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: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: allroots issues (doc and precision) Initial Comment: The documentation doesn't say to what precision allroots calculates its argument: in fact, it gives full floatingpoint precision (even if the arguments are rats or bfloats). allroots is advertised as "find[ing] all the ...roots of the real polynomial..." In fact it works on real AND complex polynomials, but requires that the coefficients all be explicit numbers (which is not stated). The following get errors: allroots(xsqrt(2)) => ALLROOTS: not a polynomial allroots(x%pi) => ** error while printing ERROR message ** ALLROOTS: polynomial not univariate: ~M Shouldn't allroots simply float its argument? allroots((x  1)^10) gets answers about 20% off because it multiplies out the expression before looking for roots. Shouldn't alreadyfactored expressions be left that way? (I am not sure what the right answer is to that, by the way  perhaps it is more uniform to expand them all as floatingpoint polynomials?) In any case, this should be documented.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789048&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:36:21

Bugs item #788892, was opened at 20030814 13:05 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788892&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeroa handled inconsistently Initial Comment: zeroa (zero+infinitesimal) and zerob (zeroinfinitesimal) are not documented, but they are $symbols, and thus available to the user. They should either be documented, or made into internal symbols. If they are documented, they need to be better supported. Most parts of Maxima don't know about zeroa on input, and as far as I know, no part of Maxima uses zeroa for user output (but see bug 774065), so I would suggest making them internal. The symbols zeroa and zerob (without dollarsign) are currently used only in defint.lisp (askgreateq), and that appears to be a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788892&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:35:12

Bugs item #788882, was opened at 20030814 12:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788882&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factcomb issues Initial Comment: factcomb( 4 * (1)! ) gives Quotient by zero error, though factcomb( (1)! ) gives no error, and for that matter there is no way factcomb can combine 4 and ( 1)!. factcomb((1)! / (2)!) gives a floatingpoint exception (floating point???). The doc for factcomb gives the example of factcomb ((N+1)^B*N!^B). First of all, the documentation (both in the Info file and in Describe) is cut off before the matching Dline, which presumably should have (n+1)! ^b. Secondly, factcomb does not in fact perform that combination. I tried loading in the source for combin.lisp to debug, and many of the above examples now return 1 instead of either the error or the correct answer. minfactorial(( 1)! / (2)!) gives Error: The variable *FACTLIST is unbound. Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:35 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs. Does the useful effect of factcomb outweigh its bugs? Instead of fixing it maybe we should just cut it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788882&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:30:09

Bugs item #788360, was opened at 20030813 15:25 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788360&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: algsys a*b=c*d grossly incomplete Initial Comment: algsys([a*b=c*d],[a,b,c,d]) returns [[a = %R2*%R3/%R1,b = %R1,C = %R2,d = %R3]] This is missing some of the solutions where one or both of a and b is zero and one or both of c and d is zero. The complete list of these solutions is: [[a=0,b=%r1,c=0,d=%r2], [a=0,b=%r3,c=%r4,d=0], [a=%r5,b=0,c=0,d=%r6], [a=%r7,b=0,c=%r8,d=0]] The first two are subsumed by the original solution as long as b # 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788360&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:29:57

Bugs item #783847, was opened at 20030805 18:35 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=783847&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: assignments to %i, inf, ... Initial Comment: Maxima allows assignments to %i, inf, ind, and und. An assignments to %i is especially troublesome (C1) %i : 42; (D1) 42 (C2) %i^2; (D2) 1764 The fix is to give $ind and $und the sysconst property. (The fix is mostly due to Stavros.) Thus change (simp.lisp) (evalwhen (load) (MAPC #'(LAMBDA (X) (MPUTPROP X T '$CONSTANT) (PUTPROP X T 'SYSCONST)) '($%PI $%I $%E $%PHI $INF $MINF $INFINITY %I $%GAMMA))) to (evalwhen (load) (MAPC #'(LAMBDA (X) (MPUTPROP X T '$CONSTANT) (PUTPROP X T 'SYSCONST)) '($%PI $%I $%E $%PHI $INF $MINF $INFINITY %I $%GAMMA $ind $und))) Additionally, I think it would be okay to give $unknown, $pos, $neg, $zero, $pz, $nz, $pn, and $pnz the sysconst property. Now disallow assignments to sysconsts by changing mset to (mlisp.lisp) to (DEFUN MSET (X Y) (declare (object y x)) (PROG NIL (COND ((OR (NULL $SETCHECK) (EQ $SETCHECK '$SETCHECK))) ((AND (OR (ATOM $SETCHECK) (MEMALIKE X (CDR $SETCHECK)) (AND (NOT (ATOM X)) (MEMALIKE (CAAR X) (CDR $SETCHECK)))) (NOT (EQ X Y))) (DISPLA (LIST '(MTEXT) (DISP2 X) ' set to  Y)) (IF $SETCHECKBREAK (LET (($SETVAL Y)) (MERRBREAK T) (SETQ Y $SETVAL))))) (COND ((ATOM X) (WHEN (OR (NOT (SYMBOLP X)) (MEMQ X '(T NIL)) (MGET X '$NUMER) (char= (GETCHARN X 1) #\&) (get x 'sysconst)) ;; prevent assignments to system consts (IF MUNBINDP (RETURN NIL)) (IF (MGET X '$NUMER) (MERROR "~:M improper value assignment to a numerical quantity" X) (MERROR "~:M improper value assignment" X))) (LET ((F (GET X 'ASSIGN))) (IF (AND F (OR (NOT (EQ X Y)) (MEMQ F '(NEVERSET READ ONLYASSIGN)))) (IF (EQ (FUNCALL F X Y) 'MUNBINDP) (RETURN NIL)))) (COND ((AND (NOT (BOUNDP X)) (NOT DSKSETP)) (ADD2LNC X $VALUES)) ((AND (NOT (EQ X Y)) (OPTIONP X)) (IF $OPTIONSET (MTELL "~:M option is being set.~%" X)) (IF (NOT (EQ X '$LINENUM)) (ADD2LNC X $MYOPTIONS)))) (RETURN (SET X Y))) ((MEMQ 'ARRAY (CDAR X)) (RETURN (ARRSTORE X Y))) ((AND $SUBSCRMAP (MEMQ (CAAR X) '(MLIST $MATRIX))) (RETURN (OUTERMAP1 'MSET X Y))) (T (MERROR "Improper value assignment:~% ~M" X))))) After the fixes (C1) load("mset.x86f"); (D2) mset.x86f (C3) und : 13; UND improper value assignment  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C4) inf : 34; INF improper value assignment  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C5) %i : 1; %I improper value assignment  an error. Quitting. To debug this try DEBUGMODE (TRUE);) Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:29 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030812 09:59 Message: Logged In: YES user_id=588346 I would suggest putting sysconst on T and NIL and getting rid of the separate test (memq x '(t nil)). That is more uniform  TRUE and FALSE are sysconsts like everything else. As for putting sysconst on pz, nz, pn, etc., I am not sure. If they were long and specific names (nonneg, nonpos, nonzero, etc.), I wouldn't have any problem. But twoletter names are just too useful  since subscripts like p[z] have a specific meaning in Maxima, it is common to use pz to mean things like potential sub z or whatever. Moreover, there is no good reason to be evaluating these symbols  tests should be e.g. if sign(x)='pz (though I know many people don't bother to quote). So to be uniform, I argue AGAINST making pz, nz, pz, and pnz (and for uniformity, pos and neg) into sysconsts.  Comment By: Raymond Toy (rtoy) Date: 20030807 09:14 Message: Logged In: YES user_id=28849 Very nice! I'll apply this shortly, with the additional symbols you mentioned.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=783847&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:26:08

Bugs item #783284, was opened at 20030804 22:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=783284&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: lratsubst and fullratsubst don't autoload Initial Comment: lratsubst and fullratsubst are documented as though they were part of the core system  documentation does not say that they have to be loaded explicitly. But they are not set up for autoloading. They should autoload from share/simplification/lrats.mac. Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:26 Message: Logged In: YES user_id=501686 Documentation for fullratsubst and lratsubst states (since probably sometime last year) that they need to be loaded from lrats.mac. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=783284&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:12:32

Bugs item #782099, was opened at 20030802 15:29 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=782099&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  Limit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit returns expression in IND Initial Comment: limit(sinh(exp(%i*x)),x,inf) => (%E^IND%E^IND)/2 should be just IND This may be related to limit(%e^ind) not giving IND.  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:12 Message: Logged In: YES user_id=501686 See also bug report # 1515430 und not propagated through functions.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=782099&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 18:02:24

Bugs item #782046, was opened at 20030802 12: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=782046&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  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(abs(x),x,0) fails Initial Comment: limit(abs(x),x,0) returns noun form, even though limit knows the limit for x>inf and x>minf. This really seems like too trivial a case to fail on. There does appear to be code in limit.lisp (bothside) to handle the zero case by looking at the pluslimit and the minuslimit, but (a) it is not being invoked and (b) it looks incomplete  it doesn't know how to interpret IND nor how to return it. So this really is a bug and not a feature request. Maxima 5.9.0  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:02 Message: Logged In: YES user_id=501686 Observed in 5.9.3 / clisp 2.34 but not in 5.9.3cvs / clisp 2.38, gcl 2.6.7, and sbcl 0.9.9. Apparently fixed by r1.20 src/limit.lisp which applies limit from both sides to expressions involving MABS. Added a test for limit(abs(x),x,0) to r1.41 tests/rtest15.mac. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=782046&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 17:45:08

Bugs item #781788, was opened at 20030801 16:16 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781788&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: scalar/matrix addition inconsistent Initial Comment: I claim that componentwise addition of scalars to matrices is wrong. By default, doallmxops=true. Define m:matrix([a,b],[c,d]). Calculate ratsimp(m.m^^1+m). This yields matrix ([a+1,b],[c,d+1]). Good. Now calculate subst(m,n,n.n^^1+n). This yields matrix ([a+1,b+1],[c+1,d+1]). I believe this is wrong. Note that this happens even when dotident is not equal to 1. Only if dotexptsimp=false (which is a pretty radical restriction) does the subst case match the nonsubst case. As far as I can tell, the only sensible thing for scalar+matrix to mean is scalar*identitymatrix + matrix. I do not believe that componentwise addition of scalar to matrix is ever useful; if it is, you can always write it as scalar*allonesmatrix + matrix. Note that scalar/matrix *multiplication* is a completely different matter  componentwise is perfectly meaningful and useful there. Maxima 5.9.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781788&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 17:30:12

Bugs item #781726, was opened at 20030801 14:45 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781726&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with IEEEfloat NaN and INF Initial Comment: flinf: 2.0^1024$ flinf => Error: Can't print a nonnumber (lisp break) Should print something special, e.g. INFe0 flnan: flinfflinf$ flnan => Bind stack overflow (lisp break) Should print something special, e.g. NaNe0 is(flnan=flnan) => TRUE NO! NaN is not equal to itself; cf ?=(flnan,flnan). is(flnan>0) => TRUE NO! is(flnan<0) => TRUE NO! flnan*0 => 0 NO! flinf*0 => 0 NO! GCL also can't print flnan/flinf. Maxima 5.9.0 gcl 2.5.0 mingw Windows 2000 Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 11:30 Message: Logged In: YES user_id=501686 Clisp does not recognize floating point INF and NAN; those 2 values cannot be produced or recognized by Clisp's floating point implementation (which is all software for greater portability). So I can't see any way, short of modifying Clisp, for Maxima to accomodate INF and NAN in a way that is workable across Lisp implementations. We could probably convince the GCL team to modify GCL to handle INF and NAN; that seems a lesser challenge than getting Clisp modified.  Comment By: Robert Dodier (robert_dodier) Date: 20050626 17:11 Message: Logged In: YES user_id=501686 In reference to the examples given in the original writeup, it is worth pointing out that GCL does indeed compute inf and nan; it just can't display them. Clisp refuses to compute the inf or nan, and there doesn't appear to be a way to compel it to do so. CMUCL is happy with inf and nan after :lisp (extensions::setfloatingpointmodes :traps nil) is executed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781726&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 17:23:39

Bugs item #781657, was opened at 20030801 12:30 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&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 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) >Summary: binomial(x,x) => 1, but binomial(1,1) => 0 Initial Comment: binomial(x,x) simplifies to 1 yet binomial(1,1) simplifies to 0. (C1) binomial(x,x); (D1) 1 (C2) binomial(1,1); (D2) 0 I agree with (d2) because: 1/(1  x) = 1 + x + x^2 + ... = sum(binomial(1,k) (x) ^k,k,0,inf) implies binomial(1,k) = (1)^k, for integers k >= 0. In the recursion relation [Knuth Vol 1, 1.2.6 Eq. (20)] binomial(r,k) = binomial(r1,k) + binomial(r1,k1) set r > 0, k > 0, and use binomial(0,0) = 1 and binomial (1,0) = 1. From this we get binomial(1,1) = 0. Also see, Knuth Vol. 1 (third edition), Section 1.2.6 Exercise 9. There may be other approaches, but I think using the recursion relations and other identities to extend the domain of the binomial function is the best method. In short, I think the simplification binomial(x,x) ==> 1 should happen only for real x with x >= 0. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 11:23 Message: Logged In: YES user_id=501686 If, and from the comments it appears it is not certain, we want to make special cases for binomial, we might get the desired effect by using an unevaluated conditional. E.g. stuff like binomial(x, x) > if x = 1 then 0 elseif realp(x) and x > 0 then 1 else 'binomial(x, x). Just a thought.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20030821 22:16 Message: Logged In: YES user_id=581700 Unless I am mistaken, the (finite) limit of BINOMIAL(x,y) at some latticepoint (a,b) in Z^2 exists if and only if a >= 0. The "if" part is easy: Just write the binomial as GAMMA(x+1)/(GAMMA(y+x+1)*GAMMA(y+1)) and observe that Gamma is certainly continuous in the open right halfplane while 1/Gamma is continuous everywhere. Now assume a <= 1. We have the following identity (for the proof see the Maxima code below) %PI*BINOMIAL(x1,y)*BINOMIAL(x,y)*y = SIN(%PI*y)*SIN(%PI*(xy))/SIN(%PI*x) We have a1 >= 0, so we already know that lim BINOMIAL(x1,y) for (x,y)>(a,b) exists. If lim BINOMIAL(x,y) also existed, lim of the whole left hand side expression of this identity would exist. Now, looking at the right hand side expression we observe that it is Zperiodic with respect to x and y (except for a possible sign change). So lim of it at (a,b) exists if and only if lim of it at (0,0) exists, which is clearly not the case. Note: Strictly speaking, the identity is valid on, say, the complement of the union of the parallels through latticepoints to the first and second axis and to the median of the first quadrant, but this leaves us with enough space :) Nevertheless, of course, it's quite customary to define BINOMIAL(a,b)=a*(a1)* ... *(ab+1)/b! for all a in R and b in Z with b >= 0 (for b=0 the numerator is an empty product), in accordance with the binomial series. This definition happens to coincide with limit(limit(BINOMIAL(x,y),y,b),x,a). matchdeclare([%%u,%%v],true)$ sum_is_1(u,v):=is(u+v = 1)$ let(gamma(%%u)*gamma(%%v),%pi/sin(%pi*%%u),sum_is_1,%%u,%%v); let(%%v/gamma(%%u),1/gamma(%%v),sum_is_1,%%u,%%v); letrat:true; lhs:%pi*y*binomial(x,y)*binomial(x1,y); makegamma(%); letsimp(%); letsimp(%); num(%)/trigexpand(expand(denom(%))); lhs=%;  Comment By: Stavros Macrakis (macrakis) Date: 20030814 10:16 Message: Logged In: YES user_id=588346 I am not sure what you mean by "there may be other approaches". binomial(a,a) should simplify to Q if and only if the double limit exists: limit binomial(x,y) = Q x>a y>a A necessary (but in general not sufficient) condition for this to exist is that the two single limits exist and are equal: limit binomial(a,y) = limit binomial(x,a) = Q y>a x>a If the limit is not welldefined, then binomial(x,x) is not well defined, and it will cause incorrect results in some case or another to arbitrarily set it to some value. I don't know if this limit is or isn't welldefined. I do know that depending on identities with unspecified domains of validity is dangerous....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 17:14:27

Bugs item #777564, was opened at 20030725 08:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=777564&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: subtraction ""(a,b) should work/FIX Initial Comment: Currently, the "" operator is defined as unary internally. However, it appears to the user as a binary operator as well. That is, the user can write "ab". Since the operator appears to be binary on the surface, it should also function as a binary operator in other contexts, in particular, I often want to do things like map("",foo,bar) or makelist(op(a,b),op,["+","","*"]) So mminus should be defined to work as a binary function  or perhaps even nary, where ""(a,b,c,...) == abc... That aligns the internal semantics with the surface syntax.  Comment By: Stavros Macrakis (macrakis) Date: 20030804 22:18 Message: Logged In: YES user_id=588346 Revised fix (DEFUN SIMPMIN (X VESTIGIAL Z) VESTIGIAL ;Ignored (COND ((null (cdr x)) 0) ; 0ary is OK, too ((NUMBERP (CADR X)) (MINUS (CADR X))) ;; Line below commented out because it might inhibit pattern matching sm 8/2003 ;; ((ATOM (CADR X)) (LIST '(MTIMES SIMP) 1 (CADR X))) ((null (cddr x)) (SIMPLIFYA (LIST '(MTIMES) 1 (SIMPLIFYA (CADR X) Z)) T)) (t (sub (cadr x) (addn (cddr x) z)))))  Comment By: Stavros Macrakis (macrakis) Date: 20030804 22:15 Message: Logged In: YES user_id=588346 Here's the fix. (DEFUN SIMPMIN (X VESTIGIAL Z) VESTIGIAL ;Ignored (IF (NULL (CDR x)) (WNAERR (CAAR L))) (COND ((NUMBERP (CADR X)) (MINUS (CADR X))) ;; Line below commented out because it might inhibit pattern matching sm 8/2003 ;; ((ATOM (CADR X)) (LIST '(MTIMES SIMP) 1 (CADR X))) ((null (cddr x)) (SIMPLIFYA (LIST '(MTIMES) 1 (SIMPLIFYA (CADR X) Z)) T)) (t (sub (cadr x) (addn (cddr x) z))))) PS The makelist example above shouldn't use the symbol 'op', which is a defined function...!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=777564&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 17:13:17

Bugs item #776441, was opened at 20030723 12:25 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&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: 7 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, s<q<r<s. The problem is somewhere in the internal great function, which by the way does some strange things, in particular: why does ordlist have an explicit check for mplus: (RETURN (COND ((= L2 0) (EQ CX 'MPLUS)) (Thanks to Barton for his contributions to tracking this down.) Maxima 5.9.0 GCL 2.5.0  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 11:13 Message: Logged In: YES user_id=501686 Increasing the priority on this one  potential for subtle breakage in various contexts.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20030808 17:50 Message: Logged In: YES user_id=581700 This one doesn't even involve MEXPT (I found it while checking one of the cases needed for proving that ORDLIST implements a consistent way of extending a given total order on a set of simplified expressions to their simplified sums and products. So it doesn't...) (C1) orderlessp(t/2,t); (D1) TRUE (C2) orderlessp(t,t+1/4); (D2) TRUE (C3) orderlessp(t/2,t+1/4); (D3) FALSE The point is that t/2 is ((MTIMES SIMP) ((RAT SIMP) 1 2) $t) and, lexicographically, we have (t, 1/2) < (t, 1), (t, 0) < (t, 1/4) and (t, 1/2, *) > (t, 1/4, +). So t corresponds to (t, 1) in the first comparison and to (t, 0) in the second comparison. Trouble. Floats instead of rational numbers give the same results, by the way. This one is more like Stavros's examples. (C1) orderlessp((x+1)^2,x^21); (D1) TRUE (C2) orderlessp(x^21,x^2); (D2) TRUE (C3) orderlessp((x+1)^2,x^2); (D3) FALSE Maybe powers whose exponents are positive integers should be treated like products. Actually, ORDMEXPT does this already but it isn't always called by ORDFN, for whatever reason. Anyway, here is the patch I'm currently experimenting with (it solves all the issues reported by Stavros and also the last example above, but in light of the other example it is certainly far from being a complete solution. It might even be totally wrong since I have no reason to believe that it is more than a simple palliative and that it would make things more consistent). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: simp.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/simp.lisp,v retrieving revision 1.5 diff C2 r1.5 simp.lisp *** simp.lisp 5 Mar 2003 01:36:26 0000 1.5  simp.lisp 8 Aug 2003 19:10:57 0000 *************** *** 1848,1854 **** ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT) (MPLUSP (CADR Y))) (NOT (ORDMEXPT Y X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X)))  1848,1854  ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT)) (NOT (ORDMEXPT Y X))) + ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  Comment By: Stavros Macrakis (macrakis) Date: 20030804 22:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+srqs => (x+1)^2+x^2+x*(x+2)(x+1)^2x^2x* (x+2) expand(%,0,0) => x^2x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long  presumably it has been around for 30+ years.  Comment By: Stavros Macrakis (macrakis) Date: 20030725 08:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)(q+s+r) => x^2x^2 (q+s+r)(s+q+r) => x^2x^2 (q+r+s)(q+s+r) => x (x + 2)  x (x + 2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 17:09:04

Bugs item #772283, was opened at 20030716 07:12 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=772283&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 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: warnings from aload_mac Initial Comment: The function $aload_mac (defined in autol.lisp) has several unused parameters. Under cmucl, executing aload_mac gives warnings (C1) factorfacsum(x,x); In: LAMBDA (FILE &AUX *LOADVERBOSE* TEM TRIED) (LET ((IN FILE) ($SYSTEM #)) (DECLARE (SPECIAL $SYSTEM)) (SETQ TEM ($FILE_SEARCH1 FILE '#)) (AND TEM ($LOAD TEM))) ==> (COMMONLISP:LET ((IN FILE) ($SYSTEM #)) (DECLARE (SPECIAL $SYSTEM)) (SETQ TEM ($FILE_SEARCH1 FILE '#)) (AND TEM ($LOAD TEM))) Note: Variable IN defined but never used. #'(LAMBDA (FILE &AUX *LOADVERBOSE* TEM TRIED) (BLOCK $ALOAD_MAC (LET # # # #))) Note: Variable TRIED defined but never used. (D1) x (C2) quit(); The $aload_mac function is (defun $aload_mac (file &aux *loadverbose* tem tried) (let ((in file) ($system (list '(mlist) #+kcl (concatenate 'string si::*systemdirectory* "../ {src,share,share1,sharem}/foo.{mc,mac}")))) (declare (special $system)) (setq tem ($file_search1 file '((mlist) $FILE_SEARCH_MAXIMA $system))) (and tem ($load tem)))) I don't understand everything in this function, so I maybe missing something, but (defun $aload_mac (file &aux *loadverbose* tem tried) (declare (ignore tem tried)) ($load ($file_search1 file `((mlist) $file_search_maxima)))) might be a start for a replacement to aload_mac. When the file isn't found, $file_search1 halts with an error. I don't think (and tem ($load tem)) is needed. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 11:09 Message: Logged In: YES user_id=501686 At some point post5.9.1, IN and TRIED were cut, so factorfacsum(x,x); no longer triggers the warnings shown above. It is doubtless possible to further clean up $ALOAD_MAC but that doesn't seem important enough for a bug report. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=772283&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 16:48:26

Bugs item #770794, was opened at 20030713 23: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=770794&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: dot expansion inconsistent Initial Comment: ma: matrix([a11,a12],[a21,a22])$ mb: matrix([b11,b12],[b21,b22])$ ma.mb => multiplied out (OK)  call it mab q.ma.mb => q.mab (OK) but ma.mb.q => ma.mb.q  that is, ma.mb doesn't get multiplied out. This is inconsistent, since "." is known to be associative (dotassoc = true).  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 10:48 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=770794&group_id=4933 
From: SourceForge.net <noreply@so...>  20060708 16:47:14

Bugs item #770258, was opened at 20030712 13:38 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=770258&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: redefining builtin functions (binom) Initial Comment: This is a documentation issue, an error message issue, and a semantics issue.... binom() is defined as an alias for binomial(), but this is not mentioned in the documentation. I wanted to use binom for the explicit form (in terms of factorials) and when I said binom(a,b):=... was surprised to get Warning  you are redefining the MACSYMA command BINOMIAL This redefines the verb form, but not the noun form, so if you now enter binom(2,x), you get back binomial(2,x), and NOT 2/((2x)!*x!). You can only get that using ev (...,binomial) or by explicitly using verbify(binomial). This is all rather unintuitive. I think that more "natural" ways to do things would be either: 1) forbid redefining builtins; or 2) when they're redefined, remove their simplification properties etc. and have them operate like normal functions; or 3) at least remove the alias which makes it function as the noun form on input  >Comment By: Robert Dodier (robert_dodier) Date: 20060708 10:47 Message: Logged In: YES user_id=501686 I'm inclined to recommend (2) and (3) because (1) conflicts with Maxima's general laissezfaire attitude.  Comment By: Raymond Toy (rtoy) Date: 20030729 09:10 Message: Logged In: YES user_id=28849 For option 1, perhaps we can use the package locks that are available in Clisp and (CVS) CMUCL. This will cause a (Lisp) error to occur on redefining symbols in the Maxima package.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=770258&group_id=4933 