You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

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

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

19
(15) 
20

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

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

31
(30) 





From: SourceForge.net <noreply@so...>  20060711 05:28:07

Bugs item #881461, was opened at 20040121 08:49 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=881461&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: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Ronis (ronis) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails on maxima CVS Initial Comment: I've been folowing maxima via CVS for years. Recently, something has broken; maxima builds and the testsuite runs fine. However make install dies with: Making install in src make[1]: Entering directory `/home/ronis/Project/notar/maxima/src' make[2]: Entering directory `/home/ronis/Project/notar/maxima/src' /bin/sh ../mkinstalldirs /usr/local/bin /bin/install c maxima /usr/local/bin/maxima /bin/sh ../mkinstalldirs "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp" /bin/install c m 644 binaryclisp/maxima.mem "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp/maxima.mem" /bin/install c "/usr/local/lib/maxima/5.9.0.1cvs/binaryclisp/lisp.run" /bin/install: too few arguments Try `/bin/install help' for more information. make[2]: *** [installclisp] Error 1 make[2]: Leaving directory `/home/ronis/Project/notar/maxima/src' make[1]: *** [installam] Error 2 make[1]: Leaving directory `/home/ronis/Project/notar/maxima/src' make: *** [installrecursive] Error 1 It looks like configure hasn't found my clisp installation. I'm running slakware9.1  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 23:28 Message: Logged In: YES user_id=501686 I put a note into r1.17 README.lisps saying Lisp type should always be specified to configure. Closing this report as fixed.  Comment By: David Ronis (ronis) Date: 20040121 17:41 Message: Logged In: YES user_id=609364 I figured out the problem. It seems that when you don't pass configure the enableclisp flag, it doesn't initialize the clisp_runtime library (even though it does autodetect clisp). Sounds like a bug, but perhaps not; this was not the behavior in slightly older CVS's. In any event, a comment in the INSTALL file would be in order if this is not a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=881461&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 05:11:17

Bugs item #831445, was opened at 20031027 16:44 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=831445&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: gcd/subres  another case Initial Comment: ratsimp of ((SQRT(3)*%I/21/2)*(SQRT(84541)*%I/(6*SQRT(3)) 11/2)^(1/3)+28*(SQRT(3)*%I/21/2)/(3*(SQRT(84541) *%I/(6*SQRT(3))11/2)^(1/3))+4)^312*((SQRT(3)*% I/21/2)*(SQRT(84541)*%I/(6*SQRT(3))11/2)^(1/3) +28*(SQRT(3)*%I/21/2)/(3*(SQRT(84541)*%I/ (6*SQRT(3))11/2)^(1/3))+4)^2+20*((SQRT(3)*%I/2 1/2)*(SQRT(84541)*%I/(6*SQRT(3))11/2)^(1/3)+28* (SQRT(3)*%I/21/2)/(3*(SQRT(84541)*%I/(6*SQRT (3))11/2)^(1/3))+4)+59 gives "quotient by zero" for gcd = subres, red, or algebraic; and an infinite loop (or at least is taking a very long time) for mod. spmod and ez work. Maxima 5.9.0 gcl 2.5.0  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 23:11 Message: Logged In: YES user_id=501686 Same behavior in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20031027 16:46 Message: Logged In: YES user_id=588346 By the way, all the gcd algorithms work correctly with algebraic:true (not the default).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=831445&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 05:03:42

Bugs item #831354, was opened at 20031027 14:45 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=831354&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: beta(2,1) inconsistent Initial Comment: beta(2, 1) => 1/2 beta(2.0, 1) => 0.5 BUT beta(2.0, 1.0) => 0.25 The fundamental problem is that beta(x,y) is undefined as a continuous real function of both x and y at (2,1), but that beta(x,1) can be extended to be a well behaved continuous function of x, namely 1/x. This is essentially the same case as x^y at (0,0). Right now, Maxima simplifies x^0=>1 and 0^x=>0 (just like beta(x,1)). The difference is that Maxima gives an error for 0^0, 0.0^0, etc. Longerterm, it would be nice if 0^x kept as a side condition (x # 0) of the simplification, but for now....  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 23:03 Message: Logged In: YES user_id=501686 Same behavior observed in 5.9.3cvs. About simplifying 0^x to 'if x # 0 then 0 else 1, that is certainly workable with unevaluated conditionals, see share/contrib/boolsimp/ for a proposed implementation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=831354&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:57:55

Bugs item #831163, was opened at 20031027 10:25 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=831163&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: part(x) should give warning Initial Comment: part(x) returns x. This is of course perfectly consistent (the null case), but it is certainly an error if actually input this way. True, it might be useful in the case apply(part,cons (expression,specifier)), where specifier is an argument, possibly the empty list, but using apply this way is somewhat unclean. I would prefer that there be an explicit form of part where the specifier is a list. The problem with that solution, of course, is that we'd then need corresponding versionf of substpart, inpart, substinpart. Yecch. For now, I would recommend giving a warning message for this case. It would be nice if there could, however, be only one such warning per interaction. I don't think we do anything like that right now.  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:57 Message: Logged In: YES user_id=501686 Same behavior in 5.9.3cvs. FWIW I don't see anything wrong here. part(x) => x is OK by me  laissez faire et laissez passer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=831163&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:49:17

Bugs item #826915, was opened at 20031020 08:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826915&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Solve wrong with irreducible polydecomp Initial Comment: poly: x^5+x3$ polypoly: subst(d2,x,d2); => (x^5+x3)^5+x^5+x6 solve(polypoly,x) => [0 = x^5+15*x^490*x^3+270*x^2406*x+249] This is incorrect. It is specifying the solutions of the outer composed polynomial (polydecomp), not the composition as a whole  that said, I don't think there is any notation in Maxima for specifying the composition of implicit solutions. Maxima 5.9.0 gcl 2.5.0  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:49 Message: Logged In: YES user_id=501686 Same behavior in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826915&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:40:34

Bugs item #826623, was opened at 20031019 22:25 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826623&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplifer returns %i*%i Initial Comment: ((%i)^(1/2)*%i)*((%i)^(1/2)) => %i*%i Resimplifying  expand(%,0,0)  correctly returns 1. Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:40 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20031019 23:55 Message: Logged In: YES user_id=588346 This may be related to the inconsistent simplification of simple expressions involving %i: Mathematically, %i^(1/4) = (%i)^(1/4), but the first simplifies to (1)^(1/8) and the second to (%i)^(1/4) . Mathematically, (1)^(1/4) = %i^(1/2) = (%i)^(1/2), but the first two simplify to 1/(1)^(1/4), while the third simplifies to sqrt(%i). There are other similar cases. This is also reminiscent of the the nonnormalization of 1/sqrt(2)  bug # 721575.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=826623&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:38:46

Bugs item #820770, was opened at 20031009 11:40 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820770&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: plog(x^2) => 2*log(x) Initial Comment: Plog is advertised as the principal branch of the complexvalued natural logarithm with %PI < CARG(X) <= +%PI This sounds very useful, and presumes that the regular 'log' function represents something other than the principal branch  perhaps all branches as a multivalued function? But plog(x^2) simplifies to 2*log(x) (after asking whether x is nonzero). This simplification is incorrect for x=1. The main meaning of plog appears to be that it will *carry out* the logarithm when the imagpart is a multiple of %pi/4. makelist([log(x),plog(x)],x,[1,%i,1+%i,%i*2,2+%i]) => [[0,0], [LOG(%I), %I*%PI/2 ], [LOG(%I+1), LOG(2)/2+%I*%PI/4 ], [LOG(2*%I), LOG(2)+%I*%PI/2 ], [LOG(%I+2), PLOG(%I+2) ] ] And the only use of plog within Maxima is by defint. I am not even sure that defint actually needs plog (as opposed to plain log)  maybe it is some sort of vestige?  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:38 Message: Logged In: YES user_id=501686 Same behavior in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820770&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:36:31

Bugs item #820188, was opened at 20031008 13:46 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820188&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Simplifying inf and minf Initial Comment: The general simplifier currently treats the various non standard objects (inf, minf, und, ind, infinity) as though they were ordinary variables. This leads to incorrect results (infinf => 0, inf*0 => 0), incomplete simplification (inf^3 doesn't simplify, though inf is always correct), and noncanonical representations (minf doesn't simplify to inf). It also seems to me that minf should be represented uniformly as inf, not as a special case. Specialcasing these objects in the general simplifier will add a very small overhead to all simplifications. The case that reminded me of this problem is abs(minf) =>minf.  Comment By: Stavros Macrakis (macrakis) Date: 20040321 14:10 Message: Logged In: YES user_id=588346 More problematic cases with inverse functions: asin(sin(inf)) => inf This should either not simplify, or give IND (if it is clever) or UND (if it is less clever). but exp(log(inf)) => inf tan(atan(inf)) => inf and the like are OK (by accident, but, hey!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820188&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:35:03

Bugs item #817567, was opened at 20031003 22:44 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817567&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor/poly leaves common factors Initial Comment: ff: factor(x^22,8*q^4q*q^2+1) => (16*x64*q^2+32)*(16*x+64*q^232)/256 Of course, this can be simplified with another pass of ordinary factorization: factor(ff) => (x4*q^2+2)*(x+4*q^22) A simpler example, but perhaps suspect because it uses q in the polynomial to factor: factor(xq,2*q^2+1) => (2*x2*q)/2  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:34 Message: Logged In: YES user_id=501686 5.9.3cvs yields (%i10) ff: factor(x^22,8*q^4q*q^2+1) ; (%o10) x^22 Not sure what the right result is here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817567&group_id=4933 
From: SourceForge.net <noreply@so...>  20060711 04:01:56

Bugs item #817557, was opened at 20031003 21:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817557&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: To be reviewed >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve/numer spurious polarform Initial Comment: solve(x^21,x),numer => [x=%E^(3.14*%i), x=%E^(6.28*%i)] same for solve(x^21.0,x),numer; Why???? Mysteriously, solve(x^2.01.0,x),numer => [x=1.0]  >Comment By: Robert Dodier (robert_dodier) Date: 20060710 22:01 Message: Logged In: YES user_id=501686 I'm informed by Stavros that the polarform is not observed on Windows, too. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:59 Message: Logged In: YES user_id=501686 5.9.3cvs / sbcl, clisp, gcl (all Linux) yield solve(x^21,x),numer; => [x = 1.2246063538223773E16 (%i  8165889364191922), x =  2.4492127076447545E16 (%i  4082944682095961)] so the reported spurious polarform seems to have gone away. Mark this report for verification on Windows  if not observed there we can close this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817557&group_id=4933 