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}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(36) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(4) 
3
(2) 
4
(1) 
5

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100314 21:35:25

Bugs item #712468, was opened at 20030331 06:44 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712468&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Values list (etc.) modified destructively Initial Comment: Many of the infolists, including Values, are modified destructively. This leads to confusing behavior like the following: (c1) values; (d1) [a,b,c] (c2) kill(values)$ (c3) d1; (d3) [] or (c4) values; (d4) [a,b,c] (c5) newval: 23$ (c6) d4; (d6) [a,b,c,newval] The Values list is modified destructively both for additions (new variable defined) and for deletions (kill). In both cases, it is strictly for effiency. In the addition case, it is to add new variables to the end (rather than the beginning) of the list efficiently. Even if we want to keep the value list in order of addition (rather than reverse order of addition), the efficiency price of using nondestructive operations is trivial. After all, how many variables (or functions or rules or whatever) are you going to add? Uservisible objects should NOT be modified destructively! It makes for far too confusing semantics! Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: Dieter Kaiser (crategus) Date: 20100314 22:35 Message: I think as long as we do not pass a copy of the lists to the user, but a reference to the global internal variable, the user observes the described effect of destructively modifications of a infolist. Instead of passing a reference we might support for all infolists a function which passes a copy of the list, e.g. (%i1) :lisp (defun $values () (copylist $values)) STYLEWARNING: redefining $VALUES in DEFUN $VALUES (%i1) a:10$ b:20$ c:30$ Both the global variable values and the function values() show three variable: (%i4) values; (%o4) [a, b, c] (%i5) values(); (%o5) [a, b, c] We kill two variable: (%i6) kill(a,c); (%o6) done The output %o4 has been modified destructively, because it is a reference to the global variable $values. The output %o5 is not modified. We have passed a copy of the list. (%i7) %o4; (%o7) [b] (%i8) %o5; (%o8) [a, b, c] I would like to suggest to close this bug report as "Won't fix". If we support in addition a function, we double functionality which might confuse the user and if we change the implementation, a lot of code might be broken. A user who needs an infolist not to be modified can do a copy, e.g. with the command copy(values). Setting the status to pending and the resolution to "Won't fix". Perhaps, I see something completely wrong. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712468&group_id=4933 
From: SourceForge.net <noreply@so...>  20100314 19:06:47

Bugs item #1995531, was opened at 20080616 17:49 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeta errors near 0.0 / 0.0b0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  >Comment By: Raymond Toy (rtoy) Date: 20100314 15:06 Message: I agree with your assessment and your solution. If you don't check it in soon, I'll do it.  Comment By: Dieter Kaiser (crategus) Date: 20100313 14:34 Message: We have a new implementation of the numerical algorithm for the zeta function. But still we have problems near the value zero. We get a Lisp error for a small floating point argument: (%i1) zeta(1.0e20); Maxima encountered a Lisp error: arithmetic error DIVISIONBYZERO signalled Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. The accurarcy is bad for bigfloat values near zero: (%i2) fpprec:20$ (%i4) zeta(1.0b20); (%o4) 5.1145234580810622639b1 (%i5) zeta(10.0b13); (%o5) 5.0000000078891903798b1 I think the best is to implement the following approximation near a zero argument: zeta(s) = 1/2  1/2*log(2*%pi)*s + O(s^2) This is the code which does it: (defun floatzeta (s) (let ((s (bigfloat:to s))) (cond ((bigfloat:< (bigfloat:* s s) (bigfloat:epsilon s)) ;; s^2 < epsilon, use the expansion zeta(s) = 1/21/2*log(2*%pi)*s (bigfloat:+ (bigfloat:/ 1 2) (bigfloat:* (bigfloat:/ 1 2) (bigfloat:log (bigfloat:* 2 (bigfloat:%pi s))) s))) ... With this approximation we get correct results for a small argument near the value zero: (%i7) zeta(1.0e20); (%o7) 0.5 (%i8) zeta(1.0b20); (%o8) 4.9999999999999999999b1 (%i9) zeta(10.0b13); (%o9) 4.9999999999908106147b1 Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080622 06:42 Message: Logged In: YES user_id=895922 Originator: NO Also try makelist(bfloat(bfzeta(1.0b7,20 + 10 * k)),k,1,40). The bug doesn't seem to be just a case of subtractive cancellation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 
From: SourceForge.net <noreply@so...>  20100314 14:14:07

Bugs item #2041214, was opened at 20080807 07:16 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2041214&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: unable solve Initial Comment: solve([x+y=1,sqrt(x+1)=1],[x,y]) returns [] Maxima version: 5.15.0Maxima build date: 17:36 4/20/2008host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20100314 15:14 Message: Maxima can solve this equations by using the package to_poly_sover. This example has been added to the open feature request ID: 2617416 "to_poly_solve in core, was: Maxima can't solve equation". Closing this bug report. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080808 05:09 Message: Logged In: YES user_id=895922 Originator: NO A work around: (%i1) load(topoly_solver)$ (%i2) to_poly_solve([x+y=1,sqrt(x+1)=1],[x,y]); (%o2) [[x=0,y=1]]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2041214&group_id=4933 
From: SourceForge.net <noreply@so...>  20100314 14:04:23

Bugs item #2933063, was opened at 20100115 20:57 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933063&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: simple equations with sqrt(x^2....) cannot be solved Initial Comment: wxmaxima version 0.8.4, naxima 5.20.1 for Windows Xp (sp3) or 2000 (sp4) simple equations or quadratic or biquadratic with unknown x in sqrt(..) cannot be solved. example 1: sqrt(x^2+a^2)=x+2 example 2: sqrt(x^2+a^2)=3*x example 3: sqrt(x^2+(a/2)^2)=x+sqrt(x^2+a^2)  >Comment By: Dieter Kaiser (crategus) Date: 20100314 15:04 Message: Maxima can solve the three examples using the package to_poly_solver. The examples of this bug report have been added to the open feature request ID: 2617416 "to_poly_solve in core, was: Maxima can't solve equation". Closing this bug report. Dieter Kaiser  Comment By: Helmut Albrecht (emu_48) Date: 20100125 11:45 Message: .. may be the "same problem": Maxima can calculate four points of intersection of two conic sections: (%i2) ellipse:1/49*x^2+1/9*y^24/49*x10/9*y+820/441=0; (%o2) y^2/9(10*y)/9+x^2/49(4*x)/49+820/441=0 (%i5) hyperbel:1/4*x^21/16*y^21=0; (%o5) y^2/16+x^2/41=0 (%i12) solve([ellipse,hyperbel], [x,y]); (%o12) [[x=2.236450839328537,y=2.001711962336829],[x=2.404118404118404,y=2.668172043010753],[x=3.872701555869873,y=6.632591093117409],[x=4.391588785046729,y=7.819475655430711]] but it can't calculate the two points of intersection of two circles with solve() (%i4) circle1:(x4)^2+(y5)^24^2=0; (%o4) (y5)^2+(x4)^216=0 (%i6) circle2:(x1)^2+(y2)^24^2=0; (%o6) (y2)^2+(x1)^216=0 (%i26) solve([circle1,circle2], [x,y]); (%o26) [ ] might be an interesting problem ;) helmut  Comment By: Nobody/Anonymous (nobody) Date: 20100116 15:30 Message: 1. (%i1) eq1:sqrt(x^2+a^2)=x+2; (%o1) sqrt(x^2+a^2)=x+2 (%i2) %^2; (%o2) x^2+a^2=(x+2)^2 (%i3) solve(%,x); (%o3) [x=(a^24)/4] (%i4) ans1:%[1]; (%o4) x=(a^24)/4 2. assume a>0 (%i5) eq2:sqrt(x^2+a^2)=3*x; (%o5) sqrt(x^2+a^2)=3*x (%i6) %^2; (%o6) x^2+a^2=9*x^2 (%i7) solve(%,x); (%o7) [x=a/2^(3/2),x=a/2^(3/2)] (%i8) ans2:%[2]; (%o8) x=a/2^(3/2) (%i9) float(%), numer; (%o9) x=0.35355339059327*a 3. assume a>0 (%i10) eq3:sqrt(x^2+(a/2)^2)=x+sqrt(x^2+a^2); (%o10) sqrt(x^2+a^2/4)=sqrt(x^2+a^2)+x (%i11) wxplot2d([lhs(eq3),rhs(eq3)], [x,5,5]),a=1$ (%t11) << Graphics >> (%i12) eq3^2,expand; (%o12) x^2+a^2/4=2*x*sqrt(x^2+a^2)+2*x^2+a^2 (%i13) %(2*x^2+a^2); (%o13) x^2(3*a^2)/4=2*x*sqrt(x^2+a^2) (%i14) %^2,expand; (%o14) x^4+(3*a^2*x^2)/2+(9*a^4)/16=4*x^4+4*a^2*x^2 (%i15) solve(%,x); (%o15) [x=(sqrt(2*sqrt(13)5)*a)/(2*sqrt(3)),x=(sqrt(2*sqrt(13)5)*a)/(2*sqrt(3)),x=(sqrt(2*sqrt(13)+5)*%i*a)/(2*sqrt(3)),x=(sqrt(2*sqrt(13)+5)*%i*a)/(2*sqrt(3))] (%i16) ans3:%[1]; (%o16) x=(sqrt(2*sqrt(13)5)*a)/(2*sqrt(3)) (%i17) float(%), numer; (%o17) x=0.4292534751294*a  Comment By: Barton Willis (willisbl) Date: 20100116 14:51 Message: Workaround: (%i2) load(to_poly_solver)$ (%i3) %solve(sqrt(x^2+a^2)=x+2,x); (%o3) %union([x=(a^24)/4])  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2933063&group_id=4933 
From: SourceForge.net <noreply@so...>  20100314 13:54:46

Bugs item #2969546, was opened at 20100312 19:04 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969546&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: jamlatino (jamlatino) Assigned to: Nobody/Anonymous (nobody) Summary: Does not solve simple equation Initial Comment: Maxima is not able to solve this simple equation 400(800*(6x))/sqrt((6x)^2+4)=0  >Comment By: Dieter Kaiser (crategus) Date: 20100314 14:54 Message: The example of this bug report has been added to the open feature request ID: 2617416 "to_poly_solve in core, was: Maxima can't solve equation". Closing this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100312 20:19 Message: Maxima is able to solve this equation with the Maxima function to_poly_solve. The package to_poly_solver has to be loaded first: (%i3) load(to_poly_solver); (%o3) "/usr/local/share/maxima/5.20post/share/contrib/to_poly_solver.mac" (%i4) eqn:400(800*(6x))/sqrt((6x)^2+4)=0$ (%i5) to_poly_solve(eqn,x); (%o5) %union([x = (2*3^(3/2)2)/sqrt(3)]) I suggest to add a comment about to_poly_solve to the documentation of solve and close this bug report. It might be arguable to extend the Maxima function solve to handle this equation too. But this would be a feature request. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969546&group_id=4933 
From: SourceForge.net <noreply@so...>  20100314 13:35:23

Bugs item #2969599, was opened at 20100312 20:57 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969599&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: Richard Hennessy (richardhennessy) Assigned to: Nobody/Anonymous (nobody) Summary: integrate bug? Initial Comment: Try, (%i6) kill(all); (out0) done (%i1) assume(x>0); (out1) [x > 0] (%i2) display2d:false; (out2) false (%i3) assume(s>0,b<0); (out3) [s > 0,b < 0] (%i4) p(s,x,b):=2*(b)^(s/2+1/2)*x^s*%e^(b*x^2)/gamma(s/2+1/2); (out4) p(s,x,b):=2*(b)^(s/2+1/2)*x^s*%e^(b*x^2)/gamma(s/2+1/2) (%i5) define(dc(x),integrate(p(s,p,b)*p(s,xp,b),p,0,inf)),s=5; (out5) dc(x):= sqrt(b)*(sqrt(2)*gamma_incomplete(1/2,b*x^2/2)*b^5*x^10+5*2^(3/2)*gamma_incomplete(3/2,b*x^2/2)*b^4*x^8+5*2^(7/2)*gamma_incomplete(5/2,b*x^2/2)*b^3*x^6 +5*2^(9/2)*gamma_incomplete(7/2,b*x^2/2)*b^2*x^4+5*2^(9/2)*gamma_incomplete(9/2,b*x^2/2)*b*x^2 +2^(11/2)*gamma_incomplete(11/2,b*x^2/2))*%e^(b*x^2/2)/4096 (%i6) define(dc(x),integrate(dc(p)*p(s,xp,b),p,0,inf)),s=5; Maxima encountered a Lisp error: Unhandled var in strongervar? Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%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 'Add new' link on that page. Please include the following information with your bug report:  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 I think it is a bug in integrate, not sure. Richard Hennessy  >Comment By: Dieter Kaiser (crategus) Date: 20100314 14:35 Message: As suggested in the last posting the calls of Lisp break have been replaced by tayerr in hayat.lisp revision 1.42. The last integral gives a noun form. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100313 00:55 Message: It is not a problem of the integration routines but of taylor. The last input of the example tries to calculate a definite integral. The integration routine calls limit to get the integrals for x>0 and x>inf. Limit tries several algorithm. One of them is a taylor expansion. This expansion fails with a Lisp break in the routine strongervar?. I think it is the best to replace all calls to the Lisp function break in the routines of taylor with calls of TAYERR. TAYERR throws or gives a Maxima error. If taylor is called from limit the error will be catched and limit continues its work. The Lisp error will vanish. This would be the result of the example of this bug result. The last input gives a noun form for the integral: (%i1) assume(x>0); (%o1) [x > 0] (%i2) assume(s>0,b<0); (%o2) [s > 0,b < 0] (%i3) p(s,x,b):=2*(b)^(s/2+1/2)*x^s*%e^(b*x^2)/gamma(s/2+1/2); (%o3) p(s,x,b):=2*(b)^(s/2+1/2)*x^s*%e^(b*x^2)/gamma(s/2+1/2) (%i4) define(dc(x),integrate(p(s,p,b)*p(s,xp,b),p,0,inf)),s=5; (%o4) dc(x):= sqrt(b)*(sqrt(2)*gamma_incomplete(1/2,b*x^2/2)*b^5*x^10 +5*2^(3/2)*gamma_incomplete(3/2,b*x^2/2)*b^4*x^8 +5*2^(7/2)*gamma_incomplete(5/2,b*x^2/2)*b^3*x^6 +5*2^(9/2)*gamma_incomplete(7/2,b*x^2/2)*b^2*x^4 +5*2^(9/2)*gamma_incomplete(9/2,b*x^2/2)*b*x^2 +2^(11/2)*gamma_incomplete(11/2,b*x^2/2))*%e^(b*x^2/2)/4096 (%i5) define(dc(x),integrate(dc(p)*p(s,xp,b),p,0,inf)),s=5 (%o5) dc(x):= sqrt(b)*b^3 *('integrate((sqrt(2)*gamma_incomplete(1/2,b*p^2/2)*b^5 *p^10 +5*2^(3/2)*gamma_incomplete(3/2,b*p^2/2)*b^4 *p^8 +5*2^(7/2)*gamma_incomplete(5/2,b*p^2/2)*b^3 *p^6 +5*2^(9/2)*gamma_incomplete(7/2,b*p^2/2)*b^2 *p^4 +5*2^(9/2)*gamma_incomplete(9/2,b*p^2/2)*b *p^2 +2^(11/2)*gamma_incomplete(11/2,b*p^2/2)) *(xp)^5*%e^(b*(xp)^2+b*p^2/2),p,0,inf))/4096 Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969599&group_id=4933 
From: SourceForge.net <noreply@so...>  20100314 01:03:13

Bugs item #811522, was opened at 20030924 06:13 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=811522&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: redundant question in limit Initial Comment: limit(r^(b2)*(xr)^2,r,0) Is b  2 positive, negative, or zero? neg; Is x zero or nonzero? zero; Is b an integer? yes; Is 2  b an even number? no; Is 2  b an even number? <== redundant question no;  >Comment By: Dieter Kaiser (crategus) Date: 20100314 02:03 Message: At first again the example of this bug report with the current Maxima 5.20post: (%i2) limit(r^(b2)*(xr)^2,r,0); Is b2 positive, negative, or zero? n; Is b positive, negative, or zero? z; Is 2b an even number? n; Is 2b an even number? n; Is 2b an even number? n; (%o2) 'limit(r^(b2)*(xr)^2,r,0) After the second question Maxima knows that b=0. Therefore, the expression 2b is even. But Maxima does not recognize this. The answer is in contradiction to the known facts and Maxima asks the same question three times. The reason is that the function evod which is called from askinteger does not look into the database for facts like equal(b,0). We had the same problem with maximaintegerp and introduced the extension checkintegerfacts. We can extend the routine checkintegerfacts to look for facts which are related to even or odd integers. With such an extension we will get: (%i4) limit(r^(b2)*(xr)^2,r,0); Is b2 positive, negative, or zero? n; Is b positive, negative, or zero? z; (%o4) 'limit(r^(b2)*(xr)^2,r,0) Maxima no longer ask the quesition "Is 2b an even number?" because this fact is deduced from the database. This is another simple example. We assume n equal to 2. Therefore n is even, but Maxima does not know it: (%i1) assume(equal(n,2))$ (%i3) askinteger(n,even); Is n an even number? y; With the extension of checkintegerfacts we get: (%i5) assume(equal(n,2))$ (%i6) assume(equal(m,3))$ (%i7) askinteger(n,even); (%o7) yes (%i8) askinteger(m,odd); (%o8) yes Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=811522&group_id=4933 