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}
(27) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(5) 
2
(4) 
3
(1) 
4

5
(1) 
6
(10) 
7
(3) 
8
(2) 
9
(1) 
10
(3) 
11
(1) 
12
(1) 
13
(7) 
14
(5) 
15
(5) 
16
(3) 
17
(7) 
18
(1) 
19
(1) 
20

21
(1) 
22
(1) 
23

24

25
(1) 
26
(1) 
27

28
(1) 
29
(1) 
30
(1) 
31
(1) 



From: SourceForge.net <noreply@so...>  20060514 20:35:14

Bugs item #1488457, was opened at 20060514 15:35 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=1488457&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 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: featurep of subscripted variables Initial Comment: (%i1) featurep(a,real); (%o1) false < OK (%i2) featurep(a[1],real); (%o2) true < not OK Do we have a policy? Are all mapatoms except %i and infinity real? That would make %o1 wrong and %o2 correct. Should the setting of domain make a difference? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488457&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 17:33:52

Bugs item #1487703, was opened at 20060512 19:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  >Comment By: Raymond Toy (rtoy) Date: 20060514 13:33 Message: Logged In: YES user_id=28849 I tried the checkedin version of sin.lisp. I think the 6 test integrals now produce the same answers now as in 5.9.3.  Comment By: David Billinghurst (billingd) Date: 20060513 20:21 Message: Logged In: YES user_id=365569 I tried this (diff attached). There isn't any change to the testsuite but there are a number of changes to the ode_contrib testsuite. I have reduced the first few to find the changes in integrate() results. There are both good and bad changes. integrate(2*(1tan(x)^2)*csc(2*x)*(csc(2*x)+cot(2*x)),x); integrate(1/(u*((sqrt(u^2+1)*abs(x)+u*x)/(u*x)1)),u); integrate(1/(u*((sqrt(1u^2)*abs(x)+u*x)/(u*x)1)),u); integrate((x*sqrt(y^2+x^2)+y)/(x*sqrt(y^2+x^2)),x); integrate(1/(u*((a*sqrt(u^2+b)*abs(x)+u*x)/(u*x)1)),u); integrate((a*x^3x*sqrt(a^2*x^4b))/sqrt(a^2*x^4b),x); I haven't attached the results  it looks ugly  but can do if required.  Comment By: Raymond Toy (rtoy) Date: 20060512 21:55 Message: Logged In: YES user_id=28849 There are two causes for this, I think. First, intform no longer sets $radexand to $all because that causes sqrt(x^2) to be x, which is not always right. Second, the line cond test ((not (alike1 exp (setq y ($expand exp)))) near the end of integrator is the actual source of the loop. I don't really understand why it wants to do this, but commenting out test and body allows this integral to work as it used to. Plus there are no failures in the testsuite. Additionally, some commented out integration tests no longer loop either.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 16:13:04

Bugs item #1488359, was opened at 20060514 11:13 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=1488359&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjuate of subscripted function Initial Comment: (%o20) f[6](x) (%i21) conjugate(%); Maxima encountered a Lisp error: Error in GET [or a callee]: (($F SIMP ARRAY) 6) is not of type SYMBOL. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488359&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 15:24:16

Bugs item #1488344, was opened at 20060514 10:24 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=1488344&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: conjugate limitation Initial Comment: The conjugate function doesn't handle long argument lists. For example (%i17) m :genmatrix(a,100,100)$ (%i18) conjugate(m)$ Maxima encountered a Lisp error: Error in MEVAL [or a callee]: MEVAL [or a callee] requires less than one hundred arguments. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488344&group_id=4933 
From: SourceForge.net <noreply@so...>  20060514 00:21:14

Bugs item #1487703, was opened at 20060513 09:36 Message generated for change (Comment added) made by billingd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  >Comment By: David Billinghurst (billingd) Date: 20060514 10:21 Message: Logged In: YES user_id=365569 I tried this (diff attached). There isn't any change to the testsuite but there are a number of changes to the ode_contrib testsuite. I have reduced the first few to find the changes in integrate() results. There are both good and bad changes. integrate(2*(1tan(x)^2)*csc(2*x)*(csc(2*x)+cot(2*x)),x); integrate(1/(u*((sqrt(u^2+1)*abs(x)+u*x)/(u*x)1)),u); integrate(1/(u*((sqrt(1u^2)*abs(x)+u*x)/(u*x)1)),u); integrate((x*sqrt(y^2+x^2)+y)/(x*sqrt(y^2+x^2)),x); integrate(1/(u*((a*sqrt(u^2+b)*abs(x)+u*x)/(u*x)1)),u); integrate((a*x^3x*sqrt(a^2*x^4b))/sqrt(a^2*x^4b),x); I haven't attached the results  it looks ugly  but can do if required.  Comment By: Raymond Toy (rtoy) Date: 20060513 11:55 Message: Logged In: YES user_id=28849 There are two causes for this, I think. First, intform no longer sets $radexand to $all because that causes sqrt(x^2) to be x, which is not always right. Second, the line cond test ((not (alike1 exp (setq y ($expand exp)))) near the end of integrator is the actual source of the loop. I don't really understand why it wants to do this, but commenting out test and body allows this integral to work as it used to. Plus there are no failures in the testsuite. Additionally, some commented out integration tests no longer loop either.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:30:36

Bugs item #1483121, was opened at 20060506 15:47 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483121&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(1/x, x, infinity) Initial Comment: (%i15) limit(1/x, x, infinity); (%o15) 0 (%i16) limit(1/x, x, infinity); (%o16) 1/infinity (should it be 0!) Please include the following build information with your bug report:  Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7   >Comment By: Barton Willis (willisbl) Date: 20060513 16:30 Message: Logged In: YES user_id=895922 infinity is the complex infinity. Maybe you wanted to do limit(1/x,x,minf). Notice that limit(infinity) > infinity and limit(1/infinity) > 0. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483121&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:27:39

Bugs item #1479149, was opened at 20060429 21:13 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&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: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration with trigonometric function and following diff Initial Comment: integrate(k*x/f(x),x), knumber, f(x)thrigonometric function  sin(x)^2, cos(x)^2, Sin(x)^3 etc. gives a very poor result. axiom gives a better and short result. following diff(%,x) gives a non simply formula. So, maxima has a problem with a trigonometric function ;)  >Comment By: Barton Willis (willisbl) Date: 20060513 16:27 Message: Logged In: YES user_id=895922 No real bug hereI'm closing the report. Barton  Comment By: Barton Willis (willisbl) Date: 20060501 12:04 Message: Logged In: YES user_id=895922 Maxima uses a constant of integration when it thinks one is really needed: (%i12) integrate(x=1,x); (%o12) x^2/2=x+integrationconstant1 This is a bug listfor a better place to ask questions about how to use Maxima see: http://maxima.sourceforge.net/maximalist.html Barton  Comment By: Raymond Toy (rtoy) Date: 20060501 11:54 Message: Logged In: YES user_id=28849 Judicious use of logcontract, trigexpand and trigsimp will produce log(44*cos(x)^2)2*x*cos(x)/sin(x). That's pretty comparable to axiom's result. Also, integrate never returns a gratuitious constant of integration, just like tables of integrals never do If you want it, you have to add it yourself.  Comment By: Nobody/Anonymous (nobody) Date: 20060501 08:19 Message: Logged In: NO Yes, trigsimp was help me, it gives simpler, but not simplest formula. For example, k=2, f(x)=sin(x)^2 integrate(2*x/(sin(x)^2,x) with trigsimp gives a following formula: [{(cos(2x)1)*log(2*cos(x)+2)}+{(cos(2*x)1)*log(22*cos(x))}+2*x*sin(2*x)]/(cos(2*x)1) Simplest result is: 2*(log(sin(x)/2)x*ctg(x)) Or, maxima don't gives (don't can) a simplest result? P.S. By the way, how about C? integrate(x,x) = x^2/2 + C. doble integrate gives a x^3/6 + C*x + c(1)  Comment By: Barton Willis (willisbl) Date: 20060430 06:55 Message: Logged In: YES user_id=895922 Did Maxima give an incorrect result for any of these integrals? Maxima does gives a lengthy formula for integrate(x / sin(x)^2,x), but it seems to be correct: (%i1) integrate(x / sin(x)^2,x)$ (%i2) diff(%,x)  x/sin(x)^2$ (%i3) exponentialize(%)$ (%i4) ratsimp(%); (%o4) 0 In addition to exponentialize and ratsimp, Maxima has functions trigsimp, trigreduce, and trigexpand. Did you try using these functions to convert the antiderivatives into the form you were looking for? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:25:59

Bugs item #1479151, was opened at 20060429 21:24 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&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: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima don't use a   Initial Comment: Example: integrate(1/x,x) gives a log(x), but must be gives a log(abs(x)). May be, maxima don't verify permissible value anyhere.  Comment By: Barton Willis (willisbl) Date: 20060430 06:34 Message: Logged In: YES user_id=895922 If you want integrate(1/x,x) = log(abs(x)), set the option variable 'logabs' to true: (%i1) logabs : true$ (%i2) integrate(1/x,x); (%o2) log(abs(x)) (%i3) logabs : false$ (%i4) integrate(1/x,x); (%o4) log(x) Since integrate(1/x,x) = log(abs(x)) isn't correct off the real axis, the default for 'logabs' is false. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 21:24:32

Bugs item #1488101, was opened at 20060513 16:24 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=1488101&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: 3 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: subst and subscripted operators Initial Comment: This works ok: (%i1) subst("[",f, f(1,2,3)); (%o1) [1,2,3] This doesn't (but ought to): (%i2) subst("[",f[1], f[1](1,2,3)); (%o2) [(1,2,3) (%i3) ?print(%); ((&[ SIMP) 1 2 3) < needs to $verbify caar Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1488101&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 01:55:31

Bugs item #1487703, was opened at 20060512 19:36 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  >Comment By: Raymond Toy (rtoy) Date: 20060512 21:55 Message: Logged In: YES user_id=28849 There are two causes for this, I think. First, intform no longer sets $radexand to $all because that causes sqrt(x^2) to be x, which is not always right. Second, the line cond test ((not (alike1 exp (setq y ($expand exp)))) near the end of integrator is the actual source of the loop. I don't really understand why it wants to do this, but commenting out test and body allows this integral to work as it used to. Plus there are no failures in the testsuite. Additionally, some commented out integration tests no longer loop either.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 01:36:14

Bugs item #1480338, was opened at 20060502 13:59 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Andrej Vodopivec (andrejv) Date: 20060513 03:36 Message: Logged In: YES user_id=1179910 I updated ifactor.lisp  maxima now returns the answer without delays and warnings. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060513 03:20 Message: Logged In: YES user_id=28849 All of the tests listed herein are fixed. But the original report about exp(sqrt(foo)...) is still slow. That does appear to be an issue with factor (ifactor).  Comment By: Raymond Toy (rtoy) Date: 20060510 13:37 Message: Logged In: YES user_id=28849 Oh. I had already made that change in my sources because cmucl complained about it. Now if we could only check in the fix!  Comment By: Andrej Vodopivec (andrejv) Date: 20060510 08:07 Message: Logged In: YES user_id=1179910 Actually just this does not fix a^(10/11..) issue  if you call ratsimp on it it still fails. To solve this and get Bartons example done fast I had to change f< to < in palgsimp and f to  in pasimp1 in rat3a.lisp. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060510 04:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 20:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 18:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 16:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060507 05:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 13:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060513 01:20:23

Bugs item #1480338, was opened at 20060502 07:59 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Raymond Toy (rtoy) Date: 20060512 21:20 Message: Logged In: YES user_id=28849 All of the tests listed herein are fixed. But the original report about exp(sqrt(foo)...) is still slow. That does appear to be an issue with factor (ifactor).  Comment By: Raymond Toy (rtoy) Date: 20060510 07:37 Message: Logged In: YES user_id=28849 Oh. I had already made that change in my sources because cmucl complained about it. Now if we could only check in the fix!  Comment By: Andrej Vodopivec (andrejv) Date: 20060510 02:07 Message: Logged In: YES user_id=1179910 Actually just this does not fix a^(10/11..) issue  if you call ratsimp on it it still fails. To solve this and get Bartons example done fast I had to change f< to < in palgsimp and f to  in pasimp1 in rat3a.lisp. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060509 22:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 14:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 12:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 10:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060506 23:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 07:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060512 23:36:55

Bugs item #1487703, was opened at 20060513 09:36 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=1487703&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 Submitted By: David Billinghurst (billingd) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((sqrt(x^46*x^2+1)x^2+1)/(2*x),x) fails Initial Comment: With CVS maxima (20060513) e:(sqrt(x^46*x^2+1)x^2+1)/(2*x); integrate(e,x); ***  Lisp stack overflow. RESET The change is recent  since Feb 06. With maxima 5.9.3 (%i2) integrate(e,x); 2 2 log(x + 2 x  1) log(x  2 x  1)  +  / 2 2 2 [ % e x I  dx + log(x)   ] x 2 / (%o2)   2 When fixed, reenable DE 105 in share/contrib/diffequations/tests/rtestode_murphy_2_2. mac  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1487703&group_id=4933 
From: SourceForge.net <noreply@so...>  20060511 12:09:29

Bugs item #1486452, was opened at 20060511 07:09 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=1486452&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: 3 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: minfactorial doesn't look inside "!" Initial Comment: The minfactorial function doesn't look inside the factorial function. So it misses some simplifications that it could do: (%i1) (n!/(n1)!)!; (%o1) (n!/(n1)!)! (%i2) minfactorial(%); (%o2) (n!/(n1)!)! < could be n! (%i3) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1486452&group_id=4933 
From: SourceForge.net <noreply@so...>  20060510 11:37:25

Bugs item #1480338, was opened at 20060502 07:59 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Raymond Toy (rtoy) Date: 20060510 07:37 Message: Logged In: YES user_id=28849 Oh. I had already made that change in my sources because cmucl complained about it. Now if we could only check in the fix!  Comment By: Andrej Vodopivec (andrejv) Date: 20060510 02:07 Message: Logged In: YES user_id=1179910 Actually just this does not fix a^(10/11..) issue  if you call ratsimp on it it still fails. To solve this and get Bartons example done fast I had to change f< to < in palgsimp and f to  in pasimp1 in rat3a.lisp. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060509 22:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 14:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 12:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 10:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060506 23:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 07:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060510 06:08:04

Bugs item #1480338, was opened at 20060502 13:59 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Andrej Vodopivec (andrejv) Date: 20060510 08:07 Message: Logged In: YES user_id=1179910 Actually just this does not fix a^(10/11..) issue  if you call ratsimp on it it still fails. To solve this and get Bartons example done fast I had to change f< to < in palgsimp and f to  in pasimp1 in rat3a.lisp. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060510 04:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 20:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 18:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 16:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060507 05:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 13:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060510 02:06:42

Bugs item #1480338, was opened at 20060502 07:59 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Raymond Toy (rtoy) Date: 20060509 22:06 Message: Logged In: YES user_id=28849 Neat. I think I found the issue. In src/rat3d.lisp, in the function iroot, there's the line (cond ((f< (haulong a) n) (list 1 (sub1 a))) That f< seems to be the problem because n is not a fixnum. Replacing f< with plain < solves both the 2^(1/111...) and a^(10/111....) issue. Someone should look at all of the uses of f<, f+, etc. in rat3*.lisp and replace them with <, +, etc., as needed.  Comment By: Andrej Vodopivec (andrejv) Date: 20060509 14:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 12:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 10:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060506 23:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 07:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060509 18:58:08

Bugs item #1480338, was opened at 20060502 13:59 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Andrej Vodopivec (andrejv) Date: 20060509 20:57 Message: Logged In: YES user_id=1179910 Some more examples: (%i1) display2d:false$ (%i2) build_info()$ Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 %i3 is OK but %i4 takes a long time  the same for all higher denominators and other bases. (%i3) 2^(1/1111111111); (%o3) 2^(1/1111111111) (%i4) 2^(1/11111111111); Maxima encountered a Lisp error: Console interrupt. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. Again %i5 is OK and %i6 has an extra (a+1)^9 factor. Similar with other examples with bigger denominators in exponent. The numerator in the exponent must be bigger than one to trigger this bug. (%i5) a^(10/1111111111); (%o5) a^(10/1111111111) (%i6) ratsimp(%); (%o6) a^(10/1111111111) (%i7) a^(10/11111111111); (%o7) a^(10/11111111111) (%i8) ratsimp(%); (%o8) a^(10/11111111111)*(a^9+9*a^8+36*a^7+84*a^6+126*a^5+126*a^4+84*a^3+36*a^2+9*a+1) Andrej  Comment By: Andrej Vodopivec (andrejv) Date: 20060508 18:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 16:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060507 05:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 13:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060508 16:37:33

Bugs item #1480338, was opened at 20060502 13:59 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Andrej Vodopivec (andrejv) Date: 20060508 18:37 Message: Logged In: YES user_id=1179910 The problem is not with the factoring code. Barton is reporting long times with version 5.9.3 (gcl+win) before ifactor was moved to src and it is not just a delay because of factoring  I interrupted the execution after a couple of minutes. Anyway I will remove the warning that factoring failed. I could also make the code give up sooner. The way things were set up before the factorization was more like testing for small factors rather than trying for complete factorization. Andrej  Comment By: Raymond Toy (rtoy) Date: 20060508 16:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060507 05:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 13:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060508 14:47:16

Bugs item #1480338, was opened at 20060502 07:59 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Raymond Toy (rtoy) Date: 20060508 10:47 Message: Logged In: YES user_id=28849 Interesting. Barton's simplified ratsimp example causes 2 errors with CMUCL because pcetimes1 does f+ with a bignum and palgsimp does f< with a bignum. Replacing these with + and < fixes the issue. However, the ratsimp example causes a warning from cmucl because it wants to compute 1^1932473987149817. This is a cmucl problem, but depending on how smart the Lisp is, it might actually try to compute that power. Finally, for the complicated ratsimp(exp((sqrt ...))) example, I think the real issue is that maxima is trying to simplify the sqrt. If you just enter sqrt(852469675641479773175661572149741); there's a delay before maxima prints out the warning about not finding the factors. Also, factor(852469675641479773175661572149741) spends some time and returns 2 factors: 34130646845983 24976663333933005427. Not sure why there's a warning at all. So I think it used to be fast because sqrt(852...) factor or somebody gave up early and returned sqrt(852...). ifactor works harder before giving up.  Comment By: Robert Dodier (robert_dodier) Date: 20060506 23:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 07:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060507 03:09:20

Bugs item #1483203, was opened at 20060506 21:09 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=1483203&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: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: GCL confused by trailing whitespace in input Initial Comment: Trailing whitespace in input causes GCL to forget to print the next input prompt. E.g. (%i1) a : 100; < there is a space character after the semicolon here (%o1) 100 a; (%o2) 100 (%i3) a : 200$ < there is a space character after the dollar sign here a; (%o4) 200 Same behavior for Maxima 5.9.3cvs / GCL 2.6.7 / Linux, and Maxima 5.9.3 / GCL 2.6.7 / Win XP. Behavior not observed with SBCL or Clisp. Could be readline strangeness, although Clisp has readline and it is OK (i.e., input prompts are printed as expected).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483203&group_id=4933 
From: SourceForge.net <noreply@so...>  20060507 03:03:57

Bugs item #1480338, was opened at 20060502 05:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&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: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp(exp(constant)) very slow Initial Comment: ratsimp, when applied to %e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248); is very slow. But can ratsimp simplify the argument to exp quickly. This expression happended towards the end of a matrixexp calculation. I've tried variations of this expression (delete hunks of various numbers)  sometimes ratsimp is very fast, other times it seems to hang. (%i18) build_info(); Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060506 21:03 Message: Logged In: YES user_id=501686 Not sure what's going on here, but maybe the problem is in the factoring code. Maxima 5.9.3 / clisp 2.34: ratsimp (%e^((sqrt(852469675641479773175661572149741) 15762598695796738)/2251799813685248)); => fast Maxima 5.9.3 / clisp 2.38 (after factor code was revised): => slow, and it complains "WARNING: could not find factors of composite: 852469675641479773175661572149741"  Comment By: Barton Willis (willisbl) Date: 20060506 05:40 Message: Logged In: YES user_id=895922 A simpler example: ratsimp(exp((1932473987149817)/589347638476187146)) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1480338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060507 02:15:01

Bugs item #1483194, was opened at 20060506 20:15 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=1483194&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: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima doesn't know much about increasing / decreasing fcns Initial Comment: Maxima can't do much w/ functions declared to be increasing, and can't do anything with functions declared decreasing. declare (F, increasing, G, decreasing); is (F(2) > F(1)); => "unable to evaluate the predicate" is (G(1) > G(2)); => "unable to evaluate the predicate" assume (xx > yy); is (F(xx) > F(yy)); => true (OK) is (G(yy) > G(xx)); => "unable to evaluate the predicate" Maxima 5.9.3cvs  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483194&group_id=4933 
From: SourceForge.net <noreply@so...>  20060506 20:47:51

Bugs item #1483121, was opened at 20060506 13:47 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=1483121&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(1/x, x, infinity) Initial Comment: (%i15) limit(1/x, x, infinity); (%o15) 0 (%i16) limit(1/x, x, infinity); (%o16) 1/infinity (should it be 0!) Please include the following build information with your bug report:  Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483121&group_id=4933 
From: SourceForge.net <noreply@so...>  20060506 20:20:27

Bugs item #1467778, was opened at 20060410 09:16 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1467778&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: Closed >Resolution: Works For Me Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Debug output provokes Clisp complaint about closed stream Initial Comment: Sometimes the quadpack functions want to print debug messages. Clisp doesn't like that, GCL and SBCL think it's OK. I don't know a workaround. Probably the problem has something to do with the way Fortran WRITE statements get translated into Lisp. Clisp 2.34: (%i1) quad_qags (sin(x), x, 0, 200*%pi), numer; Maxima encountered a Lisp error: WRITECHAR on #<CLOSED IO TERMINALSTREAM> is illegal GCL 2.6.7: (%i1) quad_qags (sin(x), x, 0, 200*%pi), numer; Compiling gazonk0.lsp. [...] ***MESSAGE FROM ROUTINE DQAGS IN LIBRARY SLATEC. ***INFORMATIVE MESSAGE, PROG CONTINUES, TRACEBACK REQUESTED * ABNORMAL RETURN * ERROR NUMBER = 2 * ***END OF MESSAGE (%o1) [ 2.2784436628435217E13, 3.9575719140433691E12, 21, 2] SBCL 0.9.9: (%i1) quad_qags (sin(x), x, 0, 200*%pi), numer; ***MESSAGE FROM ROUTINE DQAGS IN LIBRARY SLATEC. ***INFORMATIVE MESSAGE, PROG CONTINUES, TRACEBACK REQUESTED * ABNORMAL RETURN * ERROR NUMBER = 2 * ***END OF MESSAGE (%o1) [2.407196885346775e12, 3.955640448980319e12, 21, 2]  >Comment By: Robert Dodier (robert_dodier) Date: 20060506 14:20 Message: Logged In: YES user_id=501686 Retested w/ Clisp 2.38 on same system, problem has now gone away. Closing this report.  Comment By: Raymond Toy (rtoy) Date: 20060506 07:49 Message: Logged In: YES user_id=28849 I don't see this with clisp with current cvs. With clisp 2.38.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1467778&group_id=4933 