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}
(45) 
_{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...>  20100320 23:15:51

Bugs item #840848, was opened at 20031112 18:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840848&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: trigreduce doesn't enter unknown functions Initial Comment: trigexpand(f(sin(x)^2)) returns f(sin(x)^2). That is, it doesn't recurse into the arguments of unknown functions. Compare with trigreduce(f(sin(2*x))). Why the discrepancy? If there is a good reason (which I doubt), this behavior should at least be documented, recommending the use of scanmap. I discovered this when trying to simplify an expression involving atan2(...sin(x)^2+cos(x)^2...). Not even atan2 is considered a 'known' function here....  >Comment By: Dieter Kaiser (crategus) Date: 20100321 00:15 Message: Changing the title to reflect the issue. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100320 01:56 Message: I think it is trigreduce which does not enter an unknown function and not trigexpand: We expand an expression which has three terms: an integral, a function f, and a simple term: (%i4) trigexpand('integrate(sin(2*x),x)+f(sin(2*x))+sin(2*x)); (%o4) f(2*cos(x)*sin(x))+2*'integrate(cos(x)*sin(x),x)+2*cos(x)*sin(x) With trigreduce we do not get the original expression. trigreduce does not enter the function f: (%i5) trigreduce(%); (%o5) 'integrate(sin(2*x),x)+f(2*cos(x)*sin(x))+sin(2*x) Another example with trigreduce: (%i11) trigreduce(sin(x)^2); (%o11) (1cos(2*x))/2 This is not reduced: (%i12) trigreduce(f(sin(x)^2)); (%o12) f(sin(x)^2) We can add code in sp1 and gcdred in trgred.lisp to recursively apply these two functions and we will get as expected: (%i29) trigreduce(f(sin(x)^2)); (%o29) f((1cos(2*x))/2) By the way: sin(x)^2 does not expand with trigexpand. Therefore we do not get an expansion for f(sin(x)^2) too. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060713 07:29 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840848&group_id=4933 
From: SourceForge.net <noreply@so...>  20100320 23:13:32

Bugs item #856209, was opened at 20031208 14:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=856209&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency between facts() and facts(v) Initial Comment: In a given context, facts(v) applied with various v must reproduce the entire output of the facts() command. This is not the case: (C14) facts(); (D14) [z + a > 0, b > z] (C15) facts(a); (D15) [] (C16) facts(b); (D16) [b > z] (C17) facts(z); (D17) [b > z] (C18) facts(z + a); (D18) [] It would be OK to have: facts(z); => [z + a > 0,  z + b > 0] facts(a); => [z + a > 0] facts(b); => [ z + b > 0] facts(z+a); => [z + a > 0] facts(a+z); => [z + a > 0] facts(bz); => [ z + b > 0] facts(z+b); => [ z + b > 0]  >Comment By: Dieter Kaiser (crategus) Date: 20100321 00:13 Message: Fixed in compar.lisp revision 1.70. We get for the examples of this bug report: (%i2) assume(z+a>0,b>z)$ (%i3) facts(a); (%o3) [z+a > 0] (%i4) facts(b); (%o4) [b > z] (%i5) facts(z); (%o5) [z+a > 0,b > z] (%i6) facts(z+a); (%o6) [z+a > 0] (%i7) facts(a+z); (%o7) [z+a > 0] But the following does not work. This case has to be deduced from the database. This is not done by the current implementation of $facts: (%i8) facts(bz); (%o8) [] Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091130 01:22 Message: Adding a copy of the posting from the bug report ID: 2035858, which has been closed, because it is a duplicate of this report.  Barton Willis ( willisbl )  20080802 13:07 (%i1) assume(x > a); (%o1) [x>a] OKlist facts about x: (%i2) facts(x); (%o2) [x>a] (%i3) assume(x > a b); (%o3) [x+ba>0] Not OK facts(x) doesn't include x + b  a > 0 (%i4) facts(x); (%o4) [x>a] Based on the user documentation, I think most readers would assume that facts(x) would include x + b  a > 0. The user documentation says: "If item is not the name of a context, facts (item) returns a list of the facts known about item in the current context" Maybe this is mostly a documentation problem; it's not clear what "item" means: (%i10) assume(x > a + b); (%o10) [xba>0] (%i11) facts(a+b); (%o11) []  Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060719 05:48 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=856209&group_id=4933 
From: SourceForge.net <noreply@so...>  20100320 20:20:12

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: Closed >Resolution: Fixed 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: 20100320 21:20 Message: Fixed in compar.lisp revision 1.69. We no longer get the redundant questions: (%i3) limit(r^(b2)*(xr)^2,r,0); Is b2 positive, negative, or zero? n; Is b positive, negative, or zero? z; (%o3) 'limit(r^(b2)*(xr)^2,r,0) Closing this bug report as fixed. Dieter Kaiser  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 
From: SourceForge.net <noreply@so...>  20100320 17:59:48

Bugs item #781657, was opened at 20030801 20:30 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&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: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: binomial(x,x) => 1, but binomial(1,1) => 0 Initial Comment: binomial(x,x) simplifies to 1 yet binomial(1,1) simplifies to 0. (C1) binomial(x,x); (D1) 1 (C2) binomial(1,1); (D2) 0 I agree with (d2) because: 1/(1  x) = 1 + x + x^2 + ... = sum(binomial(1,k) (x) ^k,k,0,inf) implies binomial(1,k) = (1)^k, for integers k >= 0. In the recursion relation [Knuth Vol 1, 1.2.6 Eq. (20)] binomial(r,k) = binomial(r1,k) + binomial(r1,k1) set r > 0, k > 0, and use binomial(0,0) = 1 and binomial (1,0) = 1. From this we get binomial(1,1) = 0. Also see, Knuth Vol. 1 (third edition), Section 1.2.6 Exercise 9. There may be other approaches, but I think using the recursion relations and other identities to extend the domain of the binomial function is the best method. In short, I think the simplification binomial(x,x) ==> 1 should happen only for real x with x >= 0. Barton  >Comment By: Dieter Kaiser (crategus) Date: 20100320 18:59 Message: Fixed in csimp2.lisp revision 1.43.binomial(x,x) no longer simplifies to 1, if the sign of x can be negative. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100313 19:58 Message: The following is an implementation of simpbinocoef which does not simplify binomial(x,x) to the number 1, if the sign of the argument x can be negative. ;; Binomial has Mirror symmetry (defprop %binomial t commuteswithconjugate) (defun simpbinocoef (x vestigial z) (declare (ignore vestigial)) (twoargcheck x) (let ((u (simpcheck (cadr x) z)) (v (simpcheck (caddr x) z)) (y)) (cond ((integerp v) (cond ((minusp v) (if (and (integerp u) (minusp u) (< v u)) (bincomp u ( u v)) 0)) ((or (zerop v) (equal u v)) 1) ((and (integerp u) (not (minusp u))) (bincomp u (min v ( u v)))) (t (bincomp u v)))) ((integerp (setq y (sub u v))) (cond ((zerop1 y) (if (member ($csign u) '($pnz $pn $neg $nz)) (eqtest (list '(%binomial) u v) x) (bincomp u y))) (t (bincomp u y)))) ((complexfloatnumericalevalp u v) (let (($numer t) ($float t)) ($rectform ($float ($makegamma (list '(%binomial) ($float u) ($float v))))))) ((complexbigfloatnumericalevalp u v) ($rectform ($bfloat ($makegamma (list '(%binomial) ($bfloat u) ($bfloat v)))))) (t (eqtest (list '(%binomial) u v) x))))) We get the results (%i1) binomial(x,x); (%o1) binomial(x,x) (%i2) assume(x>0)$ (%i3) binomial(x,x); (%o3) 1 In addition the above code implements the numercial evaluation for floating point arguments more consistent and in addition for complex float and float and complex bigfloat values: (%i4) binomial(0.5,1/2); (%o4) 1.0 (%i5) binomial(0.5,1/2+%i); (%o5) 2.6238968513421611.279746064016377*%i (%i6) binomial(0.5b0,1/2+%i); (%o6) 2.62389685134216b01.279746064016376b0*%i Furthermore, the property mirror symmetry is added: (%i7) conjugate(binomial(1+%i,1%i)); (%o7) binomial(1%i,%i+1) The testsuite has one changed result, because binomial(t,t) does not simplify to the number 1. t has to be declared to be positive. The share_testsuite has no problems. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060708 19:23 Message: Logged In: YES user_id=501686 If, and from the comments it appears it is not certain, we want to make special cases for binomial, we might get the desired effect by using an unevaluated conditional. E.g. stuff like binomial(x, x) > if x = 1 then 0 elseif realp(x) and x > 0 then 1 else 'binomial(x, x). Just a thought.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20030822 06:16 Message: Logged In: YES user_id=581700 Unless I am mistaken, the (finite) limit of BINOMIAL(x,y) at some latticepoint (a,b) in Z^2 exists if and only if a >= 0. The "if" part is easy: Just write the binomial as GAMMA(x+1)/(GAMMA(y+x+1)*GAMMA(y+1)) and observe that Gamma is certainly continuous in the open right halfplane while 1/Gamma is continuous everywhere. Now assume a <= 1. We have the following identity (for the proof see the Maxima code below) %PI*BINOMIAL(x1,y)*BINOMIAL(x,y)*y = SIN(%PI*y)*SIN(%PI*(xy))/SIN(%PI*x) We have a1 >= 0, so we already know that lim BINOMIAL(x1,y) for (x,y)>(a,b) exists. If lim BINOMIAL(x,y) also existed, lim of the whole left hand side expression of this identity would exist. Now, looking at the right hand side expression we observe that it is Zperiodic with respect to x and y (except for a possible sign change). So lim of it at (a,b) exists if and only if lim of it at (0,0) exists, which is clearly not the case. Note: Strictly speaking, the identity is valid on, say, the complement of the union of the parallels through latticepoints to the first and second axis and to the median of the first quadrant, but this leaves us with enough space :) Nevertheless, of course, it's quite customary to define BINOMIAL(a,b)=a*(a1)* ... *(ab+1)/b! for all a in R and b in Z with b >= 0 (for b=0 the numerator is an empty product), in accordance with the binomial series. This definition happens to coincide with limit(limit(BINOMIAL(x,y),y,b),x,a). matchdeclare([%%u,%%v],true)$ sum_is_1(u,v):=is(u+v = 1)$ let(gamma(%%u)*gamma(%%v),%pi/sin(%pi*%%u),sum_is_1,%%u,%%v); let(%%v/gamma(%%u),1/gamma(%%v),sum_is_1,%%u,%%v); letrat:true; lhs:%pi*y*binomial(x,y)*binomial(x1,y); makegamma(%); letsimp(%); letsimp(%); num(%)/trigexpand(expand(denom(%))); lhs=%;  Comment By: Stavros Macrakis (macrakis) Date: 20030814 18:16 Message: Logged In: YES user_id=588346 I am not sure what you mean by "there may be other approaches". binomial(a,a) should simplify to Q if and only if the double limit exists: limit binomial(x,y) = Q x>a y>a A necessary (but in general not sufficient) condition for this to exist is that the two single limits exist and are equal: limit binomial(a,y) = limit binomial(x,a) = Q y>a x>a If the limit is not welldefined, then binomial(x,x) is not well defined, and it will cause incorrect results in some case or another to arbitrarily set it to some value. I don't know if this limit is or isn't welldefined. I do know that depending on identities with unspecified domains of validity is dangerous....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 
From: SourceForge.net <noreply@so...>  20100320 17:57:14

Bugs item #2973860, was opened at 20100320 17:57 Message generated for change (Tracker Item Submitted) made by xgateruq9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2973860&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: Oliver Kullmann (xgateruq9) Assigned to: Nobody/Anonymous (nobody) Summary: string in term causes error in evaluation Initial Comment: declare(f, posfun); is(f("x") > 0); Maxima encountered a Lisp error: "x" is not of type LIST.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2973860&group_id=4933 
From: SourceForge.net <noreply@so...>  20100320 01:32:37

Bugs item #935030, was opened at 20040414 18:17 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&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: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp with algebraic == true Initial Comment: With algebraic == true, ratsimp doesn't fully simplify some expressions. Here is an example (C1) display2d : false$ (C2) algebraic : true$ (C3) integrate(1/(2+x^3),x)$ (C4) ratsimp(diff(%,x)); (D4) 4*2^(2/3)/(4*2^(2/3)*x^3+8*2^(2/3)) (C5) ratsimp(%); (D5) 1/(x^3+2) Maybe this is the purpose of fullratsimp, but it seems odd that ratsimp fails to cancel the factor of 2^(2/3). I discovered this when I ran run_testsuite with algebraic == true. (C6) build_info(); Maxima version: 5.9.0.1cvs Maxima build date: 7:58 4/5/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.7.0 Barton  >Comment By: Dieter Kaiser (crategus) Date: 20100320 02:32 Message: This behavior is no longer present in Maxima 5.20post: (%i1) algebraic:true; (%o1) true (%i2) integrate(1/(2+x^3),x); (%o2) log(2^(2/3)*x^22*x+2^(4/3))/(3*2^(5/3)) +atan((2^(5/3)*x2)/(2*sqrt(3)))/(2^(2/3)*sqrt(3)) +log(x+2^(1/3))/(3*2^(2/3)) (%i3) ratsimp(diff(%,x)); (%o3) 1/(x^3+2) This works for algebraic:false the same way. We get immediately a fully simplified and correct result from ratsimp. The reason might be that the simplification of powers of integers has been implemented more consistent the last year. Closing this bug report as "Works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060729 08:13 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20040419 21:55 Message: Logged In: YES user_id=588346 Though this is annoying and surprising, it *is* documented: >>>>>>>>>(fullratsimp) When nonrational expressions are involved, one call to RATSIMP followed as is usual by nonrational ("general") simplification may not be sufficient to return a simplified result. <<<<<<<<< Also, the algebraic flag only changes the behavior with gcd=spmod. With gcd=subres (the default), you need two ratsimp's regardless of the setting of algebraic.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=935030&group_id=4933 
From: SourceForge.net <noreply@so...>  20100320 00:56:39

Bugs item #840848, was opened at 20031112 18:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840848&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand doesn't enter unknown functions Initial Comment: trigexpand(f(sin(x)^2)) returns f(sin(x)^2). That is, it doesn't recurse into the arguments of unknown functions. Compare with trigreduce(f(sin(2*x))). Why the discrepancy? If there is a good reason (which I doubt), this behavior should at least be documented, recommending the use of scanmap. I discovered this when trying to simplify an expression involving atan2(...sin(x)^2+cos(x)^2...). Not even atan2 is considered a 'known' function here....  >Comment By: Dieter Kaiser (crategus) Date: 20100320 01:56 Message: I think it is trigreduce which does not enter an unknown function and not trigexpand: We expand an expression which has three terms: an integral, a function f, and a simple term: (%i4) trigexpand('integrate(sin(2*x),x)+f(sin(2*x))+sin(2*x)); (%o4) f(2*cos(x)*sin(x))+2*'integrate(cos(x)*sin(x),x)+2*cos(x)*sin(x) With trigreduce we do not get the original expression. trigreduce does not enter the function f: (%i5) trigreduce(%); (%o5) 'integrate(sin(2*x),x)+f(2*cos(x)*sin(x))+sin(2*x) Another example with trigreduce: (%i11) trigreduce(sin(x)^2); (%o11) (1cos(2*x))/2 This is not reduced: (%i12) trigreduce(f(sin(x)^2)); (%o12) f(sin(x)^2) We can add code in sp1 and gcdred in trgred.lisp to recursively apply these two functions and we will get as expected: (%i29) trigreduce(f(sin(x)^2)); (%o29) f((1cos(2*x))/2) By the way: sin(x)^2 does not expand with trigexpand. Therefore we do not get an expansion for f(sin(x)^2) too. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060713 07:29 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=840848&group_id=4933 