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}
(44) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(3) 
2

3

4
(1) 
5

6

7

8

9
(2) 
10

11

12
(7) 
13

14
(1) 
15

16

17

18

19
(5) 
20
(4) 
21
(1) 
22
(2) 
23
(1) 
24
(3) 
25
(2) 
26
(6) 
27
(5) 
28

29

30

31
(2) 





From: SourceForge.net <noreply@so...>  20111031 16:28:10

Bugs item #3431261, was opened at 20111031 12:28 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3431261&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Assume applies "fuzz" to floats and bfloats Initial Comment: (%i66) assume(sss > 1.0/3); (%o66) [sss > 0.333333333333333] (%i67) is(sss > 1.0/3 + 1.0e5); (%o67) unknown <<< OK (%i68) is(sss > 1.0/3 + 1.0e10); (%o68) true <<< !!!! Same thing for bfloats. (%i69) fpprec:100$ (%i70) assume(ttt > 1.0b0/3)$ (%i71) is(ttt > 1.0b0/3 + 1.0b10); (%o71) true Strangely, this doesn't happen for round numbers: (%i72) assume(uuu > 1.0b0)$ (%i73) is(uuu > 1.0b0 + 1.0b100); (%o73) unknown Though facts() reports that the facts are recorded in bfloat, perhaps they are internally rounded to rationals???  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3431261&group_id=4933 
From: SourceForge.net <noreply@so...>  20111031 10:41:58

Bugs item #3431119, was opened at 20111031 05:41 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3431119&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: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: odelin error Initial Comment: (%i1) load(odelin)$ (%i2) odelin(('diff(f,x,2))*x^2+(f*x)/(1)^m+('diff(f,x,1))*xf,f,x); Maxima encountered a Lisp error: Error in EVENP [or a callee]: $M is not of type INTEGER. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3431119&group_id=4933 
From: SourceForge.net <noreply@so...>  20111027 22:23:19

Bugs item #3398046, was opened at 20110825 17:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3398046&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: Anton Voropaev (antonvoropaev) Assigned to: Nobody/Anonymous (nobody) Summary: radcan() causes an error Initial Comment: INPUT build_info(); radcan((8^(1/4)+2)/(2^(1/3)+2^(1/4))4^(1/3)), algebraic; INPUT AND OUTPUT (%i1) build_info(); Maxima version: 5.25.0 Maxima build date: 12:0 8/2/2011 Host type: i686pcmingw32 Lisp implementation type: Clozure Common Lisp Lisp implementation version: Version 1.7r14925M (WindowsX8632) (%o1) (%i2) radcan((8^(1/4)+2)/(2^(1/3)+2^(1/4))4^(1/3)), algebraic; Maxima encountered a Lisp error: value ((RAT SIMP) 3 4) is not of the expected type INTEGER. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20111028 00:23 Message: The reported error is not present in Maxima 5.25post. (%i1) expr:((8^(1/4)+2)/(2^(1/3)+2^(1/4))4^(1/3))$ (%i2) radcan(expr), algebraic; (%o2) (2^(31/12)2^(5/2)+2^(29/12)2^(7/3)+2^(9/4)2^(13/6)+2^(25/12) +2^(23/12)2^(11/6)+2^(7/4)2^(5/3) +2^(3/4)*(2^(5/3)+2^(19/12)2^(3/2)+2^(17/12)2^(4/3) +2^(5/4)2^(7/6)+2^(13/12)+2^(11/12) 2^(5/6)+2^(3/4)2)4) /2 Closing this bug report as "Works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3398046&group_id=4933 
From: SourceForge.net <noreply@so...>  20111027 22:06:13

Bugs item #3185855, was opened at 20110218 16:08 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3185855&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: radcan warns about floatconvert Initial Comment: radcan(2^floor(sin(x)/%pi)) gives 43 warnings that 1.0 was replaced by 1/1 This appears to be happening within sign(sin(x)/%pi), which is called by simpfloor, but calling sign directly from the top level doesn't cause the warning.  >Comment By: Dieter Kaiser (crategus) Date: 20111028 00:06 Message: Fixed in compar.lisp revision 27.10.2011 Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20111026 22:50 Message: This is a much simpler example for the reported bug: (%i1) ratsimpexpons:false$ (%i2) sign(1/%pi); (%o2) pos (%i3) ratsimpexpons:true$ (%i4) sign(1/%pi); rat: replaced 1.0 by 1/1 = 1.0 (%o4) pos The behavior depends on the setting of the global variable ratsimpexpons. It is by default false, but radcan sets the global variable to the value true. Therefore, we get the messages, when an argument of radcan calls the sign function. A simple correction is to set the global variable $ratprint to the value nil in the function numer in the file compar.lisp. The function numer is called from $sign to get a floating point approximation. But this conversion causes a call of ratsimp, when ratsimpexpons is true. This is a modified function numer: (defun numer (x) (let (($numer t) ; currently, no effect on $float, but proposed to ($ratprint nil) result) ;; Catch a Lisp error, if a floating point overflow occurs. (setq result (let ((errset nil)) (errset ($float x)))) (if result (car result) nil))) With this modification we get: (%i6) ratsimpexpons:true$ (%i7) sign(1/%pi); (%o7) pos (%i8) radcan(2^floor(sin(x)/%pi)); (%o8) 2^floor(sin(x)/%pi) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3185855&group_id=4933 
From: SourceForge.net <noreply@so...>  20111027 22:05:21

Bugs item #3398066, was opened at 20110825 18:31 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3398066&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: Anton Voropaev (antonvoropaev) Assigned to: Nobody/Anonymous (nobody) Summary: radcan generates floats? Initial Comment: See also bug report ID: 2990192 INPUT build_info(); display2d : false; radcan(sqrt(sqrt(2)+1/2)); INPUT AND OUTPUT (%i1) build_info(); Maxima version: 5.25.0 Maxima build date: 12:0 8/2/2011 Host type: i686pcmingw32 Lisp implementation type: Clozure Common Lisp Lisp implementation version: Version 1.7r14925M (WindowsX8632) (%o1) (%i2) display2d : false; (%o2) false (%i3) radcan(sqrt(sqrt(2)+1/2)); rat: replaced 1.5 by 3/2 = 1.5 (%o3) sqrt(2^(3/2)+1)/sqrt(2)  >Comment By: Dieter Kaiser (crategus) Date: 20111028 00:05 Message: Fixed in compar.lisp revision 27.10.2011 Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20111026 22:58 Message: This bug is related to the bug 3185855  radcan warns about floatconvert. It is the same problem. A correction is to modify the function numer in the file compar.lisp. See bug 3185855. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110826 20:17 Message: It seems to come from csign or sign. radcan calls simpexpt which calls csign which eventually calls numer. I don't know if csign should be trying to convert the expression to a numerical result. Could be a bug in numer too.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3398066&group_id=4933 
From: SourceForge.net <noreply@so...>  20111027 20:58:05

Bugs item #3429181, was opened at 20111027 08:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3429181&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 Private: No Submitted By: flyingfoxlee () Assigned to: Nobody/Anonymous (nobody) Summary: x^2<1 can't get x^2<2, but can get x^2<100 Initial Comment: Just like the summary, assume (x<1 and x>1), then is (x^<1) is true, but is (x^2<2) is undefined( so does 3 4 5 and 50 ,etc ), but is (x^2<100) is true again. What's happening here? Maxima version: 5.24.0 Maxima build date: 12:15 5/17/2011 Host type: x86_64unknownlinuxgnu Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.7  >Comment By: Dieter Kaiser (crategus) Date: 20111027 22:58 Message: Again some examples to show the reported problem: (%i1) assume(abs(x)<1); (%o1) [abs(x) < 1] (%i2) sign(4x^2); (%o2) pos (%i3) sign(16x^2); (%o3) pos (%i4) sign(64x^2); (%o4) pos (%i5) sign(100x^2); (%o5) pos If the number has an integer root, Maxima can determine the sign. But not for a number, which has not an integer root. (%i6) sign(5x^2); (%o6) pnz The reason is within the algorithm of the Lisp function sign. Expressions are factored by the Lisp function signfactor to determine the sign. Maxima can evaluate the sign of the factored expression. (%i7) factor(4x^2); (%o7) (x2)*(x+2) (%i8) sign(%); (%o8) pos But for a number, which does not have an integer root, the expression can not be factored. For this case Maxima does not have an algorithm to evaluate the sign. (%i11) factor(5x^2); (%o11) (x^25) This might be called a missing feature. The Maxima function sign has a lot of more limitations. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3429181&group_id=4933 
From: SourceForge.net <noreply@so...>  20111027 06:40:47

Bugs item #3429181, was opened at 20111027 06:40 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3429181&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 Private: No Submitted By: flyingfoxlee () Assigned to: Nobody/Anonymous (nobody) Summary: x^2<1 can't get x^2<2, but can get x^2<100 Initial Comment: Just like the summary, assume (x<1 and x>1), then is (x^<1) is true, but is (x^2<2) is undefined( so does 3 4 5 and 50 ,etc ), but is (x^2<100) is true again. What's happening here? Maxima version: 5.24.0 Maxima build date: 12:15 5/17/2011 Host type: x86_64unknownlinuxgnu Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3429181&group_id=4933 
From: SourceForge.net <noreply@so...>  20111026 22:37:45

Bugs item #3377380, was opened at 20110725 20:04 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377380&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  Solving equations Group: None >Status: Pending >Resolution: Works For Me Priority: 7 Private: No Submitted By: Art Lenskold (dloksnel) Assigned to: Barton Willis (willisbl) Summary: 7 nested levels Initial Comment: solve([0=x^21+(a(tx)*(t+1/(2*((tx)^2+(bsqrt(1x^2))^2))*(2(b*xt*sqrt(1x^2))*(bsqrt(1x^2))2*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)))^1*(a+(11/(4*((tx)^2+(bsqrt(1x^2))^2)^2)*(4*(b*xt*sqrt(1x^2))^2*(bsqrt(1x^2))^28*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)*(b*xt*sqrt(1x^2))*(bsqrt(1x^2))+4*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))))^(1/2)))^2 ], [x] ); Maxima version: 5.24.0 Maxima build date: 20:39 4/5/2011 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20111027 00:37 Message: I had problems with the reported equation because of a wrong syntax. After some time I have got the following equation which might the correct (By the way it helps to print the equation with the function grind): (%i1) grind(eqn); 0 = (a(tx)*sqrt((4*(bsqrt(1x^2))^2*(b*xt*sqrt(1x^2))^2 8*sqrt(2*b*sqrt(1x^2)*(t*x*(x^2+2*t*xt^22)+(tx)^2) +(b^2t^2)*x^2*(x^2+2*t*xt^22) +(2*t*x+t^2+b^2+1)*(x^22*t*x)+t^2*(x^2+b^21)) *(bsqrt(1x^2))*(b*xt*sqrt(1x^2)) +4*(2*b*sqrt(1x^2)*(t*x*(x^2+2*t*xt^22)+(tx)^2) +(b^2t^2)*x^2*(x^2+2*t*xt^22) +(2*t*x+t^2+b^2+1)*(x^22*t*x)+t^2*(x^2+b^21))) *(11/((bsqrt(1x^2))^2+4*(tx)^2)^2) +a) /((2*(bsqrt(1x^2))*(b*xt*sqrt(1x^2)) 2*sqrt(2*b*sqrt(1x^2)*(t*x*(x^2+2*t*xt^22)+(tx)^2) +(b^2t^2)*x^2*(x^2+2*t*xt^22) +(2*t*x+t^2+b^2+1)*(x^22*t*x)+t^2*(x^2+b^21))) /(2*((bsqrt(1x^2))^2+(tx)^2)) +t)) ^2 +x^21$ (%o1) done These are the first lines of the solution: (%i2) grind(solve(eqn,x)); [0 = x^6*(sqrt((b^2t^2)*x^4+sqrt(1x^2) *(2*b*t*x^3+(4*b*t^22*b)*x^2+(2*b*t^3+8*b*t)*x 2*b*t^2)+((2*b^22)*t2*t^3)*x^3 +(t^4+(8b^2)*t^2b^2+1)*x^2 +((2*b^22)*t2*t^3)*x+(b^21)*t^2) *(36*a*t *sqrt((((72*b^272)*t72*t^3)*x^7 +sqrt(1x^2)*((72*b*t^272*b^372*b)*x^6 +(552*b*t^3+(408*b^3+696*b)*t)*x^5 +(1392*b*t^4+(496*b^32592*b)*t^264*b^5 64*b^396*b) *x^4 +(1472*b*t^5+(4592*b144*b^3)*t^3 +(272*b^5+224*b^3+528*b)*t) *x^3 +(704*b*t^6+(304*b^33920*b)*t^4 +(24*b^5368*b^3960*b)*t^2 24*b^772*b^564*b^3 +(12*a16)*b) *x^2 +(128*b*t^7+(1600*b64*b^3)*t^5 +(56*b^5+592*b^3+608*b)*t^3 +(8*b^756*b^5+144*b^3 +(32*a+32)*b) *t) *x256*b*t^6+(256*b^3128*b)*t^4 +(48*b^5128*b^316*a*b)*t^24*a*b^34*a*b) +sqrt((b^2t^2)*x^4 +sqrt(1x^2) *(2*b*t*x^3+(4*b*t^22*b)*x^2+(2*b*t^3+8*b*t)*x 2*b*t^2)+((2*b^22)*t2*t^3)*x^3 +(t^4+(8b^2)*t^2b^2+1)*x^2 +((2*b^22)*t2*t^3)*x+(b^21)*t^2) *(72*t*x^6+sqrt(1x^2) *(72*b*x^5408*b*t*x^4 +(576*b*t^2+112*b^3+48*b)*x^3 +(64*b*t^3+(400*b^316*b)*t)*x^2 +(384*b*t^4+(64*b^3320*b)*t^2 +40*b^5+80*b^3) *x+128*b*t^5+(64*b^3+192*b)*t^3 +(8*b^5+80*b^3+32*b)*t) +(24*b^2384*t^2)*x^5 +(704*t^3+(240*b^224)*t)*x^4 +(512*t^4+(256960*b^2)*t^2+16*b^4112*b^2) *x^3 +(128*t^5+(704*b^2640)*t^3 +(168*b^4+352*b^248)*t) *x^2 +((512128*b^2)*t^4+(64*b^4+192*b^2+128)*t^2 8*b^680*b^432*b^2) *x128*t^5+(192*b^264)*t^3 +(40*b^480*b^2)*t) +(420*t^4+(216*b^2+600)*t^260*b^496*b^2+36)*x^6 +(896*t^5+(16*b^21976)*t^3+(48*b^4+552*b^2312)*t)*x^5 +(864*t^6+(3160440*b^2)*t^4+(560*b^41080*b^2+1008)*t^2 24*b^6+56*b^4+72*b^2+9*a+24) *x^4 [....] There seems to be no problem when entering the equation with a correct syntax. Setting the status to pending and the Resolution to "Works for me". Dieter Kaiser  Comment By: Art Lenskold (dloksnel) Date: 20110822 14:18 Message: Still fails after my correction below: solve([0=x^21+(a(tx)*(t+1/(2*((tx)^2+(bsqrt(1x^2))^2))*(2*(b*xt*sqrt(1x^2))*(bsqrt(1x^2))2*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)))^1*(a+(11/(4*(tx)^2+(bsqrt(1x^2))^2)^2)*(4*(b*xt*sqrt(1x^2))^2*(bsqrt(1x^2))^28*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)*(b*xt*sqrt(1x^2))*(bsqrt(1x^2))+4*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))))^(1/2)))^2], [x]);  Comment By: Art Lenskold (dloksnel) Date: 20110820 21:55 Message: solve([0=x^21+(a(tx)*(t+1/(2*((tx)^2+(bsqrt(1x^2))^2))*(2*(b*xt*sqrt(1x^2))*(bsqrt(1x^2))2*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)))^1*(a+(11/(4*(tx)^2+(bsqrt(1x^2))^2)^2)*(4*(b*xt*sqrt(1x^2))^2*(bsqrt(1x^2))^28*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))^(1/2)*(b*xt*sqrt(1x^2))*(bsqrt(1x^2))+4*(x^2*(b^2t^2)*(x^22+2*t*xt^2)+t^2*(x^2+b^21)(2*t*xx^2)*(1+b^2+t^22*t*x)2*b*sqrt(1x^2)*((tx)^2+t*x*(x^2+2*t*xt^22)))))^(1/2)))^2], [x]);  Comment By: Art Lenskold (dloksnel) Date: 20110803 01:18 Message: Thank you for correcting an error on my part. Did you use a diagnostic tool or was it the result of eyeballing the error ? Attached is a somewhat improved corrected expression.  Comment By: Barton Willis (willisbl) Date: 20110802 02:38 Message: The (2(b*x ... makes this an invalid expression solve([0=x^21+(a(tx)*(t+1/(2*((tx)^2+(bsqrt(1x^2))^2))*(2(b*x < Maybe you could post a corrected expression  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3377380&group_id=4933 
From: SourceForge.net <noreply@so...>  20111026 20:58:07

Bugs item #3398066, was opened at 20110825 18:31 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3398066&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: Anton Voropaev (antonvoropaev) Assigned to: Nobody/Anonymous (nobody) Summary: radcan generates floats? Initial Comment: See also bug report ID: 2990192 INPUT build_info(); display2d : false; radcan(sqrt(sqrt(2)+1/2)); INPUT AND OUTPUT (%i1) build_info(); Maxima version: 5.25.0 Maxima build date: 12:0 8/2/2011 Host type: i686pcmingw32 Lisp implementation type: Clozure Common Lisp Lisp implementation version: Version 1.7r14925M (WindowsX8632) (%o1) (%i2) display2d : false; (%o2) false (%i3) radcan(sqrt(sqrt(2)+1/2)); rat: replaced 1.5 by 3/2 = 1.5 (%o3) sqrt(2^(3/2)+1)/sqrt(2)  >Comment By: Dieter Kaiser (crategus) Date: 20111026 22:58 Message: This bug is related to the bug 3185855  radcan warns about floatconvert. It is the same problem. A correction is to modify the function numer in the file compar.lisp. See bug 3185855. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110826 20:17 Message: It seems to come from csign or sign. radcan calls simpexpt which calls csign which eventually calls numer. I don't know if csign should be trying to convert the expression to a numerical result. Could be a bug in numer too.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3398066&group_id=4933 
From: SourceForge.net <noreply@so...>  20111026 20:50:38

Bugs item #3185855, was opened at 20110218 16:08 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3185855&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: radcan warns about floatconvert Initial Comment: radcan(2^floor(sin(x)/%pi)) gives 43 warnings that 1.0 was replaced by 1/1 This appears to be happening within sign(sin(x)/%pi), which is called by simpfloor, but calling sign directly from the top level doesn't cause the warning.  >Comment By: Dieter Kaiser (crategus) Date: 20111026 22:50 Message: This is a much simpler example for the reported bug: (%i1) ratsimpexpons:false$ (%i2) sign(1/%pi); (%o2) pos (%i3) ratsimpexpons:true$ (%i4) sign(1/%pi); rat: replaced 1.0 by 1/1 = 1.0 (%o4) pos The behavior depends on the setting of the global variable ratsimpexpons. It is by default false, but radcan sets the global variable to the value true. Therefore, we get the messages, when an argument of radcan calls the sign function. A simple correction is to set the global variable $ratprint to the value nil in the function numer in the file compar.lisp. The function numer is called from $sign to get a floating point approximation. But this conversion causes a call of ratsimp, when ratsimpexpons is true. This is a modified function numer: (defun numer (x) (let (($numer t) ; currently, no effect on $float, but proposed to ($ratprint nil) result) ;; Catch a Lisp error, if a floating point overflow occurs. (setq result (let ((errset nil)) (errset ($float x)))) (if result (car result) nil))) With this modification we get: (%i6) ratsimpexpons:true$ (%i7) sign(1/%pi); (%o7) pos (%i8) radcan(2^floor(sin(x)/%pi)); (%o8) 2^floor(sin(x)/%pi) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3185855&group_id=4933 
From: SourceForge.net <noreply@so...>  20111026 18:51:20

Bugs item #3167971, was opened at 20110130 10:22 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3167971&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: Includes proposed fix >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nils Bruin (nbruin) Assigned to: Nobody/Anonymous (nobody) Summary: errormsg : false does not turn off all error printing Initial Comment: The following illustrates the problem: (%i1) errormsg : false ; (%o1) false (%i2) 1/0;  an error. To debug this try: debugmode(true); As you can see, the error message itself is suppressed but the message about debugmode survives. In fact, reading MERROR in merror.lisp, it is clear that this message is not suppressed. Probably the line (format t (intl:gettext "~&  an error. To debug this try: debugmode(true);~%")) should be replaced by (and $errormsg (format t (intl:gettext "~&  an error. To debug this try: debugmode(true);~%"))) This change does not make much difference for using maxima as intended, but is very important when trying to use maxima as a library.  >Comment By: Dieter Kaiser (crategus) Date: 20111026 20:51 Message: I am not convinced, that it is a good idea to modify the reported behavior. The second message is due to a break of Maxima. Maxima has the function errcatch with the required behavior. The result of the function errcatch is an empty list, when Maxima encountered an error. (%i1) errormsg:false$ (%i2) errcatch(1/0); (%o2) [] The last error can be displayed with the command errormsg(). (%i3) errormsg(); expt: undefined: 0 to a negative exponent. (%o3) done I would like to suggest to close this bug report as won't fix. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3167971&group_id=4933 
From: SourceForge.net <noreply@so...>  20111026 18:26:41

Bugs item #3151302, was opened at 20110104 18:34 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3151302&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Wrong plotting of functions based on spherical harmonics Initial Comment: Attached file is a script that shows d orbitals of hydrogen atom. In Maxima 22.1 it showed proper shape of these orbitals, in Maxima 23 (both Linux and Windows) there is apparently somethong wrong, the effects are different for sure comparing 22.1 and 23 version. The most probable reasons are: change in plot3d with spherical coordinates, change in orthopoly package or damaged interface to gnuplot.  >Comment By: Dieter Kaiser (crategus) Date: 20111026 20:26 Message: Fixed in plot.lisp revision 26.10.2011 Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20111026 01:00 Message: The reported bug is in the lisp function mayberealpart. With revision 5.23 of Maxima the option $draw_realpart has been introduced for 3Dplots. The default value of this option is NIL. Therefore, the global *plotrealpart* is set to NIL, too. The function mayberealpart does not handle the case *plotrealpart* for a value NIL correctly. This is the function mayberealpart: (defun mayberealpart (x) (if *plotrealpart* ($realpart x) (if (eq 0 ($imagpart x)) x nil))) The function has two bugs. 1) It is wrong to check the value of ($imagpart x) with the function eq to be zero. 2) For the case that the imaginary part is zero, it is wrong to return the value x. x might be an expression, which has a real value. A more correct version is: (defun mayberealpart (x) (if *plotrealpart* ($realpart x) (if (zerop1 ($imagpart x)) ($realpart x) nil))) With this version of mayberealpart all plots of the reported examples work as expected. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3151302&group_id=4933 
From: SourceForge.net <noreply@so...>  20111026 12:02:36

Bugs item #3428734, was opened at 20111026 07:02 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3428734&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: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(bessel_y(1,z),z) with ?z : 1 Initial Comment: The code for the antiderivative of bessel_y has an (ignore unused) declaration that seems wrong: (%i2) integrate(bessel_y(1,z),z); (%o2) bessel_y(0,z) (%i3) ?z : 1; (%o3) 1 (%i4) integrate(bessel_y(1,z),z); (%o4) integrate(bessel_y(1,z),z)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3428734&group_id=4933 
From: SourceForge.net <noreply@so...>  20111025 23:00:23

Bugs item #3151302, was opened at 20110104 18:34 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3151302&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Wrong plotting of functions based on spherical harmonics Initial Comment: Attached file is a script that shows d orbitals of hydrogen atom. In Maxima 22.1 it showed proper shape of these orbitals, in Maxima 23 (both Linux and Windows) there is apparently somethong wrong, the effects are different for sure comparing 22.1 and 23 version. The most probable reasons are: change in plot3d with spherical coordinates, change in orthopoly package or damaged interface to gnuplot.  >Comment By: Dieter Kaiser (crategus) Date: 20111026 01:00 Message: The reported bug is in the lisp function mayberealpart. With revision 5.23 of Maxima the option $draw_realpart has been introduced for 3Dplots. The default value of this option is NIL. Therefore, the global *plotrealpart* is set to NIL, too. The function mayberealpart does not handle the case *plotrealpart* for a value NIL correctly. This is the function mayberealpart: (defun mayberealpart (x) (if *plotrealpart* ($realpart x) (if (eq 0 ($imagpart x)) x nil))) The function has two bugs. 1) It is wrong to check the value of ($imagpart x) with the function eq to be zero. 2) For the case that the imaginary part is zero, it is wrong to return the value x. x might be an expression, which has a real value. A more correct version is: (defun mayberealpart (x) (if *plotrealpart* ($realpart x) (if (zerop1 ($imagpart x)) ($realpart x) nil))) With this version of mayberealpart all plots of the reported examples work as expected. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3151302&group_id=4933 
From: SourceForge.net <noreply@so...>  20111025 20:33:27

Bugs item #3159780, was opened at 20110117 08:43 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3159780&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: Problem not in Maxima Group: None >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Goudour Jean Pierre (chouettenice) Assigned to: Nobody/Anonymous (nobody) Summary: absence de menu déroulant Initial Comment:  Maxima version: 5.21.1 Maxima build date: 0:9 6/23/2010 Host type: i686pclinuxgnu Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.7  deux machine HP diférentes deux Unbutu maverick identiques apparemment les mêmes paquets installés le menu déroulant normalement toujours présent dans une fenêtre si il a bien été créé au développement et coché comme devant apparaître sur le fixe il est bien présent ainsi que la barre d'outils sur le portable il n'y est pas et il n'y a que la barre d'outils impossible de le faire apparaître désinstallés plusieurs fois complètement les paquets et tués à la main les configs dans mon espace personnel réinstallés les paquets toujours pareil, pas très pratique pour travailler de n'avoir que la barre d'outils succincte  >Comment By: Dieter Kaiser (crategus) Date: 20111025 22:33 Message: Perhaps I have not understand the french text completely, but it seems to me, that the user is missing some menu in wxMaxima or it might be a problem in Xmaxima. It is difficult to get the necessary information from this bug report. Furthermore, we now have version Maxima 5.25.1 and this bug report might be out of date. Therefore, I would like to close this bug report as "out of date". Perhaps, we can get more information. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3159780&group_id=4933 
From: SourceForge.net <noreply@so...>  20111024 23:36:43

Bugs item #3426562, was opened at 20111020 18:42 Message generated for change (Comment added) made by m8r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) Summary: Can't start Maxima  TLS index too large Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  >Comment By: M8R7qg6gp (m8r) Date: 20111024 19:36 Message: When I start wxMaxima, then it says "Maxima process terminated." in the status bar. The command line version of the Maxima in Maxima5.25.1\bin is wx86cl.exe (and it is called from maxima.bat). (This is for the version without GCL.)  Comment By: Dieter Kaiser (crategus) Date: 20111024 15:50 Message: When I am right, then you try to start wxMaxima. wxMaxima is an interface to Maxima. Can you start Maxima itself on a console? Dieter Kaiser  Comment By: M8R7qg6gp (m8r) Date: 20111021 23:51 Message: I'm sorry, yes it is Maxima5.25.1. (This is the one which is _not_ compiled by with gcl.)  Comment By: Barton Willis (willisbl) Date: 20111021 21:36 Message: Are you sure you have Maxima version 5.2.1? If there ever was version 5.2.1, it would be about ten years old: http://sourceforge.net/projects/maxima/files/Maxima/historical/ The current Maxima version is 5.25.1  Comment By: M8R7qg6gp (m8r) Date: 20111020 18:44 Message: I have the 5.2.1 version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 
From: SourceForge.net <noreply@so...>  20111024 19:50:53

Bugs item #3426562, was opened at 20111021 00:42 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) Summary: Can't start Maxima  TLS index too large Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  >Comment By: Dieter Kaiser (crategus) Date: 20111024 21:50 Message: When I am right, then you try to start wxMaxima. wxMaxima is an interface to Maxima. Can you start Maxima itself on a console? Dieter Kaiser  Comment By: M8R7qg6gp (m8r) Date: 20111022 05:51 Message: I'm sorry, yes it is Maxima5.25.1. (This is the one which is _not_ compiled by with gcl.)  Comment By: Barton Willis (willisbl) Date: 20111022 03:36 Message: Are you sure you have Maxima version 5.2.1? If there ever was version 5.2.1, it would be about ten years old: http://sourceforge.net/projects/maxima/files/Maxima/historical/ The current Maxima version is 5.25.1  Comment By: M8R7qg6gp (m8r) Date: 20111021 00:44 Message: I have the 5.2.1 version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 
From: SourceForge.net <noreply@so...>  20111024 19:30:25

Bugs item #3427581, was opened at 20111023 19:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3427581&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: Ted Woollett (woollett) Assigned to: Nobody/Anonymous (nobody) Summary: imagpart of bessel_i and bessel_k Initial Comment: There is a bug in imagpart. imagpart(bessel_i(1,%i*x)) should be %i*bessel_i(1,%i*x), but imagpart is >returning bessel_i(1,%i*x). If this simplification is not immediately made, then the numerical work should automatically enforce that the result is a real number. One way this bug shows up is the noun form returned in: (%i6) quad_qag(imagpart(bessel_i(1,%i*x)),x,1,3,3,limit=700); (%o6) quad_qag(bessel_i(1,%i*x),x,1,3,3,epsrel = 1.0E8,epsabs = 0.0, limit = 700)  >Comment By: Dieter Kaiser (crategus) Date: 20111024 21:30 Message: This bug has been fixed in bessel.lisp revision 23.10.2011. (%i1) imagpart(bessel_i(1,%i*x)); (%o1) %i*bessel_i(1,%i*x) Nevertheless, the reported example is not solved: (%i2) quad_qag(imagpart(bessel_i(1,%i*x)),x,1,3,3,limit=700); (%o2) quad_qag(%i*bessel_i(1,%i*x),x,1,3,3,epsrel = 1.e8,epsabs = 0.0, limit = 700) The reason is a small imaginary part because of rounding errors: (%i3) imagpart(bessel_i(1,%i)); (%o3) %i*bessel_i(1,%i) (%i4) rectform(%),numer; (%o4) .44005058574493362.694443716532522e17*%i For other Bessel functions Maxima knows pure real or imaginary results and cuts off the rounding errors accordingly. This can be added for the bessel_i function too. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3427581&group_id=4933 
From: SourceForge.net <noreply@so...>  20111023 17:39:30

Bugs item #3427581, was opened at 20111023 10:39 Message generated for change (Tracker Item Submitted) made by woollett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3427581&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: Ted Woollett (woollett) Assigned to: Nobody/Anonymous (nobody) Summary: imagpart of bessel_i and bessel_k Initial Comment: There is a bug in imagpart. imagpart(bessel_i(1,%i*x)) should be %i*bessel_i(1,%i*x), but imagpart is >returning bessel_i(1,%i*x). If this simplification is not immediately made, then the numerical work should automatically enforce that the result is a real number. One way this bug shows up is the noun form returned in: (%i6) quad_qag(imagpart(bessel_i(1,%i*x)),x,1,3,3,limit=700); (%o6) quad_qag(bessel_i(1,%i*x),x,1,3,3,epsrel = 1.0E8,epsabs = 0.0, limit = 700)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3427581&group_id=4933 
From: SourceForge.net <noreply@so...>  20111022 03:51:38

Bugs item #3426562, was opened at 20111020 18:42 Message generated for change (Comment added) made by m8r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) Summary: Can't start Maxima  TLS index too large Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  >Comment By: M8R7qg6gp (m8r) Date: 20111021 23:51 Message: I'm sorry, yes it is Maxima5.25.1. (This is the one which is _not_ compiled by with gcl.)  Comment By: Barton Willis (willisbl) Date: 20111021 21:36 Message: Are you sure you have Maxima version 5.2.1? If there ever was version 5.2.1, it would be about ten years old: http://sourceforge.net/projects/maxima/files/Maxima/historical/ The current Maxima version is 5.25.1  Comment By: M8R7qg6gp (m8r) Date: 20111020 18:44 Message: I have the 5.2.1 version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 
From: SourceForge.net <noreply@so...>  20111022 01:36:19

Bugs item #3426562, was opened at 20111020 17:42 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) Summary: Can't start Maxima  TLS index too large Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  >Comment By: Barton Willis (willisbl) Date: 20111021 20:36 Message: Are you sure you have Maxima version 5.2.1? If there ever was version 5.2.1, it would be about ten years old: http://sourceforge.net/projects/maxima/files/Maxima/historical/ The current Maxima version is 5.25.1  Comment By: M8R7qg6gp (m8r) Date: 20111020 17:44 Message: I have the 5.2.1 version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 
From: SourceForge.net <noreply@so...>  20111021 11:17:37

Bugs item #3426847, was opened at 20111021 06:17 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426847&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: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: float hypergeometric error  fix Initial Comment: Bogus: (%i1) hypergeometric([1],[3/2,3/2], 10000.0),fpprec : 56; (%o1) 4.3929157271741888*10^65 OK: (%i2) hypergeometric([1],[3/2,3/2], 10000.0b0),fpprec : 56; (%o2) 4.0120302702491972103831671317134763299116280927551908191b4 Putative fix: In hypergeometricbyseries, replace ;; estimate number of correct digits: (setq dig (floor (* ( (log (max (abs s) (epsilon (bigfloat x)))) (log (* es (epsilon (bigfloat x))))) #.(/ (log 2) (log 10))))) with (setq dig (floor (* ( (log (max (abs s) (epsilon x))) (log (* es (epsilon x)))) #.(/ (log 2) (log 10)))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426847&group_id=4933 
From: SourceForge.net <noreply@so...>  20111020 22:44:56

Bugs item #3426562, was opened at 20111020 18:42 Message generated for change (Comment added) made by m8r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) Summary: Can't start Maxima  TLS index too large Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  >Comment By: M8R7qg6gp (m8r) Date: 20111020 18:44 Message: I have the 5.2.1 version.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 
From: SourceForge.net <noreply@so...>  20111020 22:42:53

Bugs item #3426562, was opened at 20111020 18:42 Message generated for change (Settings changed) made by m8r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) >Summary: Can't start Maxima  TLS index too large Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 
From: SourceForge.net <noreply@so...>  20111020 22:42:19

Bugs item #3426562, was opened at 20111020 18:42 Message generated for change (Tracker Item Submitted) made by m8r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&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 Private: No Submitted By: M8R7qg6gp (m8r) Assigned to: Nobody/Anonymous (nobody) Summary: Can't start Maxima Initial Comment: I'm not sure what changed, but since today, I can't start Maxima any more. When I start wx86cl.exe I get this error message: Can't allocate required TLS indexes. First available index value was 33 What is wrong? It used to work in the past. Win7 x64  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3426562&group_id=4933 