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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

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

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

19
(15) 
20

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

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

31
(30) 





From: SourceForge.net <noreply@so...>  20060731 21:21:11

Bugs item #1052382, was opened at 20041022 14:33 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1052382&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume hard to use programmatically Initial Comment: assume(r>0 and r<1) works fine. However, if I have a function withassume(pred,expr) := ( assume(pred), expand(expr) ); you get withassume(r>0 and r<1, abs(r)) => ERROR: can't eval predicate r>0 Quoting doesn't help: withassume('(r>0 and r<1), abs(r)) => error withassume('('(r>0) and '(r<1)), abs(r)) => error withassume(('"and")(r>0) and '(r<1)), abs(r)) => error withassume('("and")(r>0) and '(r<1)), abs(r)) => error There is a workaround, however: withassume(pred,expr) := ( apply('assume,[pred]), expand(expr) ); You still have to quote the argument, but it works now: withassume('(r>0 and r<1), abs(r)) => r Alternatively, you can use the noun form of AND: withassume('("and")(r>0,r<1),abs(r)) => r Yuck in both cases.  Discussion The underlying problem is that "is", "assume", "forget", etc. quote their arguments then depend on their own little idiosyncratic evaluator.... Also that nounform logical connectives (and, or, if) aren't really supported. Maxima version: 5.9.0.9beta2 Maxima build date: 10:50 7/27/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.3  >Comment By: Stavros Macrakis (macrakis) Date: 20060731 17:21 Message: Logged In: YES user_id=588346 Writing withassume as a macro instead of a function only works in the case of a constant argument. There is still no way to pass around the expression '(r>0 and r<1). For example, using the macro definition of withassume, the following still doesn't work: condition: '(r>0 and r<1)$ withassume(condition, abs(r)) Remember, macros are a syntactic fix. The underlying problems  1) that is/assume/etc. quote their arguments and 2) that "and" cannot handle unevaluated conditions  remain.  Comment By: Robert Dodier (robert_dodier) Date: 20060731 00:51 Message: Logged In: YES user_id=501686 I know that this report is mostly about the general problem of using assume programmatically, but, writing withassume as a macro instead of a function yields the intended behavior I think: withassume(pred,expr) ::=buildq([pred, expr], block([result], assume(pred), result:expand(expr), forget(pred),result )); withassume(r>0 and r<1, abs(r)); => r facts(); => []  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1052382&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 11:58:44

Bugs item #1531458, was opened at 20060730 19:05 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531458&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: To be reviewed >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: specfunctions missing in v. 5.9.3 Initial Comment: I noticed that the directory specfunctions was missing in v. 5.9.3 Is this an oversight, or is there another reason? I am running this on RedHat Fedora Core 4 from v. 5.9.2: [sen@... ~]$ cd /usr/share/maxima/5.9.2/share [sen@... share]$ ls affine diffequations matrix share.usg trigonometry algebra integequations maximainit.lisp simplification utils calculus integration misc specfunctions vector combinatorics linearalgebra numeric sym contrib macro physics tensor >From v. 5.9.3: [sen@... share]$ pwd /usr/local/src/maxima5.9.3/share [sen@... share]$ ls affine integequations matrix simplification algebra integration maximainit.lisp sym builtinslist.txt linearalgebra misc template.texi calculus macro numeric tensor combinatorics Makefile orthopoly trigonometry contrib Makefile.am physics utils diffequations Makefile.in share.usg vector  >Comment By: Barton Willis (willisbl) Date: 20060731 06:58 Message: Logged In: YES user_id=895922 No, this isn't an oversight. The code in the 'orthoply' folder is the replacement for the code in 'specfunctions'. Let us know if the following doesn't work for you: (%i10) load("orthopoly")$ (%i11) hermite(5,x); (%o11) 120*x*((4*x^4)/15(4*x^2)/3+1) Thanks for the report. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531458&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 11:52:49

Bugs item #1531688, was opened at 20060731 06:52 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=1531688&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([ ], [ ], 0) Initial Comment: All the following should simplify to 1: hgfred([3,4],[7],0) > unsimplified mess that is also wrong hgfred([1,1],[2],0) > division by zero hgfred([1,1],[1],0) > 1 (OK) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1531688&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 10:02:49

Bugs item #1046653, was opened at 20041013 22:36 Message generated for change (Comment added) made by aalynch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&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: Abdulhaq Lynch (abdulhaq) Assigned to: Nobody/Anonymous (nobody) Summary: input prompt appearing when it should not Initial Comment: on entering e.g. integrate(,x); the input prompt appears 3 times instead of once. This is a problem for external interfaces. Thanks.  Comment By: aalynch (aalynch) Date: 20060731 10:02 Message: Logged In: YES user_id=1289744 it seems that it has been fixed. I'm working on a front endfor maxima (Kayali) and the underlying problem is that the interface is not suitable for machinemachine communication (it was after all designed for humanmachine interation). We (xmaxima, wxMaxima, whatever) really need an interface tailored for being used programmatically e.g.(in pythonesque pcode) result, errorcode, extrainfo = submit(equation) without needing to parse input/output prompts etc.  Comment By: Robert Dodier (robert_dodier) Date: 20060731 04:18 Message: Logged In: YES user_id=501686 Not sure what the problem is here. It would help to report the build_info() output and also to show a session log (just cutnpaste whatever Maxima prints out).  Comment By: Abdulhaq Lynch (abdulhaq) Date: 20041015 16:03 Message: Logged In: YES user_id=182792 unfortunately no as the problem is: when do I stop listening to Maxima i.e. when do I stop waiting for more output? To verify that the prompts are the same you have to wait to see if the second or third prompt does actually come  i.e. the problem is knowing when to wait. If we set the timeout large then it's annoying for the user and if it's too small then the communication gets messed up entirely.  Comment By: Stavros Macrakis (macrakis) Date: 20041014 14:05 Message: Logged In: YES user_id=588346 Note that the inputline number (e.g. %i34) is the same each time. Does that help in parsing Maxima's output? Of course, it would be better if there were a clean socket API where all these things were made explicit.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 05:00:10

Bugs item #1054472, was opened at 20041026 03: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=1054472&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: defint(log(1+exp(A+B*cos(phi))),phi,0,%pi) wrong Initial Comment: Maxima 5.9.0 C1) assume(B>0,BA>0)$ (C2) integrate(log(1+exp(A+B*cos(phi))),phi,0,%pi);  B B A (D2) 3 %PI LOG(%E (%E + %E )) But if we give A and B numerical values (C3) B:3$ A:2$ ev(D2,numer); (C4) (C5) (D5) 2.952421848475173 (C6) B:3.2$ A:3$ ev(D2,numer); (C7) (C8) (D8) .0191075509605848 while by evaluating the integral numerically we obtain something different (C11) B:3$ A:2$ romberg(log(1+exp(A+B*cos(phi))),phi,0,%pi); (C12) (C13) (D13) 7.506856487627962 (C14) B:3.2$ A:3$ romberg(log(1+exp(A+B*cos(phi))),phi,0,%pi); (C15) (C16) (D16) 0.663669430006855 The integrand does not look like the kind of thing that would give the romberg procedure any trouble (C25) plot2d(log(1+exp(A+B*cos(phi))),[phi,0,%pi])$ In fact, by visual inspection of the plot it is clear that the area under the curve is much closer to 0.66 (romberg's result) than to 0.02 (as integrate would have us believe). The same problem occurs if we use defint instead of integrate. Cheers.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 23:00 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Not sure, but it looks like integrate yields a different result when A and B are symbols compared to when they are given specific values A=2, B=3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1054472&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:52:50

Bugs item #1053056, was opened at 20041023 23: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=1053056&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: TIME(%) always yields 0.0 Initial Comment: TIME(%) always yields 0.0. The cause is that TIME (suprv1.lisp) returns the value of LASTTIME when the TIME argument is %. However LASTTIME is assigned 0 and never assigned anything else; LASTTIME appears to be obsolete, and it is unused except for this reference in TIME. TIME uses the 'TIME property of output labels to fetch the computation time. % isn't assigned the 'TIME property, so presumably that's why TIME was asking for LASTTIME. Let's not resurrect LASTTIME. Instead let's (1) assign % the 'TIME property (search for "putprop dtag" in macsys.lisp) to find the place to do it); and (2) cut out the special case for % in TIME.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1053056&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:51:42

Bugs item #1052382, was opened at 20041022 12:33 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1052382&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume hard to use programmatically Initial Comment: assume(r>0 and r<1) works fine. However, if I have a function withassume(pred,expr) := ( assume(pred), expand(expr) ); you get withassume(r>0 and r<1, abs(r)) => ERROR: can't eval predicate r>0 Quoting doesn't help: withassume('(r>0 and r<1), abs(r)) => error withassume('('(r>0) and '(r<1)), abs(r)) => error withassume(('"and")(r>0) and '(r<1)), abs(r)) => error withassume('("and")(r>0) and '(r<1)), abs(r)) => error There is a workaround, however: withassume(pred,expr) := ( apply('assume,[pred]), expand(expr) ); You still have to quote the argument, but it works now: withassume('(r>0 and r<1), abs(r)) => r Alternatively, you can use the noun form of AND: withassume('("and")(r>0,r<1),abs(r)) => r Yuck in both cases.  Discussion The underlying problem is that "is", "assume", "forget", etc. quote their arguments then depend on their own little idiosyncratic evaluator.... Also that nounform logical connectives (and, or, if) aren't really supported. Maxima version: 5.9.0.9beta2 Maxima build date: 10:50 7/27/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.3  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:51 Message: Logged In: YES user_id=501686 I know that this report is mostly about the general problem of using assume programmatically, but, writing withassume as a macro instead of a function yields the intended behavior I think: withassume(pred,expr) ::=buildq([pred, expr], block([result], assume(pred), result:expand(expr), forget(pred),result )); withassume(r>0 and r<1, abs(r)); => r facts(); => []  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1052382&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:46:42

Bugs item #1051692, was opened at 20041021 13:00 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1051692&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: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: VECTORSIMP does not simplfy p~(q~r) Initial Comment: I set all the following flags to TRUE: EXPANDALL, EXPANDDOT, EXPANDDOTPLUS, EXPANDCROSS, EXPANDCROSSPLUS, EXPANDCROSSCROSS, EXPANDGRAD, EXPANDGRADPLUS, EXPANDGRADPROD, EXPANDDIV, EXPANDDIVPLUS, EXPANDDIVPROD, EXPANDCURL, EXPANDCURLPLUS, EXPANDCURLCURL, EXPANDLAPLACIAN, EXPANDLAPLACIANPLUS, EXPANDLAPLACIANPROD I input VECTORSIMP(p~(q~r)); at the prompt The result was WARNING: DECLARE VECTOR INDETERMINANTS NONSCALAR TO AVOID ERRORS & TO GET FULL SIMPLIFICATION (D43) 0  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:46 Message: Logged In: YES user_id=501686 load(vect); declare([p,q,r],nonscalar); expandall:true; vectorsimp(p~(q~r)); => p . r q  p . q r Looks like the observed behavior is just due to (1) not declaring nonscalar variables and (2) not enabling the expandall flag or expandcrosscross flag. Closing this report as rejected (not a bug).  Comment By: Barton Willis (willisbl) Date: 20041025 14:07 Message: Logged In: YES user_id=895922 Is this what you wanted? (%i1) load("vect"); (% c:/msys/1.0/maxinstall/share/maxima/5.9.1.1cvs/share/vector /vect.mac (%i2) declare([p,q,r],nonscalar)$ (%i3) EXPANDCROSSCROSS : true$ (%i4) vectorsimp(p~(q~r)); (%o4) (p . r) q  (p . q) r (%i5) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1051692&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:42:58

Bugs item #1049563, was opened at 20041018 14:41 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1049563&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: Works For Me Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Memory corruption Initial Comment: The script below messes up symbol names. Various variants do not, but I can't get it simpler than this. s divmod(a,b,modulus):=1; divmodx(a,b,m):=divide(a^b,m)[2]; testing(qq,rr):= makelist([divmod(qq,rr,4),divmodx(qq,rr,4)], cnt,1,10); for p:1 thru 5 do print ([testing(13234,99456),labels]); .... [[[1, 0], [1, 0], [1, 0], [1, 0], [1, 0], [1, 0], [1, 0], [1, 0], [1, 0], [1, 0]], [(:", !©@, *8, ¡, Â, §8LG, æ°3.... Maxima version: 5.9.0.9beta2 Maxima build date: 10:50 7/27/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.3  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:42 Message: Logged In: YES user_id=501686 Not observed in 5.9.3cvs with Clisp 2.38 nor GCL 2.6.7. Closing this report as "works for me" taking into account also the negative report for 5.9.1.1cvs.  Comment By: Barton Willis (willisbl) Date: 20041021 12:47 Message: Logged In: YES user_id=895922 With 5.9.1.1cvs, I don't get the garbage. (%i3) display2d : false; (%o3) FALSE (%i4) divmod(a,b,modulus):=1; (%o4) divmod(a,b,MODULUS):=1 (%i5) divmodx(a,b,m):=divide(a^b,m)[2]; (%o5) divmodx(a,b,m):=DIVIDE(a^b,m)[2] (%i6) testing(qq,rr):= makelist([divmod(qq,rr,4),divmodx(qq,rr,4)], cnt,1,10); (%o6) testing(QQ,rr):=MAKELIST([divmod(QQ,rr,4),divmodx (QQ,rr,4)],cnt,1,10) (%i7) for p:1 thru 5 do print ([testing(13234,99456),labels]); Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] (%i12) build_info(); Maxima version: 5.9.1.1cvs Maxima build date: 12:21 10/20/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  Comment By: Barton Willis (willisbl) Date: 20041021 11:23 Message: Logged In: YES user_id=895922 With 5.9.1.1cvs, I don't get the garbage. (%i3) display2d : false; (%o3) FALSE (%i4) divmod(a,b,modulus):=1; (%o4) divmod(a,b,MODULUS):=1 (%i5) divmodx(a,b,m):=divide(a^b,m)[2]; (%o5) divmodx(a,b,m):=DIVIDE(a^b,m)[2] (%i6) testing(qq,rr):= makelist([divmod(qq,rr,4),divmodx(qq,rr,4)], cnt,1,10); (%o6) testing(QQ,rr):=MAKELIST([divmod(QQ,rr,4),divmodx (QQ,rr,4)],cnt,1,10) (%i7) for p:1 thru 5 do print ([testing(13234,99456),labels]); Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. Warning: MODULUS being set to 4, a nonprime. [[[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0],[1,0]], [%i7,%o6,%i6,%o5,%i5,%o4,%i4,%o3,%i3,%o2,%i2,%o1,% i1]] (%i12) build_info(); Maxima version: 5.9.1.1cvs Maxima build date: 12:21 10/20/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1049563&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:35:19

Bugs item #1049499, was opened at 20041018 13: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=1049499&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: Problem not in Maxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: improper font display in cygwin/texmacs Initial Comment: Problem: special font is not properly displayed with the latest versions of cygwin & texmacs & maxima (see attachments) Versions: cygwin 1.5.111 (in win/xp) texmacs 1.0.4 maxima 5.9.1 Attachments: a.txt  texmacs terminal output when maxima 5.9.1 is installed tm_wi_max.png  an equation in texmacs with maxima 5.9.1 installed b.txt  texmacs terminal output when maxima 5.9.1 is NOT installed tm_wi_max.png  same equation in texmacs with maxima 5.9.1 UNinstalled My temporary measure is uninstalling maxima, which defeats the purpose of taking advantage of maxima 5.9.1's interface to texmacs. Thanks in advance and best wishes to developers! John  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:35 Message: Logged In: YES user_id=501686 Should be reported to the TeXmacs project. Assigning category accordingly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1049499&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:23:52

Bugs item #1047432, was opened at 20041014 17:01 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1047432&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: erf(m) not simplified to erf(m) when m known to be negativ Initial Comment: assume(m<0)$ integrate((ym)*%e^y^2,y,m,inf); gives a result containing erf(m), which should have simplified to erf(m). Workaround is easy: just do expand(<<result>>,0,0) to force resimplification.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:23 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. expand(%,0,0) does not cause simplification of erf(m) to erf(m). Aside from this problem with the integral: erf(m) => erf(m) (not simplified). Dunno if it's relevant, but: featurep(erf, oddfun) => false . HOWEVER with no assumptions about mm, note that erf(mm) =>  erf(mm) .  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1047432&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:18:47

Bugs item #1046653, was opened at 20041013 16: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=1046653&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: Abdulhaq Lynch (abdulhaq) Assigned to: Nobody/Anonymous (nobody) Summary: input prompt appearing when it should not Initial Comment: on entering e.g. integrate(,x); the input prompt appears 3 times instead of once. This is a problem for external interfaces. Thanks.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:18 Message: Logged In: YES user_id=501686 Not sure what the problem is here. It would help to report the build_info() output and also to show a session log (just cutnpaste whatever Maxima prints out).  Comment By: Abdulhaq Lynch (abdulhaq) Date: 20041015 10:03 Message: Logged In: YES user_id=182792 unfortunately no as the problem is: when do I stop listening to Maxima i.e. when do I stop waiting for more output? To verify that the prompts are the same you have to wait to see if the second or third prompt does actually come  i.e. the problem is knowing when to wait. If we set the timeout large then it's annoying for the user and if it's too small then the communication gets messed up entirely.  Comment By: Stavros Macrakis (macrakis) Date: 20041014 08:05 Message: Logged In: YES user_id=588346 Note that the inputline number (e.g. %i34) is the same each time. Does that help in parsing Maxima's output? Of course, it would be better if there were a clean socket API where all these things were made explicit.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1046653&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:15:38

Bugs item #1045920, was opened at 20041013 00: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=1045920&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: Shi Qi (qishi) Assigned to: Nobody/Anonymous (nobody) Summary: a>1 and b>1, is a+b>2? Initial Comment: (%i1) assume(a>1); (%o1) [a > 1] (%i2) assume(b>1); (%o2) [b > 1] (%i3) is(a+b>2); MACSYMA was unable to evaluate the predicate: b + a > 2  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i4)  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:15 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045920&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:14:48

Bugs item #1045531, was opened at 20041012 09:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045531&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: Open Resolution: None >Priority: 6 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: real/imagpart don't know about conjugate Initial Comment: realpart('conjugate(x)) => 'conjugate(x) imagpart('conjugate(x)) => 0 should be realpart(x) and imagpart(x) What is really going on is that rpart (realpart, imagpart, etc.) don't even know conjugate exists, which is not surprising, since it is in a load package (eigen). Worse, there is no way to extend realpart/imagpart to new functions at the Maxima or the Lisp level. s  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:14 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. There has been very recent (last 2 days) work on src/conjugate.lisp, so maybe that stuff just needs some adjustment. (The definition in share/../eigen.mac is superseded by src/conjugate.lisp.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045531&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 04:10:29

Bugs item #1045503, was opened at 20041012 09: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=1045503&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: REARRAY complains about nonnumeric size argument Initial Comment: REARRAY complains if the size argument is not numeric. Example: N: 8$ ARRAY (aa, float, 2^N)$ /* OK!! */ REARRAY (aa, 3^N)$ /* OOPS !! "Argument X is not a NUMBER" */ There is an ancient FFT demo file, .../share/numeric/fft.dem, which uses REARRAY with an expression argument. So perhaps it did work at some point in the past. I guess that REARRAY could attempt to evaluate its size argument if it's not numeric. I don't know what is the usual course of action for Maxima functions. I'm running Maxima 5.9.1 (cmucl) on linux.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 22:10 Message: Logged In: YES user_id=501686 Just need to map MEVAL over the dimension arguments of rearray. Present behavior looks like a simple oversight.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1045503&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:46:37

Bugs item #1044318, was opened at 20041010 21: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=1044318&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  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: defint(1/(sin(x)^2+1),x,0,3*%pi) wrong Initial Comment: INTEGRATE(1/(SIN(x)^2+1),x,0,3*%PI) => 0 Since the integrand is everywhere >= 1/2, the integral cannot be zero  in fact integrate(1/(sin(x)^2+1),x,q,q+k*%pi) = k*pi/sqrt(2) (real q, integral k) Presumably defint is using the indefinite integral atan(2*tan(x)/sqrt(2))/sqrt(2) inappropriately.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:46 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. I find defint(1/(sin(x)^2+1),x,0,3*%pi); => sqrt(2)*atan(sqrt(2)*tan(3*%pi))/2 sqrt(2)*atan(sqrt(2)*tan(0))/2 but then ratsimp(%) => 0 .  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1044318&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:44:34

Bugs item #1042244, was opened at 20041007 07:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1042244&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gfactor(a^4+b^4) fatal error Initial Comment: The command : factorsum(a**4+b**4) works, while the command gfactorsum(a**4+b**4) does not work. I use the version 5.5 of maxima  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:44 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20041007 19:16 Message: Logged In: YES user_id=588346 Error is in gfactor(a^4+b^4)  result should be (b^2%I*a^2)*(b^2+%I*a^2)  Comment By: Stavros Macrakis (macrakis) Date: 20041007 19:11 Message: Logged In: YES user_id=588346 Specifically: gfactorsum(a^4+b^4) gives a fatal error in PSHIFT  tested in 5.9.0/GCL2.5.0/Mingw32/W2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1042244&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:41:59

Bugs item #1038624, was opened at 20041001 11: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=1038624&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: askinteger ignores asksign database Initial Comment: assume(equal(zzz,0))$ askinteger(zzz) asks the user Last time I looked, zero was an integer. You can elicit this also in cases like integrate(x^r),x,0,1), which ask Is r pnz? answer=>ZERO Is r an integer? It is also very confusing (though duly documented) that askinteger affects the *global* database, while asksign only affects the *current computation* database. Fortunately, this is not true for internal uses of askinteger like the integrate example above.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1038624&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:40:50

Bugs item #1251540, was opened at 20050803 21:08 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1251540&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Incorrect "inconsistent" error report (linsolve) Initial Comment: (%i1) linsolve([a=1],[b]); Inconsistent equations: (1)  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i2) This appears to be incorrect. The equation is not inconsistent, it is irrelevant or redundant. Setup:  Maxima version: 5.9.1 Maxima build date: 13:0 11/14/2004 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5  Running under Ubuntu Hoary Hedgehog Linux with all updates applied and vanilla xmaxima (no configuration changes). An incorrect error message doesn't matter so much in a simple example like this but can be very confusing and time consuming in more complex cases.  Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:00 Message: Logged In: YES user_id=501686 In 5.9.3cvs, GCL reports "Inconsistent equations". SBCL and Clisp trigger an error, "1 is not a list".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1251540&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:39:58

Bugs item #1036546, was opened at 20040928 14: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=1036546&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: To be reviewed Status: Open Resolution: None >Priority: 7 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: realpart(...) => expression in %i Initial Comment: realpart( (%I*%E^(%I/2)%I*%E^(%I/2))^a ) returns the expression itself.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:39 Message: Logged In: YES user_id=501686 Observed in 5.9.1 but not 5.9.3 nor 5.9.3cvs on Linux. Marking this item for review on Windows. If it doesn't appear in 5.9.3 / Windows, we can close it. By the way the lowercase version of the input expression is realpart( (%i*%e^(%i/2)%i*%e^(%i/2))^a ); and it yields (2*sin(1/2))^a .  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1036546&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:29:42

Bugs item #1035716, was opened at 20040927 14:31 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1035716&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: 4 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: maplist inconsistent with args Initial Comment: maplist(foo,a[i]) => error while map(foo,args(a[i])) => [foo(i)] I'd think these should do the same thing, especially since maplist does act like a "part" function in other ways (e.g. in respecting inflag). s  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:29 Message: Logged In: YES user_id=501686 In 5.9.3cvs, maplist(foo, a[i]) => error and also map(foo, a[i]) => error. maplist(foo, a[i]) should yield [foo(i)] as suggested above. map(foo, a[i]) should yield a[foo(i)] (by analogy with map(foo, a(i))).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1035716&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 03:00:03

Bugs item #1251540, was opened at 20050803 21:08 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1251540&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect "inconsistent" error report Initial Comment: (%i1) linsolve([a=1],[b]); Inconsistent equations: (1)  an error. Quitting. To debug this try DEBUGMODE(TRUE); (%i2) This appears to be incorrect. The equation is not inconsistent, it is irrelevant or redundant. Setup:  Maxima version: 5.9.1 Maxima build date: 13:0 11/14/2004 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5  Running under Ubuntu Hoary Hedgehog Linux with all updates applied and vanilla xmaxima (no configuration changes). An incorrect error message doesn't matter so much in a simple example like this but can be very confusing and time consuming in more complex cases.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 21:00 Message: Logged In: YES user_id=501686 In 5.9.3cvs, GCL reports "Inconsistent equations". SBCL and Clisp trigger an error, "1 is not a list".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1251540&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 02:56:35

Bugs item #1020711, was opened at 20040901 14: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=1020711&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) >Summary: another subres bug (gcd problem) Initial Comment: (%i1) integrate(sqrt(4*x^2 + 4),x,0,1); QUOTIENT by ZERO With gcd == spmod, okay (%i2) gcd : spmod; (%o2) SPMOD (%i3) integrate(sqrt(4*x^2 + 4),x,0,1); (%o3) ASINH(1) + SQRT(2) (%i4) build_info(); Maxima version: 5.9.0.9beta2 Maxima build date: 7:39 9/1/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 20:56 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Barton Willis (willisbl) Date: 20040915 10:05 Message: Logged In: YES user_id=895922 Here is another subres bug (%i1) gcd : subres$ (%i2) algebraic : false$ (%i3) ratsimp(diff(integrate(1/(1+x^5),x),x)); This is wrong: (%o3) ((30*SQRT(5)+150)*x^360*SQRT(5)*x^260*SQRT (5)*x+30*SQRT(5)+350)/(800*x^5+800) (%i4) algebraic : true$ (%i5) ratsimp(diff(integrate(1/(1+x^5),x),x)); So is this (%o5) ((SQRT(5)+5)*x^32*SQRT(5)*x^22*SQRT(5) *x+SQRT(5)+25)/(40*x^5+40) Setting gcd == spmod cleans up these bugs (%i6) gcd : spmod$ (%i7) algebraic : false$ (%i8) ratsimp(diff(integrate(1/(1+x^5),x),x)); (%o8) 1/(x^5+1) (%i9) algebraic : true$ (%i10) ratsimp(diff(integrate(1/(1+x^5),x),x)); (%o10) 1/(x^5+1) (%i11) (%i11) build_info(); Maxima version: 5.9.0.9beta2 Maxima build date: 14:13 9/9/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1020711&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 02:54:33

Bugs item #1010768, was opened at 20040817 08: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=1010768&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: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(1/z)  1/sqrt(z) => 0 Initial Comment: sqrt(1/z)  1/sqrt(z) => 0 in maxima 5.9.0.9beta2 and stable 5.9.0. If except z is real and negative, it's false but sqrt(1/z) + 1/sqrt(z) => 0 See C(23) at http://www.math.unm.edu/~wester/demos/ComplexDom ain/Macsyma.problems Cheers  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 20:54 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. A review of Wester's problems might turn up additional bugs in Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1010768&group_id=4933 
From: SourceForge.net <noreply@so...>  20060731 02:48:16

Bugs item #990924, was opened at 20040714 09:04 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=990924&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(...)) takes sign(%i) Initial Comment: Sometimes is(equal(...)) fails with the message that SIGN was called on an imaginary argument. This happens on Maxima version: 5.9.0 Maxima build date: 19:20 6/28/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18e but I have seen it with a later CMUCL snapshot, too. Smallest example I can find: (C1) prederror: false $ (C2) is(equal((%E^(%I*z)%E^(%I*z)), 0)); SIGN called on an imaginary argument: %I  an error. Quitting. To debug this try DEBUGMODE(TRUE);) Albert Reiner, <areiner@...>.  >Comment By: Robert Dodier (robert_dodier) Date: 20060730 20:48 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=990924&group_id=4933 