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}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(14) 
2
(14) 
3
(10) 
4
(11) 
5
(1) 
6

7
(2) 
8
(2) 
9
(2) 
10
(14) 
11
(4) 
12
(3) 
13
(3) 
14
(3) 
15
(1) 
16
(4) 
17
(4) 
18
(5) 
19
(2) 
20
(1) 
21
(3) 
22
(2) 
23
(1) 
24
(4) 
25
(3) 
26
(2) 
27
(1) 
28







From: SourceForge.net <noreply@so...>  20100227 21:57:34

Bugs item #2960403, was opened at 20100227 15:57 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&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: Nobody/Anonymous (nobody) Summary: spurious floats in asksign Initial Comment: (%i3) integrate(1/(x^2 + x + b)^2,x); Is b0.25 positive or negative?pos; (%o3) (4*atan((2*x+1)/sqrt(4*b1)))/(4*b1)^(3/2)+(2*x+1)/((4*b1)*x^2+(4*b1)*x+4*b^2b) (%i4) build_info(); Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 (%o4)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&group_id=4933 
From: SourceForge.net <noreply@so...>  20100226 06:45:06

Bugs item #2953369, was opened at 20100217 02:56 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Definite Integration of 1/(ab*cos(x)) wrong Initial Comment: Maxima 5.20.1 with wxMaxima. integrate(1/(ab*cos(x)),x,0,%pi); where a>0, 0<b<a yields 0.  >Comment By: Barton Willis (willisbl) Date: 20100226 00:45 Message: Notice how a float enters into the asksign: (%i4) integrate(1/(1a*cos(x)),x); Is a^21.0 positive or negative?neg; (%o4) (2*atan(((2*a+2)*sin(x))/(2*sqrt(1a^2)*(cos(x)+1))))/sqrt(1a^2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2953369&group_id=4933 
From: SourceForge.net <noreply@so...>  20100226 02:01:04

Bugs item #2958892, was opened at 20100225 12:37 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2958892&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Cyprien Gay (cgay) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect exp(matrix) Initial Comment: Wrong evaluation of matrixG below. load(functs); G: matrix([1,g],[0,1]); G.G; G.G.G; float((I+G+G.G/2+G.G.G/6+G.G.G.G/24)/%e); exp(G); Maxima version: 5.20.1 Maxima build date: 19:27 12/14/2009 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian  >Comment By: Barton Willis (willisbl) Date: 20100225 20:01 Message: Use matrixexp: (%i1) matrixexp(matrix([1,g],[0,1])); (%o1) matrix([%e,%e*g],[0,%e])  Comment By: Cyprien Gay (cgay) Date: 20100225 12:40 Message: Ooops, I forgot: I: matrix([1,0],[0,1]); Correct_exp_G: matrix([%e,g*%e],[0,%e]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2958892&group_id=4933 
From: SourceForge.net <noreply@so...>  20100225 18:40:51

Bugs item #2958892, was opened at 20100225 19:37 Message generated for change (Comment added) made by cgay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2958892&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: Cyprien Gay (cgay) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect exp(matrix) Initial Comment: Wrong evaluation of matrixG below. load(functs); G: matrix([1,g],[0,1]); G.G; G.G.G; float((I+G+G.G/2+G.G.G/6+G.G.G.G/24)/%e); exp(G); Maxima version: 5.20.1 Maxima build date: 19:27 12/14/2009 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian  >Comment By: Cyprien Gay (cgay) Date: 20100225 19:40 Message: Ooops, I forgot: I: matrix([1,0],[0,1]); Correct_exp_G: matrix([%e,g*%e],[0,%e]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2958892&group_id=4933 
From: SourceForge.net <noreply@so...>  20100225 18:37:09

Bugs item #2958892, was opened at 20100225 19:37 Message generated for change (Tracker Item Submitted) made by cgay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2958892&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: Cyprien Gay (cgay) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect exp(matrix) Initial Comment: Wrong evaluation of matrixG below. load(functs); G: matrix([1,g],[0,1]); G.G; G.G.G; float((I+G+G.G/2+G.G.G/6+G.G.G.G/24)/%e); exp(G); Maxima version: 5.20.1 Maxima build date: 19:27 12/14/2009 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2958892&group_id=4933 
From: SourceForge.net <noreply@so...>  20100225 02:20:28

Bugs item #1430379, was opened at 20060213 01:10 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430379&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: Includes proposed fix >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: algsys & algebraic == true / FIX Initial Comment: (%o7) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i8) algsys(%,[a,b,c,d]); Maxima encountered a Lisp error: (%i9) algsys(%o7,[a,b,c,d]),algebraic : true; (%o9) [[a=(sqrt(14*%r7*%r8)1)/2, ...]] Would it be OK to have algsys (or maybe just resultant) set algebraic to true? Barton  >Comment By: SourceForge Robot (sfrobot) Date: 20100225 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100210 20:24 Message: The Lisp error has gone as written in the last posting. The system is solveable with the option variable algebraic set to true: (%i1) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c]; (%o1) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i2) algsys(%,[a,b,c,d]),algebraic:true; (%o2) [[a = (sqrt(14*%r559*%r560)1)/2,b = %r559,c = %r560, d = (sqrt(14*%r559*%r560)+1)/2], [a = (sqrt(14*%r561*%r562)+1)/2,b = %r561,c = %r562, d = (sqrt(14*%r561*%r562)1)/2],[a = 0,b = %r563,c = 0,d = 1], [a = 1,b = %r564,c = 0,d = 0],[a = 1,b = 0,c = 0,d = 1], [a = 0,b = 0,c = 0,d = 0]] I think we no longer have a bug. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090125 23:22 Message: This bug reported is related to the bug report SF[609466]. A check for a number zero in a call to punivarp has been checked in. Maxima no longer gets a fatal Lisp error for the examples given in this bug report, but returns an error message: `algsys' cannot solve  system too complicated.  an error. To debug this try debugmode(true); Should we close the bug report too? The Lisp error has gone. The algorithm is not smart enough to find a solution for the problem, but that might be not a bug. To improve algsys more general we can set the flag $algebraic in the routine $algsys. That is the point a lot of global variables are set. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060815 03:16 Message: Logged In: YES user_id=501686 Observed in 5.9.3.99rc1.  Comment By: Barton Willis (willisbl) Date: 20060213 11:09 Message: Logged In: YES user_id=895922 Proposed fix: (defmfun $resultant (a b mainvar) (prog (varlist formflag $ratfac res ans genvar $keepfloat $algebraic) (setq varlist (list mainvar) $ratfac t ans 1 $algebraic t) It seems to fix the problem: (%o9) [b*c+a^2a,b*d+a*bb,c*d+a*cc,d^2d+b*c] (%i10) algsys(%,[a,b,c,d]); (%o10) [[a=(sqrt(14*%r7*%r8)1)/2,b=%r7 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1430379&group_id=4933 
From: SourceForge.net <noreply@so...>  20100224 11:59:03

Bugs item #2957758, was opened at 20100224 04:41 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957758&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  Plotting Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: maurerpe (maurerpe) Assigned to: Nobody/Anonymous (nobody) Summary: plotting gamma_incomplete_regularized incorrect Initial Comment: In a new session: gamma_incomplete_regularized(3,0); > 1 (which is correct) gamma_incomplete_regularized(3,0.1); > .9998453469297354 (also correct) plot2d(gamma_incomplete_regularized(3,x),[x,0,10]); (plot window opens, but the plot is scaled incorrectly. It starts at 2 instead of at 1. It appears to be a plot of gamma_incomplete(3,x) instead of the regularized version). This is true for a plot of gamma_incomplete_regularized(a,x), for a != 2 and a != 3. The plot appears to be gamma_incomplete(a,x). Note that for a = 2 and a = 3, the functions are equivalent, so it cannot be determined if gamma_incomplete_regularized and gamma_incomplete is being plotted. I have only observed this while plotting. Evaluating the functions produces the correct results. The error was originally noticed when using the cdf_gamma function in the distrib package (which uses the gamma_incomplete_regularized function).  >Comment By: Dieter Kaiser (crategus) Date: 20100224 12:59 Message: This bug is caused by a typo in the function $gamma_incomplete_regularized. The verb function simplified wrongly to gamma_incomplete. Fixid in gamma.lisp revision 1.48. Closing this bug report as fixed. Dieter Kaiser  Comment By: maurerpe (maurerpe) Date: 20100224 04:45 Message: Here is the version that I am running: Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.19gentoo  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957758&group_id=4933 
From: SourceForge.net <noreply@so...>  20100224 03:45:07

Bugs item #2957758, was opened at 20100223 22:41 Message generated for change (Comment added) made by maurerpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957758&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  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: maurerpe (maurerpe) Assigned to: Nobody/Anonymous (nobody) Summary: plotting gamma_incomplete_regularized incorrect Initial Comment: In a new session: gamma_incomplete_regularized(3,0); > 1 (which is correct) gamma_incomplete_regularized(3,0.1); > .9998453469297354 (also correct) plot2d(gamma_incomplete_regularized(3,x),[x,0,10]); (plot window opens, but the plot is scaled incorrectly. It starts at 2 instead of at 1. It appears to be a plot of gamma_incomplete(3,x) instead of the regularized version). This is true for a plot of gamma_incomplete_regularized(a,x), for a != 2 and a != 3. The plot appears to be gamma_incomplete(a,x). Note that for a = 2 and a = 3, the functions are equivalent, so it cannot be determined if gamma_incomplete_regularized and gamma_incomplete is being plotted. I have only observed this while plotting. Evaluating the functions produces the correct results. The error was originally noticed when using the cdf_gamma function in the distrib package (which uses the gamma_incomplete_regularized function).  >Comment By: maurerpe (maurerpe) Date: 20100223 22:45 Message: Here is the version that I am running: Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.19gentoo  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957758&group_id=4933 
From: SourceForge.net <noreply@so...>  20100224 03:41:53

Bugs item #2957758, was opened at 20100223 22:41 Message generated for change (Tracker Item Submitted) made by maurerpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957758&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  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: maurerpe (maurerpe) Assigned to: Nobody/Anonymous (nobody) Summary: plotting gamma_incomplete_regularized incorrect Initial Comment: In a new session: gamma_incomplete_regularized(3,0); > 1 (which is correct) gamma_incomplete_regularized(3,0.1); > .9998453469297354 (also correct) plot2d(gamma_incomplete_regularized(3,x),[x,0,10]); (plot window opens, but the plot is scaled incorrectly. It starts at 2 instead of at 1. It appears to be a plot of gamma_incomplete(3,x) instead of the regularized version). This is true for a plot of gamma_incomplete_regularized(a,x), for a != 2 and a != 3. The plot appears to be gamma_incomplete(a,x). Note that for a = 2 and a = 3, the functions are equivalent, so it cannot be determined if gamma_incomplete_regularized and gamma_incomplete is being plotted. I have only observed this while plotting. Evaluating the functions produces the correct results. The error was originally noticed when using the cdf_gamma function in the distrib package (which uses the gamma_incomplete_regularized function).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957758&group_id=4933 
From: SourceForge.net <noreply@so...>  20100224 02:20:30

Bugs item #2944659, was opened at 20100202 15:07 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944659&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  Limit Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: limit(erf(sqrt(log(t))/sqrt(2)),t,0) > Lisp error Initial Comment: This example gives a Lisp error: (%i7) limit(erf(sqrt(log(t))/sqrt(2)),t,0); Maxima encountered a Lisp error: The value NIL is not of type FIXNUM. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. The constant sqrt(2) in the numerator or denominator is necessary to get the error. Without the constant the limit gives a noun form. (%i8) limit(erf(sqrt(log(t))),t,0); (%o8) 'limit(erf(sqrt(log(t))),t,0) I think the source of the error is taylim (now the constant sqrt(2) is in the numerator): (%i9) tlimit(erf(sqrt(log(t))*sqrt(2)),t,0); Maxima encountered a Lisp error: The value NIL is not of type FIXNUM. Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. Dieter Kaiser  >Comment By: SourceForge Robot (sfrobot) Date: 20100224 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100209 23:59 Message: I think this error has gone. We get a noun form for the examples of this bug report: (%i4) limit(erf(sqrt(log(t))*sqrt(2)),t,0); (%o4) 'limit(erf(sqrt(2)*sqrt(log(t))),t,0) (%i5) limit(erf(sqrt(log(t))/sqrt(2)),t,0); (%o5) 'limit(erf(sqrt(log(t))/sqrt(2)),t,0) This might be due to the change of the code for simplifying 0^a which has been reverted in parts. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944659&group_id=4933 
From: SourceForge.net <noreply@so...>  20100223 22:23:42

Bugs item #2957489, was opened at 20100223 16:23 Message generated for change (Tracker Item Submitted) made by jamlatino You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957489&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: jamlatino (jamlatino) Assigned to: Nobody/Anonymous (nobody) Summary: Does not solve equation but after it is rearranged it does Initial Comment: If I enter the equation in the following form, it does not solve it: solve(exp(a * x)  C * exp(b * x)=0,x); [%e^(b*x)=%e^(a*x)/C] But if I rearrange the equation like this solve(exp(a * x) /exp(b * x) = C,x); [x=log(C)/(ba)] then it gives the correct answer.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2957489&group_id=4933 
From: SourceForge.net <noreply@so...>  20100222 04:26:07

Bugs item #2956413, was opened at 20100221 23:12 Message generated for change (Settings changed) made by vttoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2956413&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: Tests Group: Fix for 5.9.2 >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pwRrfV <a href="http://qcvrzswrfyyb.com/">qcvrzswrfyyb</a>;, Initial Comment: pwRrfV <a href="http://qcvrzswrfyyb.com/">qcvrzswrfyyb</a>;, [url=http://rmetmxouuyee.com/]rmetmxouuyee[/url], [link=http://ygdjisehfwru.com/]ygdjisehfwru[/link], http://gjfuhvpiikyy.com/  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2956413&group_id=4933 
From: SourceForge.net <noreply@so...>  20100222 04:12:57

Bugs item #2956413, was opened at 20100222 04:12 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2956413&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: Tests Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pwRrfV <a href="http://qcvrzswrfyyb.com/">qcvrzswrfyyb</a>;, Initial Comment: pwRrfV <a href="http://qcvrzswrfyyb.com/">qcvrzswrfyyb</a>;, [url=http://rmetmxouuyee.com/]rmetmxouuyee[/url], [link=http://ygdjisehfwru.com/]ygdjisehfwru[/link], http://gjfuhvpiikyy.com/  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2956413&group_id=4933 
From: SourceForge.net <noreply@so...>  20100221 14:26:05

Bugs item #719968, was opened at 20030412 00:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: No SIMP function Initial Comment: The info file documents a function SIMP, which "causes exp to be simplified regardless of the setting of the switch SIMP which inhibits simplification if FALSE". But there is no such function defined. It is also not clear if this is supposed to force resimplification of the whole expression, or only the part without SIMP flags.  >Comment By: Dieter Kaiser (crategus) Date: 20100221 15:26 Message: A comment about the possibility to resimplify an expression with the command expand(expr,0,0) has been added to Simplifications.texi revision 1.25. The possibility to resimplify with the command ev(expr,noeval) is already documented. In addition and if it is desired we might support a user function resimplify which does expand(expr,0,0) in a more user friendly way. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100217 19:53 Message: Again an example to show the possibilities we have: We set the variable y and x. (%i1) y:sin(x); x:1; (%o1) sin(x) (%o2) 1 We change the environment: (%i3) exponentialize:true; (%o3) true These are three possibilities to resimplify sin(x) without evaluation (the value of x is not inserted): (%i4) expand(y,0,0); (%o4) %i*(%e^(%i*x)%e^(%i*x))/2 (%i5) ev(y,noeval); (%o5) %i*(%e^(%i*x)%e^(%i*x))/2 (%i6) ?resimplify(y); (%o6) %i*(%e^(%i*x)%e^(%i*x))/2 These three possibilities behave differently when we have a CRE expression. (%i13) exponentialize:false$ (%i12) r:rat(2*sin(x)); (%o12)/R/ 2 sin(x) (%i13) exponentialize:true$ The function expand does a specrepcheck. The result is no longer a CRE expression: (%i14) expand(r,0,0); (%o14) %i*(%e^(%i*x)%e^(%i*x)) The function ev simplifies and returns a CRE expression: (%i15) ev(r,noeval); (%o15)/R/ (%i*(%e^(%i*x))^2%i)/%e^(%i*x) The Lisp function resimplify does nothing for a CRE expression: (%i16) ?resimplify(r); (%o16)/R/ 2 sin(x) The possibility to resimplify with ev(expr,noeval) is part of the documentation of the function ev. I would like to suggest to add a comment to the function expand that expand(expr,0,0) allows the resimplification of an expression and to close this bug report. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20060829 16:58 Message: Logged In: YES user_id=588346 expand(...,0,0) calls ?resimplify. The difference is that expand does a specrepcheck. Since almost no simplification flags apply to specreps, it is probably appropriate to do the specrepcheck. You could argue that if the input is in CRE form, you should just rerat it to get the effect of changed keepfloat, ratfac, etc. flags, but I think that's too complicated; and you can always call rat to rerat. ex:log(a*b) => log(a b) rex:rat(ex)$ logexpand:all$ ex => log(a b) rex => /R/ log(a b) expand(ex) => log(b) + log(a) ?resimplify(ex) => log(b) + log(a) expand(rex) => log(b) + log(a) ?resimplify(rex) => /R/ log(a b)  Comment By: Robert Dodier (robert_dodier) Date: 20060829 16:34 Message: Logged In: YES user_id=501686 There exists a Lisp function RESIMPLIFY  How does expand(foo, 0, 0) differ from ?resimplify(foo) ?  Comment By: Stavros Macrakis (macrakis) Date: 20060828 16:48 Message: Logged In: YES user_id=588346 Robert, you suggest that we expose Simplifya. But Simplifya is called automatically by meval every time you evaluate anything. You might think it was useful when simp=false. But when simp=false, it has no effect. I think what you want is a "resimplify" function, which would resimplify all subparts of an expression with current settings. As I've mentioned in email before, this already exists, though admittedly in a very obscure form: expand(...,0,0). It would be reasonable to have a userfriendly name for it, e.g. resimplify.  Comment By: Robert Dodier (robert_dodier) Date: 20050411 05:23 Message: Logged In: YES user_id=501686 The description of the simp function went away some months ago (late 2004, I think). So the documentation of a nonexistent function is no longer a problem. It makes me wonder, though, if we to expose SIMPLIFYA somehow or something like that. If the answer is "no", let's close this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 
From: SourceForge.net <noreply@so...>  20100221 12:25:17

Bugs item #834813, was opened at 20031103 02:22 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: a < b or 1 < 2 wrong Initial Comment: Assume nothing is known about a and b. prederror:true just making sure it is set to the default for the test avoid ev in case ev complicates matters a<b or 1<2 => error ! is(a<b or 1<2) => error ! if (a<b or 1<2) then 5 => error ! prederror:false a<b or 1<2 => unknown ! is(a<b or 1<2) => true (OK) if a<b or 1<2 then 5 => 5 (OK) I believe that (a<b or 1<2) should be returning true in all these cases. Maxima 5.9.0 gcl 2.5.0 Windows 2000  >Comment By: Dieter Kaiser (crategus) Date: 20100221 13:25 Message: With prederror:false (the default value) the examples of this bug report work as expected: (%i1) prederror; (%o1) false (%i2) a<b or 1<2; (%o2) true (%i3) is(a<b or 1<2); (%o3) true (%i4) if (a<b or 1<2) then 5; (%o4) 5 When we set prederror to true we get the following: (%i11) prederror:true; (%o11) true (%i12) a<b or 1<2; Unable to evaluate predicate a < b  an error. To debug this try: debugmode(true); (%i13) is(a<b or 1<2); Unable to evaluate predicate a < b  an error. To debug this try: debugmode(true); (%i14) if (a<b or 1<2) then 5; Unable to evaluate predicate a < b  an error. To debug this try: debugmode(true); I think this is the expected and documented behaviour of the option variable prederror. It might be arguable that an error should be given only if the whole predicate can not be evaluated to be true or false. But the error message is clear. At this point we might close this bug report, because the default behaviour works as expected and the case prederror:false is documented. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060710 06:55 Message: Logged In: YES user_id=501686 Code for unevaluated conditionals (share/contrib/boolsimp/) handles a < or 1 < 2 (also xxx or true, example given below) as expected when prederror = false (which is boolsimp's default mode). Same problems are observed when boolsimp = true, because I wrote boolsimp to have the same behavior as current code when prederror = true. I'd rather just be rid of prederror altogether and have the code always yield what is now yielded when prederror = false.  Comment By: Stavros Macrakis (macrakis) Date: 20031103 02:25 Message: Logged In: YES user_id=588346 Same problem for xxx or true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&group_id=4933 
From: SourceForge.net <noreply@so...>  20100221 04:51:56

Bugs item #2940133, was opened at 20100126 11:05 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2940133&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  Limit Group: None Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(log(x),x,0) Initial Comment: Maxima report the wrong answer for the title's limit, it reports: infinity (not inf) (also instead of the symbol) and even if i try log(x) > 0 it reports infinity...  Comment By: Nobody/Anonymous (nobody) Date: 20100221 04:51 Message: W6Mitu <a href="http://otadxzaqaelt.com/">otadxzaqaelt</a>;, [url=http://zhlwwyztgeme.com/]zhlwwyztgeme[/url], [link=http://vhcljkrrodga.com/]vhcljkrrodga[/link], http://fdfiowxaosjt.com/  Comment By: Dan Gildea (dgildea) Date: 20100218 07:51 Message: Added discussion of this case to manual.  Comment By: Nobody/Anonymous (nobody) Date: 20100126 23:55 Message: obviusly i tryed the right limit, it worked (inf) but even from left is inf (even if it's not a funcion limit...) should it not to say: "error" instead of "infinity"? it could be misunderstanding...  Comment By: Raymond Toy (rtoy) Date: 20100126 19:09 Message: Perhaps you wanted limit(log(x),x,0,'plus) > minf. "infinity" is the complex infinity. Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2940133&group_id=4933 
From: SourceForge.net <noreply@so...>  20100220 22:15:06

Bugs item #910270, was opened at 20040305 07:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=910270&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: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1/+3*x parses as 1/(+3*x) Initial Comment: A plus sign immediately following a multiplicative operator causes the next multiplicative term to bind tightly: 1/+3*x == 1/(+3*x) == 1/(3*x) (!!) should be (1/3)*x 1/+x/3 == 1/(+x/3) == 3/x (!!) should be (1/+x)/3 = 1/(3*x) a^+b*c == a^+(b*c) (!!) should be (a^b)*c With negative signs, these parse correctly: 1/3*x == (1/3)*x == x/3 1/x/3 == (1/x)/3 == 1/(3*x) a^b*c == (a^b)*c == c/(a^b) Maxima 5.9.0 on GCL 2.5.0 mingw32 W2k Athlon  >Comment By: Dieter Kaiser (crategus) Date: 20100220 23:15 Message: Fixed as suggested in nparse.lisp revision 1.56. The right binding power of the "+" has been increased to a value 134. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100214 13:57 Message: In the examples of this bug report, the operator "" works correctly as a prefix operator in examples like x^a*y > y/(x^a) and x/a*y > (x/a)*y because the right binding power rpb of the operator "" has a value 134 which is greater than the left binding power of the operator "*" with a value of 120 and the right binding power of the operator "/" with a value of 120. The operator "+" will behave the same way, when we increase the right binding power to a value of 134 too. We will get the expexted results: (%i6) 1/+3*x; (%o6) x/3 (%i6) 1/+x/3; (%o6) 1/(3*x) (%i6) a^+b*x; (%o6) a^b*x Both, the testsuite and the share_testsuite have no problems with this change of the right binding power of the operator "+". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060724 04:42 Message: Logged In: YES user_id=501686 Examples work the same in 5.9.3cvs. The observed behavior has something to do with LBP and RBP properties, although I don't know if the following numbers account entirely for the observed behavior. :lisp (mapcar #'lbp '($+ $ $* $/ $^)) => (100 100 120 120 140) :lisp (mapcar #'rbp '($+ $ $* $/ $^)) => (100 134 200 120 139)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=910270&group_id=4933 
From: SourceForge.net <noreply@so...>  20100219 14:24:01

Bugs item #2952900, was opened at 20100216 17:21 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&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: Open Resolution: None Priority: 5 Private: No Submitted By: traxi (traxi) Assigned to: Nobody/Anonymous (nobody) Summary: Solving equations with logarithms Initial Comment: (%i1) solve([log(x)*x=0], [x]); (%o1) [x=1,x=0] Should only be [x=1,x=0]  Comment By: Nobody/Anonymous (nobody) Date: 20100219 14:23 Message: decreases driven society <a href="http://www.business247.ae">new decline power computer 104</a> [url=http://sarahkassel.com]uncertainty weathering[/url] http://support.microsoft.com  Comment By: traxi (traxi) Date: 20100219 07:32 Message: I'm only interested in real results. Is it possible to configure maxima, ony to get real results in this case?  Comment By: Stavros Macrakis (macrakis) Date: 20100218 22:05 Message: I think you mean "should only be [x=1]". Maxima actually got lucky here, because x=0 is arguably a solution by continuity, since limit(log(x)*x,x,0) = 0 (even for negative x).  Comment By: Barton Willis (willisbl) Date: 20100218 01:07 Message: The alternative solver (to_poly_solve) can not solve this equation either: (%i13) load(to_poly_solver)$ (%i12) %solve([log(x)*x=0], [x]); Division by 0 (%o12) %union() Thanks for this reportI'll try to fix to_poly_solve function.  Comment By: traxi (traxi) Date: 20100217 08:26 Message: Should only be x=1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&group_id=4933 
From: SourceForge.net <noreply@so...>  20100219 07:32:27

Bugs item #2952900, was opened at 20100216 18:21 Message generated for change (Comment added) made by traxi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&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: Open Resolution: None Priority: 5 Private: No Submitted By: traxi (traxi) Assigned to: Nobody/Anonymous (nobody) Summary: Solving equations with logarithms Initial Comment: (%i1) solve([log(x)*x=0], [x]); (%o1) [x=1,x=0] Should only be [x=1,x=0]  >Comment By: traxi (traxi) Date: 20100219 08:32 Message: I'm only interested in real results. Is it possible to configure maxima, ony to get real results in this case?  Comment By: Stavros Macrakis (macrakis) Date: 20100218 23:05 Message: I think you mean "should only be [x=1]". Maxima actually got lucky here, because x=0 is arguably a solution by continuity, since limit(log(x)*x,x,0) = 0 (even for negative x).  Comment By: Barton Willis (willisbl) Date: 20100218 02:07 Message: The alternative solver (to_poly_solve) can not solve this equation either: (%i13) load(to_poly_solver)$ (%i12) %solve([log(x)*x=0], [x]); Division by 0 (%o12) %union() Thanks for this reportI'll try to fix to_poly_solve function.  Comment By: traxi (traxi) Date: 20100217 09:26 Message: Should only be x=1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&group_id=4933 
From: SourceForge.net <noreply@so...>  20100218 22:05:02

Bugs item #2952900, was opened at 20100216 12:21 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&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: Open Resolution: None Priority: 5 Private: No Submitted By: traxi (traxi) Assigned to: Nobody/Anonymous (nobody) Summary: Solving equations with logarithms Initial Comment: (%i1) solve([log(x)*x=0], [x]); (%o1) [x=1,x=0] Should only be [x=1,x=0]  >Comment By: Stavros Macrakis (macrakis) Date: 20100218 17:05 Message: I think you mean "should only be [x=1]". Maxima actually got lucky here, because x=0 is arguably a solution by continuity, since limit(log(x)*x,x,0) = 0 (even for negative x).  Comment By: Barton Willis (willisbl) Date: 20100217 20:07 Message: The alternative solver (to_poly_solve) can not solve this equation either: (%i13) load(to_poly_solver)$ (%i12) %solve([log(x)*x=0], [x]); Division by 0 (%o12) %union() Thanks for this reportI'll try to fix to_poly_solve function.  Comment By: traxi (traxi) Date: 20100217 03:26 Message: Should only be x=1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&group_id=4933 
From: SourceForge.net <noreply@so...>  20100218 21:55:46

Bugs item #2954472, was opened at 20100218 16:55 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rectform with large floats gives bad answer Initial Comment: rectform(1e160/(1e160+%i)) => 0.0 (should be 1.0  1.0e160) We should probably specialcase the float case to give better precision by avoiding underflow.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954472&group_id=4933 
From: SourceForge.net <noreply@so...>  20100218 11:56:38

Bugs item #2954141, was opened at 20100218 05:56 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954141&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: Kummer reflection Initial Comment: The Kummer reflection formula is applied in cases where it would be best to not use it: (%i12) expand_hypergeometric : true$ OK: (%i13) hypergeometric([2],[3],x); (%o13) x^2/12(2*x)/3+1 Not OK: (%i14) hypergeometric([2],[3],x); (%o14) hypergeometric([5],[3],x)*%e^(x) I think good fix would be be apply the identity in only cases that make lead to a polynomial case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2954141&group_id=4933 
From: SourceForge.net <noreply@so...>  20100218 07:51:06

Bugs item #2940133, was opened at 20100126 06:05 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2940133&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  Limit Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: limit(log(x),x,0) Initial Comment: Maxima report the wrong answer for the title's limit, it reports: infinity (not inf) (also instead of the symbol) and even if i try log(x) > 0 it reports infinity...  >Comment By: Dan Gildea (dgildea) Date: 20100218 02:51 Message: Added discussion of this case to manual.  Comment By: Nobody/Anonymous (nobody) Date: 20100126 18:55 Message: obviusly i tryed the right limit, it worked (inf) but even from left is inf (even if it's not a funcion limit...) should it not to say: "error" instead of "infinity"? it could be misunderstanding...  Comment By: Raymond Toy (rtoy) Date: 20100126 14:09 Message: Perhaps you wanted limit(log(x),x,0,'plus) > minf. "infinity" is the complex infinity. Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2940133&group_id=4933 
From: SourceForge.net <noreply@so...>  20100218 01:07:37

Bugs item #2952900, was opened at 20100216 11:21 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&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: Open Resolution: None Priority: 5 Private: No Submitted By: traxi (traxi) Assigned to: Nobody/Anonymous (nobody) Summary: Solving equations with logarithms Initial Comment: (%i1) solve([log(x)*x=0], [x]); (%o1) [x=1,x=0] Should only be [x=1,x=0]  >Comment By: Barton Willis (willisbl) Date: 20100217 19:07 Message: The alternative solver (to_poly_solve) can not solve this equation either: (%i13) load(to_poly_solver)$ (%i12) %solve([log(x)*x=0], [x]); Division by 0 (%o12) %union() Thanks for this reportI'll try to fix to_poly_solve function.  Comment By: traxi (traxi) Date: 20100217 02:26 Message: Should only be x=1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&group_id=4933 
From: SourceForge.net <noreply@so...>  20100217 19:44:46

Bugs item #752417, was opened at 20030611 08:55 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=752417&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: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Felix Edgar Klee (feklee) Assigned to: Nobody/Anonymous (nobody) Summary: KEEPFLOAT:TRUE ignored by SOLVE Initial Comment: The documentation for SOLVE and for tools that use SOLVE (e.g. EIGENVALUES) doesn't state that floating point numbers are always converted to rational numbers and that KEEPFLOAT:TRUE is being ignored.  >Comment By: Dieter Kaiser (crategus) Date: 20100217 20:44 Message: The suggested extension to the documentation has been added in Polynomials.text revision 1.31. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090311 11:10 Message: Adding the proposed change to the documentation of SF[2556130]. Dieter Kaiser File Added: 0001ExplanationforlimitationsofKEEPFLOATindoc.patch  Comment By: Dieter Kaiser (crategus) Date: 20090311 11:03 Message: Adding the comment of SF[2556130] to this bug report and closing SF[2556130]. This is the correct thread: "Since the behaviour of maxima doesn't seem likely to change on this, we should probably add a reference to it in the documentation. I believe the keepfloat docs are most appropriate." Dieter Kaiser  Comment By: Rupert Swarbrick (rswarbrick) Date: 20090202 02:14 Message: For reference, this issue was first raised by Felix Klee on the Maxima mailing list on June 8th 2003. In the archived email logs, this starts at line 87000 of the unzipped 2003.txt  Comment By: Rupert Swarbrick (rswarbrick) Date: 20090202 02:13 Message: See 2556130 for a proposed patch. Sorry for the trackerrelated incompetence!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=752417&group_id=4933 