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}

_{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...>  20090102 18:37:59

Bugs item #1602426, was opened at 20061124 20:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1602426&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: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve([a=b,b=3],[a]) Initial Comment: On Maxima 5.9.3.99rc4 (which I guess is almost identical to 5.10) compiled with sbcl for Ubuntu solve([a=b,b=3],[a]) produces  Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value 2 is not of type LIST. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  I think solve should work also when the number of equations is different from the number of unknowns. Other people have the same problem with different configurations. For example Maxima 5.10.0 + sbcl or clisp. Some people have reported: Maxima 5.10.0 + gcl>"Inconsistent equations" (no Lisp error)  >Comment By: Dieter Kaiser (crategus) Date: 20090102 19:37 Message: No problem with Maxima 5.17post on Windows with GCL 2.6.8 and CLISP 2.44 and Ubuntu with CLISP 2.44. (%i68) solve([a=b,b=3],[a]); (%o68) [] (%i69) solve([a=b,b=3],[a,b]); (%o69) [[a = 3, b = 3]] Closing this bug report. Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20070131 01:19 Message: Logged In: NO i think this is not a bug if b!=3 these equations are inconsistent indeed. guenter  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1602426&group_id=4933 
From: SourceForge.net <noreply@so...>  20090102 18:30:07

Bugs item #1603369, was opened at 20061126 22:41 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1603369&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: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Solve bind stack overflow Initial Comment: solve([product(xi,i,1,20),x=5],x) => bind stack overflow on the other hand, Maxima has no problem with solve([product(xi,i,1,500)],x); Maxima 5.10.0 GCL 2.6.8 Windows  >Comment By: Dieter Kaiser (crategus) Date: 20090102 19:30 Message: It seems that the problem has gone: (%i63) solve([product(xi,i,1,20),x=5],x); (%o63) [[x = 5]] (%i64) solve([product(xi,i,1,200),x=5],x); (%o64) [[x = 5]] Results on Windows XP with GCL 2.6.8, CLISP 2.44 and Ubuntu with CLISP 2.44. Closing the bug report. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1603369&group_id=4933 
From: SourceForge.net <noreply@so...>  20090102 17:31:24

Bugs item #609466, was opened at 20020915 05:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609466&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal error in solve/algsys Initial Comment: solve( [ a^2+b^2+c^21, c*f+b*d+a*b, c*g+b*f+a*c, c*f+b*d+a*b, b^2+d^2+f^21, f*g+d*f+b*c, c*g+b*f+a*c, f*g+d*f+b*c, g^2+f^2+c^21], [a,b,c,d,f,g]) gives "Caught fatal error".  >Comment By: Dieter Kaiser (crategus) Date: 20090102 18:31 Message: This is going on in algsys for the given example (I have added debugging code): (%i17) algebraic:false$ (%i18) solve([a*d+b*c,a+d],[a,b,c,d]); /* The first equation: Maxima gets two solutions */ 2 in CALLSOLVE: call solve with a  c b and var = a : roots = (((MEQUAL SIMP) $A ((MTIMES SIMP RATSIMP) 1 ((MEXPT SIMP) ((MTIMES SIMP) $B $C) ((RAT SIMP) 1 2)))) 1 ((MEQUAL SIMP) $A ((MEXPT SIMP) ((MTIMES SIMP) $B $C) ((RAT SIMP) 1 2))) 1) : fail = NIL /* This is the second equation. This simplifies to 0. Maxima does not find roots. */ 2 2 in CALLSOLVE: call solve with c b  sqrt(b) sqrt(c) and var = b : roots = NIL : fail = (((MEQUAL SIMP) $B $B) 1) : q = ((MEQUAL SIMP) $B $B) : = 0 /* Solve has not found roots, the algorithm now calls the routine CALLAPPRS with a zero argument. This zero argument is passed to the function PUNIVARP which generates a fatal error, because it can handle only lists (Here the code is corrected.) */ CALLAPPRS with 0 `algsys' cannot solve  system too complicated.  an error. To debug this try debugmode(true); This is the same example with the algebraic flag enabled: (%i19) algebraic:true; (%o19) true (%i20) solve([a*d+b*c,a+d],[a,b,c,d]); 2 in CALLSOLVE: call solve with a  c b and var = a : roots = (((MEQUAL SIMP) $A ((MTIMES SIMP RATSIMP) 1 ((MEXPT SIMP) ((MTIMES SIMP) $B $C) ((RAT SIMP) 1 2)))) 1 ((MEQUAL SIMP) $A ((MEXPT SIMP) ((MTIMES SIMP) $B $C) ((RAT SIMP) 1 2))) 1) : fail = NIL /* Now Maxima take another equation and find more solutions */ in CALLSOLVE: call solve with d + sqrt(b) sqrt(c) and var = d : roots = (((MEQUAL SIMP) $D ((MTIMES SIMP RATSIMP) 1 ((MEXPT SIMP) $B ((RAT SIMP) 1 2)) ((MEXPT SIMP) $C ((RAT SIMP) 1 2)))) 1) : fail = NIL /* Maxima calls again with the second root from the first equation */ in CALLSOLVE: call solve with d  sqrt(b) sqrt(c) and var = d : roots = (((MEQUAL SIMP) $D ((MTIMES SIMP RATSIMP) ((MEXPT SIMP) $B ((RAT SIMP) 1 2)) ((MEXPT SIMP) $C ((RAT SIMP) 1 2)))) 1) : fail = NIL (%o20) [[a =  sqrt(%r12 %r13), b = %r12, c = %r13, d = sqrt(%r12) sqrt(%r13)], [a = sqrt(%r14 %r15), b = %r14, c = %r15, d =  sqrt(%r14) sqrt(%r15)]] I have not tried to improve the algorithm, but to understand what is going on. We have two possibilities to correct the Lisp error: (1) Do not call PUNIVARP with a zero argument: (or (and (numberp poly) (= poly 0)) ; Check zero argument (punivarp poly) (merror "`algsys' cannot solve  system too complicated.")) With this correction the algorithm goes on. The result would be an empty list. (2) Add a test to the routine PUNIVARP: (defun punivarp (poly) ;; Test if called with the number zero, return NIL (when (and (numberp poly) (= poly 0)) (returnfrom punivarp nil)) The example above is shown with this correction. ALGSYS returns with an error and displays: `algsys' cannot solve  system too complicated. Perhaps we can add a message like "Try again with algebraic:true". PUNIVARP is only called within the file algsys.lisp. Thus no other code depends directly on a change of PUNIVARP. The testsuite has no problems with both solutions. I think I would prefer the second solution to avoid the Lisp Error. It is not very nice to get the error message for simple equations, but perhaps we can improve the algorithm of algsys later. The following two bugs report the same problem: SF[1663399 ] solve/algsys bug SF[1430379 ] algsys & algebraic == true / FIX Should we correct the Lisp Error and close the related bug reports? Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20070917 21:44 Message: Logged In: YES user_id=588346 Originator: YES An even simpler fatal error: solve([a*d+b*c,a+d],[a,b,c,d]) => Fatal error solve([a*d+b*c,a+d],[a,b,c,d]), algebraic => OK (in 5.13.0)  Comment By: Barton Willis (willisbl) Date: 20060910 14:21 Message: Logged In: YES user_id=895922 These errors don't happen if algebraic == true. We could locally set algebraic to true in solve / algsys, but I doubt that fix the real bug.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 20:19 Message: Logged In: YES user_id=501686 Observed in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20020918 06:09 Message: Logged In: YES user_id=588346 A simpler fatal error. solve([a+b+c=0,a^2+b^2+c^2=1],[a,b,c])  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609466&group_id=4933 
From: SourceForge.net <noreply@so...>  20090102 00:08:51

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: 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: 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 