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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

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...>  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 
From: SourceForge.net <noreply@so...>  20060826 19:23:11

Bugs item #1489285, was opened at 20060515 21:14 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489285&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: Nobody/Anonymous (nobody) Summary: conjugate is real valued Initial Comment: (%i1) declare(z,complex); (%o1) done (%i2) imagpart(conjugate(z)); (%o2) 0 To cure this, declare conjugate to be complex: (%i3) declare(conjugate,complex); (%o3) done (%i4) imagpart(conjugate(z)); (%o4) imagpart(conjugate(z)) Now %o4 could be imagpart(z). Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:23 Message: Logged In: YES user_id=501686 Fixed by r1.5 src/conjugate.lisp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1489285&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:20:33

Bugs item #1488457, was opened at 20060514 14:35 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488457&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: 7 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: featurep of subscripted variables Initial Comment: (%i1) featurep(a,real); (%o1) false < OK (%i2) featurep(a[1],real); (%o2) true < not OK Do we have a policy? Are all mapatoms except %i and infinity real? That would make %o1 wrong and %o2 correct. Should the setting of domain make a difference? Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:20 Message: Logged In: YES user_id=501686 featurep is a pretty confused function. A substantial bit of logic has accreted onto featurep, but as it stands it is incomplete (as in the example above). We probably need to separate (1) the stuff which is just checking for declaration flags from (2) the stuff which is attempting to infer elementp(x, S) for S = reals, complexes, etc. I think featurep should implement (1), but not (2), which should be a revision of elementp. Bumping up the priority  weakness of assume/declare stuff is a serious hindrance.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488457&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:12:03

Bugs item #1488359, was opened at 20060514 10:13 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488359&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 subscripted function Initial Comment: (%o20) f[6](x) (%i21) conjugate(%); Maxima encountered a Lisp error: Error in GET [or a callee]: (($F SIMP ARRAY) 6) is not of type SYMBOL. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:11 Message: Logged In: YES user_id=501686 Fixed by r1.5 src/conjugate.lisp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488359&group_id=4933 
From: SourceForge.net <noreply@so...>  20060826 19:02:18

Bugs item #1488344, was opened at 20060514 09: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=1488344&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 limitation Initial Comment: The conjugate function doesn't handle long argument lists. For example (%i17) m :genmatrix(a,100,100)$ (%i18) conjugate(m)$ Maxima encountered a Lisp error: Error in MEVAL [or a callee]: MEVAL [or a callee] requires less than one hundred arguments. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060826 13:02 Message: Logged In: YES user_id=501686 Fixed by r1.5 src/conjugate.lisp.  Comment By: Robert Dodier (robert_dodier) Date: 20060516 21:15 Message: Logged In: YES user_id=501686 I don't know that we should associate this bug with conjugate  this appears to be the GCL limitation on the number of arguments (64 at present), so it seems like we should either label it a GCL bug, or maybe a $MATRIX bug (since it might be that the GCL limitation is triggered by $MATRIX).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488344&group_id=4933 