Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(28) 
2018 
_{Jan}
(70) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{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...>  20100202 23:41:28

Bugs item #2944927, was opened at 20100203 01:11 Message generated for change (Comment added) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944927&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  Polynomials Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: Here is the screen session illustrating the problem: " Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.34 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) ?? coeff 0: coeff (Functions and Variables for Polynomials) 1: logconcoeffp (Functions and Variables for Logarithms) 2: multinomial_coeff (Functions and Variables for Sets) 3: poly_coefficient_ring (Functions and Variables for grobner) 4: taylor_order_coefficients (Functions and Variables for Series) Enter spaceseparated numbers, `all' or `none': 0  Function: coeff (<expr>, <x>, <n>) Returns the coefficient of `<x>^<n>' in <expr>. <n> may be omitted if it is 1. <x> may be an atom, or complete subexpression of <expr> e.g., `sin(x)', `a[i+1]', `x + y', etc. (In the last case the expression `(x + y)' should occur in <expr>). Sometimes it may be necessary to expand or factor <expr> in order to make `<x>^<n>' explicit. This is not done automatically by `coeff'. Examples: (%i1) coeff (2*a*tan(x) + tan(x) + b = 5*tan(x) + 3, tan(x)); (%o1) 2 a + 1 = 5 (%i2) coeff (y + x*%e^x + 1, x, 0); (%o2) y + 1 (%o1) true (%i2) coeff(2 * x * z, x * z, 1); (%o2) 0 (%i3) coeff(2 * x * z, x, 1); (%o3) 2 z (%i4) coeff(2 * x * z, foo, 1); (%o4) 0 "  please note that 'x * z' is a "complete subexpression" of '2 * x * z', still, the returned value is 0, though it should be 2. Still, 'coeff' returns 2z correctly in the second example. Furthermore, an attempt to find a coefficient at 'foo', which is not present in the expression, also yields 0. In all these cases 0 is a very strange return value  if whatever 'k' is a coefficient in 'expr', then 'expr' is divisible by 'k'. So, based on this, the failing expressions are divisible by 0. Is there a notion of 'undef' (like in Perl) or of NaN (like in "C") in 'maxima' ? ... It's even worse  it still works with the original expression consisting of 'x' and 'z', but it doesn't work with equivalent expression with 'u', 'v': " (%i9) coeff(2 * x * z, x, 1); (%o9) 2 z (%i10) coef(2 * u * v, v, 1); (%o10) coef(2 u v, v, 1) (%i11) coef(2 * u * v, u, 1); (%o11) coef(2 u v, u, 1) "  >Comment By: Sergei (sergeiste) Date: 20100203 01:41 Message: Another kind of failure: " %i22) coeff(v * u * v, v); (%o22) 0 ".  Comment By: Sergei (sergeiste) Date: 20100203 01:39 Message: Sorry, I misspelled 'coef'  firget one 'f' at the end. With correct spelling failure is the same for 'u', 'v': " (%i17) coeff(2 * (u * v), (u * v)); (%o17) 0 ",  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944927&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 23:39:01

Bugs item #2944927, was opened at 20100203 01:11 Message generated for change (Comment added) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944927&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  Polynomials Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: Here is the screen session illustrating the problem: " Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.34 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) ?? coeff 0: coeff (Functions and Variables for Polynomials) 1: logconcoeffp (Functions and Variables for Logarithms) 2: multinomial_coeff (Functions and Variables for Sets) 3: poly_coefficient_ring (Functions and Variables for grobner) 4: taylor_order_coefficients (Functions and Variables for Series) Enter spaceseparated numbers, `all' or `none': 0  Function: coeff (<expr>, <x>, <n>) Returns the coefficient of `<x>^<n>' in <expr>. <n> may be omitted if it is 1. <x> may be an atom, or complete subexpression of <expr> e.g., `sin(x)', `a[i+1]', `x + y', etc. (In the last case the expression `(x + y)' should occur in <expr>). Sometimes it may be necessary to expand or factor <expr> in order to make `<x>^<n>' explicit. This is not done automatically by `coeff'. Examples: (%i1) coeff (2*a*tan(x) + tan(x) + b = 5*tan(x) + 3, tan(x)); (%o1) 2 a + 1 = 5 (%i2) coeff (y + x*%e^x + 1, x, 0); (%o2) y + 1 (%o1) true (%i2) coeff(2 * x * z, x * z, 1); (%o2) 0 (%i3) coeff(2 * x * z, x, 1); (%o3) 2 z (%i4) coeff(2 * x * z, foo, 1); (%o4) 0 "  please note that 'x * z' is a "complete subexpression" of '2 * x * z', still, the returned value is 0, though it should be 2. Still, 'coeff' returns 2z correctly in the second example. Furthermore, an attempt to find a coefficient at 'foo', which is not present in the expression, also yields 0. In all these cases 0 is a very strange return value  if whatever 'k' is a coefficient in 'expr', then 'expr' is divisible by 'k'. So, based on this, the failing expressions are divisible by 0. Is there a notion of 'undef' (like in Perl) or of NaN (like in "C") in 'maxima' ? ... It's even worse  it still works with the original expression consisting of 'x' and 'z', but it doesn't work with equivalent expression with 'u', 'v': " (%i9) coeff(2 * x * z, x, 1); (%o9) 2 z (%i10) coef(2 * u * v, v, 1); (%o10) coef(2 u v, v, 1) (%i11) coef(2 * u * v, u, 1); (%o11) coef(2 u v, u, 1) "  >Comment By: Sergei (sergeiste) Date: 20100203 01:39 Message: Sorry, I misspelled 'coef'  firget one 'f' at the end. With correct spelling failure is the same for 'u', 'v': " (%i17) coeff(2 * (u * v), (u * v)); (%o17) 0 ",  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944927&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 23:11:45

Bugs item #2944927, was opened at 20100203 01:11 Message generated for change (Tracker Item Submitted) made by sergeiste You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944927&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  Polynomials Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergei (sergeiste) Assigned to: Nobody/Anonymous (nobody) Summary: wrong return value of 'coeff' Initial Comment: Here is the screen session illustrating the problem: " Maxima 5.20.1 http://maxima.sourceforge.net using Lisp SBCL 1.0.34 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) ?? coeff 0: coeff (Functions and Variables for Polynomials) 1: logconcoeffp (Functions and Variables for Logarithms) 2: multinomial_coeff (Functions and Variables for Sets) 3: poly_coefficient_ring (Functions and Variables for grobner) 4: taylor_order_coefficients (Functions and Variables for Series) Enter spaceseparated numbers, `all' or `none': 0  Function: coeff (<expr>, <x>, <n>) Returns the coefficient of `<x>^<n>' in <expr>. <n> may be omitted if it is 1. <x> may be an atom, or complete subexpression of <expr> e.g., `sin(x)', `a[i+1]', `x + y', etc. (In the last case the expression `(x + y)' should occur in <expr>). Sometimes it may be necessary to expand or factor <expr> in order to make `<x>^<n>' explicit. This is not done automatically by `coeff'. Examples: (%i1) coeff (2*a*tan(x) + tan(x) + b = 5*tan(x) + 3, tan(x)); (%o1) 2 a + 1 = 5 (%i2) coeff (y + x*%e^x + 1, x, 0); (%o2) y + 1 (%o1) true (%i2) coeff(2 * x * z, x * z, 1); (%o2) 0 (%i3) coeff(2 * x * z, x, 1); (%o3) 2 z (%i4) coeff(2 * x * z, foo, 1); (%o4) 0 "  please note that 'x * z' is a "complete subexpression" of '2 * x * z', still, the returned value is 0, though it should be 2. Still, 'coeff' returns 2z correctly in the second example. Furthermore, an attempt to find a coefficient at 'foo', which is not present in the expression, also yields 0. In all these cases 0 is a very strange return value  if whatever 'k' is a coefficient in 'expr', then 'expr' is divisible by 'k'. So, based on this, the failing expressions are divisible by 0. Is there a notion of 'undef' (like in Perl) or of NaN (like in "C") in 'maxima' ? ... It's even worse  it still works with the original expression consisting of 'x' and 'z', but it doesn't work with equivalent expression with 'u', 'v': " (%i9) coeff(2 * x * z, x, 1); (%o9) 2 z (%i10) coef(2 * u * v, v, 1); (%o10) coef(2 u v, v, 1) (%i11) coef(2 * u * v, u, 1); (%o11) coef(2 u v, u, 1) "  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944927&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 21:37:33

Bugs item #2944431, was opened at 20100202 07:26 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0007s^1.874 Initial Comment: Hi, I have the following Problem (from a German math book for K12): Given the following function f(x):=0.0007*s^1.874. 1. It is not possible to solve(f(x)=500,x) Given t(x):=(f(x)f(500))/(x500) 2. It is not possible to calculate limit(t(x),x,500) or to approximate by t(499.99999999999999999). From a certain number of 9s, the result is wrong. Given 1.5^x=34 3. It is not possible to solve the equation.  Comment By: Nobody/Anonymous (nobody) Date: 20100202 21:37 Message: Thanks rtoy, but the bugs are causing problems. I, as a teacher, started to replace the TI Voyage 200, by maxima. The TI Voyage is very simply. You type solve and (almost) every equation will be solve. So maxima is one step back for my students. Ok, they are forced to think before they decide to solve an equation because they have to choose a function which is able to solve the equation, but, in my opinion, K12stuff should be solved in a very simply way. Maybe this post helps to fix the bugs. To the programmers: Thanks for maxima  Comment By: Raymond Toy (rtoy) Date: 20100202 14:27 Message: 1. Maxima converts the float number to rationals and is trying to solve 7/10000*s^(937/500). It seems that maxima did find the roots, but is taking a very long time to sort all 937 roots. This is a bug. If you want numerical results, then perhaps find_root is what you're looking for. 2. That is due to the finite precision available with floating point. If you want to be able to do this with arbitrary precision use bfloats with enough digits. This is not a bug. 3. Yes, maxima cannot solve this equation. That is a bug. But for numerical answers, maybe find_root is what you're looking for.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 16:40:50

Bugs item #1954693, was opened at 20080430 07:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: 2D display of long denominator of nested fractional Initial Comment: Dear Developers of Maxima, I think that I met a bug of Maxima to display nested fractionals in the 2D style. If the denominator of a nested fractional is long, it is not displayed correctly. The display width controll based on the variable LINEL seems to be not effective in the denominator. Compared to this, the numerator of a nested fractional causes no such problem to be displayed even when the numerator is long. Here, I have prepared a program for demonstration:  /* * denominator_of_nested_fractional_is_not_displayed_correctly.maxima: * * The line length, which is usually controlled by the variable LINEL, * is not recognized in the denominator of a nested fractional, if the * nested fractional has a long denominator. * * S.Adachi 2008/04/29 */ /* Do not use ``display2d:false;'', since this is a problem in displaying a mathematical expression in the 2D style. */ X:product(f(i+1/2),i,0,20); Y:product(g(i+1/2),i,0,20); Z:X/Y; /* A nested fractional; its denominator is not displayed correctly. */ /* END */  This is a problem in displaying mathematical expressions in the 2D style. Accordingly, I cannot attach here the log list that is obtained by running the above program. (If I include in a bug report the mathematical expressions that are displayed in the 2D style by Maxima, the posted bug report becomes a disordered gabage in appearance.) So, please execute the above program by the command maxima b denominator_of_nested_fractional_is_not_displayed_correctly.maxima to see the phenomenon that I am reporting in this letter. I am using a console terminal with line width 80 to run the above program. It is essential for Maxima to display any mathematical expression in a correct mannar. If it is not, we cannot read the output from Maxima. So, please fix this bug. Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20100202 17:40 Message: I think this bug report is related to the following bug report: ID 635708  Bad 2ddisplay of a long denominator. A 2ddisplay with a small value of linel shows that the long denominator is not broken up correctly. This seems to be a general problem. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080622 23:55 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core.  Comment By: Robert Dodier (robert_dodier) Date: 20080504 07:55 Message: Logged In: YES user_id=501686 Originator: NO Observed in Maxima 5.15.0cvs. NOT observed in 5.9.0  so I guess the display code was modified incorrectly at some point. I can try some different versions, but it will be a while. The line width doesn't appear to be important  I get incorrect output when linel:65, or linel:70, or linel:80.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 16:06:46

Bugs item #635708, was opened at 20021108 22:17 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635708&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: Bad 2ddisplay of a long denominator Initial Comment: f(n):=IF n = 0 THEN 1 ELSE 91919*gg(x^n+f(EV(n 1,SIMP))) simp:false; Now calculate and display f(6)*f(6) (with the display window fairly narrow, say 60 columns wide). displa generates lines that are wider than the window, which wrap around and make the display illegible (especially the exponents). I realize that unsimplified expressions are an unusual case.... I ran across this problem during a debugging session where I turned of SIMP to check something.  >Comment By: Dieter Kaiser (crategus) Date: 20100202 17:06 Message: I think this problem is not restricted to unsimplified expressions. It is a general problem of the 2ddisplay. This is the most simple example I have found to see the general problem. We take a long numerator and a long denominator. (%i1) num:a1+a2+a3+a4+a5+a6+a7+a8+a9; (%o1) a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1 (%i2) denom:b1+b2+b3+b4+b5+b6+b7+b8+b9; (%o2) b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 We set linel to a small value 10. (%i4) linel:10; (%o4) 10 We display num/denom. This is a correct display. (%i5) num/denom; (%o5) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /(b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) We get the error when we multiply the denominator with a further constant. The last line is no longer broken up correctly: (%i6) num/(x*denom); (%o6) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /((b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) x) I had a look into the display routines. The additional constant x causes a nested expression which seems to confuse the highly recursive algorithm and the counting of space available for the expression. But I have not seen a way to correct this behaviour. Remark: The display of unsimplified matrices is easy to correct. The 2ddisplay routines have a check for unsimplified matrices. This can be removed without problems. Changing the title to reflect the issue. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060701 06:15 Message: Logged In: YES user_id=501686 Another bit of simp / display strangeness: simp : false; matrix ([a, b], [c, d]); Result is displayed as "matrix([a, b], [c, d])" (i.e. without the ascii art). I wonder why unsimplified matrices aren't displayed the same as simplified ones.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635708&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 15:52:22

Bugs item #2944687, was opened at 20100202 15:52 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944687&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: expand error in a particular expression Initial Comment: Incorrect result for: expand(expand(2*sqrt(2)*(6+x)+sqrt(2)*(6x))); sqrt(2) x + 30 sqrt(2) The result is alread wrong (though not as readable) after the first expand. Most slight variations of the input, for instance putting 5 or 7 instead of 6, do NOT yield a wrong answer. Maxima version: 5.13.0 Maxima build date: 22:7 9/5/2008 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944687&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 15:07:43

Bugs item #2944659, was opened at 20100202 16:07 Message generated for change (Tracker Item Submitted) made by crategus 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: Open Resolution: None 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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944659&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 14:27:13

Bugs item #2944431, was opened at 20100202 02:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0007s^1.874 Initial Comment: Hi, I have the following Problem (from a German math book for K12): Given the following function f(x):=0.0007*s^1.874. 1. It is not possible to solve(f(x)=500,x) Given t(x):=(f(x)f(500))/(x500) 2. It is not possible to calculate limit(t(x),x,500) or to approximate by t(499.99999999999999999). From a certain number of 9s, the result is wrong. Given 1.5^x=34 3. It is not possible to solve the equation.  >Comment By: Raymond Toy (rtoy) Date: 20100202 09:27 Message: 1. Maxima converts the float number to rationals and is trying to solve 7/10000*s^(937/500). It seems that maxima did find the roots, but is taking a very long time to sort all 937 roots. This is a bug. If you want numerical results, then perhaps find_root is what you're looking for. 2. That is due to the finite precision available with floating point. If you want to be able to do this with arbitrary precision use bfloats with enough digits. This is not a bug. 3. Yes, maxima cannot solve this equation. That is a bug. But for numerical answers, maybe find_root is what you're looking for.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 07:26:06

Bugs item #2944431, was opened at 20100202 07:26 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0007s^1.874 Initial Comment: Hi, I have the following Problem (from a German math book for K12): Given the following function f(x):=0.0007*s^1.874. 1. It is not possible to solve(f(x)=500,x) Given t(x):=(f(x)f(500))/(x500) 2. It is not possible to calculate limit(t(x),x,500) or to approximate by t(499.99999999999999999). From a certain number of 9s, the result is wrong. Given 1.5^x=34 3. It is not possible to solve the equation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944431&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 05:41:15

Bugs item #2943581, was opened at 20100201 01:51 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2943581&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: Dirk Bosmans (dbinf) Assigned to: Nobody/Anonymous (nobody) Summary: Grind omits empty strings Initial Comment: grind() on an empty string omits the 'surrounding' quotes, making the empty string "" disappear in the output. stringdisp has no effect, as in this example: Maxima 5.19.2 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL) ... (%i1) stringdisp:false; (%o1) false (%i2) key=""; (%o2) key = (%i3) grind(%); key = $ (%o3) done (%i4) stringdisp:true; (%o4) true (%i5) key=""; (%o5) key = "" (%i6) grind(%); key = $ (%o6) done  >Comment By: Robert Dodier (robert_dodier) Date: 20100201 22:41 Message: Fixed by r1.38 src/grind.lisp; now grind("") displays "" as expected. Closing this report as fixed. Thanks for bringing this item to our attention.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2943581&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 01:48:13

Bugs item #2944278, was opened at 20100202 02:22 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944278&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: To be reviewed >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of atan(x) from 0 to 1 crashes maxima Initial Comment:  Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  Command entered: romberg(atan(x),x,0,1) Result: Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. I'm not sure what else to include  >Comment By: Dieter Kaiser (crategus) Date: 20100202 02:48 Message: Of course Maxima can do the numerical and symbolic integration: (%i4) romberg(atan(x),x,0,1); (%o4) 0.438824279365977 (%i5) integrate(atan(x),x,0,1); (%o5) (2*log(2)%pi)/4 >From the build info I guess you have installed a Debian or Ubuntu package. It is a known problem that the Debian and Ubuntu package Maxima 5.17.1 compiled with GCL 2.6.7 does not work. It is not a problem of Maxima. Please get Debian or Ubuntu to provide a working version or try a version from another source e.g. sourceforge.net or http://zeus.nyf.hu/~blahota/maxima. Closing this bug report as invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944278&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 01:22:21

Bugs item #2944278, was opened at 20100202 01:22 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944278&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of atan(x) from 0 to 1 crashes maxima Initial Comment:  Maxima version: 5.17.1 Maxima build date: 14:9 7/13/2009 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  Command entered: romberg(atan(x),x,0,1) Result: Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Universal error handler called recursively (:ERROR NIL CONDITIONS::CLCSUNIVERSALERRORHANDLER "" "Couldn't protect") Maxima encountered a Lisp error: Error in CONDITIONS::CLCSUNIVERSALERRORHANDLER [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. I'm not sure what else to include  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2944278&group_id=4933 
From: SourceForge.net <noreply@so...>  20100202 01:08:36

Bugs item #1620165, was opened at 20061221 15:29 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1620165&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: assoc needs to check argument, was: Strange error Initial Comment: The following maxima code alphas=[]; alpha(n):=assoc(n,alphas); alpha(5); gives the error ======================================================== Maxima encountered a Lisp error: Error in PROGN [or a callee]: Caught fatal error [memory may be damaged] Automatically continuing. ======================================================== On the other hand assoc(5,[]); returns false (as it should). ==================================================== This is the banner of maxima Maxima 5.9.3 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)  >Comment By: Dieter Kaiser (crategus) Date: 20100202 02:08 Message: A test has been added with revision 1.8 of mutils.lisp. We get: (%i2) assoc(a,b); assoc: Second argument must be a list: b  an error. To debug this try: debugmode(true); (%i3) assoc(a,[b]); assoc: Improper form for list: [b]  an error. To debug this try: debugmode(true); (%i4) assoc(a,[a+b]); (%o4) b (%i5) assoc(c,[a+b,[c,d]]); (%o5) d Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20061221 16:23 Message: Logged In: YES user_id=501686 Originator: NO assoc should inspect its 2nd argument to verify it is a list. The error message is triggered because alphas=[] is not an assignment, so in assoc(5, alphas) the 2nd argument is a symbol, not the empty list. In this case assoc should print "Expected a list, got a symbol" or something.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1620165&group_id=4933 