[Reduce-algebra-developers] Bug in definite integration? From: Дмитрий Гончаров - 2013-01-12 15:20:00 Attachments: REDUCEbug.jpg ```Results of calculating definite integrals is different in the case below, nevertheless indefinite integrals and limits are the same. Value of 12 is incorrect. Looks like a bug. Screenshot attached. Any comments? Thanks. D. ht:=4-(x-1)^2; 2 ht := - x + 2*x + 3 ht1:=x*ht; 2 ht1 := x*( - x + 2*x + 3) int(x*ht,x); 2 2 x *( - 3*x + 8*x + 18) ------------------------- 12 int(ht1,x); 2 2 x *( - 3*x + 8*x + 18) ------------------------- 12 int(x*ht,x,-1,3); 12 int(ht1,x,-1,3); 32 ---- 3 ```
 [Reduce-algebra-developers] Bug in definite integration? From: Дмитрий Гончаров - 2013-01-12 15:20:00 Attachments: REDUCEbug.jpg ```Results of calculating definite integrals is different in the case below, nevertheless indefinite integrals and limits are the same. Value of 12 is incorrect. Looks like a bug. Screenshot attached. Any comments? Thanks. D. ht:=4-(x-1)^2; 2 ht := - x + 2*x + 3 ht1:=x*ht; 2 ht1 := x*( - x + 2*x + 3) int(x*ht,x); 2 2 x *( - 3*x + 8*x + 18) ------------------------- 12 int(ht1,x); 2 2 x *( - 3*x + 8*x + 18) ------------------------- 12 int(x*ht,x,-1,3); 12 int(ht1,x,-1,3); 32 ---- 3 ```
 Re: [Reduce-algebra-developers] Bug in definite integration? From: Arthur Norman - 2013-01-12 16:52:20 ```On Sat, 12 Jan 2013, Дмитрий Гончаров wrote: > Results of calculating definite integrals is different in the case > below, nevertheless indefinite integrals and limits are the same. > Value of 12 is incorrect. Looks like a bug. > Any comments? Thanks for the very neatly presented and concise case, which indeed looks like a bug! The definite integration code has a load of quite elaborate pattern matching that is there to catch special cases where indefinite integration might fail, and my presumption is that one of the rules there has triggered when it should not. I observe that x*(4-(x-1)^2 fails while (4-(x-1)^2)*x behaves OK. When I do initial tracing of the code I observe it diving in through e.g. simpinteg that is code in packages/defint where the patterns and rewrites are. I have not just yet tracked which is the bad one! Arthur ```
 Re: [Reduce-algebra-developers] Bug in definite integration? From: Arthur Norman - 2013-01-12 20:42:52 ```I see bad things happening when indefint2 and transf and defint_choose get activated. Furthermore I can trim the bad case down even further to int(3*(x^2-x), x, 0, 1); int((x^2-x)*3, x, 0, 1); but right now I do not understand what defint_choose and friends are trying to do. But it seems to be of the essence that there is a subtraction there in x^2-x. Hahaha int(2*(x-a), x, 0, 1); yields zero incorrectly. int(1*(x-a), x, 0, 1) yields an answer that contains the "indefint2" operator, as does int((2/3)*(x-a), x, p, q); So something there is well messed up! Arthur ```
 Re: [Reduce-algebra-developers] Bug in definite integration? From: Arthur Norman - 2013-01-13 11:05:58 ```This is as much to other developers as to the original poster... I am narrowing down issues at least a bit. In defintb.red the rules for defint_choose return "unknown" in a default case. I guess I will observe that this already means there would be a misery if the user happened to have a variable by that name in play! Because it is an algebraic form this can then participate in algebra! So the second entry in indefint2_rules in definth.red can map indefint(n, A-B, x, y) onto indefint2(n, A, x, y) - indefint2(n, B, x, y); then in due course defint_choose may return unknown and if one is unlucky then the two parts will both be unknown and will cancel. In fact if the case I have been trying n=3 and the expression I get there is (3*unknown-3*unknown) which leads to a result of zero being handed back to the user. I believe that the simplest way I can make things more robust will be to put in "where freeof(A, unknown)" in a bunch of the rules, and I know that by doing that I can fix the particular case that has been reported... but this still feels very delicate to me. I also look at the penultimate rule in indefint2_rules that maps indefint2(b, f, x, y) to b*indefint2(f,x,y) and the constraint it applies is that b does not involve x (which seems 100% sensible to me) but that b is not 1. This uses "~~b" and ~~ pattern variables are supposed to do special things as regards the neutral value for the associated operator. So had there been a visible "*" in the pattern then b could have ended up as 1 even without a * visible in the target. But here ~~b is not adjacant to any operator and so this should not apply. I think I believe that the "~~b" is illegal abd should be merely "~b" and thatqualifier b!=1 is not wanted. As things are this can sometimes lead to messed up results that have the intermediate form indefint2 still left visible. So I have checked in a new defint/definth.red that addresses some of the above and that will I hope be at least a little better, but perhaps further investigation of that package is called for? Arthur ```