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