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}
(50) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{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...>  20100312 23:55:56

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: Open Resolution: None 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: 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...>  20100312 20:59:30

Bugs item #2968174, was opened at 20100310 20:29 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968174&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: Richard Hennessy (richardhennessy) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of hypergeometric bug Initial Comment: Try, kill(all); display2d:false; false integrate(bessel_j(4,x),x); hypergeometric([5/2],[7/2,5],x^2/4)*x^5/1920 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^6/11520 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^7/80640 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^8/645120 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^9/5806080 Only the first entry is right. Richard Hennessy  >Comment By: Dieter Kaiser (crategus) Date: 20100312 21:59 Message: I think this is a general bug of the integrator. In general the integrator can not handle functions with more than one argument correctly, when one of the arguments is an expression or a list. Another example is: First a correct result. The first argument is an atom: (%i10) integrate(gamma_incomplete(a,x^2)*x^2,x); (%o10) 'integrate(gamma_incomplete(a,x^2)*x^2,x) Now the first argument is an expression. We get a wrong result: (%i11) integrate(gamma_incomplete(2*a,x^2)*x^2,x); (%o11) gamma_incomplete(2*a,1)*x^3/3 The reason is that the functions powerlist and rat10 do not handle this type of functions correctly. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968174&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 19:57:48

Bugs item #2969599, was opened at 20100312 14:57 Message generated for change (Tracker Item Submitted) made by richardhennessy 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: Open Resolution: None 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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969599&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 19:54:50

Bugs item #2968344, was opened at 20100311 01:47 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968344&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: gamma_incomplete(1.0, 4.368265444147715e+19) fails Initial Comment: Maxima cannot evaluate gamma_incomplete for the given parameters. I think the asymptotic formula would work quite well here.  >Comment By: Dieter Kaiser (crategus) Date: 20100312 20:54 Message: This is fixed in gamma.lisp revision 1.50. The suggested change of *gammaincompleteeps* has been committed. Closing this bug report as fixed. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100312 04:33 Message: The problem is *gammaincompleteeps*. It is currently 1e16. This is, in general, way too small, because the exit criterion is that abs(del1) < *gammaincompleteeps*. I think that there's no guarantee that del is ever exactly equal to one. I think a more realistic limit would be (* 2 doublefloatepsilon). Making this change allows gamma_incomplete to return 0.0 in this case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968344&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 19:19:30

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: Open 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: 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...>  20100312 18:52:34

Bugs item #2969480, was opened at 20100312 16:54 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969480&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: an error 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 algsys: tried and failed to reduce system to a polynomial in one variable; give up.  an error. To debug this try: debugmode(true);  >Comment By: Dieter Kaiser (crategus) Date: 20100312 19:52 Message: This bug report seems to be a duplicate of report ID: 2969482  algsys: tried and failed to reduce system to a polynomial in. Again this report gives to information about what might be wrong. Closing this bug report as a duplicate. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969480&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 18:50:19

Bugs item #2969482, was opened at 20100312 16:55 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969482&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: algsys: tried and failed to reduce system to a polynomial in 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  >Comment By: Dieter Kaiser (crategus) Date: 20100312 19:50 Message: Please, we need an example to see what might be wrong. Without an example this bug report is invalid. Setting the status to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969482&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 18:47:14

Bugs item #1219846, was opened at 20050613 19:46 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1219846&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  Translator Group: None >Status: Closed >Resolution: Fixed Priority: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: properties of translated functions Initial Comment: After translating a function, the properties of the function are messed up. Consider (%i1) f(x) := x; (%o1) f(x):=x This is OK: (%i2) properties(f); (%o2) [FUNCTION] (%i3) translate(f)$ Three questions: (1) Why is transfun listed five times? (2) Why doesn't f have the function property anymore? (3) Why the upper case? (%i4) properties(f); (%o4) [TRANSFUN,TRANSFUN,TRANSFUN,TRANSFUN,TRANSFUN] (%i5) build_info(); 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 Barton  >Comment By: Dieter Kaiser (crategus) Date: 20100312 19:47 Message: Fixed in outmis.lisp 1.22. Now we get: (%i1) f(x):=x^2; (%o1) f(x):=x^2 (%i2) properties(f); (%o2) [function] (%i3) translate(f); (%o3) [f] (%i4) properties(f); (%o4) [transfun,function] Closing this bug report as fixed. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20060123 18:51 Message: Logged In: YES user_id=28849 2) Don't know. 3) It doesn't seem to be uppercase anymore 1) I think this is caused by this bit in properties in outmis.lisp: ((and (or (get (car y) 'mfexpr*) (fboundp x)) (not (memq '&SYSTEM FUNCTION l))) (nconc l (list (cond ((get x 'translated) '$transfun) ((mgetl x '($rule ruleof)) '$rule) (t '&SYSTEM FUNCTION))))) After translation x if fboundp, so this always succeeds so transfun gets appended for every single property. Don't know what the right thing would be here.  Comment By: Robert Dodier (robert_dodier) Date: 20060121 19:26 Message: Logged In: YES user_id=501686 Modify title to narrow topic.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1219846&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 18:04:51

Bugs item #2969546, was opened at 20100312 12:04 Message generated for change (Tracker Item Submitted) made by jamlatino 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: Open 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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969546&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 15:55:44

Bugs item #2969482, was opened at 20100312 15:55 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969482&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: algsys: tried and failed to reduce system to a polynomial in 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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969482&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 15:54:56

Bugs item #2969480, was opened at 20100312 15:54 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969480&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: an error 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 algsys: tried and failed to reduce system to a polynomial in one variable; give up.  an error. To debug this try: debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2969480&group_id=4933 
From: SourceForge.net <noreply@so...>  20100312 03:33:10

Bugs item #2968344, was opened at 20100310 19:47 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968344&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: gamma_incomplete(1.0, 4.368265444147715e+19) fails Initial Comment: Maxima cannot evaluate gamma_incomplete for the given parameters. I think the asymptotic formula would work quite well here.  >Comment By: Raymond Toy (rtoy) Date: 20100311 22:33 Message: The problem is *gammaincompleteeps*. It is currently 1e16. This is, in general, way too small, because the exit criterion is that abs(del1) < *gammaincompleteeps*. I think that there's no guarantee that del is ever exactly equal to one. I think a more realistic limit would be (* 2 doublefloatepsilon). Making this change allows gamma_incomplete to return 0.0 in this case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968344&group_id=4933 