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}
(83) 
S  M  T  W  T  F  S 



1

2
(6) 
3
(1) 
4
(2) 
5
(1) 
6
(3) 
7

8

9

10
(2) 
11
(3) 
12
(18) 
13
(11) 
14
(4) 
15
(25) 
16

17

18

19

20

21

22

23

24
(9) 
25

26
(17) 
27
(19) 
28
(2) 
29
(4) 
30
(2) 
31
(10) 


From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #619927, was opened at 20021007 15:05 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=619927&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: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: (1.0b0)^(1/3) vs (1.0d0)^(1/3) Initial Comment: With domain : real, (1.0b0)^(1.3) evaluates to its principal value while (1.0d0)^(1/3) evaluates using the realbranch rule. (C24) domain : real; (D24) REAL (C25) (1.0b0)^(1/3); (D25) 8.660254037844387B1 %I + 5.0B1 (C26) (1.0d0)^(1/3); (D26)  1.0 (C27) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=619927&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #721575, was opened at 20030414 21:45 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&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: 2/sqrt(2) doesn\'t simplify Initial Comment: 2/sqrt(2) doesn't simplify. Similarly for 2/2^(2/3). On the other hand, x/sqrt(x) => sqrt(x). And of course sqrt(2) simplifies to itself  it doesn't become 2/sqrt(2)!! I believe the original examples should simplify to sqrt(2) and 2^(1/3). Note that 2^(4/3) => 2*2^(1/3) (the current behavior) is probably CORRECT, in order to make things like 10^(10/3) intelligible. Or is there something I'm missing? Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  Comment By: Stavros Macrakis (macrakis) Date: 20031008 21:21 Message: Logged In: YES user_id=588346 More examples. Righthand side is after ratsimp/algebraic. I believe the general simplifier should be giving those forms. 1/(2*2^(2/3)) 2^(1/3)/4 1/2^(2/3) 2^(1/3)/2 1/(2*SQRT(2)) SQRT(2)/4 1/SQRT(2) SQRT(2)/2 1/(2*2^(1/3)) 2^(2/3)/4 1/2^(1/3) 2^(2/3)/2 Things get worse with nonnumeric contents. In the following, each group of expressions denotes the same thing, but none simplifies to the others. I have put *** next to those forms which are the results of ratsimp/algebraic. Note that in several cases, there is more than one equivalent ratsimp'ed form.... 1/(a*b)^(5/2) 1/(a^2*b^2*SQRT(a*b)) *** SQRT(a*b)/(a^3*b^3) *** 1/(a*b)^(3/2) 1/(a*b*SQRT(a*b)) *** SQRT(a*b)/(a^2*b^2) *** 1/(a*b)^(7/6) 1/(a^(2/3)*b^(2/3)*SQRT(a*b)) *** SQRT(a*b)/(a^(5/3)*b^(5/3)) *** (a*b)^(5/6)/(a^2*b^2) *** 1/(a*b)^(5/6) *** 1/(a^(1/3)*b^(1/3)*SQRT(a*b)) *** (a*b)^(1/6)/(a*b) *** SQRT(a*b)/(a^(4/3)*b^(4/3)) *** 1/SQRT(a*b) *** SQRT(a*b)/(a*b) *** a^(1/3)*b^(1/3)/SQRT(a*b) *** 1/(a*b)^(1/6) *** SQRT(a*b)/(a^(2/3)*b^(2/3)) *** (a*b)^(5/6)/(a*b) *** Now it is true that these expressions are in fact not all equivalent as to principal value, but I will leave that exercise for later. Many of them are, and they are not being canonicalized.  Comment By: Stavros Macrakis (macrakis) Date: 20030417 12:53 Message: Logged In: YES user_id=588346 Yes, of course there are ways within Maxima to perform this simplification. But it should be the default in the general simplifer. The logic already appears to be in the general simplifier, but there is a bug in this particular case. If the general simplifier's philosophy were to leave such things untouched, why does it simplify x/sqrt(x) and the like?  Comment By: Barton Willis (willisb) Date: 20030417 12:44 Message: Logged In: YES user_id=570592 Try ratsimp with algebraic : true (C1) z : 2/sqrt(2); (D1) 2/SQRT(2) (C2) ratsimp(z); (D2) 2/SQRT(2) (C3) ratsimp(z),algebraic; (D3) SQRT(2) (C4) z : 2/2^(2/3); (D4) 2/2^(2/3) (C5) ratsimp(z); (D5) 2/2^(2/3) (C6) ratsimp(z),algebraic; (D6) 2^(1/3) (C7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #635338, was opened at 20021107 22:17 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635338&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: ratsimp bug Initial Comment: In Maxima 5.5/Windows/gcl expr: 4*(SQRT(5)1)/(SQRT(5)*(102*SQRT(5))* ((4*x+SQRT(5)+1)^2/(102*SQRT(5))+1)) 4*(SQRT(5)+1)/(SQRT(5)*(2*SQRT(5)+10)* ((4*xSQRT(5)+1)^2/(2*SQRT(5)+10)+1)) (SQRT(5)+3)*(4*x+SQRT(5)+1)/ ((10*SQRT(5)+10)*(2*x^2+(SQRT(5)+1)*x+2)) +(SQRT(5)3)*(4*xSQRT(5)+1)/ ((1010*SQRT(5))*(2*x^2+(1SQRT(5))*x+2)) +1/(5*(x1)) expr,x=1.1,numer => 1.638... exprsimp: ratsimp(expr) exprsimp,x=1.1,numer => 0.384...n (!!!) Other simplifications do not run into this problem, e.g. ratsimp(factor(expr)), ratsimp(rat(expr)), which nicely yield 1/(x^51).  Comment By: Robert Dodier (robert_dodier) Date: 20060630 21:24 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs / sbcl 0.9.9.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #629716, was opened at 20021028 01:37 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629716&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: dotexptsimp and x^^2/FIX Initial Comment: In general, dotexptsimp:false inside Expand expands out noncommutative powers to noncommutative products, e.g. dotexptsimp:false; expand((x.y)^^2) => x.y.x.y But not always: dotexptsimp:false expand(x^^2) => x^^2 and dotexptsimp:false expand(x.y^^2) => x.y^^2 This makes it impossible (?) to simplify (x.y)^^2 . y  x.y.x.y^^2 to zero. There is a simple patch for this, which makes expand (x^^3) => x.x.x (if dotexptsimp:false). I wonder if that will cause problems anywhere else? Here's the patch. In simpncexpt, just remove the mnctimesp test in the two tests which read as follows: ((and (or (mplusp factor) (and (not $dotexptsimp) (mnctimesp factor))) ....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629716&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:22:06

Bugs item #742909, was opened at 20030524 16:27 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&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  Trigonometry Group: None Status: Open Resolution: None Priority: 4 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(x/2)) makes a mess Initial Comment: trigrat(sin(x/2)) => (%I*(SIN(x/2)*SIN(x)+COS(x/2)*COS(x)COS(x/2)) COS(x/2)*SIN(x)+SIN(x/2)*COS(x)SIN(x/2))/(2*SIN(x/2) ^2+2*COS(x/2)^2) Although this is correct, I doubt that this is what trigrat is supposed to do. After all, it has not eliminated sin (x/2); the result contains sin(x/2), but also contains sin^2+cos^2, so it doesn't seem "more linear" in any sense. Also, it is not a canonical form: trigrat(ev(sin (x/2),halfangles)) gives something else (even messier). Note also that sin(2*x) does not expand in trigrat.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:22

Bugs item #651585, was opened at 20021210 12:24 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=651585&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: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve cannot handle sets of nonlinear e Initial Comment: intech19:/fix/f/debian/mm/maxima/59/maxima$ ./maximalocal GCL (GNU Common Lisp) Version(2.5.0) Thu Dec 5 08:07:35 EST 2002 Licensed under GNU Library General Public License Contains Enhancements by W. Schelter Maxima 5.9.0rc3 http://maxima.sourceforge.net Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (C1) y:[ (x2x1)^2+(y2y1)^2=36^2, (x3x1)^2+(y3y1)^2=25^2, (x3x2)^2+(y3y2)^2 =17^2]; 2 2 2 2 (D1) [(Y2  Y1) + (x2  x1) = 1296, (Y3  Y1) + (x3  x1) = 625, 2 2 (Y3  Y2) + (x3  x2) = 289] (C2) solve(y, [x1, y1, x2, y2, x3, y3]); Error: 0 is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. ======================================================================= intech19:/fix/f/debian/mm/maxima/59/maxima$ ./maximalocal i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `+' / 8 8 8 ooooo 8oooo `____' 8 8 8 8 8  8 o 8 8 o 8 8 + ooooo 8oooooo ooo8ooo ooooo 8 Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 19941997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 19992001 Maxima 5.9.0rc3 http://maxima.sourceforge.net Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (C1) y:[ (x2x1)^2+(y2y1)^2=36^2, (x3x1)^2+(y3y1)^2=25^2, (x3x2)^2+(y3y2)^2 =17^2]; 2 2 2 2 (D1) [(Y2  Y1) + (x2  x1) = 1296, (Y3  Y1) + (x3  x1) = 625, 2 2 (Y3  Y2) + (x3  x2) = 289] (C2) solve(y, [x1, y1, x2, y2, x3, y3]); ***  CDR: 0 is not a list The following restarts are available: R1 = Macsyma toplevel 1. Break [1]>  Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:56 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs. 2nd example needs to have c replaced by C to trigger error: algsys ([a*b*C(a1)*(a+1)*d,b*(a*db*C+1), C*(a*db*C+1),ad*(a*db*C)], [a,b,C,d]); => error  Comment By: Stavros Macrakis (macrakis) Date: 20030131 15:20 Message: Logged In: YES user_id=588346 Another example (checked in 5.9.0rc4): algsys([a*b*C(a1)*(a+1)*d,b*(a*db*C+1),C*(a*db*C+1),ad* (a*db*C)],[a,b,c,d]) => Error: 0 is not of type LIST.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=651585&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:21

Bugs item #611129, was opened at 20020918 08:52 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611129&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Egregious bug in Solve/Algsys Initial Comment: In a very simple case, Solve/Algsys (a) reports many incorrect solutions and (b) misses all the parameterized solutions.  Define equations eqs: [a+b+c=0, a*b*c=1]  These seem pretty simple, don't they?  Solve 2 equations for 3 unknowns (normal algsys) sols: solve(eqs,[a,b,c])  Gives 12 solutions  Substitute back the solutions subst: map(lambda([sol],subst(sol,eqs)),sols)  Big mess  Now evaluate them numerically to eyeball them rectform(subst),numer  Surprise! Only 6 of the 12 are right. And it is completely missing the parametric solution(s)!!! For example, a= 2 / ( sqrt( Q^44*Q )  Q^2 ) b= ( sqrt( Q^44*Q )  Q^2 ) / (2*Q) c= Q  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:22 Message: Logged In: YES user_id=501686 Observed in 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611129&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:21

Bugs item #609466, was opened at 20020914 21:26 Message generated for change (Settings changed) made by robert_dodier 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 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: Robert Dodier (robert_dodier) Date: 20060626 12:19 Message: Logged In: YES user_id=501686 Observed in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20020917 22: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...>  20060827 00:20:21

Bugs item #607079, was opened at 20020909 19:21 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=607079&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve with repeated variable Initial Comment: solve([x=1],[x,x]) returns [[x=1%R12,x=%R12]] which is obviously bogus. It should either complain about the repeated solution variable or  better  return [[x=1]] or [[x=1,x=1]]  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:15 Message: Logged In: YES user_id=501686 Maxima 5.9.1 & 5.9.3: solve([x = 1], [x, x]) => bogus solution. But algsys([x = 1], [x, x]) => [[x = 1]]. Cut algsys out of summary line accordingly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=607079&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:18:55

Bugs item #505443, was opened at 20020118 09:53 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=505443&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: Halfangle limitation Initial Comment: Setting HALFANGLES gives sin(x/2) => sqrt(1cos(x))/2. Of course, this is wrong if x is negative. Need to make it smarter.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:13 Message: Logged In: YES user_id=501686 For the record, (halfangles : true, sin (x/2)); => sqrt(1cos(x))/sqrt(2)$ i.e., same behavior as when this report was first made. Recently (Maxima 5.9.3) floor and ceiling have been implemented as simplifying functions, and the simplifications for entier mentioned below are all implemented. (1)^(2*floor(x)) => 1 floor(floor(x)) => floor(x) floor(x + 5) => floor(x) + 5 Perhaps this means it is now reasonable to change the halfangle simplification to (1)^floor(x/(2*%pi)) * <whatever>.  Comment By: Stavros Macrakis (macrakis) Date: 20021003 10:49 Message: Logged In: YES user_id=588346 The proposed correction, sign(x)*sqrt(1cos(x)) / sqrt(2) only extends the validity of the formula from [0,2pi] to [ 2pi,2pi]. It continues to be incorrect whenever fix(x/(2*pi)) is odd. I suppose you could use (1)^entier(x/(2*pi)) * sqrt(1cos(x))/sqrt(2) but I'm not sure that is terribly useful, especially since Maxima knows nothing about Entier except how to evaluate it for constants. For example, (1)^(2*Entier(...)) should simplify to 1, but doesn't. Entier(Entier(x)) should simplify to Entier (x). Entier(x+5) should simplify to Entier(x)+5. Etc.  Comment By: Raymond Toy (rtoy) Date: 20020627 11:42 Message: Logged In: YES user_id=28849 What are you expecting? I think it would be fairly easy for maxima to say sign(x)*sqrt(1cos(x))/2 (assuming I got that right.) See halfangleaux in logarc.lisp.  Comment By: Cliff Yapp (starseeker) Date: 20020626 15:19 Message: Logged In: YES user_id=11463 Unfortunately, I wasn't the original person to speak on this one  I just submitted it from the list, and I can't remember who it was. If you think the current behavior is OK then it probably isn't worth fussing with too much. CY  Comment By: Raymond Toy (rtoy) Date: 20020626 15:06 Message: Logged In: YES user_id=28849 What are you expecting? I think it would be fairly easy for maxima to say sign(x)*sqrt(1cos(x))/2 (assuming I got that right.) See halfangleaux in logarc.lisp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=505443&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:18:55

Bugs item #580721, was opened at 20020712 12:38 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand bug Initial Comment: Consider this: (C1) display2d:false; (D1) FALSE (C2) tan(%pi/2+x); (D2) COT(x) (C3) tan(%pi/2+%pi*x); (D3) TAN(%PI*x+%PI/2) (C4) %,trigexpand; Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE);) d3 should have been expanded into cot(%pi*x) instead of getting a division by zero error.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:40 Message: Logged In: YES user_id=501686 For the record, same problem observed in maxima 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:18:55

Bugs item #708917, was opened at 20030324 10:34 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=708917&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigreduce(sin(x)^2/cos(x)^2) Initial Comment: trigreduce(sin(x)^2/cos(x)^2) => tan(x)^2 Shouldn't it return (1cos(2*x))/(1+cos(2*x))? For that matter, it would be nice if trigreduce(tan(x)^2) also did this, but the documentation of trigreduce explicitly says that it handles only sin's and cos's (unlike trigexpand, which handles trigs in general). On the other hand, Trigrat already does this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=708917&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 23:56:09

Bugs item #1535101, was opened at 20060805 11:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1535101&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: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: where is interpolate in Maxima 5.9.3 Initial Comment: I often used interpolate with last version but with this new version (5.9.3) under Windows... If I ask to Maxima interpolate (sin(x)  x/2, x, 0.1, %pi); It seems that interpolate doesn't exist. Thank you all.  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 17:56 Message: Logged In: YES user_id=501686 Closing this report (not a bug, as mentioned in comment below).  Comment By: Robert Dodier (robert_dodier) Date: 20060805 21:06 Message: Logged In: YES user_id=501686 interpolate was renamed to find_root because interpolate was an inaccurate name considering what the code actually does. By the way, if sign in to Sourceforge before making a bug report, or at least leave your email, we can contact you about the bug report. I'll leave this report open for a while in case the original poster comes back.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1535101&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 23:52:46

Bugs item #1533584, was opened at 20060802 20:03 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1533584&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  Plotting Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(sum(1/i,i,1,n),[n,1,10]) produces stack overflow Initial Comment: Executing "plot2d(sum(1/i,i,1,n), [n,1,10])" fails with "Unrecoverable error: bind stack overflow".  Comment By: Robert Dodier (robert_dodier) Date: 20060805 21:14 Message: Logged In: YES user_id=501686 plot2d assumes (unless told otherwise) that the expression to be plotted can be evaluated at any point within [1, 10]. However sum(1/i,i,1,n) is only welldefined for integer n. Perhaps you meant L1 : makelist (n, n, 1, 10); L2 : makelist (sum(1/i, i, 1, n), n, 1, 10); L2 : L2, numer; plot2d ([discrete, L1, L2]); Although "plot2d(sum(1/i,i,1,n), [n,1,10]); isn't valid, plot2d should try to do something smarter than stack overflow in that case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1533584&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 23:48:30

Bugs item #1521112, was opened at 20060712 05:14 Message generated for change (Settings changed) made by robert_dodier 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: Lisp Core  Solving equations 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  Comment By: Barton Willis (willisbl) Date: 20060813 20:53 Message: Logged In: YES user_id=895922 Without hacking the function solvex (in src/solve), I don't think there is a way to get at this information. Of course, which equation is is inconsistent is somewhat arbitrary: in [x=3,x=6,x=7], which two equations are inconsistent? Maybe you would like to use the function rank: (%i24) load(linearalgebra)$ (%i25) rank(matrix([6,7],[6,17])); (%o25) 2(%i26) rank(matrix([6,7],[6,7])); (%o26) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521112&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 23:47:11

Bugs item #1530653, was opened at 20060728 15:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530653&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: Documentation Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Callaham (callaham) Assigned to: Viktor Toth (vttoth) Summary: documentation for 'riemann' Initial Comment: In Maxima 5.9.3, in the ctensor package, describe(riemann); 2; prints: 8<     ... If the variable `cframe_flag' is `false', the Riemann tensor is computed directly from the Christoffelsymbols. If `cframe_flag' is `false', the covariant Riemanntensor is computed first from the frame field coefficients. 8<     I think the second sentence should begin, If `cframe_flag' is `true', .... The same error appears in maxima.pdf.  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 17:47 Message: Logged In: YES user_id=501686 Fixed by r1.31 doc/info/Ctensor.texi. Closing this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1530653&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 23:38:22

Bugs item #1527404, was opened at 20060723 11:50 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1527404&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 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve incorrect result Initial Comment: Maxima 5.9.3cvs. linsolve returns an incorrect result for this example (adapted from bug report 887025). array(A,4)$ list_eq : [A[4]+A[3]+A[2]+A[1] = 1, A[2]*DY/(2*coeff_y)A[1]*DY/(2*coeff_y)+A[4]*DY/2+A[3]*DY/2 = 0, A[4]*DX/(2*coeff_x)+A[3]*DX/(2*coeff_x)A[2]*DX/(2*coeff_x) + A[1]*DX/(2*coeff_x) = 0]; list_un : [A[1],A[2],A[3],A[4]]; soln_linsolve : linsolve(list_eq,list_un); => [A[1] = ((2*%r1+1)*DX+2*%r11)/(2*DX+2), A[2] = (2*%r11)/2,A[3] = (%r1*DX+%r11)/(DX+1), A[4] = %r1] Then ratsimp(subst(soln_linsolve,list_eq)); => [1 = 1,(DXcoeff_y)*DY/(2*coeff_y*DX+2*coeff_y) = 0, 0 = 0]  Comment By: Barton Willis (willisbl) Date: 20060823 21:12 Message: Logged In: YES user_id=895922 Two observations: (1) array(A,4) has nothing to do with this bug. (2) to get the solution, replace DX by coeff_y in Maxima's solution. I know that none of this helps all that much... Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1527404&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 23:26:35

Bugs item #1521155, was opened at 20060712 06:54 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521155&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: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: set_up_dot_simplifications of sums (affine package) Initial Comment: Hi, if I want to define simplification rules in the affine package like set_up_dot_simplifications([p1l.Iz.p1rcb1*Iz+sb1*Iy]); (the effect of an propagator onto an spin operator), I get something like [sb1,(p1l.Iz.p1rcb1*Iz)/Iy] instead of [p1l.Iz.p1rcb1*Iz, cb1*Izsb1*Iy] Is it possible to take influence on set_up_dot_simplifications to do like I want. The whole sequence of commands was load("affine"); dotdistrib:true; dotexptsimp:false; dotassoc:true; dotconstrules:true; dotscrules:true; current_variables:[Ix,Iy,Iz]; set_up_dot_simplifications([p1l.Iz.p1rcb1*Iz+sb1*Iy]); Thank you cm  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1521155&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 20:33:14

Bugs item #1517589, was opened at 20060705 09:39 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517589&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Polynomials Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong multiplicities for a simple polynomial Initial Comment: solve produces correct solutions, but wrong multiplicities: (%i1) solve((z^21/%e)^3=0,z); 1 1 (%o1) [z =  , z = ] sqrt(%e) sqrt(%e) (%i2) multiplicities; (%o2) [1, 1] (%i3) ================================================= Maxima version: 5.9.3 Maxima build date: 14:45 6/5/2006 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.38 (20060124)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517589&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 20:31:08

Bugs item #1515063, was opened at 20060630 05:37 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515063&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: Jaime E. Villate (villate) Assigned to: Nobody/Anonymous (nobody) Summary: display2d should use parenthesis for limits Initial Comment: 'limit(b*x+a*x+x,x,3); produces: limit b x + a x + x x > 3 which is misleading. It should better give: limit ( b x + a x + x ) x > 3  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 14:31 Message: Logged In: YES user_id=501686 Fixed by r1.24 src/displa.lisp on CVS head (assign right and left operator precedence values for %limit the same as for %sum). (I changed my mind  it was indeed a bug to omit the parentheses.)  Comment By: Robert Dodier (robert_dodier) Date: 20060708 12:56 Message: Logged In: YES user_id=501686 OK, I understand now that the question is raised wrt display2d : true. I don't know that the given display is ambiguous. When limit is displayed alone, the parentheses are absent, it is true. However, when there are other terms, limit is displayed in parentheses. So I am inclined to close this item as "won't fix". (%i8) FOO * 'limit(b*x+a*x+x,x,3); (%o8) (limit b x + a x + x) FOO x > 3 (%i9) foo * FOO * 'limit(b*x+a*x+x,x,3); (%o9) foo (limit b x + a x + x) FOO x > 3 (%i10) foo * 'limit(b*x+a*x+x,x,3); (%o10) foo (limit b x + a x + x) x > 3 (%i12) FOO + 'limit(b*x+a*x+x,x,3); (%o12) FOO + (limit b x + a x + x) x > 3 (%i13) foo + FOO + 'limit(b*x+a*x+x,x,3); (%o13) FOO + (limit b x + a x + x) + foo x > 3 (%i14) foo + 'limit(b*x+a*x+x,x,3); (%o14) (limit b x + a x + x) + foo x > 3  Comment By: Robert Dodier (robert_dodier) Date: 20060630 09:16 Message: Logged In: YES user_id=501686 Jaime, what is the Maxima version? I see (%i1) display2d:false; (%o1) false (%i2) 'limit(b*x+a*x+x,x,3); (%o2) 'limit(b*x+a*x+x,x,3) with 5.9.3 & 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515063&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:54:09

Bugs item #1496329, was opened at 20060528 04: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=1496329&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: 8 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(CRE matrix, ...) Initial Comment: See also bug 1495041. (%i1) equal(rat(matrix([x])),matrix([x])); (%o1) equal(matrix([x]),matrix([x])) (%i2) is(%); Maxima encountered a Lisp error: Error in AND [or a callee]: Caught fatal error With a typo, Maxima gives an Lisp error: (%i3) equal(rat(matrix([x])),matirx([x])); (%o3) equal(matrix([x]),matirx([x])) (%i4) is(%); Maxima encountered a Lisp error: Error in INFSIMP [or a callee]: #:X33554 is not of type LIST. This bug seems to require that one argument is a CRE matrix: (%i5) equal(rat(f(x)),f(x)); (%o5) equal(f(x),f(x)) (%i6) is(%); (%o6) true Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:54 Message: Logged In: YES user_id=501686 Increasing priority.  Comment By: Robert Dodier (robert_dodier) Date: 20060605 20:09 Message: Logged In: YES user_id=501686 Here is a related example that appeared on the mailing list. is (equal (ident (2), rat (ident (2)))); => CAR: 1 is not a list (Maxima 5.9.3 / Clisp 2.34) => Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] (Maxima 5.9.3 / GCL 2.6.7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1496329&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:48:34

Bugs item #1492785, was opened at 20060522 02:45 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1492785&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 or other UI Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Emacs freezes in maximamode Initial Comment: I use Emacs 21.4.14 and Maxima 5.9.3 in fedora core 5. Both work fine independently After adding the instructions mentioned in the maxima webpage into the .emacs file: (setq automodealist (cons '("\\.max" . maximamode) automodealist)) (setq loadpath (cons "/usr/share/maxima/5.9.3/emacs" loadpath )) (autoload 'maxima "maxima" "Running Maxima interactively" t) (autoload 'maximamode "maxima" "Maxima editing mode" t) every time I activate the maxima mode emacs freezes.  Comment By: Nobody/Anonymous (nobody) Date: 20060613 03:34 Message: Logged In: NO See comments 6 and 7: http://bugs.gentoo.org/show_bug.cgi?id=130245  Comment By: Nobody/Anonymous (nobody) Date: 20060613 03:14 Message: Logged In: NO See comments 6 and 7: http://bugs.gentoo.org/show_bug.cgi?id=130245  Comment By: Sebastian Schubert (sebschub) Date: 20060609 16:58 Message: Logged In: YES user_id=1438953 Did you got the necessary information? I have the same problem. I use cvs emacs and maxima ebuild in Gentoo. It adds ;; maxima mode (setq loadpath (cons "/usr/share/maxima/5.9.3/emacs" load path)) (autoload 'maximamode "maxima" "Maxima mode" t) (autoload 'maxima "maxima" "Maxima interactive" t) (setq automodealist (cons '("\\.max" . maximamode) auto modealist)) (autoload 'dbl "dbl" "Make a debugger to run lisp, maxima and or gdb in" t) (autoload 'gclmode "gcl" "Major mode for editing maxima code and interacting with debugger" t) (setq automodealist (cons '("\\.ma?[cx]\\'" . maxima mode) automodealist)) ;; emaxima mode (autoload 'emaximamode "emaxima" "EMaxima" t) (addhook 'emaximamodehook 'emaximamarkfileasemaxima) to the site file. After starting emacs "Mx maxima" shows Loading maxima (source)...done and freezes. I have to Cg. A "Mx maxima" again and everything is fine...  Comment By: Robert Dodier (robert_dodier) Date: 20060604 23:03 Message: Logged In: YES user_id=501686 Can't tell what's going on here. To the original poster: Please put your email here, or post a message to the Maxima mailing list (http://maxima.sourceforge.net/maximalist.html). Without further information this problem cannot be solved. Marking this items as "pending" so it will be closed automatically in 2 weeks if not resolved otherwise.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1492785&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:33:59

Bugs item #1490397, was opened at 20060517 11:12 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1490397&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Polynomials Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: subres gcd wrong Initial Comment: Here is an example of where subres produces the wrong result but spmod is ok. p:(x^3+1)/(2*x^5+2); q:(sqrt(5)+5)/(20*x^2+(10*sqrt(5)10)*x+20); gcd:subres; ratsimp(p+q); => ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/(80*x^5+80) But now see what happens with spmod: gcd:spmod; ratsimp(p+q); => ((sqrt(5)+5)*x^5+(5*sqrt(5)5)*x^4+10*x^310*x^2+(5*sqrt(5)+5)*x +sqrt(5)15) /(20*x^7+(10*sqrt(5)10)*x^6+20*x^5+20*x^2+(10*sqrt(5)10)*x+20) factor(%): => (sqrt(5)*x^5+5*x^55*sqrt(5)*x^45*x^4+10*x^310*x^2+5*sqrt(5)*x+5*x +sqrt(5)15) /(10*(x+1)*(2*x^2sqrt(5)*xx+2)*(x^4x^3+x^2x+1)) Maxima doesn't notice but the numerator has the factor 2*x^2sqrt(5)*xx+2: divide((sqrt(5)*x^5+5*x^55*sqrt(5)*x^45*x^4+10*x^310*x^2+5*sqrt(5)*x+5*x +sqrt(5)15), (2*x^2sqrt(5)*xx+2)); => [((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/2,0] So the final result of ratsimp is ((sqrt(5)+5)*x^32*sqrt(5)*x^22*sqrt(5)*x+sqrt(5)15)/2/(10*(x+1)*(x^4x^3+x^2x+1)); Notice that the numerator matches the numerator for the subres result, but the denominator is off by a factor of 4!  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:33 Message: Logged In: YES user_id=501686 Increasing the priority. GCD problems are widely reported. We really need to clean this up.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1490397&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:31:39

Bugs item #1489164, was opened at 20060515 16: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=1489164&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: 8 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(%i,0)) Initial Comment: (%i9) is(equal(%i,0)); `sign' called on an imaginary argument: (%i10) is(equal(und,0)); `sign' called on `und'. I claim that both of these should evaluate to false. It seems that equal should call csign, not $sign. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:31 Message: Logged In: YES user_id=501686 Increase priority. This is a serious hindrance.  Comment By: Robert Dodier (robert_dodier) Date: 20060604 23:05 Message: Logged In: YES user_id=501686 Fix title of this item (equla > equal).  Comment By: Robert Dodier (robert_dodier) Date: 20060515 18:09 Message: Logged In: YES user_id=501686 Agreed, these are bugs, and these should both yield false.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489164&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:24:34

Bugs item #1491486, was opened at 20060519 04: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=1491486&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  Complex Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjugate of complex ^ complex Initial Comment: The conjugate of complex^complex sometimes signals an error when it shouldn't: (%i12) conjugate((1+%i)^%i); `sign' called on an imaginary argument: Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:24 Message: Logged In: YES user_id=501686 Fixed by r1.5 src/conjugate.lisp.  Comment By: Robert Dodier (robert_dodier) Date: 20060604 23:04 Message: Logged In: YES user_id=501686 Refined category.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1491486&group_id=4933 