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

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(2) 
2
(7) 
3

4
(4) 
5

6

7
(5) 
8

9

10
(2) 
11
(1) 
12

13

14
(1) 
15
(2) 
16
(8) 
17
(8) 
18
(2) 
19
(7) 
20
(3) 
21
(1) 
22
(2) 
23
(9) 
24
(10) 
25
(4) 
26
(3) 
27

28
(7) 
29
(2) 
30
(4) 
31
(13) 






From: SourceForge.net <noreply@so...>  20100123 10:44:08

Bugs item #2937837, was opened at 20100123 11:44 Message generated for change (Tracker Item Submitted) made by dbinf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937837&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dirk Bosmans (dbinf) Assigned to: Nobody/Anonymous (nobody) Summary: find_root_error documentation incorrect Initial Comment: The documentation (5.19.2) states : "find_root expects the function in question to have a different sign at the endpoints of the search interval. If this condition is not met, the behavior of find_root is governed by find_root_error. When find_root_error is true, find_root prints an error message. Otherwise find_root returns the value of find_root_error." That last part should be something like this: "... When find_root_error is true, find_root prints an error message. Otherwise, if numberp(find_root_error) is true, find_root returns the value of find_root_error. Otherwise, find_root returns the partiallyevaluated find_root expression find_root(first_argument, false, false)" This behaviour is what is programmed in the last few lines of share/maxima/15.9.2/src/intpol.lsp, and is indeed what happens if calling find_root with for example find_root_error = false or with find_root_error:disp("Houston, we have a problem".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937837&group_id=4933 
From: SourceForge.net <noreply@so...>  20100123 09:58:20

Bugs item #2786017, was opened at 20090503 12:25 Message generated for change (Comment added) made by van_nek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2786017&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: realonly in algsys.lisp Initial Comment: The option variable realonly is quite confusing since it does not find real solutions, but only solutions which are free of %i (purely using freeof). For example, when realonly is false, algsys ([x^4 + 1], [x]); returns [[x = (1)^(1/4)], [x = (1)^(1/4)*%i], [x = (1)^(1/4)], [x = (1)^(1/4)*%i]] But when realonly is true, it returns [[x = (1)^(1/4)], [x = (1)^(1/4)]] while it is natural to expect []. Maybe it is better to modify the behavior and filter roots by checking something like is_real(x) := is(trigsimp(imagpart(x)) = 0); and not just freeof(%i, x) With the freeof approach we may also omit real roots of irreducible polynomials: sol : map ('rhs, solve (3*x^3  3*x + 1)); [(sqrt(3)*%i/21/2)/(3*(3^(3/2)*%i/21/6)^(1/3)) +(3^(3/2)*%i/21/6)^(1/3)*(sqrt(3)*%i/21/2), (3^(3/2)*%i/21/6)^(1/3)*(sqrt(3)*%i/21/2) +(sqrt(3)*%i/21/2)/(3*(3^(3/2)*%i/21/6)^(1/3)), (3^(3/2)*%i/21/6)^(1/3)+1/(3*(3^(3/2)*%i/21/6)^(1/3))] map (lambda([x], freeof(%i, x)), sol); [false,false,false] map ('is_real, sol); [true,true,true] So when realonly and algexact are set to true, algsys ([3*x^3  3*x + 1], [x]) just returns [].  >Comment By: Volker van Nek (van_nek) Date: 20100123 10:58 Message: Hi Alexey, yesterday I noticed this problem too and found your bug report. I think you are right, freeof(%i, x) is not a sufficient test to recognize nonzero imaginary parts. E.g. (1)^(1/4) passes. So I wonder why you did not fix that problem. You suggested the right thing. It is one line in src/algsys.lisp to change: 348352: (defun realonly (rootsl) (cond ((null rootsl) nil) ;; ((freeof '$%i (car rootsl)) ;; problem ((equal 0 (sratsimp ($imagpart (car rootsl)))) ;; fix ? (nconc (list (car rootsl)) (realonly (cdr rootsl)))) (t (realonly (cdr rootsl))))) This change passes the test suite. So I would commit this new line. Or do I overlook something? Why did you hesitate to commit? Volker van Nek  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2786017&group_id=4933 
From: SourceForge.net <noreply@so...>  20100122 18:55:07

Bugs item #2937182, was opened at 20100122 14:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Assume does not always affect ratsimp/fullratsimp result Initial Comment: First, assume that x>=0: assume(x>=0); facts(); // returns x>=0 is(fullratsimp(sqrt(x^2))=x); // returns TRUE Now, forget about x>=0 and assume x<0: forget(x>=0); assume(x<0); facts(); // returns 0>x is(fullratsimp(sqrt(x^2))=x); // returns FALSE Is the expected result here TRUE instead of FALSE? For me this result is unexpected. It was achieved using the SAGE 4.3 system which is shipped with Maxima 5.20. I'm not sure this bug is related to Maxima, but it seems so. The behavior of this Maxima 5.20 built into the SAGE system differs from behavior of Maxima 5.17.1 which was used by me previously. Because of such difference I receive not exactly incorrect, but slightly different results in the newer version of Maxima. Thus it seems to me that the results given by the latest version can be simplified at higher degree. Cheers, Dima  >Comment By: Dieter Kaiser (crategus) Date: 20100122 19:55 Message: For a negative symbol x Maxima simplifies the sqrt function the following way: (%i1) assume(x<0)$ (%i2) sqrt(x^2); (%o2) x The function fullratsimp is not needed and does not change anything for this example. We always get for this example: (%i3) is(sqrt(x^2)=x); (%o3) true The only way I have found to get the reported oberservation is to give the variable x a positive value. (Maxima does not give an error if we assign a positive value to a symbol which is assumed to be negative). (%i6) x:10; (%o6) 10 Now the sqrt function simplifies to a positive value: (%i7) sqrt(x^2); (%o7) 10 We get false for the example from above: (%i9) is(sqrt(x^2)=x); (%o9) false I think there is no real problem. Setting the status to pending and the resoltution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 
From: SourceForge.net <noreply@so...>  20100122 13:05:42

Bugs item #2937182, was opened at 20100122 16:05 Message generated for change (Tracker Item Submitted) made by kirzhanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Assume does not always affect ratsimp/fullratsimp result Initial Comment: First, assume that x>=0: assume(x>=0); facts(); // returns x>=0 is(fullratsimp(sqrt(x^2))=x); // returns TRUE Now, forget about x>=0 and assume x<0: forget(x>=0); assume(x<0); facts(); // returns 0>x is(fullratsimp(sqrt(x^2))=x); // returns FALSE Is the expected result here TRUE instead of FALSE? For me this result is unexpected. It was achieved using the SAGE 4.3 system which is shipped with Maxima 5.20. I'm not sure this bug is related to Maxima, but it seems so. The behavior of this Maxima 5.20 built into the SAGE system differs from behavior of Maxima 5.17.1 which was used by me previously. Because of such difference I receive not exactly incorrect, but slightly different results in the newer version of Maxima. Thus it seems to me that the results given by the latest version can be simplified at higher degree. Cheers, Dima  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2937182&group_id=4933 
From: SourceForge.net <noreply@so...>  20100121 00:48:06

Bugs item #2935631, was opened at 20100120 09:01 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2935631&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  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bfloat(log(n)) can be different from log(bfloat(n)) Initial Comment: bfloat(log(n)) uses logbigfloat, which calls fplog to compute the result. log(bfloat(n)) uses bigfloatlog to compute the result using the property log(f*2^m) = log(f)+m*log(2). Since the algorithms are different, the result of bfloat(log(n)) and log(bfloat(n)) could be different. I suggest changing logbigfloat to call bigfloatlog so that the results are guaranteed to be the same.  >Comment By: Raymond Toy (rtoy) Date: 20100120 19:48 Message: Fixed. logbigfloat calls bigfloatlog as needed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2935631&group_id=4933 
From: SourceForge.net <noreply@so...>  20100120 21:20:38

Bugs item #2934291, was opened at 20100118 14:40 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima does not integrate a real power of sin/cos Initial Comment: I try to integrate a function cos(t)^0.5 and receive no definite result (the result is the same as output). If I try to integrate function cos(t)^delta I receive this error: Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. It seems that the antiderivative of cos(t)^delta can be calculated using hypergeometric function. Maxima version info: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Dieter Kaiser (crategus) Date: 20100120 22:20 Message: I had a look at functions.wolfram.com to get the integral of this bug report. This is a direct link http://functions.wolfram.com/01.07.21.1026.01. Closing this bug report. Dieter Kaiser  Comment By: Dmitry Kirzhanov (kirzhanov) Date: 20100120 12:39 Message: crategus, thank you for the explanation. Can you interpret this bug report as a feature request? BTW, would you be so kind to give a reference to any source (a handbook, i.e.) which explains how to deal with such integrals?  Comment By: Dieter Kaiser (crategus) Date: 20100119 16:52 Message: There are two issues: 1. Maxima does not know the general solution of integrate(cos(x)^y,x) in terms of a hypergeometric function 2F1 and Maxima does not know solutions of this integrals for y a rational number. A general solution might be: sin(x)*cos(x)^(y+1)*2F1(1/2, (y+1)/2; (y+3)/2; cos(x)^2) /(y+1)/sqrt(sin(x)^2) All these integrals return an unevaluated noun form. This is a missing feature of Maxima. I think it is not a bug. 2. The error message for one of the integrals is a known problem with the debian distribution of Maxima 5.17.1 which is compiled with GCL 2.6.7. It is not a problem of Maxima. The debian distrubtion does not work. Please try to get a working distribution, e.g. from sourceforge.net. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&group_id=4933 
From: SourceForge.net <noreply@so...>  20100120 14:01:59

Bugs item #2935631, was opened at 20100120 09:01 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2935631&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bfloat(log(n)) can be different from log(bfloat(n)) Initial Comment: bfloat(log(n)) uses logbigfloat, which calls fplog to compute the result. log(bfloat(n)) uses bigfloatlog to compute the result using the property log(f*2^m) = log(f)+m*log(2). Since the algorithms are different, the result of bfloat(log(n)) and log(bfloat(n)) could be different. I suggest changing logbigfloat to call bigfloatlog so that the results are guaranteed to be the same.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2935631&group_id=4933 
From: SourceForge.net <noreply@so...>  20100120 11:39:13

Bugs item #2934291, was opened at 20100118 16:40 Message generated for change (Settings changed) made by kirzhanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&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 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima does not integrate a real power of sin/cos Initial Comment: I try to integrate a function cos(t)^0.5 and receive no definite result (the result is the same as output). If I try to integrate function cos(t)^delta I receive this error: Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. It seems that the antiderivative of cos(t)^delta can be calculated using hypergeometric function. Maxima version info: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Dmitry Kirzhanov (kirzhanov) Date: 20100120 14:39 Message: crategus, thank you for the explanation. Can you interpret this bug report as a feature request? BTW, would you be so kind to give a reference to any source (a handbook, i.e.) which explains how to deal with such integrals?  Comment By: Dieter Kaiser (crategus) Date: 20100119 18:52 Message: There are two issues: 1. Maxima does not know the general solution of integrate(cos(x)^y,x) in terms of a hypergeometric function 2F1 and Maxima does not know solutions of this integrals for y a rational number. A general solution might be: sin(x)*cos(x)^(y+1)*2F1(1/2, (y+1)/2; (y+3)/2; cos(x)^2) /(y+1)/sqrt(sin(x)^2) All these integrals return an unevaluated noun form. This is a missing feature of Maxima. I think it is not a bug. 2. The error message for one of the integrals is a known problem with the debian distribution of Maxima 5.17.1 which is compiled with GCL 2.6.7. It is not a problem of Maxima. The debian distrubtion does not work. Please try to get a working distribution, e.g. from sourceforge.net. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 23:33:03

Bugs item #2092031, was opened at 20080904 01:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2092031&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: changevar sign error Initial Comment: method 1. use changevar(...) (%i2) assume(x > 2, t > 0, t < 3, cos(t) > 0, sin(t) > 0 ); (%o2) [x > 2,t > 0,t < 3,cos(t) > 0,sin(t) > 0] (%i3) nix : 'integrate(x/sqrt(x^24),x); (%o3) 'integrate(x/sqrt(x^24),x) (%i4) nixt : changevar(nix,x2/cos(t), t, x) ; (%o4) 2*%i*'integrate(sin(t)/(sqrt(cos(t)1)*cos(t)^2*sqrt(cos(t)+1)),t) (%i5) nixt : rootscontract(nixt); (%o5) 2*%i*'integrate(sin(t)/(cos(t)^2*sqrt(cos(t)^21)),t) (%i6) scanmap('trigsimp,nixt); (%o6) 2*'integrate(1/cos(t)^2,t) (%i7) ev(%,nouns); (%o7) 2*tan(t) method 2. do it by hand (%i8) ix : subst(x=2/cos(t),x/sqrt(x^2  4) )* diff(2/cos(t)); (%o8) 4*sin(t)*del(t)/(sqrt(4/cos(t)^24)*cos(t)^3) (%i9) ix : trigsimp(ix); (%o9) 2*del(t)/(sin(t)^21) (%i10) ix : ratsubst(1,cos(t)^2+sin(t)^2,ix); (%o10) 2*del(t)/cos(t)^2 (%i11) integrate(coeff(ix,del(t) ) ,t); (%o11) 2*tan(t) This example was submitted by Robert Marik on the mailing list. I have tried to be very careful about the range of the variables involved. Ted Woollett woollett@... windows xp maxima 5.16.1  >Comment By: Dieter Kaiser (crategus) Date: 20100120 00:33 Message: With the current CVS version Maxima 5.20post we get for both examples the same result 2*tan(t). That is the new result for the first example: (%i2) assume(x > 2, t > 0, t < 3, cos(t) > 0, sin(t) > 0 )$ (%i3) nix : 'integrate(x/sqrt(x^24),x); (%o3) 'integrate(x/sqrt(x^24),x) (%i4) nixt : changevar(nix,x2/cos(t), t, x) ; (%o4) 2*%i*'integrate(sin(t)/(sqrt(cos(t)1)*cos(t)^2*sqrt(cos(t)+1)),t) (%i5) nixt : rootscontract(nixt); (%o5) 2*%i*'integrate(sqrt(1/(cos(t)^21))*sin(t)/cos(t)^2,t) (%i6) scanmap('trigsimp,nixt); (%o6) 2*'integrate(1/cos(t)^2,t) (%i7) ev(%,nouns); (%o7) 2*tan(t) We get the old result when we set the flag radexpand to ALL: (%i1) radexpand:all$ (%i2) assume(x > 2, t > 0, t < 3, cos(t) > 0, sin(t) > 0 )$ (%i3) nix : 'integrate(x/sqrt(x^24),x); (%o3) 'integrate(x/sqrt(x^24),x) (%i4) nixt : changevar(nix,x2/cos(t), t, x) ; (%o4) 2*%i*'integrate(sin(t)/(sqrt(cos(t)1)*cos(t)^2*sqrt(cos(t)+1)),t) (%i5) nixt : rootscontract(nixt); (%o5) 2*%i*'integrate(sqrt(1/(cos(t)^21))*sin(t)/cos(t)^2,t) (%i6) scanmap('trigsimp,nixt); (%o6) 2*'integrate(1/cos(t)^2,t) (%i7) ev(%,nouns); (%o7) 2*tan(t) The output of line (%o5) shows that we get an expression sqrt(1/x). With radexpand:all this is simplified to 1/sqrt(x) later in the calculation and we get a different sign for the result. I think the reported problem has gone because the automatic simplification of sqrt(1/x) > 1/sqrt(x) has gone with revision 1.96 of simp.lisp. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2092031&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 20:55:51

Bugs item #1517077, was opened at 20060704 19:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517077&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Stas Fomin (sfomin) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: "Polynomial Arithmetic with Rests" Initial Comment: Consider example from tutorial: http://maxima.sourceforge.net/docs/tutorial/en/gaertnertutorialrevision/Pages/PArithRests0001.htm Maxima 5.9.1:  (%i9) poly: x^6 +19*x^5 + x^4  14*x^3  x^2  3*x + 1; 6 5 4 3 2 (%o9) x + 19 x + x  14 x  x  3 x + 1 (%i10) mod(poly, 11); 6 5 4 3 2 (%o10) x  3 x + x  3 x  x  3 x + 1  This agree with the manual. Maxima 5.9.3:  (%i1) poly: x^6 +19*x^5 + x^4  14*x^3  x^2  3*x + 1; 6 5 4 3 2 (%o1) x + 19 x + x  14 x  x  3 x + 1 (%i2) mod(poly, 11); 6 5 4 3 2 (%o2) mod(x + 19 x + x  14 x  x  3 x + 1, 11)  This conflicts with the documentation.  >Comment By: Dieter Kaiser (crategus) Date: 20100119 21:55 Message: I think this bug report is out of date. The function polymod is documented. polymod gives the expected result. (%i54) poly: x^6 +19*x^5 + x^4  14*x^3  x^2  3*x + 1; (%o54) x^6+19*x^5+x^414*x^3x^23*x+1 (%i55) polymod(poly,11); (%o55) x^63*x^5+x^43*x^3x^23*x+1 Closing this bug report as out of date. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060708 20:42 Message: Logged In: YES user_id=501686 Function mod was renamed to polymod. Document needs to be updated accordingly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1517077&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 20:28:36

Bugs item #2752650, was opened at 20090411 12:55 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2752650&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Harry Litzroth (hlitzroth) Assigned to: Nobody/Anonymous (nobody) Summary: implicit_plot: cirkel to small to appear? Initial Comment: After loading implicit_plot, the instruction implicit_plot([(y+4)^2+(x5)^21/24=0], [x,10,10],[y,10,10], [gnuplot_preamble,"set zeroaxis;set size ratio 1;"]); shows a small cirkel where it should be. However the instruction implicit_plot([(y+4)^2+(x5)^21/25=0], [x,10,10],[y,10,10], [gnuplot_preamble,"set zeroaxis;set size ratio 1;"]); does not show anything anymore. And the same is true for denominators larger than 25. The problem appears in commandline maxima, in xmaxima and in wxmaxima.  >Comment By: Dieter Kaiser (crategus) Date: 20100119 21:28 Message: As suggested in this thread after an increase of the values of ip_grip both examples work as expected. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20090421 12:41 Message: The solution given by mister Andrejv works fine, as I could have imagined. The creation of the plot of course becomes slower with increasing values in ip_grid. Thank you for this solution.  Comment By: Andrej Vodopivec (andrejv) Date: 20090413 00:19 Message: This is a consequence of the algorithm used by implicit plot (changes of signs). A workaround is to increase the values of ip_grip. ip_grid: [60, 60]$ implicit_plot(...)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2752650&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 19:56:03

Bugs item #1063219, was opened at 20041109 17:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1063219&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: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d Initial Comment: Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5 plot2d function does nothing at all. It worked perfectly in v. 5.9.0. ristoid@...  >Comment By: Dieter Kaiser (crategus) Date: 20100119 20:56 Message: I think this bug report is out of date. Furthermore, I think there is no problem. The only way I have found to get the invalid plot expression plot2d([y=x^2], ...) from wxMaxima is to enter an invalid expression. Perhaps the user wanted to plot a function y(x):=x^2, but used a wrong syntax. I think we can close this bug report. Setting the resolution to "out of date". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060802 05:51 Message: Logged In: YES user_id=501686 Need to punt the problem reported by sergiodf to wxMaxima. Reassigning the category accordingly. plot2d([y=x^2], ...) isn't a valid plot2d expression.  Comment By: Sergiodf (sergiodf) Date: 20060114 15:46 Message: Logged In: YES user_id=366828 I don't know. I am a begginer to Maxima. That command was automaticly generated by wxMaxima (a wxWindows frontend to Maxima <http://wxmaxima.sourceforge.net/>;), so i supose it's a valid one. But if you think it is not, please write me a valid one and i will try it.  Comment By: Raymond Toy (rtoy) Date: 20060113 22:46 Message: Logged In: YES user_id=28849 Reopening. But is plot2d([y=x^2], [x,5,5], [y,5,5], [plot_format, gnuplot])$ a valid plot?  Comment By: SourceForge Robot (sfrobot) Date: 20060110 04:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Sergiodf (sergiodf) Date: 20060108 21:50 Message: Logged In: YES user_id=366828 Same problem here! I am using wxMaxima, but same thing with xMaxima. It seems like Maxima is doing his job (high CPU usage), but gnuplot does not appears. The command is: plot2d([y=x^2], [x,5,5], [y,5,5], [plot_format, gnuplot])$ (just an example... same problem with other expressions). Maxima info: ==================================================== (%i7) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Submit New' link on that page. Please include the following build information with your bug report:  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  The above information is also available from the Maxima function build_info(). ==================================================== GNUPlot info: ==================================================== G N U P L O T Version 4.0 patchlevel 0 last modified Thu Apr 15 14:44:22 CEST 2004 System: MSWindows 32 bit ====================================================  Comment By: Raymond Toy (rtoy) Date: 20051130 05:39 Message: Logged In: YES user_id=28849 Changed to pending.  Comment By: Raymond Toy (rtoy) Date: 20041123 16:28 Message: Logged In: YES user_id=28849 Do you have gnuplot? Does it work? What plot2d command did you give? What is plot_options? Hmm. I don't use windows.  Comment By: Raymond Toy (rtoy) Date: 20041123 00:41 Message: Logged In: YES user_id=28849 No additional information, and it works for me, so I'm closing this bug.  Comment By: Nobody/Anonymous (nobody) Date: 20041113 03:31 Message: Logged In: NO Look if you have installed gnuplot correctly.  Comment By: Raymond Toy (rtoy) Date: 20041109 20:37 Message: Logged In: YES user_id=28849 More information needed. What did you plot? Do you have gnuplot? What exactly happened?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1063219&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 19:38:32

Bugs item #754008, was opened at 20030613 16:59 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=754008&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot3d occlusion failure; replot problem Initial Comment: plot3d(a*exp(1/b),[a,.1,2],[b,.1,2]); Bring up the config window and set azimuth to about 133. The grey wireframe appears in the rear corner of the cube, though it should be occluded. Now hit "replot". First of all, the plot becomes smaller. (Why?) Then, when you rotate it, it breaks up into little squares or pieces of broken glass as you rotate it, though it reverts to a correct plot after you stop rotating. This doesn't happen in the original plot. Maxima 5.9.0 gcl 2.5.0 Windows 2000 mingw Athlon  >Comment By: Dieter Kaiser (crategus) Date: 20100119 20:38 Message: Perhaps this bug report as out of date. This report does not mention what plot program is used. I have tried to reproduce the problem with Maxima 5.20.1 on Windows with gnuplot graph Version 4.2 (patchlevel 3). I have got no problems with the plot. Setting the status to pending and the resolution to "out of date". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=754008&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 18:54:20

Bugs item #695086, was opened at 20030228 15:33 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=695086&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d number overflow Initial Comment: plot2d(1.0e9,[x,0,1]) gives the popup error "Error: integer value too large to represent". "Details" shown below. It also doesn't recover well from the error  it shows an empty plot window (in Plot Windows: Separate mode). Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 integer value too large to represent integer value too large to represent while executing "expr {round(ceil($aa)) }" (procedure "getTicks" line 12) invoked from within "getTicks $y2 $y1 [expr {$shei/50}" (procedure "axisTicks" line 27) invoked from within "axisTicks $win $c" (procedure "replot2d" line 40) invoked from within "replot2d $win" (procedure "plot2d" line 4) invoked from within "plot2d data {plot2d {label "1.0E+9"} {xversusy { 0.0000000000 0.0100000000 0.0200000000 0.0300000000 0.0400000000 0.0500000000 0.0600000000 0...." ("eval" body line 1) invoked from within "eval $command" (procedure "doShowPlot" line 14) invoked from within "doShowPlot $win $data" (procedure "maximaFilter" line 45) invoked from within "maximaFilter .maxima.text sock208"  >Comment By: Dieter Kaiser (crategus) Date: 20100119 19:54 Message: The reported problem seems to be no longer present in Maxima 5.20post. I have tried the plot with openmath plot format with SBCL 1.0.29/Linux and GCL 2.6.8/Windows. In both cases the plot window shows a horizontal line. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060704 08:03 Message: Logged In: YES user_id=501686 Still observed n 5.9.3 / sbcl / linux, command line Maxima, with openmath plot format, but not with gnuplot plot format. Tcl/tk is barfing because the argument of round is a float which is too big to fit into a 32 bit int. Looking at the code for getTicks (plotting/omplotdata), I don't see any easy way to fix it. Maybe we can use 64 bit ints or something. Here is an observation of the bug: set_plot_option([plot_format,openmath]); plot2d(1.0e9,[x,0,1]); => Error in startup script: integer value too large to represent while executing "expr {round(ceil($aa)) }" (procedure "getTicks" line 12) invoked from within [...] With gnuplot, plot2d succeeds and the plot window shows a horizontal line.  Comment By: Raymond Toy (rtoy) Date: 20030525 16:14 Message: Logged In: YES user_id=28849 This seems to be an issue with tcl/tk. With gnuplot, a straight line is plotted.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=695086&group_id=4933 
From: SourceForge.net <noreply@so...>  20100119 15:52:25

Bugs item #2934291, was opened at 20100118 14:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima does not integrate a real power of sin/cos Initial Comment: I try to integrate a function cos(t)^0.5 and receive no definite result (the result is the same as output). If I try to integrate function cos(t)^delta I receive this error: Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. It seems that the antiderivative of cos(t)^delta can be calculated using hypergeometric function. Maxima version info: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Dieter Kaiser (crategus) Date: 20100119 16:52 Message: There are two issues: 1. Maxima does not know the general solution of integrate(cos(x)^y,x) in terms of a hypergeometric function 2F1 and Maxima does not know solutions of this integrals for y a rational number. A general solution might be: sin(x)*cos(x)^(y+1)*2F1(1/2, (y+1)/2; (y+3)/2; cos(x)^2) /(y+1)/sqrt(sin(x)^2) All these integrals return an unevaluated noun form. This is a missing feature of Maxima. I think it is not a bug. 2. The error message for one of the integrals is a known problem with the debian distribution of Maxima 5.17.1 which is compiled with GCL 2.6.7. It is not a problem of Maxima. The debian distrubtion does not work. Please try to get a working distribution, e.g. from sourceforge.net. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&group_id=4933 
From: SourceForge.net <noreply@so...>  20100118 13:57:32

Bugs item #2934291, was opened at 20100118 16:40 Message generated for change (Tracker Item Submitted) made by kirzhanov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&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 Private: No Submitted By: Dmitry Kirzhanov (kirzhanov) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima does not integrate a real power of sin/cos Initial Comment: I try to integrate a function cos(t)^0.5 and receive no definite result (the result is the same as output). If I try to integrate function cos(t)^delta I receive this error: Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. It seems that the antiderivative of cos(t)^delta can be calculated using hypergeometric function. Maxima version info: Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934291&group_id=4933 
From: SourceForge.net <noreply@so...>  20100118 02:38:45

Bugs item #2934064, was opened at 20100118 02:38 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934064&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem loading ezunits Initial Comment: Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Loading ezunits results in an error when unitp is compiled, since unitp depends on unitop_p which is not compiled: ; (DEFUN $UNITP ...) is being compiled. ;; The variable $UNITOP_P is undefined. ;; The compiler will assume this variable is a global. The solution is to modify ezunits.mac, to replace the line: compile (constantp_not0, constantp_not1, mult_expr_nontrivialconstfactorsp, nondimensional, unitp, nonconstantp); with the line: compile (constantp_not0, constantp_not1, mult_expr_nontrivialconstfactorsp, nondimensional, unitop_p, unitp, nonconstantp);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2934064&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 22:42:05

Bugs item #2933996, was opened at 20100117 16:26 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933996&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: abs_integrate bug Initial Comment: (%i1) load("abs_integrate.mac"); The answer isn't wrong, but the error message indicates that something has gone wrong: (%i2) integrate(f(floor(x)),x); Too few arguments supplied to floor_int(q,x); found: [g2405] Too few arguments supplied to floor_int(q,x); found: [g2782] (%o2) integrate(f(floor(x)),x) Better (no error message) (%i3) integrate(g(floor(x)),x); (%o3) integrate(g(floor(x)),x)  >Comment By: Barton Willis (willisbl) Date: 20100117 16:42 Message: Fixed by CVS revision 1.23  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933996&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 22:26:39

Bugs item #2933996, was opened at 20100117 16:26 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933996&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: abs_integrate bug Initial Comment: (%i1) load("abs_integrate.mac"); The answer isn't wrong, but the error message indicates that something has gone wrong: (%i2) integrate(f(floor(x)),x); Too few arguments supplied to floor_int(q,x); found: [g2405] Too few arguments supplied to floor_int(q,x); found: [g2782] (%o2) integrate(f(floor(x)),x) Better (no error message) (%i3) integrate(g(floor(x)),x); (%o3) integrate(g(floor(x)),x)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933996&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 17:11:03

Bugs item #2933882, was opened at 20100117 18:11 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933882&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 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Power function: 0^a not fully implemented Initial Comment: We assume a to be positive: (%i1) assume(a>0)$ This is correct: (%i2) 0^a; (%o2) 0 The exponent is negative. The result is not correct: (%i3) 0^a; (%o3) 0 The realpart of the exponent is positive. Therefore we should give zero as a result: (%i4) 0^(a+%i*y); 0 to a complex quantity has been generated.  an error. To debug this try: debugmode(true); (%i5) 0^(2+%i*10); 0 to a complex quantity has been generated.  an error. To debug this try: debugmode(true); Maxima simplifies all expressions which does not contain the symbol %i to zero. Furthermore, Maxima does not look at the sign of the realpart. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933882&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 02:00:09

Bugs item #2234113, was opened at 20081107 13:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2234113&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Plotting Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: mluca (bluluca789) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d odd roots of X plots only positive values Initial Comment: The bug is only from version 5.14.x (tested for windows versions), typing plot2d(x^(1/3),[x,5,5]) the plot is only for x>0. For versions up to 5.13.x the plot is correct. Calculating x(1/3) with x<0, the result is correct (%i1) 27^(1/3); (%o1) 3 The plot3d function is not affected by this problem  >Comment By: Dieter Kaiser (crategus) Date: 20100117 03:00 Message: In Maxima 5.20post the plot of this example works for me too. Closing this bug report as "Works for me". Dieter Kaiser  Comment By: Leo Butler (l_butler) Date: 20091009 17:51 Message: In v5.19.2, this plot command works as you wish. I suggest upgrading your version of Maxima, since it is rather old.  Comment By: mluca (bluluca789) Date: 20090715 13:34 Message: The new version of maxima gives a complex number for the cube root of a negative value, and the plot2d is only for real numbers.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2234113&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 01:55:16

Bugs item #2219974, was opened at 20081104 05:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2219974&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: Pending >Resolution: Works For Me Priority: 7 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(asinh(1), log(1 + sqrt(2)))); => false Initial Comment: is(equal(asinh(1), log(1 + sqrt(2)))); => false (should be true) Result is due to bigfloat evaluation of asinh(1)  log(1 + sqrt(2)), which yields a small positive residual. signbfloat=false disables bigfloat evaluation: is(equal(asinh(1), log(1 + sqrt(2)))), signbfloat=false; => unknown which is not entirely helpful, but at least it is not incorrect. Not sure what to do here. Certainly we don't want the sign test to be too quick to return true or false, but if we make the numerical test more stringent, we could miss some otherwisesolvable problems.  >Comment By: Dieter Kaiser (crategus) Date: 20100117 02:55 Message: This error seems to be no longer present. We had changes to the implementation of the bigfloat routines. Perhaps because of these changes the example of this bug report works. This is my version: Maxima version: 5.20post Maxima build date: 1:2 1/17/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian At this is the result: (%i1) is(equal(asinh(1), log(1 + sqrt(2)))); (%o1) true Setting the status to pending at the resolution to works for me. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20081106 05:05 Message: One way to get through the test suite with signbfloat : false is to add a logcontract to the top of sign1: (defun sign1 (x) (let (($logconcoeffp '$integerp)) (setq x (specrepcheck x)) (setq x ($logcontract (infsimp* x))) ....) I tested this with SBCL 1.0.22 + CVS Maxima.  Comment By: Barton Willis (willisbl) Date: 20081105 00:40 Message: I built Maxima using signbfloat : false. The test suite reports two problems in rtest16; here is one problem testsuite problem (the other is similar): OK with signbfloat : true: (%i1) limit((%pi*4^N*N!^2)/(2*2^(2*N)*gamma(N+1/2)*gamma(N+3/2)), N, inf); (%o1) 0 Not OK: (%i2) signbfloat : false$ (%i3) limit((%pi*4^N*N!^2)/(2*2^(2*N)*gamma(N+1/2)*gamma(N+3/2)), N, inf); Is log(4)  2 * log(2) positive, negative, or zero? zero; Is 2 * log(2)  log(4) positive, negative, or zero? zero; (%o3) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2219974&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 01:26:51

Bugs item #2933440, was opened at 20100116 17:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933440&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(z^2) simplifies to %i*sqrt(z^2) for z complex Initial Comment: Maxima always simplifies sqrt(z^2) > %i*sqrt(z^2). This is not correct for z a complex value. (%i2) declare(z,complex)$ (%i3) sqrt(z^2); (%o3) %i*sqrt(z^2) We get the wrong sign for e.g. %i: (%i4) %,z=%i; (%o4) 1 This is the correct result: (%i5) sqrt(%i^2); (%o5) 1 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100117 02:26 Message: Fixed in simp.lisp revision 1.96. No simplification if the argument is complex: (%i1) declare(z,complex)$ (%i2) sqrt(z^2); (%o2) sqrt(z^2) Simplification if the argument is real: (%i3) sqrt(x^2); (%o3) %i*abs(x) Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933440&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 01:24:33

Bugs item #2852992, was opened at 20090906 17:42 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2852992&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(1/x)%i/sqrt(x) not zero Initial Comment: For any real value sqrt(1/x) should simplify to %i/sqrt(x). We try a positive symbol and get a wrong sign: (%i1) assume(x>0)$ (%i2) sqrt(1/x); (%o2) %i/sqrt(x) This should be zero: (%i3) sqrt(1/x)%i/sqrt(x); (%o3) 2*%i/sqrt(x) For numbers all is correct. We get the expected answers for positive and negative numbers: (%i15) sqrt(1/2)%i/sqrt(2); (%o15) 0 (%i16) sqrt(1/(2))%i/sqrt(2); (%o16) 0 For a general real value we get a wrong simplification too: (%i18) kill(all)$ (%i1) expr:sqrt(1/x)%i/sqrt(x); (%o1) 1/sqrt(x)%i/sqrt(x) The expression is wrongly simplified. We should get zero for positive and negative numbers: (%i2) expr,x=2; (%o2) sqrt(2)*%i (%i3) expr,x=2; (%o3) 0 This bug is related to the bug ID: 1010768 "sqrt(1/z)  1/sqrt(z) => 0". Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100117 02:24 Message: Fixed in simp.lisp revision 1.96. For a real argument Maxima simplifies: (%i1) sqrt(1/x); (%o1) %i/sqrt(x) The example of this bug report simplifies to zero: (%i2) sqrt(1/x)%i/sqrt(x); (%o2) 0 No simplification if the argument is complex: (%i3) declare(z,complex)$ (%i4) sqrt(1/z); (%o4) sqrt(1/z) Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2852992&group_id=4933 
From: SourceForge.net <noreply@so...>  20100117 01:19:44

Bugs item #1010768, was opened at 20040817 16:43 Message generated for change (Comment added) made by crategus 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: Closed >Resolution: Fixed Priority: 5 Private: No 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: Dieter Kaiser (crategus) Date: 20100117 02:19 Message: Fixed in simp.lisp revision 1.96. Maxima no longer simplifies sqrt(1/x) when the sign is not known. (%i2) sqrt(1/x); (%o2) sqrt(1/x) (%i3) assume(x>0)$ (%i4) sqrt(1/x); (%o4) 1/sqrt(x) (%i5) sqrt(1/x)1/sqrt(x); (%o5) 0 (%i6) sqrt(1/x)+1/sqrt(x); (%o6) 0 Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060731 04: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 