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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: SourceForge.net <noreply@so...>  20060712 11:14:17

Bugs item #1521112, was opened at 20060712 11: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=1521112&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 Submitted By: Araceli GÃ¡rate GarcÃa (agarate) Assigned to: Nobody/Anonymous (nobody) Summary: To know which are the inconsistent equations Initial Comment: Hi, I have an inconsistent equation system, I need to know which are the inconsistent equations when the linsolve command is used. I know that this is displayed when the flag solve_inconsistent_error is true, but I need to use this information in a program. For example, (%i169) linsolve([a+b=0,a+b=1,a+c=2],[a,c]); Inconsistent equations: (2)  an error. Quitting. To debug this try debugmode(true); (%i170) I need to know that 2 is the inconsistent equation, Is there any way to know that? Thank you Araceli  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521112&group_id=4933 
From: SourceForge.net <noreply@so...>  20060712 09:48:18

Bugs item #1521077, was opened at 20060712 09: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=1521077&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: Open Resolution: None Priority: 5 Submitted By: Araceli GÃ¡rate GarcÃa (agarate) Assigned to: Nobody/Anonymous (nobody) Summary: Minimal requirements Initial Comment: Hi, My master degree thesis is a software based on Maxima. I need to know which are the minimal requirements to run maxima in a pc. Could you help me? Thanks in advance Araceli GÃ¡rate Student of CICESE Research Center  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521077&group_id=4933 
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 
From: SourceForge.net <noreply@so...>  20060710 05:04:56

Bugs item #836773, was opened at 20031105 13:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&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: Share Libraries Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ntrig is broken Initial Comment: (C4) load("ntrig.mac"); (D4) ?C\:\/maxima\/Maxima\/share\/maxima\/5\.9\.0 \/share\/trigonometry\/ntrig\.mac (C5) sin(6*%pi/5); (D5) (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) (C6) float(%); (D6) 0.58778525229247 (C7) sin(float(6*%pi/5)); (D7) 0.58778525229247 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:04 Message: Logged In: YES user_id=501686 Assign category = share libraries.  Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:03 Message: Logged In: YES user_id=501686 Bug shown in original report is fixed by r1.2 share/trigonometry/ntrig.mac, which was made to fix bug report # 1082010 (sign error). Patches proposed here were never applied so far as I can tell. Bug not observed in 5.9.3cvs. Closing this report as fixed.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031116 11:21 Message: Logged In: YES user_id=581700 What about combining the two approaches like this. define_variable (usin_list, block([e1 : (sqrt(5)1)/4, e2 : (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)), e3 : (sqrt(5)+1)/4, e4 : sqrt(sqrt(5)+5)/(2*sqrt(2))], [e1, e2, e3, e4, 1, e4, e3, e2, e1, 0]), any)$ usin(n):= /* MODE_DECLARE treats INTEGER like FIXNUM... */ (mode_declare(n,number), /* Note that this works because MOD is supposed to return an integer in [9, 10] here. Sadly, GCL misbehaves (see bug #706562). Normally, this doesn't matter, however: If the argument of SIN is an integer multiple of %pi/2 the usual simplification routines take care of it, so at this point N won't be a multiple of 5. */ if (n : mod(n, 20)) > 0 then usin_list[n] else usin_list[10+n])$ ucos(n):= usin(5n)$  Comment By: Barton Willis (willisbl) Date: 20031115 12:47 Message: Logged In: YES user_id=895922 I wrote testing code for ntrig; both proposed fixes pass all the tests. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20031110 15:07 Message: Logged In: YES user_id=588346 Please test the following replacement for ntrig. /* Some of these simplifications give results with radicals in the denominator. These could be presimplified here, but ratsimp(...),algebraic:true will also take care of it. */ eval_when([translate,batch,demo,load,loadfile], matchdeclare(n,integerp))$ tellsimpafter(sin(n*%pi/10),usin(n))$ tellsimpafter(cos(n*%pi/10),ucos(n))$ tellsimpafter(tan(n*%pi/10),usin(n)/ucos(n))$ tellsimpafter(cot(n*%pi/10),ucos(n)/usin(n))$ tellsimpafter(sec(n*%pi/10),1/ucos(n))$ tellsimpafter(csc(n*%pi/10),1/usin(n))$ usin_list: makelist( [ 0, (sqrt(5)1)/4, sqrt(2)*(sqrt(5)1)*sqrt(sqrt(5)+5)/8, (sqrt(5)+1)/4, sqrt(sqrt(5)+5)/(2*sqrt(2)), 1] [i], i,[1,2,3,4,5,6,5,4,3,2,1,2,3,4,5,6,5,4,3,2] ) /* In the pre11/2003 version, usin_list[3] was (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)). But the new version is better simplified, and simplifies just as well. */ $ usin(n):= (declare(n,integer), n : remainder(n,20), if n<0 then n:n+20, /* Workaround for bug in remainder */ (if n <= 10 then usin_list[n+1] /* 1origin indexing */ else usin_list[n+1]) )$ ucos(n):=usin(n+5)$  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031107 10:51 Message: Logged In: YES user_id=581700 Perhaps simply rewrite USIN(N):= BLOCK([YUK:mod(N,20)], signum(YUK)*(YUK:abs(mod(YUK,10)), IF YUK=1 THEN (SQRT(5)1)/4 ELSE IF YUK=2 THEN (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) ELSE IF YUK=3 THEN (SQRT(5)+1)/4 ELSE IF YUK=4 THEN SQRT(SQRT(5)+5)/(2*SQRT(2))))$ UCOS(N):= USIN(5N)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 05:04:33

Bugs item #1082010, was opened at 20041209 04:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1082010&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: Share Libraries Group: None Status: Closed >Resolution: Fixed Priority: 5 Submitted By: FrancoB (franco68tn) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in NTRIG.MAC(?) Initial Comment: Wrong values of trigonometric functions. I suppose that there is a bug in "/share/maxima/5.9.1/share/trigonometry/ntrig.mac". Some values of trigonometric functions are wrong after ntrig.mac has been loaded. Try this: kill(all)$ postfix("°")$ x°:=x*%pi/180$ for i: 0 thru 20 do print("sin(",i*18,"°)","=",float(sin (i*18°)))$ for i: 0 thru 20 do print("cos(",i*18,"°)","=",float(cos (i*18°)))$ for i: 0 thru 20 do if not(i = 5 or i = 15) then print("tan (",i*18,"°)","=",float(tan(i*18°))) else print("tan (",i*18,"°) = NOT DEFINED")$ You will see that the output is okay. Now load ntrig.mac and then reexecute the same instructions: load(ntrig)$ for i: 0 thru 20 do print("sin(",i*18,"°)","=",float(sin (i*18°)))$ for i: 0 thru 20 do print("cos(",i*18,"°)","=",float(cos (i*18°)))$ for i: 0 thru 20 do if not(i = 5 or i = 15) then print("tan (",i*18,"°)","=",float(tan(i*18°))) else print("tan (",i*18,"°) = NOT DEFINED")$ and you will see a lot of results (sixteen!) with wrong sign! oooooooooooooooooooo Furthermore, these two commands produce different outputs: <1> kill(all)$ load(ntrig)$ sin(6*%pi/5),numer; yields the correct result (0.58778525229247325), <2> kill(all)$ load(ntrig)$ sin(6*%pi/5); %,numer; yields the wrong result (0.58778525229247325). Best regards, Franco Buratti (Italy) bufranz@...  Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5   >Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:04 Message: Logged In: YES user_id=501686 Assign resolution = fixed.  Comment By: Viktor Toth (vttoth) Date: 20041210 06:11 Message: Logged In: YES user_id=1023504 The reported bug is not present in the current version of cvs. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1082010&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 05:03:41

Bugs item #836773, was opened at 20031105 13:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ntrig is broken Initial Comment: (C4) load("ntrig.mac"); (D4) ?C\:\/maxima\/Maxima\/share\/maxima\/5\.9\.0 \/share\/trigonometry\/ntrig\.mac (C5) sin(6*%pi/5); (D5) (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) (C6) float(%); (D6) 0.58778525229247 (C7) sin(float(6*%pi/5)); (D7) 0.58778525229247 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:03 Message: Logged In: YES user_id=501686 Bug shown in original report is fixed by r1.2 share/trigonometry/ntrig.mac, which was made to fix bug report # 1082010 (sign error). Patches proposed here were never applied so far as I can tell. Bug not observed in 5.9.3cvs. Closing this report as fixed.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031116 11:21 Message: Logged In: YES user_id=581700 What about combining the two approaches like this. define_variable (usin_list, block([e1 : (sqrt(5)1)/4, e2 : (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)), e3 : (sqrt(5)+1)/4, e4 : sqrt(sqrt(5)+5)/(2*sqrt(2))], [e1, e2, e3, e4, 1, e4, e3, e2, e1, 0]), any)$ usin(n):= /* MODE_DECLARE treats INTEGER like FIXNUM... */ (mode_declare(n,number), /* Note that this works because MOD is supposed to return an integer in [9, 10] here. Sadly, GCL misbehaves (see bug #706562). Normally, this doesn't matter, however: If the argument of SIN is an integer multiple of %pi/2 the usual simplification routines take care of it, so at this point N won't be a multiple of 5. */ if (n : mod(n, 20)) > 0 then usin_list[n] else usin_list[10+n])$ ucos(n):= usin(5n)$  Comment By: Barton Willis (willisbl) Date: 20031115 12:47 Message: Logged In: YES user_id=895922 I wrote testing code for ntrig; both proposed fixes pass all the tests. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20031110 15:07 Message: Logged In: YES user_id=588346 Please test the following replacement for ntrig. /* Some of these simplifications give results with radicals in the denominator. These could be presimplified here, but ratsimp(...),algebraic:true will also take care of it. */ eval_when([translate,batch,demo,load,loadfile], matchdeclare(n,integerp))$ tellsimpafter(sin(n*%pi/10),usin(n))$ tellsimpafter(cos(n*%pi/10),ucos(n))$ tellsimpafter(tan(n*%pi/10),usin(n)/ucos(n))$ tellsimpafter(cot(n*%pi/10),ucos(n)/usin(n))$ tellsimpafter(sec(n*%pi/10),1/ucos(n))$ tellsimpafter(csc(n*%pi/10),1/usin(n))$ usin_list: makelist( [ 0, (sqrt(5)1)/4, sqrt(2)*(sqrt(5)1)*sqrt(sqrt(5)+5)/8, (sqrt(5)+1)/4, sqrt(sqrt(5)+5)/(2*sqrt(2)), 1] [i], i,[1,2,3,4,5,6,5,4,3,2,1,2,3,4,5,6,5,4,3,2] ) /* In the pre11/2003 version, usin_list[3] was (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)). But the new version is better simplified, and simplifies just as well. */ $ usin(n):= (declare(n,integer), n : remainder(n,20), if n<0 then n:n+20, /* Workaround for bug in remainder */ (if n <= 10 then usin_list[n+1] /* 1origin indexing */ else usin_list[n+1]) )$ ucos(n):=usin(n+5)$  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031107 10:51 Message: Logged In: YES user_id=581700 Perhaps simply rewrite USIN(N):= BLOCK([YUK:mod(N,20)], signum(YUK)*(YUK:abs(mod(YUK,10)), IF YUK=1 THEN (SQRT(5)1)/4 ELSE IF YUK=2 THEN (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) ELSE IF YUK=3 THEN (SQRT(5)+1)/4 ELSE IF YUK=4 THEN SQRT(SQRT(5)+5)/(2*SQRT(2))))$ UCOS(N):= USIN(5N)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 04:55:43

Bugs item #834813, was opened at 20031102 18:22 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&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: a < b or 1 < 2 wrong Initial Comment: Assume nothing is known about a and b. prederror:true just making sure it is set to the default for the test avoid ev in case ev complicates matters a<b or 1<2 => error ! is(a<b or 1<2) => error ! if (a<b or 1<2) then 5 => error ! prederror:false a<b or 1<2 => unknown ! is(a<b or 1<2) => true (OK) if a<b or 1<2 then 5 => 5 (OK) I believe that (a<b or 1<2) should be returning true in all these cases. Maxima 5.9.0 gcl 2.5.0 Windows 2000  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 22:55 Message: Logged In: YES user_id=501686 Code for unevaluated conditionals (share/contrib/boolsimp/) handles a < or 1 < 2 (also xxx or true, example given below) as expected when prederror = false (which is boolsimp's default mode). Same problems are observed when boolsimp = true, because I wrote boolsimp to have the same behavior as current code when prederror = true. I'd rather just be rid of prederror altogether and have the code always yield what is now yielded when prederror = false.  Comment By: Stavros Macrakis (macrakis) Date: 20031102 18:25 Message: Logged In: YES user_id=588346 Same problem for xxx or true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 04:48:20

Bugs item #834417, was opened at 20031101 23:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834417&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: 3 Submitted By: Luc Maisonobe (maisonobe) Assigned to: Nobody/Anonymous (nobody) Summary: wrong TeX output for indexed variables with exponent Initial Comment: This simple session shows the error: (C1) tex(expand((1+alpha[1])^2)); $$\alpha^2\left(1\right)+2\,\alpha_{1}+1$$ (D1) FALSE Instead of \alpha^2\left(1\right), I would have expected \alpha_{1}^2  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 22:48 Message: Logged In: YES user_id=501686 Example in original report is OK. Here is the 5.9.3 output: (%i1) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ Example shown in comment below still the same: (%i3) tex(f[5](x)^9); $$f_{5}(x)^9$$ I guess that's not quite right, but it seems like a pretty minor bug so I've reduced the priority.  Comment By: Barton Willis (willisbl) Date: 20031115 13:03 Message: Logged In: YES user_id=895922 The file texmexpt.lisp has a possible fix for this bug. (C1) load("l:/texmexpt.lisp")$ (C2) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ (D2) FALSE Here is another problem: Powers of subscripted functions don't TeX with the exponent immediately following the function (C3) f[5](x)^9; (D3) f[5](x)^9 (C4) tex(%); $$f_{5}(x)^9$$ Barton  Comment By: Barton Willis (willisbl) Date: 20031115 13:02 Message: Logged In: YES user_id=895922 The file texmexpt.lisp has a possible fix for this bug. (C1) load("l:/texmexpt.lisp")$ (C2) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ (D2) FALSE Here is another problem: Powers of subscripted functions don't TeX with the exponent immediately following the function (C3) f[5](x)^9; (D3) f[5](x)^9 (C4) tex(%); $$f_{5}(x)^9$$ Barton  Comment By: Barton Willis (willisbl) Date: 20031115 13:01 Message: Logged In: YES user_id=895922 The file texmexpt.lisp has a possible fix for this bug. (C1) load("l:/texmexpt.lisp")$ (C2) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ (D2) FALSE Here is another problem: Powers of subscripted functions don't TeX with the exponent immediately following the function (C3) f[5](x)^9; (D3) f[5](x)^9 (C4) tex(%); $$f_{5}(x)^9$$ Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834417&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:59:31

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: Open Resolution: None 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: 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 
From: SourceForge.net <noreply@so...>  20060710 03:53:13

Bugs item #816808, was opened at 20031002 14:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816808&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: subst(in)part of rat  internal errs Initial Comment: substpart(x,2/3,2) => $x not of type integer It turns out that mformat doesn't change ((rat) 2 3) to ((mquotient) 2 3) as I'd have expected. substinpart does not give an error, but it does give an invalid result: substinpart(x,2/3,2) => ((rat simp) 2 $x) so if you try to manipulate it further, you *then* get an error. substinpart also neglects to simplify rats when the substitution is numeric: substinpart(4,2/3,2) => 2/4 (!!) Maxima 5.9,0 gcl 2.5.0 mingw32 W2k Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:53 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816808&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:49:07

Bugs item #815836, was opened at 20031001 07:19 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=815836&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jaime E. Villate (villate) Assigned to: Nobody/Anonymous (nobody) >Summary: "step" fails for negative values Initial Comment: Using Maxima 5.9.0 (GCL, Debian package 5.9.011), I have tried out a simple "for" loop from 3 to 3, and then the same loop in reverse order from 3 to 3. The second one fails: (C10) x1: 3$ (C11) x2: 3$ (C12) p: 5$ (C13) for x:x1 step (x2x1)/p thru x2 do display(x); x =  3 9 x =   5 3 x =   5 3 x =  5 9 x =  5 x = 3 (D13) DONE (C14) x1: 3$ (C15) x2: 3$ (C16) for x:x1 step (x2x1)/p thru x2 do display(x); (D16) DONE In this second case I had to use a '' that was not necessary in the first case: (C17) for x:x1 step ''(x2x1)/p thru x2 do display(x); x = 3 9 x =  5 3 x =  5 3 x =   5 9 x =   5 x =  3  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:49 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20031002 01:03 Message: Logged In: YES user_id=588346 Yes, the current code for DO foolishly assumes that the step's sign can be determined from the syntactic form of the unevaluated step expression, but it also (peculiarly) re evaluates the step each time around the loop. It also uses the most generic way of comparing things (is), but I suppose that ensures that it will correctly handle fixnums, floats, bfloats, rats, and possible etc.'s. So we have such lovely nonsense as: q:1$ for i : 1 thru 5 step q do print(xxx) ... does nothing because "q" is syntactically positive for i step i thru 10 do print(i) ... prints 1 2 4 8 ... note reevaluation of i each time through for i:1 thru 20 step i*2i do print(i); ... note trick for multiplicative counting for i:1 thru 8 step i*2i do print(i); ... even alternating sign... but why does it end with 16? => 1 ,  2 , 4 ,  8 , 16 assume(u>0,v>0); for i:u step v thru u+10*v do print(i); ... amazing, eh? The solution is to evaluate step exactly once.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=815836&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:45:32

Bugs item #814957, was opened at 20030930 02:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=814957&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Xmaxima >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: No internet => No xMaxima Initial Comment: The windows compiled version of xMaxima refuses to work if a connection to internet is not available and working. A message saying "Error starting Maxima: Could not open a socket" is issued. After that the window xMaxima keeps mute, no prompt, no echo, nothing... If we have no Internet connection how can we keep working with Maxima through the xMaxima interface?  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:45 Message: Logged In: YES user_id=501686 I wonder just how much network stuff needs to be active in order to enable the Maxima <> Xmaxima connection. It seems like just having the network stuff running with the loopback address (127.0.0.1) should be enough. Should be possible to test by shutting down any other interfaces and then trying to launch Xmaxima.  Comment By: Peter Ulrich Kruppa (pukruppa) Date: 20031111 08:26 Message: Logged In: YES user_id=778327 Some of my students have reported this problem to me, too, although everything on my laptop (WinXP Home Edition) works fine  even without internet connection. The only significant difference to their machines, I can think of, is that I once activated XP's compatibility mode for older programs (sorry, I don't know the exact words since I am running XP in german  do search for "compatibility" in the help menu and reinstall maxima with it). Just one possibility. Regards, Uli.  Comment By: Stavros Macrakis (macrakis) Date: 20030930 12:25 Message: Logged In: YES user_id=588346 An active Internet connection is not required by xMaxima. However, you must have sockets installed, working, and enabled, because Maxima uses them for interprocess communication. Firewall software may be closing off sockets, for example.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=814957&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:42:22

Bugs item #812968, was opened at 20030926 03:29 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=812968&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: Joel Ray Holveck (piquan) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(...)) says unknown, ratsimp says 0 Initial Comment: The way I understood EQUAL, it seems that it's supposed to answer true if ratsimp returns true. But in the following equation, it is clear that this is not happening. Sorry about the mess; this was the simplest reproduction scenario I could find. (C112) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2)), (x1)/(2*x*sqrt(2)))); (D112) UNKNOWN (C113) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2)), (x)/(2*x*sqrt(2))1/(2*x*sqrt(2)))); (D113) TRUE (C114) ratsimp(x/(2*x*sqrt(2))  1/(2*x*sqrt(2))  (x1)/(2*x*sqrt(2))); (D114) 0 (C115) facts(); (D115) [NOT EQUAL(x, 0)] I did consider that the problem may be related to the fact that ratsimp simplifies the two sides of the equation differently, so I tried putting them on the same side. In the following, the left side of the equal ratsimp's to 0 (as seen in D114), and yet equal doesn't assert that it's equal to 0. (C130) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2))  (x1)/(2*x*sqrt(2)), 0)); (D130) UNKNOWN I may be missing something obvious here I'm just learning Maxima but this seems off to me.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:42 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 17:44 Message: Logged In: YES user_id=501686 Looking at src/compar.lisp, it appears that the compare and sign functions don't call ratsimp, maybe they should. Hard to tell what's going on in compar.lisp.  Comment By: Stavros Macrakis (macrakis) Date: 20030927 11:58 Message: Logged In: YES user_id=588346 You are absolutely right: this is a bug. Worse, is(equal(1/sqrt(2),sqrt(2)/2)) and even is(equal(1/sqrt (2)sqrt(2)/2,0)) return False! As you say, it should be using ratsimp(1/sqrt(2)sqrt(2)/2)  which does correctly return 0. It is also a known problem (bug?) that 1/sqrt(2) and sqrt(2)/2 do not simplify to the same thing, but as you say, even when you put them on the same side, it doesn't work.... 5.9.0 gcl 2.5.0 W2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=812968&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:38:58

Bugs item #808676, was opened at 20030918 10:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=808676&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: bfloat(1+10^30) rounds wrong with fpprec:20 Initial Comment: fpprec:20$ bfloat(1+10^30)  1; > 3.388...B21 The correct answer is 0.0b0, because bfloat(1+10^30) should round to exactly 1.0b0.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:38 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Raymond Toy (rtoy) Date: 20041123 11:27 Message: Logged In: YES user_id=28849 I think the problem is because it converts the ratio (10^30+1)/10^30 to a bigfloat and doesn't quite round correctly. It's off by one bit. Adding 1b0+1b30 does round correctly and return 1b0 exactly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=808676&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:29:09

Bugs item #801231, was opened at 20030905 10: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=801231&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  Assume Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MAX(a+b,c) is NOT equal to MAX(c,a+b) Initial Comment: (C1) assume(a+b>c)$ (C2) MAX(a+b,c); MAX(c,a+b); (D2) b + a (C3) (D3) MAX(c, b + a) #why it is not simplified ? (C4) is(MAX(a+b,c)=MAX(c,a+b)); (D4) FALSE #why FALSE if must be TRUE ? P.S. Appreciate if you exclude javascripts from the site. Alexander VIDYBIDA vidybida@...  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:29 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Barton Willis (willisb) Date: 20030905 11:46 Message: Logged In: YES user_id=570592 Most likely, this bug is related to the bug (C1) assume(a+b > c); (D1) [ C + b + a > 0] (C2) sign(a+bc); (D2) POS (C3) sign(c(a+b)); (D3) PNZ The result of PNZ (positive, negative, or zero) isn't wrong; however, Maxima should be able to determine that c  (a + b) < 0. That is (d3) should be NEG instead of PNZ. Barton  Comment By: Nobody/Anonymous (nobody) Date: 20030905 11:08 Message: Logged In: NO Comment by A lexander VIDYBIDA vidybida@... Maxima version: 5.9.0 Maxima build date: 19:1 8/5/2003 host type: i586pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.27 (released 20010717) (built 3223390905) (memory 3269088151)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=801231&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:27:06

Bugs item #798571, was opened at 20030901 08:10 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=798571&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) >Summary: sign(sqrt(2)/2  1/sqrt(2)) => zero, pos, neg, or pnz Initial Comment: Depending on the values of fpprec and signbfloat, sign(sqrt(2)/2  1/sqrt(2)) evaluates to zero, pos, neg, or pnz. (C1) display2d : false; (D1) FALSE (C2) a : sqrt(2)/2  1/sqrt(2); (D2) SQRT(2)/21/SQRT(2) (C3) for k : 20 thru 25 do (fpprec : k, print(k,sign(a))); 20 ZERO 21 POS 22 ZERO 23 POS 24 ZERO 25 NEG (D3) DONE (C4) sign(a), signbfloat : true; (D4) NEG (C5) sign(a), signbfloat : false; (D5) PNZ Here is another example  this time sign(p) should evaluate to pos. (C7) p : exp(x)  sum(x^k/k!,k,0,15)$ (C8) p : subst(1/10000001,x,p)$ (C9) sign(p),signbfloat : true; (D9) ZERO (C10) sign(p),signbfloat : false; (D10) PNZ (C11) for k : 20 thru 25 do (fpprec : k, print(k,sign (p))); 20 POS 21 NEG 22 NEG 23 ZERO 24 POS 25 ZERO (D11) DONE (C12) Additionally, signbfloat isn't documented (C17) describe("signbfloat"); (D17) FALSE Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:27 Message: Logged In: YES user_id=501686 The p : exp(x)  sum(x^k/k!,k,0,15)$ etc stuff is still present in 5.9.3cvs. Now sqrt(2)/2  1/sqrt(2) simplifies to 0, so that one has gone away. Incrementing the priority since sign problems are pervasive and important.  Comment By: Stavros Macrakis (macrakis) Date: 20031019 23:57 Message: Logged In: YES user_id=588346 About the specific case of sqrt(2)/2  1/sqrt(2), cf. bug 721575  they should really simplify to a standard form and cancel. The general problem of using approximate arithmetic to check sign/is remains.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=798571&group_id=4933 