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}
(10) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(3) 
2
(6) 
3
(3) 
4
(2) 
5
(2) 
6
(6) 
7
(2) 
8

9
(1) 
10
(1) 
11
(2) 
12

13
(1) 
14
(2) 
15
(17) 
16
(5) 
17
(2) 
18
(4) 
19

20
(1) 
21

22
(22) 
23
(5) 
24

25

26
(1) 
27

28
(4) 
29
(1) 
30






From: SourceForge.net <noreply@so...>  20080602 05:25:32

Bugs item #1981518, was opened at 20080601 16:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&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: 6 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: Calling desolve inside a "for...do" makes it loop endlessly Initial Comment: In 5.14.0 (CLISP 2.41) calling desolve inside a "for...do" block makes it loop endlessly. (%i1) for i : 1 thru 3 do (print(i)); 1 2 3 (%o1) done (%i2) for i : 1 thru 3 do (desolve('diff(foo(x),x)=1,foo(x)), print(i)); 1 1 1 ... Seems to happen with CLISP and SBCL, but not with GCL and CMUCL. Actually, the problem is related to ilt which is called by desolve. http://www.math.utexas.edu/pipermail/maxima/2008/011592.html  >Comment By: Robert Dodier (robert_dodier) Date: 20080601 23:25 Message: Logged In: YES user_id=501686 Originator: NO Looks like MDO in src/mlisp.lisp uses a variable (VAR) which is declared special and clobbered by some function called from ilt. Changing the name from VAR to MYVAR avoids the name collision. I'll commit a patch in a day or two.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981518&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 04:46:58

Bugs item #1913067, was opened at 20080312 22:06 Message generated for change (Comment added) made by robertmarik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913067&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: Ximin Luo (infinity0x) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot integrate 1/(1+x^n) Initial Comment: Maxima cannot integrate functions of the form 1/(1+x^n) for n >= 7. Mathematica is capable of this. Maxima attempts the integration via an algorithm which seems to involve taking partial fractions. For example, if you try to integrate 1/(1+x^7) for example, Maxima gives: log(1+x)/7  integral(x^52*x^4+3*x^34*x^2+5*x6)/(x^6x^5+x^4x^3+x^2x+1) / 7 I'm guessing a different algorithm (such as that employed by Mathematica) is required to give a fully symbolic answer. For the record, the integral(1/(1+x^7)) is: Log[1 + x]/7  (Cos[Pi/7]*Log[1 + x^2  2*x*Cos[Pi/7]])/7  (Cos[(3*Pi)/7]*Log[1 + x^2  2*x*Cos[(3*Pi)/7]])/7  (Cos[(5*Pi)/7]*Log[1 + x^2  2*x*Cos[(5*Pi)/7]])/7 + (2*ArcTan[(x  Cos[Pi/7])*Csc[Pi/7]]* Sin[Pi/7])/7 + (2*ArcTan[(x  Cos[(3*Pi)/7])* Csc[(3*Pi)/7]]*Sin[(3*Pi)/7])/7 + (2*ArcTan[(x  Cos[(5*Pi)/7])* Csc[(5*Pi)/7]]*Sin[(5*Pi)/7])/7  Additionally, this also means that we can calculate the integral(that nasty rational function), by calculating 7 * ( log(1+x)/7  integral(1/(1+x^7)) ) As a side note, Mathematica also cannot give integral(that nasty rational function) fully symbolically. Instead, it gives: RootSum[1  #1 + #1^2  #1^3 + #1^4  #1^5 + #1^6 & , (6*Log[x  #1] + 5*Log[x  #1]*#1  4*Log[x  #1]*#1^2 + 3*Log[x  #1]* #1^3  2*Log[x  #1]*#1^4 + Log[x  #1]*#1^5)/(1 + 2*#1  3*#1^2 + 4*#1^3  5*#1^4 + 6*#1^5) & ] where RootSum[ f, form ] represents the sum of form[x] for all x that satisfy the polynomial equation f[x] == 0.  Comment By: Robert Marik (robertmarik) Date: 20080602 06:46 Message: Logged In: YES user_id=2033662 Originator: NO This could be a similar problem (copied from Maxima discussion list) Hello all, Maxima fails to evaluate integral of 1/(x^4+3*x^2+1). Answers to this problem on Maxima list include:  BTW Maxima is able to factor x4+3*x2+1. To factor a polynomial over the Gaussian integers, use "gfactor" instead of "factor": gfactor(x4+3*x2+1) => (x2%i*x+1)*(x2+%i*x+1) itegrate doesn't handle 1/(x4+3*x2+1), but it does handle 1/gfactor(x4+3*x2+1).  Probably the integration code should be replaced. The commercial Macsyma does the integral, which is kind of a mess, but if you ev(%,numer) you get 0.72361 * atan(1.61804 * x)  0.27639 * atan(0.61803 * x)  The Horowitz method (1969) gives the rational part of the antiderivative of a rational function. The method for the logarithmic part is due to Trager (1976), I think. The residue method (at least for definite integration of rational functions) that Maxima might be using seems to be due to Wang (circa 1974). Maybe Maxima isn't using the best methods for rational function integration?  Comment By: Raymond Toy (rtoy) Date: 20080317 16:19 Message: Logged In: YES user_id=28849 Originator: NO By handcomputed, I mean someone wrote out the expansion of x^6+1 as (x^2+1)*(x^2+sqrt(3)*x+1)*(x^2sqrt(3)*x+1). I'm not sure maxima can figure that out itself. For the general case x^n+c, we would need to write that as a product of quadratics (and maybe a linear term). Easy to do since we know the roots are, more or less, the n roots of unity. I think the results will be pretty ugly for n >= 7.  Comment By: Raymond Toy (rtoy) Date: 20080317 16:19 Message: Logged In: YES user_id=28849 Originator: NO By handcomputed, I mean someone wrote out the expansion of x^6+1 as (x^2+1)*(x^2+sqrt(3)*x+1)*(x^2sqrt(3)*x+1). I'm not sure maxima can figure that out itself. For the general case x^n+c, we would need to write that as a product of quadratics (and maybe a linear term). Easy to do since we know the roots are, more or less, the n roots of unity. I think the results will be pretty ugly for n >= 7.  Comment By: Ximin Luo (infinity0x) Date: 20080317 15:27 Message: Logged In: YES user_id=2003896 Originator: YES i don't know how to integrate these without knowing the roots of the equation; i thought mathematica was, because it could integrate 1/(1+x^n) without being able to integrate (that nasty rational function). (and i thought algorithms do to this would be available somewhere else.) also, i assumed maxima was already factorising the equation for arbitrarily large values of n. but your approach seems feasible. what do you mean by handcomputed though? as in, numerically instead of algebraically? wouldn't that give imprecise answers?  Comment By: Raymond Toy (rtoy) Date: 20080317 14:37 Message: Logged In: YES user_id=28849 Originator: NO If you can, please describe how to integrate these without knowing the roots of the equation. FWIW, maxima has a special function to integrate functions of the form f(x)/(a*x^n+b). (See enprog and eprog in sinint.lisp.) It only handles the cases of n = 4, 5, 6. And it does this by essentially doing a partial fraction expansion with handcomputed quadratic factors. It seems feasible to extend this to any n.  Comment By: Raymond Toy (rtoy) Date: 20080317 14:37 Message: Logged In: YES user_id=28849 Originator: NO If you can, please describe how to integrate these without knowing the roots of the equation. FWIW, maxima has a special function to integrate functions of the form f(x)/(a*x^n+b). (See enprog and eprog in sinint.lisp.) It only handles the cases of n = 4, 5, 6. And it does this by essentially doing a partial fraction expansion with handcomputed quadratic factors. It seems feasible to extend this to any n.  Comment By: Raymond Toy (rtoy) Date: 20080317 14:37 Message: Logged In: YES user_id=28849 Originator: NO If you can, please describe how to integrate these without knowing the roots of the equation. FWIW, maxima has a special function to integrate functions of the form f(x)/(a*x^n+b). (See enprog and eprog in sinint.lisp.) It only handles the cases of n = 4, 5, 6. And it does this by essentially doing a partial fraction expansion with handcomputed quadratic factors. It seems feasible to extend this to any n.  Comment By: Raymond Toy (rtoy) Date: 20080313 01:30 Message: Logged In: YES user_id=28849 Originator: NO Actually, the roots are obviously the seven roots of 1, which maxima does know, and it could have done the partial fraction expansion to find the value of the integral. Not sure how or where to teach maxima about this, though. Some thought needed.  Comment By: Ximin Luo (infinity0x) Date: 20080312 23:32 Message: Logged In: YES user_id=2003896 Originator: YES The point is that Maxima does not NEED to know the roots of that equation. Sorry for making this unclear. By doing the integral using a different algorithm which doesn't involve taking partial fractions, you can avoid the above, and get a purely symbolic integral, like Mathematic does.  Comment By: Raymond Toy (rtoy) Date: 20080312 23:16 Message: Logged In: YES user_id=28849 Originator: NO Maxima can't give an answer because it doesn't know the roots of (x^7+1)/(x+1). If you set integrate_use_rootsof:true, then maxima can return an answer, but unless you can compute the roots of the above equation, it's probably not very helpful.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913067&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 03:45:42

Bugs item #1981628, was opened at 20080602 12:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&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: a bug of radcan() and radexpand Initial Comment: Dear Developers of Maxima, radcan() does not behave in the correct way. In the online desription of radcan() with the correction of a misprint, which is informed in a separate report by me, it is written that  Function: radcan (<expr>) ... ... When `radexpand' is `false', certain transformations are inhibited. `radcan (sqrt (1x))' remains `sqrt (1x)' and is not simplified to `%i sqrt (x1)'. `radcan (sqrt (x^2  2*x + 1))' remains `sqrt (x^2  2*x + 1)' and is not simplified to `x  1'. ... ... The control by the variable `radexpand' does not work in the present Maxima. A demonstration program is as follows:  /* * a_bug_of_radcan.maxima: * * S.Adachi 2008/06/01 */ display2d:false; radexpand; /* Inspect the value of `radexpand' */ radcan(sqrt(x^22*x+1)); /* expected to reduce to x1 */ radexpand:false; radcan(sqrt(x^22*x+1)); /* expected to remain sqrt(x^22*x+1) */ /* 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(a_bug_of_radcan.maxima) batching #p/Volumes/HFS+2/home/adachi/work/301/a_bug_of_radcan.maxima (%i2) display2d : false (%o2) false (%i3) radexpand (%o3) true (%i4) radcan(sqrt(12*x+x^2)) (%o4) x1 (%i5) radexpand:false (%o5) false (%i6) radcan(sqrt(12*x+x^2)) (%o6) x1 (%o7) "a_bug_of_radcan.maxima"  If `radexpand' is `false', `radcan(sqrt(x^22*x+1))' is expected to remain `sqrt(x^22*x+1)'. However, Maxima returns `x1' in reality. This is a bug. I think that this is a very serious bug of radcan(). Please fix it. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 03:44:08

Bugs item #1981626, was opened at 20080602 12:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981626&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: a misprint about radcan() in the manual Initial Comment: Dear Developers of Maxima, I found a misprint in the description of radcan() in Maxima manual (both of pdf and online versions). This part of the description of radcan() in Maxima 5.14.0cvs is as follows:  [Macintosh:/tmp:1] adachi% maxima batchstring='? radcan' 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) describe(radcan, exact)  Function: radcan (<expr>) ... ... When `radexpand' is `false', certain transformations are inhibited. `radcan (sqrt (1x))' remains `sqrt (1x)' and is not simplified to `%i sqrt (x1)'. `radcan (sqrt (x^2  2*x + 11))' remains `sqrt (x^2  2*x + 1)' and is not simplified to `x  1'. ... ...  The misprint is as follows: WRONG: `radcan (sqrt (x^2  2*x + 11))' remains `sqrt (x^2  2*x + 1)' ... CORRECT: `radcan (sqrt (x^2  2*x + 1))' remains `sqrt (x^2  2*x + 1)' ... I inspected the corresponding description in an old manual "Macsyma Mathematics and System Refercen Manual" (16th Edition) published by Macsyma, Inc. in 1996. On p.37 in this Macsyma manual, it is written as radexpand default: true When set to false, this option variable inhibits certain transformations: ... ; and radcan(sqrt(x^22+1)) remains sqrt(x^2+2x+1) and is not transformed to x1. ... Clearly, the above description in Maxima manual comes from this part in the old Macsyma manual. So, I think that the misprint is confirmed. Please correct the misprint. Sincerely yours, Satoshi Adachi P.S. Furthermore, radcan() does not work as is described in the corrected manual. This is a bug of radcan(). I will report this bug in a separate report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981626&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 03:40:00

Bugs item #1981623, was opened at 20080602 12:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&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 sign of sqrt() Initial Comment: Dear Developers of Maxima, I found that sqrt() returns the incorrect expression that has the sign opposite to the ture expression when some certain argument is given to sqrt(). Namely, sqrt() interprets incorrectly the database that is prepared by assume(). Here is an demonstration program:  /* * wrong_sign_of_sqrt.maxima * * S.Adachi 2008/06/01 */ display2d:false; assume(x >= 0, x <= 1); correct_result_1:sqrt((x1)^2); correct_result_2:sqrt(1/(x1)^2); correct_result_3:sqrt(a*(x1)^2); incorrect_result_1:sqrt(a/(x1)^2); incorrect_result_2:sqrt(a^2/(x1)^2); incorrect_result_3:sqrt(x^2/(x1)^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_sign_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/299/wrong_sign_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) assume(x >= 0,x <= 1) (%o3) [x >= 0,x <= 1] (%i4) correct_result_1:sqrt((x1)^2) (%o4) 1x (%i5) correct_result_2:sqrt(1/(x1)^2) (%o5) 1/(1x) (%i6) correct_result_3:sqrt(a*(x1)^2) (%o6) sqrt(a)*(1x) (%i7) incorrect_result_1:sqrt(a/(x1)^2) (%o7) sqrt(a)/(x1) (%i8) incorrect_result_2:sqrt(a^2/(x1)^2) (%o8) abs(a)/(x1) (%i9) incorrect_result_3:sqrt(x^2/(x1)^2) (%o9) x/(x1) (%o10) "wrong_sign_of_sqrt.maxima"  I wonder why sqrt() returns the wrong expression if sqrt((x1)^2) appears in the denominator of some fraction in the argument that is more complex than some threshold (e.g. the numerator is not a simple number or something like that). I think that this is a very severe bug of sqrt() and the database that is prepared by assume(). This bug puts many user programs to the state producing many wrong results. Please fix this severe bug. Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981623&group_id=4933 
From: SourceForge.net <noreply@so...>  20080602 02:28:14

Bugs item #1980715, was opened at 20080531 11:39 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1980715&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: Nobody/Anonymous (nobody) >Assigned to: Dan Gildea (dgildea) Summary: wrong radcansimplification Initial Comment: Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 radcan(3^(1/6)*9^(1/3)); sqrt(3) and that ist wrong! helfried.kravanja@...  >Comment By: Dan Gildea (dgildea) Date: 20080601 22:28 Message: Logged In: YES user_id=1797506 Originator: NO fixed in src/nrat4.lisp revision 1.17: o spc5: was losing denominator in building gcdlist (%i2) radcan(3^(1/6)*9^(1/3)); (%o2) 3^(5/6) (%i3) radcan(81^(1/5)*9^(1/3)); (%o3) 3*3^(7/15)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1980715&group_id=4933 