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}
(21) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(4) 
2
(4) 
3
(10) 
4
(13) 
5
(1) 
6
(4) 
7
(2) 
8
(4) 
9
(1) 
10
(3) 
11
(1) 
12
(7) 
13
(6) 
14
(4) 
15
(7) 
16
(2) 
17
(5) 
18

19
(3) 
20

21
(2) 
22

23

24

25
(14) 
26

27
(4) 
28
(2) 
29

30

31

From: SourceForge.net <noreply@so...>  20090117 22:49:33

Bugs item #593530, was opened at 20020810 18:30 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  >Comment By: Stavros Macrakis (macrakis) Date: 20090117 16:56 Message: I don't see the point of quoting the documentation at length. Clearly zeroequiv is approximate and not guaranteed to determine whether the expression is 0 or not in all cases. However, this does not excuse flagrantly bad cases like zeroequiv(xatan(x),x). Also, the fact that zeroequiv is "not used for incore functions" is not relevant. Zeroequiv is a documented part of the system, and is not working as documented, or as a reasonable user would expect it to work. The fact that *you* have decided not to fix it is not relevant. Perhaps someone else will. Reverting to status=open.  Comment By: Dieter Kaiser (crategus) Date: 20090117 16:14 Message: The documentation of zeroequiv says: "zeroequiv has these restrictions: Do not use functions that Maxima does not know how to differentiate and evaluate. If the expression has poles on the real line, there may be errors in the result (but this is unlikely to occur). If the expression contains functions which are not solutions to first order differential equations (e.g. Bessel functions) there may be incorrect results. The algorithm uses evaluation at randomly chosen points for carefully selected subexpressions. This is always a somewhat hazardous business, although the algorithm tries to minimize the potential for error." The documentation takes into account that zeroequiv can have problems. The function is not used for in core functions. Only one application in code which is not documented can be found. Setting resolution to "wont fix" and the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090101 19:08 Message: These are the actual results for the given examples: (%i16) zeroequiv(xatan(x),x); (%o16) dontknow (%i17) zeroequiv(sin(1/1000),x); (%o17) false (%i18) zeroequiv(sin(asin(x)+1/1000)x,x); (%o18) false (%i19) zeroequiv(sin(x+1/1000)sin(x),x); (%o19) true (%i20) zeroequiv(atan(x)^1000,x); (%o20) false (%i17) and (%i18) now give false, (%i20) no longer gives an internal error but the answer false. I think (%i19) should give the answer false too. Within the Maxima project I have found only two calls to zeroequiv in the file share/calculus/qual.mac. This package does a qualitative analysis of functions. I have not found any reference to the functions of qual.mac in the Maxima documentation and I have not found a call to the functions of qual.mac. zeroequiv does not work perfectly, but this is not expected even by the documentation in the Maxima manual. I think at this time it is not worth to improve the function zeroequiv, because there seems to be no important code which depends on the function. To close the bug report I would like to suggest the following options: (1) Closing the bug report without any change. (2) Cutting out the function from the Maxima manual. (3) Moving the code to share/calculus/qualsp.lisp. Perhaps we should close the related bug report SF[626760] "zeroequiv extremely slow (minor)" too.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 13:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20090117 22:46:50

Bugs item #626760, was opened at 20021022 04:19 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626760&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeroequiv extremely slow (minor) Initial Comment: expr: LOG(x^2+SQRT(2)*x+1) LOG(x^2SQRT(2)*x+1) +2*ATAN((2*x+SQRT(2))/SQRT(2)) +2*ATAN((2*xSQRT(2))/SQRT(2)) +SQRT(2)*LOG(x+1) SQRT(2)*LOG(x1) 2*SQRT(2)*ATAN(1/x)$ zeroequiv(expr,x) takes over a minute, though it is not at all subtle how nonzero it is: rectform(expr),numer, ..., x=0.1 => 3.314.44i ..., x=0.9 => 6.394.44i ..., x=1.1 => 7.38 ..., x=1.5 => 6.38 ..., x=20 => 6.28 Zeroequiv is really supposed to be quick and dirty....  >Comment By: Stavros Macrakis (macrakis) Date: 20090117 16:49 Message: In Maxima 5.15, the original expression (but in lower case) takes 0.02 sec and correctly gives false. zeroequiv(LOG(1),x) correctly gives dontknow and returns instantaneously since Maxima function names are now lowercase (unlike in 2002 when the bug report was submitted). Closing as fixed.  Comment By: Dieter Kaiser (crategus) Date: 20090117 16:35 Message: This bug report is related to SF[593530] "Zeroequiv issues". zeroequiv is not used for in core functions. Problems are known and documented. This is the result for the example: (%i9) expr:LOG(x^2+SQRT(2)*x+1)LOG(x^2SQRT(2)*x+1)+2*ATAN((2*x+SQRT(2))/SQRT(2)) +2*ATAN((2*xSQRT(2))/SQRT(2))+SQRT(2)*LOG(x+1) SQRT(2)*LOG(x1)2*SQRT(2)*ATAN(1/x) (%i10) zeroequiv(expr,x); (%o10) dontknow On a Windows system with GCL 2.6.8 and a CPU with 1.8 GHZ we get (%i11) for i:1 thru 100000 do zeroequiv(expr,x); Evaluation took 15.8900 seconds (15.8900 elapsed) (%o11) done One call to zeroequiv needs about 16/100,000 seconds. Setting resolution to "wont fix" and status to pending. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626760&group_id=4933 
From: SourceForge.net <noreply@so...>  20090117 22:46:24

Bugs item #626760, was opened at 20021022 10:19 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626760&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeroequiv extremely slow (minor) Initial Comment: expr: LOG(x^2+SQRT(2)*x+1) LOG(x^2SQRT(2)*x+1) +2*ATAN((2*x+SQRT(2))/SQRT(2)) +2*ATAN((2*xSQRT(2))/SQRT(2)) +SQRT(2)*LOG(x+1) SQRT(2)*LOG(x1) 2*SQRT(2)*ATAN(1/x)$ zeroequiv(expr,x) takes over a minute, though it is not at all subtle how nonzero it is: rectform(expr),numer, ..., x=0.1 => 3.314.44i ..., x=0.9 => 6.394.44i ..., x=1.1 => 7.38 ..., x=1.5 => 6.38 ..., x=20 => 6.28 Zeroequiv is really supposed to be quick and dirty....  >Comment By: Dieter Kaiser (crategus) Date: 20090117 22:35 Message: This bug report is related to SF[593530] "Zeroequiv issues". zeroequiv is not used for in core functions. Problems are known and documented. This is the result for the example: (%i9) expr:LOG(x^2+SQRT(2)*x+1)LOG(x^2SQRT(2)*x+1)+2*ATAN((2*x+SQRT(2))/SQRT(2)) +2*ATAN((2*xSQRT(2))/SQRT(2))+SQRT(2)*LOG(x+1) SQRT(2)*LOG(x1)2*SQRT(2)*ATAN(1/x) (%i10) zeroequiv(expr,x); (%o10) dontknow On a Windows system with GCL 2.6.8 and a CPU with 1.8 GHZ we get (%i11) for i:1 thru 100000 do zeroequiv(expr,x); Evaluation took 15.8900 seconds (15.8900 elapsed) (%o11) done One call to zeroequiv needs about 16/100,000 seconds. Setting resolution to "wont fix" and status to pending. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626760&group_id=4933 
From: SourceForge.net <noreply@so...>  20090117 22:43:48

Bugs item #887639, was opened at 20040130 15:45 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: listarray when use_fast_arrays : true Initial Comment: Outputs (D2) and (D4) are okay. But the list (D6) should not contain 'true'. (C1) a[0] : 1$ (C2) listarray(a); (D2) [1] (C3) use_fast_arrays : true$ (C4) listarray(a); (D4) [1] (C5) b[0] : 1$ (C6) listarray(b); (D6) [TRUE, 1] (C7) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  >Comment By: Dieter Kaiser (crategus) Date: 20090117 23:01 Message: The suggested change to skip over the element (dim1 t) in a hashtable for an undeclared fast array is checked in. The further problems of the post dated to 20040203 in this thread are related to a missing type and range check for the indices when use_fast_arrays:true. This is not part of the original bug report. Code to do the type and range checking is suggested on the mailing list. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090103 19:22 Message: The error in this bug report is caused by the function (defun makeequalhashtable (notdim1) (let ((table (makehashtable :test 'equal))) (or notdim1 (setf (gethash 'dim1 table) t)) table)) This function adds for a onedimensional array the pair (dim1 t) to the hashtable. Every time we look into the hashtable we have to take care of this extra element. This is not done in the function listarray. A correction would be: ((hashtablep ary) (let (vals (tab ary)) (declare (special vals tab)) (maphash #'(lambda (x &rest l) l (unless (eq x 'dim1) (push (gethash x tab) vals))) ary) (reverse vals))) Now the function skip the value with the key DIM1. To get it even more analog to a listarry for a normal array I have further introduced a call to the Lisp function rerverse. Now the array elements are in the expected order too. This are the results for an onedimensional fast array (I have used only numbers as a key, but every value would be possible): (%i6) use_fast_arrays:true$ (%i7) a[1]:1$ (%i8) listarray(a); (%o8) [1] (%i9) a[10]:10$ (%i10)listarray(a); (%o10) [1,10] We put two strings between the numbers and get again the expected order: (%i11) a[5]:"Auto"$ (%i13) a[6]:"Baum"$ (%i14) listarray(a); (%o14) [1,"Auto","Baum",10] With the proposed fix onedimensional fast arrays and listarray will work as expected. This does not solve the further problems reported in the last post. Remark: The value (dim1 t) is only used at two places. Especially the dimension check in the function arrstore in mlisp.lisp does not seem to be very useful. Because we have a hashtable this simple implementation might cause more problems. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20040203 00:12 Message: Logged In: YES user_id=588346 use_fast_arrays:true has lots of problems: use_fast_arrays: false$ a: [1,2]$ a[3]$ => error OK a[3]: 5$ => error OK a[1,1] => error OK Now compare with the use_fast_arrays: true case. use_fast_arrays: true$ b: [1,2]$ b[3] => error OK b[3]: 5$ => no error ??? b[3] => error ??? b => [1,2] ??? setting b[3] didn't give an error, but has no effect on b c[1]: 5$ c => #<hashtable 234234234> (ridiculous internal thingy prints out) limit(c,x,inf) => internal error, limit doesn't know about arrays d[1,1]:5$ d[1] => false ????  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&group_id=4933 
From: SourceForge.net <noreply@so...>  20090117 21:14:54

Bugs item #593530, was opened at 20020811 00:30 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Zeroequiv issues Initial Comment: Zeroequiv gives Dontknow for xatan(x) This function is wellbehaved and numerically nonzero for abs(x)>1.0e8. The following give True: sin(1/1000) !!! (no variable) sin(asin(x)+1/1000)x sin(x+1/1000)sin(x) This gets an internal error (stack overflow): atan(x)^1000  >Comment By: Dieter Kaiser (crategus) Date: 20090117 22:14 Message: The documentation of zeroequiv says: "zeroequiv has these restrictions: Do not use functions that Maxima does not know how to differentiate and evaluate. If the expression has poles on the real line, there may be errors in the result (but this is unlikely to occur). If the expression contains functions which are not solutions to first order differential equations (e.g. Bessel functions) there may be incorrect results. The algorithm uses evaluation at randomly chosen points for carefully selected subexpressions. This is always a somewhat hazardous business, although the algorithm tries to minimize the potential for error." The documentation takes into account that zeroequiv can have problems. The function is not used for in core functions. Only one application in code which is not documented can be found. Setting resolution to "wont fix" and the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090102 01:08 Message: These are the actual results for the given examples: (%i16) zeroequiv(xatan(x),x); (%o16) dontknow (%i17) zeroequiv(sin(1/1000),x); (%o17) false (%i18) zeroequiv(sin(asin(x)+1/1000)x,x); (%o18) false (%i19) zeroequiv(sin(x+1/1000)sin(x),x); (%o19) true (%i20) zeroequiv(atan(x)^1000,x); (%o20) false (%i17) and (%i18) now give false, (%i20) no longer gives an internal error but the answer false. I think (%i19) should give the answer false too. Within the Maxima project I have found only two calls to zeroequiv in the file share/calculus/qual.mac. This package does a qualitative analysis of functions. I have not found any reference to the functions of qual.mac in the Maxima documentation and I have not found a call to the functions of qual.mac. zeroequiv does not work perfectly, but this is not expected even by the documentation in the Maxima manual. I think at this time it is not worth to improve the function zeroequiv, because there seems to be no important code which depends on the function. To close the bug report I would like to suggest the following options: (1) Closing the bug report without any change. (2) Cutting out the function from the Maxima manual. (3) Moving the code to share/calculus/qualsp.lisp. Perhaps we should close the related bug report SF[626760] "zeroequiv extremely slow (minor)" too.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 19:05 Message: Logged In: YES user_id=501686 Maxima 5.9.3: Same behavior observed for each example. zeroequiv seems to be a hack. If we don't fix it (which could be a pretty serious investment), maybe we should cut it. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593530&group_id=4933 
From: SourceForge.net <noreply@so...>  20090116 19:45:07

Bugs item #783847, was opened at 20030806 02:35 Message generated for change (Comment added) made by crategus 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: Closed >Resolution: Fixed Priority: 5 Private: No 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: Dieter Kaiser (crategus) Date: 20090116 20:44 Message: The suggested test is added. Assignment to a symbol which is declared to be a SYSCONST is prevented. Closing the bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090114 00:37 Message: The assignment of values to system constants (%i, %pi, ...) is still possible. The constants $inf, $minf, $und, $ind, $infinity t and nil have been given the property SYSCONST in file simp.lisp (rev.1.34, 2.4.2007). But the proposed additional check against a SYSCONST in the function mset in the file mlist.lisp has not been added. The change would be (when (or (not (symbolp x)) (member x '(t nil) :test #'eq) (mget x '$numer) (get x 'sysconst)) ; Do not allow assignment of a SYSCONST With this additional check it would be no longer possible to assign a value to a system constant and the bug report could be closed. I am wondering why this test is not added. The testsuite would have no problems Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060708 20:29 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030812 17: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 17: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...>  20090116 19:14:34

Bugs item #1055377, was opened at 20041027 17:25 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1055377&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: 3 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: assignment to SETVAL causes a break if SETCHECK: ALL Initial Comment: The user can intercept an assignment by means of SETCHECK, SETCHECKBREAK, and SETVAL. If SETCHECK: ALL, every assignment is intercepted and a message is printed. If SETCHECKBREAK: TRUE, a break prompt is given as well. The user can change the assignment in midstream by assigning to SETVAL; that new value replaces the original assignment. All this works as expected, with one strangeness: the SETVAL assignment itself is intercepted, with a message printed and a break prompt. Exiting from this nested break prompt takes the user back to the original break prompt. I guess the solution is to have the code (mset in mlisp.lisp) pass over the assignment if the variable in question is SETVAL. The observed behavior is confusing, but yields the correct result (i.e., the original assignedto variable is given a different assignment). Maxima version: 5.9.1 Maxima build date: 21:24 9/23/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19a  >Comment By: Dieter Kaiser (crategus) Date: 20090116 20:14 Message: The suggested additional check has been checked out. Closing the bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090114 23:40 Message: This is the code with an additional check which makes sure that the code does not do an extra break when setting $setval: (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)) ;; We do not break when setting $setval itself (if (and $setcheckbreak (not (eq x '$setval))) ; added test (let (($setval y)) (merrbreak t) (setq y $setval))))) With this additional test the strange behavior of this bug report vanish and the bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1055377&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 18:40:36

Bugs item #2501765, was opened at 20090112 11:36 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2501765&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((14*x^232)/(x^4+3*x^2+1)^2,x,0,inf); Initial Comment: integrate((14*x^232)/(x^4+3*x^2+1)^2,x,0,inf); produces a division by zero error. Maxima ought to be able to do this integral. And maxima can do the indefinite integral, producing a rational expression and another integral. Maxima can compute that definite integral.  >Comment By: Dan Gildea (dgildea) Date: 20090115 13:40 Message: Fix in solve.lisp rev 1.22 gives correct multiplicity of roots. (%i6) integrate((14*x^232)/(x^4+3*x^2+1)^2,x,0,inf); (%o6) (sqrt(3sqrt(5))*(139*sqrt(2)*sqrt(5)+345*sqrt(2))*%pi +sqrt(sqrt(5)+3)*(345*sqrt(2)139*sqrt(2)*sqrt(5))*%pi) /200 (%i7) float(%); (%o7) 14.47111834594389 (%i8) quad_qags((14*x^232)/(x^4+3*x^2+1)^2,x,0,1000); (%o8) [14.47111834594389,1.179685737489548e9,441,0]  Comment By: Raymond Toy (rtoy) Date: 20090114 08:46 Message: I think this fails because maxima computes the multiplicities of the roots of the denominator incorrectly. The roots are double roots, but maxima thinks they're single and hence gets a division by zero error when trying to compute the residue by differentiating the denominator once instead of twice. See also https://sourceforge.net/tracker2/?func=detail&aid=2505241&group_id=4933&atid=104933  Comment By: Raymond Toy (rtoy) Date: 20090112 12:01 Message: Maxima is using a keyhole contour and is computing the residues of the integrand. I think Maxima doesn't notice that the poles are multiple poles, and just uses the simple method of computing the residue by differentiating the denominator. This produces a division by zero.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2501765&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 18:35:30

Bugs item #2505241, was opened at 20090113 14:20 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve multiplicities wrong Initial Comment: This is right: (%i543) solve((x^2+2*x+1)^7,x); (%o543) [x =  1] (%i544) multiplicities; (%o544) [14] But this is wrong: (%i545) solve((y^4+3*y^2+1)^7,y)$ (%i546) multiplicities; (%o546) [1, 1, 1, 1] Each root has multiplicity 7, not 1. In solve.lisp, after easycases, there is a comment from Barton about commenting out some code dealing with multiplicities. Not sure if this would fix the problem, or what the actual problem is in the comment.  >Comment By: Dan Gildea (dgildea) Date: 20090115 13:35 Message: In solve.lisp rev 1.22, pass multiplicity parameter through easycases to solve. (%i2) solve((x^2+2*x+1)^7,x); (%o2) [x = 1] (%i3) multiplicities; (%o3) [14] (%i4) solve((y^4+3*y^2+1)^7,y)$ (%i5) multiplicities; (%o5) [7,7,7,7] I didn't touch the commented code.  Comment By: Barton Willis (willisbl) Date: 20090115 06:26 Message: Also after uncommenting, the code in solve.lisp I commented out in 2004, the testsuite reports two problems: Error found in c:\maximacvs3\maxima\tests\rtest15.mac, problem: (137) Error found in c:\maximacvs3\maxima\tests\rtestint.mac, problem: (45)  Comment By: Barton Willis (willisbl) Date: 20090115 06:11 Message: I wish that my comment had more details. I tried uncommenting the codethen (%i1) solve((x^2+2*x+1)^7,x)$ Wrong, but previously correct. (%i2) multiplicities; (%o2) [2] Wrong: (%i3) solve((y^4+3*y^2+1)^7,y)$ (%i4) multiplicities; (%o4) [1, 1, 1, 1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 11:26:55

Bugs item #2505241, was opened at 20090113 13:20 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve multiplicities wrong Initial Comment: This is right: (%i543) solve((x^2+2*x+1)^7,x); (%o543) [x =  1] (%i544) multiplicities; (%o544) [14] But this is wrong: (%i545) solve((y^4+3*y^2+1)^7,y)$ (%i546) multiplicities; (%o546) [1, 1, 1, 1] Each root has multiplicity 7, not 1. In solve.lisp, after easycases, there is a comment from Barton about commenting out some code dealing with multiplicities. Not sure if this would fix the problem, or what the actual problem is in the comment.  >Comment By: Barton Willis (willisbl) Date: 20090115 05:26 Message: Also after uncommenting, the code in solve.lisp I commented out in 2004, the testsuite reports two problems: Error found in c:\maximacvs3\maxima\tests\rtest15.mac, problem: (137) Error found in c:\maximacvs3\maxima\tests\rtestint.mac, problem: (45)  Comment By: Barton Willis (willisbl) Date: 20090115 05:11 Message: I wish that my comment had more details. I tried uncommenting the codethen (%i1) solve((x^2+2*x+1)^7,x)$ Wrong, but previously correct. (%i2) multiplicities; (%o2) [2] Wrong: (%i3) solve((y^4+3*y^2+1)^7,y)$ (%i4) multiplicities; (%o4) [1, 1, 1, 1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 11:11:44

Bugs item #2505241, was opened at 20090113 13:20 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve multiplicities wrong Initial Comment: This is right: (%i543) solve((x^2+2*x+1)^7,x); (%o543) [x =  1] (%i544) multiplicities; (%o544) [14] But this is wrong: (%i545) solve((y^4+3*y^2+1)^7,y)$ (%i546) multiplicities; (%o546) [1, 1, 1, 1] Each root has multiplicity 7, not 1. In solve.lisp, after easycases, there is a comment from Barton about commenting out some code dealing with multiplicities. Not sure if this would fix the problem, or what the actual problem is in the comment.  >Comment By: Barton Willis (willisbl) Date: 20090115 05:11 Message: I wish that my comment had more details. I tried uncommenting the codethen (%i1) solve((x^2+2*x+1)^7,x)$ Wrong, but previously correct. (%i2) multiplicities; (%o2) [2] Wrong: (%i3) solve((y^4+3*y^2+1)^7,y)$ (%i4) multiplicities; (%o4) [1, 1, 1, 1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 05:34:42

Bugs item #2508928, was opened at 20090115 00:34 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=2508928&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([a+5/6,a+7/3],[2*a+23/3],4*z*(1z)) fails Initial Comment: This returns a result with false in the result. The error comes from HYPCOS. The arguments, a+11/6, a+7/3, 2*(a+11/6)+1, are correct for HYPCOS but HYPCOS fails to find the correct expression and returns NIL.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2508928&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 04:48:40

Bugs item #2508877, was opened at 20090114 23:48 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=2508877&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: 2 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: simp2f1willcontinuein Initial Comment: There are many cases where Maxima will print SIMP2F1WILLCONTINUEIN. hgfred([a,a+1/2],[3/2],x) is one such expression. This is a reminder that Maxima doesn't know how to reduce this to some other form. But A&S 15.2.4 can reduce 3/2 to 1/2, and Maxima knows what hgfred([a,a+1/2],[1/2],x) is when a is a positive integer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2508877&group_id=4933 
From: SourceForge.net <noreply@so...>  20090115 01:06:38

Bugs item #2505945, was opened at 20090113 21:24 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505945&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: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) >Assigned to: Raymond Toy (rtoy) Summary: hgfred([2,1/2],[3],x^2); Initial Comment: (%i45) hgfred([2,1/2],[3],x^2); 1 Enter hgfred[[2,1/2],[3],x^2] Nonvariable 2nd argument to diff: x^2 But hgfred([2,1/2],[3],x) doesn't give an error.  >Comment By: Raymond Toy (rtoy) Date: 20090114 20:06 Message: Fixed in hyp.lisp, rev 1.93. We don't try differentiating wrt to a nonvariable anymore.  Comment By: Raymond Toy (rtoy) Date: 20090114 08:51 Message: FWIW, this is a bug in the code. It's using A&S 15.2.4 to transform F(a,b;c;z) to F(a,b;cn;z): F(a,b;cn;z) = 1/poch(cn,n)/z^(cn1)*diff(z^(c1)*F(a,b;c;z), ,z,n)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505945&group_id=4933 
From: SourceForge.net <noreply@so...>  20090114 22:40:56

Bugs item #1055377, was opened at 20041027 17:25 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1055377&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: Open Resolution: None Priority: 3 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: assignment to SETVAL causes a break if SETCHECK: ALL Initial Comment: The user can intercept an assignment by means of SETCHECK, SETCHECKBREAK, and SETVAL. If SETCHECK: ALL, every assignment is intercepted and a message is printed. If SETCHECKBREAK: TRUE, a break prompt is given as well. The user can change the assignment in midstream by assigning to SETVAL; that new value replaces the original assignment. All this works as expected, with one strangeness: the SETVAL assignment itself is intercepted, with a message printed and a break prompt. Exiting from this nested break prompt takes the user back to the original break prompt. I guess the solution is to have the code (mset in mlisp.lisp) pass over the assignment if the variable in question is SETVAL. The observed behavior is confusing, but yields the correct result (i.e., the original assignedto variable is given a different assignment). Maxima version: 5.9.1 Maxima build date: 21:24 9/23/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19a  >Comment By: Dieter Kaiser (crategus) Date: 20090114 23:40 Message: This is the code with an additional check which makes sure that the code does not do an extra break when setting $setval: (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)) ;; We do not break when setting $setval itself (if (and $setcheckbreak (not (eq x '$setval))) ; added test (let (($setval y)) (merrbreak t) (setq y $setval))))) With this additional test the strange behavior of this bug report vanish and the bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1055377&group_id=4933 
From: SourceForge.net <noreply@so...>  20090114 13:51:22

Bugs item #2505945, was opened at 20090113 21:24 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505945&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([2,1/2],[3],x^2); Initial Comment: (%i45) hgfred([2,1/2],[3],x^2); 1 Enter hgfred[[2,1/2],[3],x^2] Nonvariable 2nd argument to diff: x^2 But hgfred([2,1/2],[3],x) doesn't give an error.  >Comment By: Raymond Toy (rtoy) Date: 20090114 08:51 Message: FWIW, this is a bug in the code. It's using A&S 15.2.4 to transform F(a,b;c;z) to F(a,b;cn;z): F(a,b;cn;z) = 1/poch(cn,n)/z^(cn1)*diff(z^(c1)*F(a,b;c;z), ,z,n)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505945&group_id=4933 
From: SourceForge.net <noreply@so...>  20090114 13:46:58

Bugs item #2501765, was opened at 20090112 11:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2501765&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((14*x^232)/(x^4+3*x^2+1)^2,x,0,inf); Initial Comment: integrate((14*x^232)/(x^4+3*x^2+1)^2,x,0,inf); produces a division by zero error. Maxima ought to be able to do this integral. And maxima can do the indefinite integral, producing a rational expression and another integral. Maxima can compute that definite integral.  >Comment By: Raymond Toy (rtoy) Date: 20090114 08:46 Message: I think this fails because maxima computes the multiplicities of the roots of the denominator incorrectly. The roots are double roots, but maxima thinks they're single and hence gets a division by zero error when trying to compute the residue by differentiating the denominator once instead of twice. See also https://sourceforge.net/tracker2/?func=detail&aid=2505241&group_id=4933&atid=104933  Comment By: Raymond Toy (rtoy) Date: 20090112 12:01 Message: Maxima is using a keyhole contour and is computing the residues of the integrand. I think Maxima doesn't notice that the poles are multiple poles, and just uses the simple method of computing the residue by differentiating the denominator. This produces a division by zero.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2501765&group_id=4933 
From: SourceForge.net <noreply@so...>  20090114 02:24:48

Bugs item #2505945, was opened at 20090113 20:24 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=2505945&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([2,1/2],[3],x^2); Initial Comment: (%i45) hgfred([2,1/2],[3],x^2); 1 Enter hgfred[[2,1/2],[3],x^2] Nonvariable 2nd argument to diff: x^2 But hgfred([2,1/2],[3],x) doesn't give an error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505945&group_id=4933 
From: SourceForge.net <noreply@so...>  20090113 23:37:04

Bugs item #783847, was opened at 20030806 02:35 Message generated for change (Comment added) made by crategus 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 Private: No 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: Dieter Kaiser (crategus) Date: 20090114 00:37 Message: The assignment of values to system constants (%i, %pi, ...) is still possible. The constants $inf, $minf, $und, $ind, $infinity t and nil have been given the property SYSCONST in file simp.lisp (rev.1.34, 2.4.2007). But the proposed additional check against a SYSCONST in the function mset in the file mlist.lisp has not been added. The change would be (when (or (not (symbolp x)) (member x '(t nil) :test #'eq) (mget x '$numer) (get x 'sysconst)) ; Do not allow assignment of a SYSCONST With this additional check it would be no longer possible to assign a value to a system constant and the bug report could be closed. I am wondering why this test is not added. The testsuite would have no problems Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060708 20:29 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030812 17: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 17: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...>  20090113 19:20:35

Bugs item #2505241, was opened at 20090113 14:20 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=2505241&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve multiplicities wrong Initial Comment: This is right: (%i543) solve((x^2+2*x+1)^7,x); (%o543) [x =  1] (%i544) multiplicities; (%o544) [14] But this is wrong: (%i545) solve((y^4+3*y^2+1)^7,y)$ (%i546) multiplicities; (%o546) [1, 1, 1, 1] Each root has multiplicity 7, not 1. In solve.lisp, after easycases, there is a comment from Barton about commenting out some code dealing with multiplicities. Not sure if this would fix the problem, or what the actual problem is in the comment.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2505241&group_id=4933 
From: SourceForge.net <noreply@so...>  20090113 14:12:35

Bugs item #2440077, was opened at 20081217 08:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2440077&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: pepo pintus (pepox) Assigned to: Nobody/Anonymous (nobody) Summary: plot3d error Initial Comment: hi, sorry for my bad english! I write to report an error in maxima 5.16.36 on macbook pro with processor intel! to my following code plot3d ([cos(x)*(3 + y*cos(x/2)), sin(x)*(3 + y*cos(x/2)),y*sin(x/2)], [x, %pi, %pi], [y, 1, 1], ['grid, 50, 15]); maxima answers Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value #(3.141592653589793 1.0 0.0 3.015928947446201 1.0 0.0 2.8902652413026093 1.0 0.0 2.7646015351590174 1.0 0.0 2.6389378290154255 1.0 0.0 2.5132741228718336 1.0 0.0 (.......) is not of type (COMMONLISP:ARRAY DOUBLEFLOAT). Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. ps: I haven't problem with plot2d! thanks, bye.  >Comment By: Raymond Toy (rtoy) Date: 20090113 09:12 Message: The issue with plot3d doesn't exist in current Maxima. Marking as pending/fixed. If you have problems compiling maxima, as on the mailing list.  Comment By: Raymond Toy (rtoy) Date: 20081222 15:40 Message: Mac OS 10.4 on ppc or x86? But that shouldn't matter if you already have a working version of cmucl. Just download the maxima sources and compile it yourself. That should work. If it doesn't compile, we want to know.  Comment By: pepo pintus (pepox) Date: 20081222 15:33 Message: I can't install 5.17 because I have tiger! How I can do to install cmucl on my mac os 10.4? thanks  Comment By: Raymond Toy (rtoy) Date: 20081222 12:04 Message: I can reproduce this on 5.16.3, with CMUCL. It's been fixed in 5.17. Please upgrade if possible.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2440077&group_id=4933 
From: SourceForge.net <noreply@so...>  20090113 14:06:41

Bugs item #2494349, was opened at 20090108 14:14 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2494349&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: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Peter Mller (rafpeterm) Assigned to: Nobody/Anonymous (nobody) Summary: solve(e^y  y = 0, y) solves to y = e Initial Comment: Hi, I think the result for solve(e^y  y = 0, y) is wrong. maxima outputs y = e, instead of [], because the expression is simply wrong (e^y  y can never be null). What do you think about it?  >Comment By: Raymond Toy (rtoy) Date: 20090113 09:06 Message: This doesn't appear to be a problem with current Maxima. Marking as pending/fixed.  Comment By: Nobody/Anonymous (nobody) Date: 20090108 22:42 Message: For me solve(e^yy=0,y) returns [y = e]. solve(exp(y)y=0,y) returns [y = %e]. I will try the current maxima version as I'm using an old one as I noticed: Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20090108 14:30 Message: First, did you mean to use %e instead of e? Second solve(e^yy=0,y) returns [y = e^y] for me, not [y = e]. The result isn't really wrong, just not very useful. solve is not very smart.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2494349&group_id=4933 
From: SourceForge.net <noreply@so...>  20090113 14:04:50

Bugs item #2504519, was opened at 20090113 08:14 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2504519&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong display Initial Comment: does anybody why all those "9999999" appear ? (%i14) s^4+3.3*s^3+25.94*s^2+85.1*s; (%o14) s^4+3.3*s^3+25.94*s^2+85.09999999999999*s change the 8 to 5 or lower and it will disappear. best regards  >Comment By: Raymond Toy (rtoy) Date: 20090113 09:04 Message: This is because 85.1 cannot be represented exactly in (IEEE) floating point format. If you want exact numbers use 851/10. This is not a problem with maxima. Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2504519&group_id=4933 
From: SourceForge.net <noreply@so...>  20090113 13:14:17

Bugs item #2504519, was opened at 20090113 13:14 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=2504519&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong display Initial Comment: does anybody why all those "9999999" appear ? (%i14) s^4+3.3*s^3+25.94*s^2+85.1*s; (%o14) s^4+3.3*s^3+25.94*s^2+85.09999999999999*s change the 8 to 5 or lower and it will disappear. best regards  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2504519&group_id=4933 
From: SourceForge.net <noreply@so...>  20090112 22:28:46

Bugs item #2089423, was opened at 20080902 20:02 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2089423&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: laplace(..) with 1D display Initial Comment: In both console and xmaxima mode with display2d:false I get laplace('diff(a(t), t), t, s ); > s * ?%laplace(a(t), t, s )  a(0) instead of the expected s * 'laplace(a(t), t, s )  a(0) Using ilt(..) doesn't cure this display behavior, but desolve(..) does cure this behavior (for some mysterious reason). This is a minor complaint, since I can simply avoid the problem with 2D display, or else start my session with: (%i1) ( display2d:false, desolve('diff(a(t), t) =  b*a(t), a(t ) ) )$ (%i2) laplace('diff(a(t), t), t, s); (%o2) s * 'laplace(a(t), t, s )  a(0) Ted Woollett woollett@... Maxima version: 5.16.1 Maxima build date: 14:34 8/11/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20090112 22:37 Message: NOUN and VERB properties for the functions laplace and ilt are added in rev. 1.10. The linear display now works as expected. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090110 22:42 Message: The function $laplace introduces the symbol %laplace for a noun form. The problem is the $grindfunction. $grind is formating the output for 1Ddisplay. This function handles %symbols as Lisp symbols and put a ?char at the beginning. This is different from the functionality of 2ddisplay. The function makestring remove both % and $chars from the output string. A simple correction would be to put the properties NOUN and VERB on the property list. You can observe this effect very simple: Do first an output with a quote: (%i8) 'laplace('diff(a(t),t),t,s); (%o8) 'laplace('diff(a(t),t),t,s) And then again without a quote: (%i9) laplace('diff(a(t),t),t,s); (%o9) s*'laplace(a(t),t,s)a(0) What has happened is that the first input adds the properties NOUN and VERB to the property list. This is done by the parser. Thus the following input has a correct 1ddisplay output. Thus the correction would be to add the following two lines to the file laplac.lisp: (defprop $laplace %laplace verb) (defprop %laplace $laplace noun) With this change the symbol LAPLACE works like DIFF or INTEGRATE. Remark: The function ilt() shows the same problem. Again the properties NOUN and VERB can be added. The output for the function SPECINT is different again. The reason is that we do not introduce the symbol %SPECINT but return a noun form with the symbol $SPECINT. I think this should be changed to get a more consistent NOUN/VERB behavior. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2089423&group_id=4933 