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
(2) 
2
(6) 
3
(7) 
4
(2) 
5
(9) 
6
(14) 
7
(10) 
8
(6) 
9
(12) 
10
(1) 
11
(4) 
12
(9) 
13
(5) 
14
(18) 
15

16
(3) 
17
(3) 
18
(3) 
19
(1) 
20
(2) 
21
(5) 
22
(14) 
23
(2) 
24
(5) 
25
(1) 
26

27
(4) 
28
(8) 
29
(17) 
30
(8) 





From: SourceForge.net <noreply@so...>  20091111 22:43:52

Bugs item #2184396, was opened at 20081021 15:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong factorization of sqrt() Initial Comment: Dear Developers of Maxima, I found a wrong behavihor of sqrt(). It is a principle that sqrt(X*Y) should not be factorized to sqrt(X)*sqrt(Y) unless X and Y can be judged to be nonnegative. I found a case in which this principle is broken. Here is a program for demonstration:  /* * wrong_factorization_of_sqrt.maxima: * * S.Adachi 2008/10/01 */ display2d:false; /* real for 1 <= x <= 2 */ correct:sqrt((11/x)*(2/x1)); /* real for 2sqrt(2) <= x <= 2+sqrt(2) */ INCORRECT:sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); INCORRECT_AT_2:at(INCORRECT,[x=2]); SHOULD_BE_POSITIVE:float(INCORRECT_AT_2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(wrong_factorization_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/307/wrong_factorization_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) correct:sqrt((11/x)*(2/x1)) (%o3) sqrt((11/x)*(2/x1)) (%i4) INCORRECT:sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) (%o4) sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) (%i5) INCORRECT_AT_2:at(INCORRECT,[x = 2]) (%o5) sqrt((2sqrt(2))/21)*sqrt(1(sqrt(2)+2)/2) (%i6) SHOULD_BE_POSITIVE:float(INCORRECT_AT_2) (%o6) 0.70710678118655 (%o7) "wrong_factorization_of_sqrt.maxima"  At first, as is seen from (%i2) and (%o2), sqrt(11/x)*(2/x1)) is not factorized to sqrt(...)*sqrt(...) in any automatic way. This is the correct behavihor. Next, as is seen from (%i3) and (%o3), sqrt(1(2sqrt(2))/x)*((2+sqrt(2))/x1)) is factorized to sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) in an automatic way. THIS IS AN INCORRECT BEHAVIOR. This expression is nonnegative for 2sqrt(2) <= x <= 2+sqrt(2). However, as is demonstrated by (%i4)(%o5), the calculated expression takes a negative value at x=2. Please stop the incorrect factorization of sqrt(X*Y) to sqrt(X)*sqrt(Y). Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20091111 23:43 Message: I think I have found the bug in the routine compsplt. (defun compsplt (x) (cond ((atom x) (setq lhs x rhs 0)) ((atom (car x)) (setq lhs x rhs 0)) > ((not (null (cdr (symbols x)))) (compsplt2 x)) (t (compsplt1 x)))) At the marked line Maxima tests the CDR of the result of the function SYMBOLS. SYMBOLS returns a list of all variables of an expression. The list is of the form '($X $Y ...), where $X, $Y are the variables. Because COMPSPLT takes the CDR of SYMBOLS, one symbol in an expression is not recognized. Later in the algorithm the sign of this variable is not taken into account. For almost all expression this behavior seems to be no problem, but not for the examples of this bug report. When we change the test of the marked line: ((not (null (symbols x))) ... the sign of the given examples of this bug report are correct: (%i3) sign(1(2+sqrt(2))*x); (%o3) pnz (%i4) sign(1(2+sqrt(2))/x); (%o4) pnz and the reported expression does not longer factorize wrongly: (%i5) sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); (%o5) sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) One example of the testsuite no longer works. It is one of the new examples for the sign of the abs function. This is the example: (%i2) assume(abs(x)<%e/2+sin(1)); (%o2) [sin(1)+%e/2 > abs(x)] (%i3) is(x>2*%e); (%o3) true This will be the new result: (%i6) assume(abs(x)<%e/2+sin(1)); (%o6) [abs(x)+sin(1)+%e/2 > 0] (%i7) is(x>2*%e); (%o7) unknown This test no longer works, because the ordering of the terms will change. The reason is that COMPSPLT calls splitsum for one variable x in the expression too. So, with one exception the testsuite and the share_testsuite have no problems with the suggested change in COMPSPLT. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091111 01:27 Message: For the record. Again two example for a wrong sign: (%i3) sign(1(1+sqrt(2))/x); (%o3) neg (%i4) sign(1(1+sqrt(2))*x); (%o4) neg For these expressions the functions splitprod and splitsum are called. I have not figured out up to now the reason for the bug, but the variable x is lost somewhere and not taken into account to determine the sign. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091008 00:10 Message: Maxima can simplify the sqrt function correctly. No simplification, when the sign of a is not known: (%i1) sqrt(a*z); (%o1) sqrt(a*z) Simplification for a a positive or b a negative value: (%i2) assume(a>0)$ (%i3) sqrt(a*z); (%o3) sqrt(a)*sqrt(z) (%i4) assume(b<0)$ (%i5) sqrt(b*z); (%o5) sqrt(b)*sqrt(z) The problem of this bug report is one of the factors of the example. The sign is wrongly determined to be negative: (%i8) sign(1(2sqrt(2))/x); (%o8) neg Therefore Maxima does the above simplification, which is wrong. Dieter Kaiser  Comment By: boud (boud1) Date: 20090219 03:31 Message: There's another bug related to this one IMHO: [ 2202764 ] Taylor series of sqrt(1+xy) http://sourceforge.net/tracker/index.php?func=detail&aid=2202764&group_id=4933&atid=104933 [This is why i came here  i had a Taylor series bug that i think is equivalent.] HACK SOLUTION: The bug is solved for me (maxima 5.10.0, debianetch) by setting radexpand : false; ANALYSIS: However, i'm not convinced that this is a sufficient response to the bug. i don't really know maxima well enough to know what would be most reasonable. (1) Set radexpand to false by default? And add more warnings in the documentation (or do we expect users to learn mathematics elsewhere than in software documentation?) (2) Tell maxima not to rewrite sqrt(X) as %i sqrt(X) when domain:real ? (3) Extend the "is X positive, negative or zero?" question to the cases where it still needs to be asked but so far does not get asked, i.e. when deciding whether sqrt(X*Y) = sqrt(X)*sqrt(Y) or sqrt(X*Y) =  sqrt(X)*sqrt(Y) ? (4) Decide not to invert the order of an expression inside sqrt( ... ) if domain:real, except when it's sure that the expression is positive?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&group_id=4933 
From: SourceForge.net <noreply@so...>  20091111 07:51:08

Bugs item #2895770, was opened at 20091111 16:51 Message generated for change (Tracker Item Submitted) made by satoshi_adachi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2895770&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: apply(sum,...) behaves as if it is apply(sum,ev(...)) Initial Comment: Dear Developers of Maxima, This letter informs you that sum() and product() behave strangely when they are used as the first argument of apply(). The behavior actually observed for apply(sum, LIST_OF_ARGUMENTS) is not the expected one for it but coincides with the expected one for apply(sum, ev(LIST_OF_ARGUMENTS)). The same behavior is observed for apply(product, LIST_OF_ARGUMENTS). In my understanding, this is thought to be a bug for sum() and product(). Below, I will explain this behavior of sum() and product().  (1) Normal behavior of apply()  The following program demonstrates the normal behavior of apply(): ............................................................................... /* * behavior_of_apply.maxima: * * S.Adachi 2009/11/10 */ display2d:false; arg_lst:[x]; OK1:apply(sin, arg_lst); x:%pi/2; OK2:apply(sin, arg_lst); OK3:apply(sin, ev(arg_lst)); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(behavior_of_apply.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/behavior_of_apply.maxima (%i2) display2d : false (%o2) false (%i3) arg_lst:[x] (%o3) [x] (%i4) OK1:apply(sin,arg_lst) (%o4) sin(x) (%i5) x:%pi/2 (%o5) %pi/2 (%i6) OK2:apply(sin,arg_lst) (%o6) sin(x) (%i7) OK3:apply(sin,ev(arg_lst)) (%o7) 1 (%o8) "behavior_of_apply.maxima" ............................................................................... Please look at (%i6) and (%o6). At this point, arg_lst is equal to [x] and thereby the result of apply(sin, arg_lst) becomes sin(x). Even though the variable x is given the value %pi/2, this value is not used when apply() is called with the arguments sin and [x]. This is the normal expected behavior of apply(). If we want [x] to be evaluated in the current environment, we have to use ev(arg_lst) instead of arg_lst (see (%i7) and (%o7)).  (2) Strange behavior of sum() when it is used as 1st argument of apply()  The following program demonstrates the strange behavior of sum() when it is used as the first argument of apply(): ............................................................................... /* * strange_behavior_of_sum.maxima: * * S.Adachi 2009/11/10 */ display2d:false; arg_lst:[f(i), i, 1, n]; OK1:apply(sum, arg_lst); n:4; STRANGE:apply(sum, arg_lst); OK2:apply(sum, ev(arg_lst)); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(strange_behavior_of_sum.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/strange_behavior_of_sum.maxima (%i2) display2d : false (%o2) false (%i3) arg_lst:[f(i),i,1,n] (%o3) [f(i),i,1,n] (%i4) OK1:apply(sum,arg_lst) (%o4) 'sum(f(i),i,1,n) (%i5) n:4 (%o5) 4 (%i6) STRANGE:apply(sum,arg_lst) (%o6) f(4)+f(3)+f(2)+f(1) (%i7) OK2:apply(sum,ev(arg_lst)) (%o7) f(4)+f(3)+f(2)+f(1) (%o8) "strange_behavior_of_sum.maxima" ............................................................................... In this example, arg_lst is set to [f(i),i,1,n] at (%i3). After arg_lst is prepared, n is set to 4 at (%i5). At (%i6), apply(sum,arg_lst) is calculated. At (%i7), apply(sum,ev(arg_lst)) is calculated. Both results become f(4)+f(3)+f(2)+f(1) as are seen at (%o6) and (%o7). This result is expected for apply(sum,ev(arg_lst)) but is never for apply(sum,arg_lst). The result expected for apply(sum,arg_lst) is 'sum(f(i),i,1,n). Namely, apply(sum,arg_lst) actually behaves as if it is apply(sum,ev(arg_lst)). I think that this is a bug.  (3) This bug of sum() is serious for programming.  This bug of sum() when it is supplied to the first argument of apply() is very serious one for writing programs. The bug causes a serious confusion of the object language and the observation language (programming language). To demonstrate how serious this bug is, I have prepared a toy program, which traces the process of calculation for a given expression. It is as follows: ............................................................................... /* * demonstration_of_strangeness_of_sum.maxima: * * S.Adachi 2009/11/10 */ display2d:false; trace_calc(X) := trace_calc_sub(X, 0); trace_calc_sub(X, indent) := block([res], if (atom(X)) then ( print(smake(indent, " "),"[ATOM]:",X), res:X ) else ( block([n,i,arg_lst,a,b], print(smake(indent, " "),"[FUNC]: OP =",op(X)), arg_lst:[], n:length(X), for i:1 thru n do ( a:part(X,i), print(smake(indent, " "),"[FUNC]: ARG(",i,") = ",a," >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b]) ), res:apply(op(X),arg_lst), print(smake(indent, " "),"[FUNC]: RES = ",res) ) ), res); ex1_OK:a*b*F(n)+c*G(n); ex1_tr_OK:trace_calc(ex1_OK); ex2_OK:a*b*sum(f(i),i,1,n)+c*product(g(i),i,1,n); ex2_tr_BAD:trace_calc(ex2_OK); /* END */ ............................................................................... The result of execution is as follows: ............................................................................... Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(demonstration_of_strangeness_of_sum.maxima) batching #p/Volumes/HFS+2/home/adachi/work/406/demonstration_of_strangeness_of_sum.maxima (%i2) display2d : false (%o2) false (%i3) trace_calc(X):=trace_calc_sub(X,0) (%o3) trace_calc(X):=trace_calc_sub(X,0) (%i4) trace_calc_sub(X,indent):=block([res], if atom(X) then (print(smake(indent," "),"[ATOM]:",X),res:X) else block([n,i,arg_lst,a,b], print(smake(indent," "),"[FUNC]: OP =", op(X)),arg_lst:[],n:length(X), for i thru n do (a:part(X,i), print(smake(indent," "), "[FUNC]: ARG(",i,") = ",a, " >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b])), res:apply(op(X),arg_lst), print(smake(indent," "),"[FUNC]: RES = ", res)),res) (%o4) trace_calc_sub(X,indent):=block([res], if atom(X) then (print(smake(indent," "),"[ATOM]:",X),res:X) else block([n,i,arg_lst,a,b], print(smake(indent," "),"[FUNC]: OP =", op(X)),arg_lst:[],n:length(X), for i thru n do (a:part(X,i), print(smake(indent," "), "[FUNC]: ARG(",i,") = ",a, " >"), b:trace_calc_sub(a,indent+1), arg_lst:append(arg_lst,[b])), res:apply(op(X),arg_lst), print(smake(indent," "),"[FUNC]: RES = ", res)),res) (%i5) ex1_OK:a*b*F(n)+c*G(n) (%o5) c*G(n)+a*b*F(n) (%i6) ex1_tr_OK:trace_calc(ex1_OK) [FUNC]: OP = + [FUNC]: ARG( 1 ) = c*G(n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = c > [ATOM]: c [FUNC]: ARG( 2 ) = G(n) > [FUNC]: OP = G [FUNC]: ARG( 1 ) = n > [ATOM]: n [FUNC]: RES = G(n) [FUNC]: RES = c*G(n) [FUNC]: ARG( 2 ) = a*b*F(n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = a > [ATOM]: a [FUNC]: ARG( 2 ) = b > [ATOM]: b [FUNC]: ARG( 3 ) = F(n) > [FUNC]: OP = F [FUNC]: ARG( 1 ) = n > [ATOM]: n [FUNC]: RES = F(n) [FUNC]: RES = a*b*F(n) [FUNC]: RES = c*G(n)+a*b*F(n) (%o6) c*G(n)+a*b*F(n) (%i7) ex2_OK:a*b*sum(f(i),i,1,n)+c*product(g(i),i,1,n) (%o7) c*'product(g(i),i,1,n)+a*b*'sum(f(i),i,1,n) (%i8) ex2_tr_BAD:trace_calc(ex2_OK) [FUNC]: OP = + [FUNC]: ARG( 1 ) = c*'product(g(i),i,1,n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = c > [ATOM]: c [FUNC]: ARG( 2 ) = 'product(g(i),i,1,n) > [FUNC]: OP = product [FUNC]: ARG( 1 ) = g(i) > [FUNC]: OP = g [FUNC]: ARG( 1 ) = i > [ATOM]: i [FUNC]: RES = g(i) [FUNC]: ARG( 2 ) = i > [ATOM]: i [FUNC]: ARG( 3 ) = 1 > [ATOM]: 1 [FUNC]: ARG( 4 ) = n > [ATOM]: n [FUNC]: RES = 'product(g(i),i,1,4) [FUNC]: RES = c*'product(g(i),i,1,4) [FUNC]: ARG( 2 ) = a*b*'sum(f(i),i,1,n) > [FUNC]: OP = * [FUNC]: ARG( 1 ) = a > [ATOM]: a [FUNC]: ARG( 2 ) = b > [ATOM]: b [FUNC]: ARG( 3 ) = 'sum(f(i),i,1,n) > [FUNC]: OP = sum [FUNC]: ARG( 1 ) = f(i) > [FUNC]: OP = f [FUNC]: ARG( 1 ) = i > [ATOM]: i [FUNC]: RES = f(i) [FUNC]: ARG( 2 ) = i > [ATOM]: i [FUNC]: ARG( 3 ) = 1 > [ATOM]: 1 [FUNC]: ARG( 4 ) = n > [ATOM]: n [FUNC]: RES = 'sum(f(i),i,1,4) [FUNC]: RES = a*b*'sum(f(i),i,1,4) [FUNC]: RES = c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4) (%o8) c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4) (%o9) "demonstration_of_strangeness_of_sum.maxima" ............................................................................... This expected result at (%o8) is c*'product(g(i),i,1,n)+a*b*'sum(f(i),i,1,n). But the calculated result is c*'product(g(i),i,1,4)+a*b*'sum(f(i),i,1,4). Namely, n is accidentally replaced by 4. This strange result is caused by the coincidence of the names of the variable n in the observation language (programming language) and the variable n in the object language (given expression). The value of the variable n used in the program is accidentally transferred to the variable n in the object expression.  (4) Strange behavior of product() when it is used as 1st argument of apply()  As is seen in the demonstration of (3), product() also has the same bug as sum() when it is supplied to the first argument of apply(). I do not know when this behavior of sum() and product() was brought into the code. It might be some relatively recent time. In this case, this behavior could be called a bug. Or, the behavior might originate at a long time ago in the code. In this case, you may say that this is not a bug but is a part of ''specification'' of Maxima. Even if you may, this is a serious inconsistency in Maxima and lets programming in Maxima be more difficult and be ugly since some workaround is necessary. I hope that this bug (in my understanding) will be fixed in future. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2895770&group_id=4933 
From: SourceForge.net <noreply@so...>  20091111 02:11:27

Bugs item #2888450, was opened at 20091029 11:21 Message generated for change (Settings changed) made by ynrobyvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2888450&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: Invalid Priority: 5 Private: No Submitted By: Rudolf Vyborny (ynrobyvr) Assigned to: Nobody/Anonymous (nobody) Summary: wrong result Initial Comment: wrong result in calculating limit of x*floor(1/x) as x goes to 0  >Comment By: Rudolf Vyborny (ynrobyvr) Date: 20091111 12:11 Message: Answer to rtoy. The limit is 1, your proof is essentially orrect. I prefer the following proof: 1/x1<floor(1/x)<=1/x, hence for x>0 we have 1x<xfloor(1/x)<=1. It follows that the limit from the right is 1. The proof for the limit from the left is similar. Answer to crategus: The function does have a limit, namely 0. Your staement 2. is correct but your conclusion 3. is erroneous.  Comment By: Dieter Kaiser (crategus) Date: 20091110 07:11 Message: Sorry, I have no mathematical proof. I have come to the conclusion because of the follwing: 1. The function floor(x) is discontinuous. 2. The function x*floor(1/x) has an infinite number of points of discontinuity in any infinitesimal intervall when aproching zero. 3. Therefore, the function does not approach a limit. I could be wrong. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091110 03:17 Message: Isn't the limit 1? Let any x small enough, 1/x = n + e, where n is an integer and e < 1. Then floor(1/x) = n and x*floor(1/x) is n/(n+e) = 1  e/(n+e). As n gets larger (and x gets smaller), this approaches 1. Did I make a mistake?  Comment By: Dieter Kaiser (crategus) Date: 20091110 02:59 Message: With Maxima 5.19post I get a noun form too. There have been serveal changes the last time to improve limit. Furthermore, I think the limit of the example is not defined. Therefore, it seems to be not wrong to return a noun form. Setting the status to pending and works for me. Dieter Kaiser  Comment By: Rudolf Vyborny (ynrobyvr) Date: 20091029 13:02 Message: I got the wrong result, namely 0. I attached my file  Comment By: Raymond Toy (rtoy) Date: 20091029 12:12 Message: I get the noun form back. Not wrong, but could be better. What were you expecting?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2888450&group_id=4933 
From: SourceForge.net <noreply@so...>  20091111 00:28:03

Bugs item #2184396, was opened at 20081021 15:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong factorization of sqrt() Initial Comment: Dear Developers of Maxima, I found a wrong behavihor of sqrt(). It is a principle that sqrt(X*Y) should not be factorized to sqrt(X)*sqrt(Y) unless X and Y can be judged to be nonnegative. I found a case in which this principle is broken. Here is a program for demonstration:  /* * wrong_factorization_of_sqrt.maxima: * * S.Adachi 2008/10/01 */ display2d:false; /* real for 1 <= x <= 2 */ correct:sqrt((11/x)*(2/x1)); /* real for 2sqrt(2) <= x <= 2+sqrt(2) */ INCORRECT:sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); INCORRECT_AT_2:at(INCORRECT,[x=2]); SHOULD_BE_POSITIVE:float(INCORRECT_AT_2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(wrong_factorization_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/307/wrong_factorization_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) correct:sqrt((11/x)*(2/x1)) (%o3) sqrt((11/x)*(2/x1)) (%i4) INCORRECT:sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) (%o4) sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) (%i5) INCORRECT_AT_2:at(INCORRECT,[x = 2]) (%o5) sqrt((2sqrt(2))/21)*sqrt(1(sqrt(2)+2)/2) (%i6) SHOULD_BE_POSITIVE:float(INCORRECT_AT_2) (%o6) 0.70710678118655 (%o7) "wrong_factorization_of_sqrt.maxima"  At first, as is seen from (%i2) and (%o2), sqrt(11/x)*(2/x1)) is not factorized to sqrt(...)*sqrt(...) in any automatic way. This is the correct behavihor. Next, as is seen from (%i3) and (%o3), sqrt(1(2sqrt(2))/x)*((2+sqrt(2))/x1)) is factorized to sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) in an automatic way. THIS IS AN INCORRECT BEHAVIOR. This expression is nonnegative for 2sqrt(2) <= x <= 2+sqrt(2). However, as is demonstrated by (%i4)(%o5), the calculated expression takes a negative value at x=2. Please stop the incorrect factorization of sqrt(X*Y) to sqrt(X)*sqrt(Y). Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20091111 01:27 Message: For the record. Again two example for a wrong sign: (%i3) sign(1(1+sqrt(2))/x); (%o3) neg (%i4) sign(1(1+sqrt(2))*x); (%o4) neg For these expressions the functions splitprod and splitsum are called. I have not figured out up to now the reason for the bug, but the variable x is lost somewhere and not taken into account to determine the sign. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091008 00:10 Message: Maxima can simplify the sqrt function correctly. No simplification, when the sign of a is not known: (%i1) sqrt(a*z); (%o1) sqrt(a*z) Simplification for a a positive or b a negative value: (%i2) assume(a>0)$ (%i3) sqrt(a*z); (%o3) sqrt(a)*sqrt(z) (%i4) assume(b<0)$ (%i5) sqrt(b*z); (%o5) sqrt(b)*sqrt(z) The problem of this bug report is one of the factors of the example. The sign is wrongly determined to be negative: (%i8) sign(1(2sqrt(2))/x); (%o8) neg Therefore Maxima does the above simplification, which is wrong. Dieter Kaiser  Comment By: boud (boud1) Date: 20090219 03:31 Message: There's another bug related to this one IMHO: [ 2202764 ] Taylor series of sqrt(1+xy) http://sourceforge.net/tracker/index.php?func=detail&aid=2202764&group_id=4933&atid=104933 [This is why i came here  i had a Taylor series bug that i think is equivalent.] HACK SOLUTION: The bug is solved for me (maxima 5.10.0, debianetch) by setting radexpand : false; ANALYSIS: However, i'm not convinced that this is a sufficient response to the bug. i don't really know maxima well enough to know what would be most reasonable. (1) Set radexpand to false by default? And add more warnings in the documentation (or do we expect users to learn mathematics elsewhere than in software documentation?) (2) Tell maxima not to rewrite sqrt(X) as %i sqrt(X) when domain:real ? (3) Extend the "is X positive, negative or zero?" question to the cases where it still needs to be asked but so far does not get asked, i.e. when deciding whether sqrt(X*Y) = sqrt(X)*sqrt(Y) or sqrt(X*Y) =  sqrt(X)*sqrt(Y) ? (4) Decide not to invert the order of an expression inside sqrt( ... ) if domain:real, except when it's sure that the expression is positive?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&group_id=4933 