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

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

Bugs item #1515430, was opened at 20060701 02:30 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515430&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: und not propagated through functions Initial Comment: The symbol und, which I guess stands for undefined, isn't propagated through functions, e.g., [sin(und), sqrt(und), log(und), und^2, exp(und)] => [sin(und),sqrt(und),log(und),und^2,%e^und] An example found in the wild: limit(atan(tan(x)^2),x,inf); => atan(und) Not sure what's the right answer for foo(und) in general, but it seems like atan(und) is probably not the best answer in this particular case.  >Comment By: Stavros Macrakis (macrakis) Date: 20060815 10:26 Message: Logged In: YES user_id=588346 There are two issues here: the handling of "und" in general (which I think has been discussed in various bug reports) and the particular case where limit returns an embedded und. As far as I know, the only part of Maxima that knows anything about und is the limit package, which outputs it. The rest of Maxima feels free to do nonsensical things with und, e.g. undund = 0 (should be und) etc. Und is also a rather blunt instrument. Anyway, that is another discussion. As for limit itself, it should never return an embedded und. You might want to check if this particular case has been reported before  I think it has.  Comment By: Barton Willis (willisbl) Date: 20060702 05:39 Message: Logged In: YES user_id=895922 The one variable limit function cleans up all of these: (%i8) map('limit, [sin(und), log(und), sqrt(und), und^2, exp(und)]); (%o8) [und, und, und, und, und] (%i9) limit(atan(tan(x)^2),x,inf); (%o9) atan(und) (%i10) limit(%); (%o10) und (1) Should limit be required to clean up such things or should it be automatic? I think it would be OK if they were, but I'm not certain that it would be a good thing. Sometimes cos(und) carries more information than does just 'und.' (2) I think (%o10) is OK, but maybe it should be 'ind' instead (indefinite but bounded). (3) With 5.9.2, cos(und) > `sign' called on `und'. This was a bug that got fixed when we changed the code for applying reflection identities. (4) limit doesn't clean up stuff like sin(ind), but maybe it should: limit(sin(ind)) > ind. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515430&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 14:06:12

Bugs item #1379761, was opened at 20051213 14:14 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1379761&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: nusum leaves unsimplified product 2*3 Initial Comment: nusum(n^2*2^n,n,1,k) => 2*(k^22*k+3)*2^k2*3 Note the unsimplified (2*3) Maxima 5.9.2 Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)  >Comment By: Stavros Macrakis (macrakis) Date: 20060815 10:06 Message: Logged In: YES user_id=588346 I traced nusum to make sure this is a nusum and not an underlying Maxima problem  normally Maxima code can't return unsimplified expressions. It is indeed a nusum problem: it is calling factor on an integer as part of the result. So I agree with Robert that it can be "don't fix".  Comment By: Robert Dodier (robert_dodier) Date: 20051219 10:35 Message: Logged In: YES user_id=501686 As nusum is superseded by the more recent and extensive Zeilberger package (share/contrib/Zeilberger), I am inclined to close this report as "won't fix". GosperSum doesn't have this bug: load ("Zeilberger/LOADZeilberger.mac"); GosperSum (n^2*2^n, n, 1, k); => ((k+1)^24*(k+1)+6)*2^(k+1)6 best, Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1379761&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:39:37

Bugs item #1463872, was opened at 20060403 16:46 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1463872&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Xmaxima >Group: To be reviewed Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: showtime printout on same line Initial Comment: (%i8) showtime:true;Evaluation took 0.00 seconds (0.00 elapsed) (%o8) true This should be (and used to be): (%i8) showtime:true; Evaluation took 0.00 seconds (0.00 elapsed) (%o8) true Maxima 5.9.3 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:39 Message: Logged In: YES user_id=501686 Not observed in Xmaxima for Maxima 5.9.3cvs / Linux. Can someone retry this with a recent build on Windows? If it is not observed there we can close this report. Marking this item for followup.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1463872&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:37:13

Bugs item #1460767, was opened at 20060329 09:23 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1460767&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: psi[n](float) doesn't return a float Initial Comment: psi[0](0.5) doesn't give us a float. But psi[0](1/2) gives 2*log(2)%gamma. A check of the code indicates psi only works with rationals.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1460767&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:35:53

Bugs item #1458733, was opened at 20060326 06:29 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1458733&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: complexnumberp too lenient Initial Comment: I think complexnumberp should return false whenever its first argument doesn't have the form a + %i * b (explicitly, but a or b could vanish, so a or %i*b are OK as well). But consider: MAXIMA> (complexnumberp '((mexpt) 8.7 $%i) 'floatp) 1> (COMPLEXNUMBERP ((MEXPT) 8.6999999999999993 $%I) FLOATP) 2> (FLOATP ((MEXPT) 8.6999999999999993 $%I)) <2 (FLOATP NIL) 2> (FLOATP 8.6999999999999993) <2 (FLOATP T) <1 (COMPLEXNUMBERP T) I think this is a bug that could cause trouble. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1458733&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:34:10

Bugs item #1458597, was opened at 20060325 18:58 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1458597&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of x^2/x yields x (ignores zero value) Initial Comment: Simplification of x^2/x yields x, although that is not valid when x = 0. Other examples involving polynomials are easy to construct, e.g, (x  1)^2/(x  1) => x  1, (x  1)*(x + 1)/(x  1) => x + 1. Dunno if quotient simplifications include other kinds of expressions. Perhaps simplification of quotients could yield unevaluated conditionals, e.g., something like x^2/x => if x # 0 then x else undefined(x^2/x); or (assume(not equal(x, 0)), x^2/x) => x.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1458597&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:33:34

Bugs item #1452341, was opened at 20060317 06:46 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1452341&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: solve(x^(5/2)+1,x) produces incorrect roots Initial Comment: Consider: (%i16) display2d:false; (%o16) false (%i17) solve(x^(5/2)+1,x); (%o17) [x = %e^(4*%i*%pi/5),x = %e^(2*%i*%pi/5),x = %e^(2*%i*%pi/5), x = %e^(4*%i*%pi/5),sqrt(x) = 1] (%i18) map(lambda([u],rhs(u)^(5/2)+1),%); (%o18) [2,0,0,2,%i+1] Clearly some of the roots are wrong.  Comment By: Raymond Toy (rtoy) Date: 20060515 07:35 Message: Logged In: YES user_id=28849 This fails because solvespec and solvespec1 (src/solve.lisp) tries to solve y^5+1 = 0 and then x^(1/2) = y, and assumes all the roots are actually roots. More care is needed. This is complicated because solvespec1 calls solve to find the roots, which saves them on the global variable, so we need to examine the global vars to find our roots.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1452341&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:32:56

Bugs item #1448605, was opened at 20060312 19: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=1448605&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Jeffrey Pikul (jpikul) Assigned to: Nobody/Anonymous (nobody) Summary: atan returns illegal value Initial Comment: (%i1) atan(tan(4)); (%o1) 4 (should be 4  %pi, or 0.858407346 as a float) (%i2) declare(z,complex); (%o2) done (%i3) atan(tan(z)); (%o3) z (see below) atan(tan(z)) ==> z is only true if %pi/2<z<%pi/2, so this should return atan(tan(z)) unless qualified with: assume(z<%pi/2,z>%pi/2); Maxima version: 5.9.2 Maxima build date: 9:5 10/12/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  Comment By: Nobody/Anonymous (nobody) Date: 20060313 08:38 Message: Logged In: NO Looks like SIMP%ASIN etc in src/trigo.lisp make the same type of simplification  afoo(foo(x)) => x for foo in {sin, cos, ...}.  Comment By: Nobody/Anonymous (nobody) Date: 20060312 22:46 Message: Logged In: NO Source of this bug seems to be SIMP%ATAN in src/trigi.lisp, in particular this line: (if (eq (caar y) '%tan) (cadr y)) where y is the argument of atan. It seems likely that the other simplification functions in the same file might suffer from similar naive assertions about function inverses. Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1448605&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:32:21

Bugs item #1447320, was opened at 20060310 09:07 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1447320&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: isolate / disolate / isolate_wrt_times interaction => error Initial Comment: Interactions between isolate, disolate, and isolate_wrt_times somehow causes a Lisp error ("ZEROP: ((RAT SIMP) 1 10) is not a number" and stuff like that). Here is a transcript which shows the error  I wasn't able to find anything simpler or shorter. Not sure what's going on here.  Robert Dodier Maxima 5.9.2.99rc3 http://maxima.sourceforge.net Using Lisp CLISP 2.34 (20050720) 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. (%i1) isolate (expand ((a+b+c)^2), c); 2 2 (%t1) b + 2 a b + a 2 (%o1) c + 2 b c + 2 a c + %t1 (%i2) disolate (%t1, a); Warning  you are redefining the Maxima function intersection 2 (%t2) b 2 (%o2) 2 a b + a + %t2 (%i3) isolate (expand ((a+b+c)^2), c); 2 (%o3) c + 2 b c + 2 a c + %t1 (%i4) expand((a+b)^5); 5 4 2 3 3 2 4 5 (%o4) b + 5 a b + 10 a b + 10 a b + 5 a b + a (%i5) isolate (%o4, a); 5 4 2 3 3 2 4 5 (%o5) b + 5 a b + 10 a b + 10 a b + 5 a b + a (%i6) isolate_wrt_times: true$ (%i7) isolate (%o4, a); (%t7) 5 b Maxima encountered a Lisp error: ZEROP: ((RAT SIMP) 1 10) is not a number Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:32 Message: Logged In: YES user_id=501686 In the last line of MEMSIMILAR (src/outmis.lisp), (defun memsimilar (item1 item2 item2ev) (cond ((equal item2ev 0) nil) ((alike1 item1 item2ev) item2) (t (let ((errorsw t) r) (setq r (catch 'errorsw (div item2ev item1))) (and (mnump r) (not (zerop r)) (div item2 r)))))) the MNUMP check fails to protect ZEROP (which barfs on Maxima RAT objects). Probably the ZEROP should be changed to something equivalent to ?r = 0 (i.e. syntactic similarity to 0). Probably need to make sure that catches all kinds of zeros.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1447320&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:21:44

Bugs item #1440069, was opened at 20060227 19:46 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1440069&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: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: euler numbers & zerobern Initial Comment: The option variable 'zerobern' changes the way euler evaluates. This isn't mentioned in the user documentation. Maybe it's not intended for zerobern to make any difference, or maybe it's a documentation error. I don't know. (%i1) euler(3),zerobern : true; (%o1) 0 (%i2) euler(3),zerobern : false; (%o2) 61 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1440069&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:18:54

Bugs item #1435600, was opened at 20060220 19:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1435600&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: equal function Initial Comment: is(equal(true,true)) will return true is(equal(false,false)) will return false but is(equal(true,false) or is(equal(false,true)) will give a bug ... syntax error. Why not provide a k_delta function like in Macsymas? e.g. k_delta(true,false) returns false k_delta(true,true) returns true k_delta(1,1) returns 1 k_delta(1,0) returns 0 HuenYK v 5.9.1 Maxima Comment: there are some good features in Maxima especially on Random(n). Macsymas only give a ceiling of n = 10^8.  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:18 Message: Logged In: YES user_id=501686 Boosting the priority of this one. It's really obnoxious.  Comment By: Nobody/Anonymous (nobody) Date: 20060312 23:43 Message: Logged In: NO The problem is that at present Maxima attempts to decide all equal (and notequal) comparisons as if the arguments were comparable numbers. This policy fails with errors of different sorts when the arguments are incomparable (e.g., boolean, complex, or matrices). MEQP in src/compar.lisp calls COMPARE (numerical comparison) if LIKE (structural comparison) fails; it should instead call COMPARE only if the arguments are comparable. I can't see a good way to determine comparability. Probably it is OK to assume comparability if incomparability can't be established. Even this weak policy is problematic, due to the weakness of the assume / declare database system. It seems we should be able to let comparable = not featurep(x, real) or maybe featurep(x, nonscalar) or maybe testing for various domains featurep(x, complex) or featurep(x, boolean) or .... but various problems immediately crop up, e.g., featurep(matrix([1, 2]), nonscalar) => false, featurep(matrix([1, 2]), real) => true, no builtin boolean property (and therefore true and false aren't boolean), featurep(1 + %i, nonscalar) => false, (declare (foo, nonscalar), featurep (foo(x), nonscalar)) => false, etc etc. Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1435600&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:16:27

Bugs item #1430379, was opened at 20060212 18:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430379&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: algsys & algebraic == true / FIX Initial Comment: (%o7) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i8) algsys(%,[a,b,c,d]); Maxima encountered a Lisp error: (%i9) algsys(%o7,[a,b,c,d]),algebraic : true; (%o9) [[a=(sqrt(14*%r7*%r8)1)/2, ...]] Would it be OK to have algsys (or maybe just resultant) set algebraic to true? Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:16 Message: Logged In: YES user_id=501686 Observed in 5.9.3.99rc1.  Comment By: Barton Willis (willisbl) Date: 20060213 04:09 Message: Logged In: YES user_id=895922 Proposed fix: (defmfun $resultant (a b mainvar) (prog (varlist formflag $ratfac res ans genvar $keepfloat $algebraic) (setq varlist (list mainvar) $ratfac t ans 1 $algebraic t) It seems to fix the problem: (%o9) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i10) algsys(%,[a,b,c,d]); (%o10) [[a=(sqrt(14*%r7*%r8)1)/2,b=%r7 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430379&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:13:46

Bugs item #1430245, was opened at 20060212 12:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430245&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core >Group: To be reviewed Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: error using ode2 Initial Comment: Maxima 5.9.2 for Windows crashes when using this statement ode2('diff(y,x,2)'diff(y,x)+y=cos(x),y,x); Paolo Ferraresi.  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:13 Message: Logged In: YES user_id=501686 Not observed in Maxima 5.9.3.99rc1 / Clisp 2.38 / Linux. Someone please try this on Windows. If it works OK we can close this report. Marking this report for followup.  Comment By: Raymond Toy (rtoy) Date: 20060407 07:31 Message: Logged In: YES user_id=28849 Current CVS seems to work. (But I didn't test on Windows.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430245&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:11:25

Bugs item #1419046, was opened at 20060130 13: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=1419046&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sign bug Initial Comment: (%i14) 1sqrt(1x); (%o14) 1sqrt(1x) (%i15) x * diff(%,x)/%; (%o15) x/(2*(1sqrt(1x))*sqrt(1x)) (%i16) abs(%); Yeechs! numerator is x. (%o16) x/(2*abs(sqrt(1x)1)*sqrt(1x)) Let's check the sign at 0.1 (%i17) subst(x=0.1,%); (%o17) 0.97673129462279451 Try again using cabs; this looks OK: (%i18) 1sqrt(1x); (%o18) 1sqrt(1x) (%i19) x * diff(%,x)/%; (%o19) x/(2*(1sqrt(1x))*sqrt(1x)) (%i20) cabs(%); Is x  1 positive, negative, or zero? neg; (%o20) abs(x)/abs(2*x+2*sqrt(1x)2) Let's try again  this time I'll trace sign (%i23) x * diff(%,x)/%; (%o23) x/(2*(1sqrt(1x))*sqrt(1x)) (%i24) abs(%); 1 Enter sign [x/(2*(1sqrt(1x))*sqrt(1x))] 1 Exit sign pn 1 Enter sign [1/(1sqrt(1x))] 1 Exit sign pn 1 Enter sign [1sqrt(1x)] 1 Exit sign pn 1 Enter sign [1/sqrt(1x)] 1 Exit sign pos 1 Enter sign [x] 1 Exit sign pos < bogus (%i30) build_info(); Maxima version: 5.9.2.19cvs Maxima build date: 10:34 1/27/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:11 Message: Logged In: YES user_id=501686 Observed in 5.9.3.99rc1 / Clisp 2.38.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1419046&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:07:34

Bugs item #1418010, was opened at 20060129 08:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1418010&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(sin(x)/cos(x)^2,x,0,%pi/3) not simplified Initial Comment: If we apply the fix from Bug 137470 (http://sourceforge.net/tracker/index.php?func=detail&aid=1374704&group_id=4933&atid=104933) The result is 1/cos(%pi/3)1/cos(0). This is right but is not simplified to 1.  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:07 Message: Logged In: YES user_id=501686 Observed in 5.9.3.99rc1 / Clisp 2.38.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1418010&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:06:20

Bugs item #1409904, was opened at 20060119 06:47 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1409904&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: li[2] and li[3] are only accurate to singleprecision Initial Comment: After examining the code for li2numer and li3numer, we see that the constants used in evaluating these two functions are only accurate to 8 digits or so. li[2](0.5) > 0.5822405249432515 According to mma, the result is 0.58224052646501250590265632  Comment By: Raymond Toy (rtoy) Date: 20060201 08:27 Message: Logged In: YES user_id=28849 A new implementation of li[2] has been added, so li[2] should have doublefloat precision accuracy now. li[2](0.5) > .5822405264650125.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1409904&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:03:34

Bugs item #1401409, was opened at 20060110 03:57 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1401409&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Kubula (kubula) Assigned to: Nobody/Anonymous (nobody) Summary: wrong function acot Initial Comment: I have maxima for windows (5.9.2) and maxima on my debian Sarge(5.9.19). When I plot graph of function acot (arc cotangent) I see, that this graph is wrong. (%i1) plot2d(acot(x),[x,10,10]) ; This is graph of function atan(1/x), but acot is defined by formula acot(x) = Pi/2  atan(x)  Comment By: Kubula (kubula) Date: 20060206 07:06 Message: Logged In: YES user_id=1020884 My formula is correct. Formula pi/2  atan(x) is inverse function for function cotangent on interval (0;pi). Formula atan(1/x) is inverse funciton for function cotangent on interval (pi/2;pi/2). So bug is in help, because there isn't interval defined.  Comment By: Barton Willis (willisbl) Date: 20060110 15:08 Message: Logged In: YES user_id=895922 >From Abramowitz and Stegun (A&S): acot(x) = atan(1/x) (4.4.8) atan(x) + acot(x) = pi/2 if real part(x) <= 0 (4.4.4) atan(x) + acot(x) = pi/2 if real part(x) > 0 (4.4.4) According to Abramowitz and Stegun (the unoffical offical reference for Maxima), your formula isn't correct in the left half plane. Nevertheless, such things are easy to mess up, so I'll carefully check A&S identities 4.4.4  4.4.9 using cvs Maxima. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1401409&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 03:00:13

Bugs item #1394256, was opened at 20051231 02: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=1394256&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: Fix for 5.9.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Berny B (redgolpe) Assigned to: Nobody/Anonymous (nobody) Summary: Divisors not working properly Initial Comment: Divisors(n) does not return all expected values: (%i1) divisors(83*1237*1367); (%o1) {1, 83, 1690979, 140351257}  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 21:00 Message: Logged In: YES user_id=501686 Not observed in 5.9.3.99rc1. Closing this report as fixed per comment by Barton Willis.  Comment By: Barton Willis (willisbl) Date: 20051231 08:53 Message: Logged In: YES user_id=895922 Thank you for the bug report. I fixed the bug in CVS (nset.lisp). Until you update your Maxima, a workaround is to assign the option variable 'intfaclim' the value 'false': (%i2) divisors(83*1237*1367); (%o2) {1,83,1690979,140351257} (%i3) divisors(83*1237*1367), intfaclim : false; (%o3) {1,83,1237,1367,102671,113461,1690979,140351257} Alternatively: (%i4) intfaclim : false$ (%i5) divisors(83*1237*1367); (%o5) {1,83,1237,1367,102671,113461,1690979,140351257} Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1394256&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:56:03

Bugs item #1392182, was opened at 20051228 11:45 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1392182&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: polynomial factoring fails Initial Comment: factor(x^4y^4) factor(x^5+y^5) Maxima 5.9.2 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) 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. (%i1) factor(x^3y^3); Error in FACTOR [or a callee]: Error in TYPEERRORDATUM [or a callee]: The slot CONDITIONS::DATUM is unbound in the object #<CONDITIONS::INTERNALTYPEERROR.0>. Please contct pwang@... to obtain the polymomial package "ppack" that can be included in maxima for distribution. Paul  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 20:55 Message: Logged In: YES user_id=501686 Not observed in 5.9.3.99rc1. Closing this report as "works for me".  Comment By: Barton Willis (willisbl) Date: 20051229 17:34 Message: Logged In: YES user_id=895922 I don't have this problem with 5.9.2.10cvs: (%i1) factor(x^3y^3); (%o1) (yx)*(y^2+x*y+x^2) (%i2) factor(x^4y^4); (%o2) (yx)*(y+x)*(y^2+x^2) (%i3) factor(x^5+y^5); (%o3) (y+x)*(y^4x*y^3+x^2*y^2x^3*y+x^4) (%i4) build_info(); Maxima version: 5.9.2.10cvs Maxima build date: 12:57 12/20/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (%o4) Barton  Comment By: Barton Willis (willisbl) Date: 20051229 17:33 Message: Logged In: YES user_id=895922 I don't have this problem with 5.9.2.10cvs: (%i1) factor(x^3y^3); (%o1) (yx)*(y^2+x*y+x^2) (%i2) factor(x^4y^4); (%o2) (yx)*(y+x)*(y^2+x^2) (%i3) factor(x^5+y^5); (%o3) (y+x)*(y^4x*y^3+x^2*y^2x^3*y+x^4) (%i4) build_info(); Maxima version: 5.9.2.10cvs Maxima build date: 12:57 12/20/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (%o4) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1392182&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:49:31

Bugs item #1379761, was opened at 20051213 12: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=1379761&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: nusum leaves unsimplified product 2*3 Initial Comment: nusum(n^2*2^n,n,1,k) => 2*(k^22*k+3)*2^k2*3 Note the unsimplified (2*3) Maxima 5.9.2 Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)  Comment By: Robert Dodier (robert_dodier) Date: 20051219 08:35 Message: Logged In: YES user_id=501686 As nusum is superseded by the more recent and extensive Zeilberger package (share/contrib/Zeilberger), I am inclined to close this report as "won't fix". GosperSum doesn't have this bug: load ("Zeilberger/LOADZeilberger.mac"); GosperSum (n^2*2^n, n, 1, k); => ((k+1)^24*(k+1)+6)*2^(k+1)6 best, Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1379761&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:48:40

Bugs item #1376860, was opened at 20051208 20: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=1376860&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: specint(gammaincomplete(v,a*t)*exp(p*t),t) seems wrong Initial Comment: (%i12) assume(v>0,p>0); (%o12) [v>0,p>0] (%i13) specint(gammaincomplete(v,a*t)*exp(p*t),t); SIMP2F1WILLCONTINUEIN (%o13) a^v*(p+a)^(v1)*gamma(v+1)*%f[2,1]([v+1,3/2],[2],p/(p+a)) Compare this with (%i14) specint(gammagreek(v,a*t)*exp(p*t),t); (%o14) a^v*p^(v1)*gamma(v+1)/((a/p+1)^v*v) This matches formula 34, p 179 in Tables of Transforms. Considering gammaincomplete = gamma(n)gammagreek, the expression for gammaincomplete seems wrong. It might still be right if the hypergeometric function simplifies, but maxima can't, and I can't think of any way to simplify it either.  Comment By: Raymond Toy (rtoy) Date: 20060212 12:15 Message: Logged In: YES user_id=28849 The fix for transforming %w causes this return the result in terms of the associated Legendre function Q. Somewhat better, but I do not know if this is equivalent.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1376860&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:46:57

Bugs item #1374700, was opened at 20051206 11: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=1374700&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: integrate((1+tan(x)^2)/tan(x),x); Initial Comment: Nonreal result  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 20:46 Message: Logged In: YES user_id=501686 Maxima 5.9.3.99rc1 / Clisp 2.38: integrate((1+tan(x)^2)/tan(x),x); => log(tan(x)) which seems right. Maybe if someone else wants to weigh in here. If someone else agrees this result is OK, we can close this report.  Comment By: Raymond Toy (rtoy) Date: 20060213 11:07 Message: Logged In: YES user_id=28849 This integral is transformed to cos(x)/sin(x)*(sin(x)^2/cos(x)^2+1). Then maxima uses the substitution y=sin(x) to get 1/y*(y^2/(1y^2)+1. However: integrate(1/y*(y^2/(1y^2)+1),y) > log(y)log(y^21)/2. But integrate(expand(1/y*(y^2/(1y^2)+1)),y) > log(y)log(1y^2)/2. The former is wrong for our integration problem; the latter would produce the desired answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1374700&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:43:13

Bugs item #1372477, was opened at 20051203 13:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1372477&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 (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: log(neg integer) not fully simplified/fix Initial Comment: (%i1) declare(n,integer); (%o1) DONE (%i2) assume(n > 0); (%o2) [n>0] (%i3) log(n^2), lognegint, logexpand; An extra log expand is needed: (%o3) log(n^2)+%i*%pi (%i4) %,logexpand; (%o4) 2*log(n)+%i*%pi A putative fix; in simpln, replace (add2 '((mtimes simp) $%i $%pi) (cond ((equal y 1) 0) (t (list '(%log simp) (neg y)))))) with something like (and $lognegint (maximaintegerp y) (eq ($sign y) '$neg)) (add (mul '$%i '$%pi) (take '(%log) (neg y)))) If both ($sign y) and ($sign (neg y)) evaluate to '$neg, we're toast. But that would never happen... Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 20:43 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=1372477&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:39:42

Bugs item #1372264, was opened at 20051203 03: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=1372264&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: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: no user doc for 'numer_pbranch' Initial Comment: There is no user documentation for 'numer_pbranch.' Also 'simpexpt' has some rough edges: Compare (%i19) (2.0b0)^(2/3); (%o19) 1.374729636998603B0*%i7.937005259840998B1 with (%i20) (2.0)^(2/3); (%o20) 2^(2/3) Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060814 20:39 Message: Logged In: YES user_id=501686 The stuff about float simplification has been copied to a separate bug report (1540354).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1372264&group_id=4933 
From: SourceForge.net <noreply@so...>  20060815 02:38:38

Bugs item #1540354, was opened at 20060814 20:38 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=1540354&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of float to fractional power (simpexpt) Initial Comment: Split off from [ 1372264 ] no user doc for 'numer_pbranch': Bigfloat: (%i19) (2.0b0)^(2/3); (%o19) 1.374729636998603B0*%i7.937005259840998B1 Float: (%i20) (2.0)^(2/3); (%o20) 2^(2/3) 5.9.3cvs / Clisp 2.38: (2.0)^(2/3) => 1.0*2^(2/3)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1540354&group_id=4933 