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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(6) 
3
(7) 
4
(2) 
5
(9) 
6
(14) 
7
(10) 
8
(6) 
9
(12) 
10
(1) 
11
(4) 
12
(9) 
13
(5) 
14
(18) 
15

16
(3) 
17
(3) 
18
(3) 
19
(1) 
20
(2) 
21
(5) 
22
(14) 
23
(2) 
24
(5) 
25
(1) 
26

27
(4) 
28
(8) 
29
(17) 
30
(8) 





From: SourceForge.net <noreply@so...>  20091128 23:56:03

Bugs item #2135806, was opened at 20080929 13:02 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2135806&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: noun / verb confusion for real/imag part Initial Comment: I think (%o4) should be (conjugate(z)+z)/2: (%i4) subst(lambda([s], (s + conjugate(s))/2), 'realpart, realpart(z)); (%o4) realpart(z) For the sub to happen, we need to nounify: (%i5) subst(lambda([s], (s + conjugate(s))/2), nounify(realpart), realpart(z)); (%o5) (conjugate(z)+z)/2 For other functions (say cos), the nounify isn't needed: (%i7) subst(lambda([s], 42), 'cos, cos(x)); (%o7) 42 So, I think the nounify(realpart) shouldn't be needed in (%i5).  >Comment By: Dieter Kaiser (crategus) Date: 20091129 00:56 Message: The substitution does not work as expected, because internally in Maxima the function realpart lives in two different forms: a noun form with the symbol %realpart and a verb form with the symbol $realpart. Because of this, we do not get the expected answer for the example of the bug report. The symbol 'realpart is passed with its noun form to the function subst. The verb function realpart(z) is evaluated (not simplified) to the internal noun form ((%realpart) $z). The substitution does not work, because subst distinguish the two forms: (%i1) declare(z,complex)$ (%i2) subst(lambda([s], (s + conjugate(s))/2), 'realpart, realpart(z)); (%o2) 'realpart(z) As written in the bug report a nounify helps. Again realpart(z) is evaluated to an internal noun form. Now we do not pass the verb form, but the symbol %realpart to subst: (%i3) subst(lambda([s], (s + conjugate(s))/2), nounify(realpart), realpart(z)); (%o3) (conjugate(z)+z)/2 We get the same result, when we prevent the evaluation of realpart(z) by quoting the function. Now only the verb form is present: (%i4) subst(lambda([s], (s + conjugate(s))/2), 'realpart, '(realpart(z))); (%o4) (conjugate(z)+z)/2 This behavior is different from simplifing functions like sin, cos, ... These functions only have one internal representation, that is a noun form. The "noun/verb confusion" is the expected behavior and is due to the implementation of functions like realpart. Perhaps, we can improve the documentation on this topic. I had no look at the code of subst. Perhaps, it is possible to do an implementation which ignores the noun/verb scheme for symbols. We could change the implementation of the function realpart and friends or we might modify the function subst. I think both ways are feature requests. Therefore, I would like to close this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090111 00:53 Message: The reason for the different behavior is that the functions realpart() and imagpart() have not the property ALIAS like the functions sin() or cos(). The parser returns for the input 'realpart the symbol $realpart. For fully implemented simplifying functions the parser returns e.g. for the input cos the symbol %cos because of the property ALIAS. Unfortunately, the Lisp function risplitnoun introduces the symbols %realpart and %imagpart and realpart(z) simplifies to the expression ((%realpart) z). The function subst() does not work because of the different symbols. The call nounify(realpart) changes the verb form $realpart to the noun form %realpart and now it works again. This behavior can be changed when we do not use the symbol %realpart but change the function risplitnoun like: (defun risplitnoun (l) (cons (list '($realpart) l) (list '($imagpart) l))) A noun which is declared to be complex now gives the expression: (($REALPART SIMP) $Z) The original code does a simplify, but I think this is not possible for the whole expression (we loop endlessly) and not necessary for the argument l. We get the correct expression from the simplifier. We have to change the symbols %realpart and %imagpart at about 5 places in the whole code. The testsuite has no problems with this changes. With this change the example will work as expected: (%i25) subst(lambda([s], (s + conjugate(s))/2), 'realpart, realpart(z)); (%o25) (conjugate(z)+z)/2 Remark: With the original code and the changed code we get: 'realpart(x+%i*y); 'realpart(x+%i*y) /* intern ((%realpart) .... ) */ In this case the parser returns the symbol %realpart. Because realpart() is not a simplifying function Maxima can not further simplify this expression e.g. rectform('realpart(1)); realpart(1) So what do you think? Should we change %realpart to $realpart in risplitnoun. Perhaps later we can introduce a simplifying function realpart(). Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2135806&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 22:40:59

Bugs item #1977146, was opened at 20080528 23:37 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977146&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: Robert Marik (robertmarik) Assigned to: Nobody/Anonymous (nobody) Summary: radexpand does not work as explained in documentation Initial Comment: >From maxima discussion list: Maxima manual states the following  When radexpand is false, certain transformations are inhibited. radcan (sqrt (1x)) remains sqrt (1x) and is not simplified to %i sqrt (x1). radcan (sqrt (x^2  2*x + 11)) remains sqrt (x^2  2*x + 1) and is not simplified to x  1.  Neglecting the typo in radcan (sqrt (x^2  2*x + 11)) which should be probably radcan (sqrt (x^2  2*x + 1)), I get the answer x1 also with radexpand:false. Moreover, sqrt(1x) remains sqrt(1x) even with radexpand:true. Is the documentation of radcan obsolete? Robert Marik reponse of Richard Fateman radexpand was inserted by someone else, after the code was written in 1970. I do not know if the documentation or the program is buggy, since I'm not sure what was intended. RJF  >Comment By: Dieter Kaiser (crategus) Date: 20091128 23:40 Message: I think the option variable radexpand controls the simplification of the power function, but does not control the function radcan. This is wrongly documented. radexpand works for expressions like (x*y)^a and (x^a)^b. Some examples are: (%i2) radexpand:false$ (%i3) (x*y)^a; (%o3) (x*y)^a (%i4) (x*y)^a,radexpand:true; (%o4) (x*y)^a The expression simplifies, if radexpand is set to ALL: (%i5) (x*y)^a,radexpand:all; (%o5) x^a*y^a (%i6) (x^a)^b; (%o6) (x^a)^b (%i7) (x^a)^b,radexpand:true; (%o7) (x^a)^b The expression simplifies, if radexpand is set to ALL: (%i8) (x^a)^b,radexpand:all; (%o8) x^(a*b) Both expressions simplify only, if radexpand is set to ALL. Therefore, the value ALL has the effect, that all variables are assumed to be positive and real. With a value of TRUE, radexpand controls the simplifcation of the power function for even and odd rational numbers. For an even rational power we do not get a simplification: (%i12) (x*y)^(1/2); (%o12) sqrt(x*y) (%i13) (x*y)^(1/2),radexpand:true; (%o13) sqrt(x*y) But we get a simplification for an odd power, if radexpand is set to TRUE: (%i14) (x*y)^(1/3); (%o14) (x*y)^(1/3) (%i15) (x*y)^(1/3),radexpand:true; (%o15) x^(1/3)*y^(1/3) The function radcan simplifies the above expressions with power functions too, but does not depend on the flag radexpand: The flag is set to FALSE: (%i34) radexpand; (%o34) false radcan simplifies the expressions. The flag radexpand does not matter: (%i35) radcan((x*y)^a); (%o35) x^a*y^a (%i36) radcan((x^a)^b); (%o36) x^(a*b) Therefore, radcan always assumes the variables to be positive and real. In a first step, all of these should be documented more clearly. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977146&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 21:25:11

Bugs item #1981628, was opened at 20080602 05:45 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: a bug of radcan() and radexpand Initial Comment: Dear Developers of Maxima, radcan() does not behave in the correct way. In the online desription of radcan() with the correction of a misprint, which is informed in a separate report by me, it is written that  Function: radcan (<expr>) ... ... When `radexpand' is `false', certain transformations are inhibited. `radcan (sqrt (1x))' remains `sqrt (1x)' and is not simplified to `%i sqrt (x1)'. `radcan (sqrt (x^2  2*x + 1))' remains `sqrt (x^2  2*x + 1)' and is not simplified to `x  1'. ... ... The control by the variable `radexpand' does not work in the present Maxima. A demonstration program is as follows:  /* * a_bug_of_radcan.maxima: * * S.Adachi 2008/06/01 */ display2d:false; radexpand; /* Inspect the value of `radexpand' */ radcan(sqrt(x^22*x+1)); /* expected to reduce to x1 */ radexpand:false; radcan(sqrt(x^22*x+1)); /* expected to remain sqrt(x^22*x+1) */ /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(a_bug_of_radcan.maxima) batching #p/Volumes/HFS+2/home/adachi/work/301/a_bug_of_radcan.maxima (%i2) display2d : false (%o2) false (%i3) radexpand (%o3) true (%i4) radcan(sqrt(12*x+x^2)) (%o4) x1 (%i5) radexpand:false (%o5) false (%i6) radcan(sqrt(12*x+x^2)) (%o6) x1 (%o7) "a_bug_of_radcan.maxima"  If `radexpand' is `false', `radcan(sqrt(x^22*x+1))' is expected to remain `sqrt(x^22*x+1)'. However, Maxima returns `x1' in reality. This is a bug. I think that this is a very serious bug of radcan(). Please fix it. Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20091128 22:25 Message: This bug report is a duplicate of the bug report ID: 1977146  radexpand does not work as explained in documentation. Closing this bug report as a duplicate: Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20090409 00:17 Message: (%i1) radcan(sqrt((x1)^2)); (%o1) abs(x  1) (%i2) radcan(sqrt(x^22*x+1)); (%o2) x  1 (%i3) build_info(); Maxima version: 5.17.1 Maxima build date: 19:10 12/18/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1981628&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 08:51:56

Bugs item #2905207, was opened at 20091128 03:48 Message generated for change (Settings changed) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905207&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: dsimcha (dsimcha) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum broken on example with gammas Initial Comment: (%i1) set_display(none); (%o1) set_display(none) (%i2) s : (%e^(1)*(sum((1p)^(nk)/(nk)!,n,0,inf))*p^k)/k!; inf ==== n  k  1 \ (1  p) k %e ( > ) p / (n  k)! ==== n = 0 (%o2)  k! (%i3) load(simplify_sum) ; (%o3) C:/PROGRA~1/MAXIMA~1.2/share/maxima/5.19.2/share/contrib/solve_rec/simpl\ ify_sum.mac (%i4) simplify_sum(s); Is k positive, negative, or zero? pos; k  p k %gammagreek( k, 1  p) p %e (%o4)   ( k)! k! I have no idea what the right answer to this problem is, but what Maxima gave obviously isn't it. If k > 0, either k! is undefined or (k)! is undefined. Both appear in the denominator of Maxima's answer. Also, should %gammagreek be %gamma?  >Comment By: Andrej Vodopivec (andrejv) Date: 20091128 09:51 Message: If you assume that k is an integer, then your input s is not defined. It can't be negative because of k! in the denominator and if it is positive, you get a division by zero in the sum. But Maxima does not assume that k is an integer. Here is what Mathematica returns In[1]:= s = (Exp[1]*(Sum[(1  p)^(n  k)/(n  k)!, {n, 0, Infinity}])*p^k)/k! Out[1]= (E^p p^k (Gamma[k]  Gamma[k, 1  p]))/(k! Gamma[k]) I believe that Maxima and Mathematica return equivalent answers. The simplify_sum will use hgfred to simplify this sum: (%i1) trace(hgfred)$ (%i2) s : (%e^(1)*(sum((1p)^(nk)/(nk)!,n,0,inf))*p^k)/k!$ (%i3) simplify_sum(s); Is k positive, negative, or zero?pos; 1 Enter hgfred[[1],[1k],1p] 1 Exit hgfredk*%gammagreek(k,1p)*(1p)^k*%e^(1p) (%o3) (k*%gammagreek(k,1p)*p^k*%e^(p))/((k)!*k!) I am closing this bugreport as invalid. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905207&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 02:48:55

Bugs item #2905207, was opened at 20091127 21:48 Message generated for change (Tracker Item Submitted) made by dsimcha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905207&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: dsimcha (dsimcha) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum broken on example with gammas Initial Comment: (%i1) set_display(none); (%o1) set_display(none) (%i2) s : (%e^(1)*(sum((1p)^(nk)/(nk)!,n,0,inf))*p^k)/k!; inf ==== n  k  1 \ (1  p) k %e ( > ) p / (n  k)! ==== n = 0 (%o2)  k! (%i3) load(simplify_sum) ; (%o3) C:/PROGRA~1/MAXIMA~1.2/share/maxima/5.19.2/share/contrib/solve_rec/simpl\ ify_sum.mac (%i4) simplify_sum(s); Is k positive, negative, or zero? pos; k  p k %gammagreek( k, 1  p) p %e (%o4)   ( k)! k! I have no idea what the right answer to this problem is, but what Maxima gave obviously isn't it. If k > 0, either k! is undefined or (k)! is undefined. Both appear in the denominator of Maxima's answer. Also, should %gammagreek be %gamma?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2905207&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 02:20:13

Bugs item #2836410, was opened at 20090812 19:07 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2836410&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: itayperl (itayperl) Assigned to: Nobody/Anonymous (nobody) Summary: won't factor complex polynomials? Initial Comment: I can't get maxima to factor some complex polynomials: (%i1) p1:expand((t+1%i)*(t%i)); (%o1) t^22*%i*t+t%i1 (%i2) p2:expand((t+2%i)*(t+1%i)*(t%i)); (%o2) t^33*%i*t^2+3*t^26*%i*tt%i3 (%i3) factor(p1); (%o3) t^22*%i*t+t%i1 (%i4) factor(p2); (%o4) t^33*%i*t^2+3*t^26*%i*tt%i3 (%i5) factor(solve(p2)); (%o5) [t = ((1)^(1/6)*%i+%i(1)^(1/6))/(1)^(1/6), t = ((1)^(1/6)*%i%i(1)^(1/6))/(1)^(1/6),t = %i1]  >Comment By: SourceForge Robot (sfrobot) Date: 20091128 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: 20091113 23:27 Message: It is not clear what the desired result should look like. Perhaps the function gfactor does what is needed: (%i17) gfactor(p1); (%o17) (t%i)*(t%i+1) (%i18) gfactor(p2); (%o18) (t%i)*(t%i+1)*(t%i+2) This seems to be not a bug report, but a support request. This might be out of date. 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=2836410&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 02:20:12

Bugs item #2840634, was opened at 20090819 22:05 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2840634&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: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: CLIENT: Lost socket connection Initial Comment: I have the following file (see attached). Whenever I open wxMaxima and open the file, I get the following error after the line algsys(...) : CLIENT: Lost socket connection ...Restart maxima with 'Maxima>Restart maxima'. Sometimes, after restarting maxima, it manages to automatically continue. This also happens if I introduce the algsys(...) line within maxima (not wxmaxima). I am running ubuntu 9.04  >Comment By: SourceForge Robot (sfrobot) Date: 20091128 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: 20091113 21:50 Message: I am running Maxima on Ubuntu 9.10. That is the info from the Maxima function build_info(): Maxima version: 5.19post Maxima build date: 20:9 11/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3467128190) I have no problems with the attached wxm file. There is not enough information to confirm a bug. Changing the status to pending and the resolution to works for me. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20090821 21:04 Message: Hmm. Not observed w/ Maxima 5.19.0 + Windows. What do you see if you try batch("sin_nombre.wxm"); in command line Maxima? What does build_info(); say?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2840634&group_id=4933 
From: SourceForge.net <noreply@so...>  20091128 01:21:05

Bugs item #1038624, was opened at 20041001 19:58 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1038624&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: askinteger ignores asksign database Initial Comment: assume(equal(zzz,0))$ askinteger(zzz) asks the user Last time I looked, zero was an integer. You can elicit this also in cases like integrate(x^r),x,0,1), which ask Is r pnz? answer=>ZERO Is r an integer? It is also very confusing (though duly documented) that askinteger affects the *global* database, while asksign only affects the *current computation* database. Fortunately, this is not true for internal uses of askinteger like the integrate example above.  >Comment By: Dieter Kaiser (crategus) Date: 20091128 02:21 Message: Fixed in compar.lisp revision 1.64. Some examples: (%i1) assume(equal(z,0))$ (%i2) askinteger(z); (%o2) yes (%i3) assume(equal(a,2))$ (%i4) askinteger(a); (%o4) yes (%i5) askinteger(2*a); (%o5) yes (%i6) askinteger(2+a); (%o6) yes Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060731 05:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1038624&group_id=4933 
From: SourceForge.net <noreply@so...>  20091127 02:20:23

Bugs item #2896728, was opened at 20091112 16:47 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896728&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: To be reviewed >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: function sqrt() crashes Initial Comment: typing :sqrt(100); Answer : 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. 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  >Comment By: SourceForge Robot (sfrobot) Date: 20091127 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: 20091112 23:09 Message: This bug report and the bug report ID: 2896713  "integration error" are not a problem of Maxima and not a problem of Ubuntu 9.10. Today, I have updated my system to Ubuntu 9.10 and I have no problems to compile and to run the testsuite of Maxima. I am sure that even Maxima 5.17.1 would have no problem to run on Ubuntu 9.10. The problem is the debian package for Maxima 5.17.1 with a binary which is compiled with GCL 2.6.7. The best that could be done is to distribute a new and clean debian package. Remark: I have started to build a debian package. Perhaps there is interest to get a working package. But I need some help to get it all correct. Setting this bug report to pending and the resulution to "Works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896728&group_id=4933 
From: SourceForge.net <noreply@so...>  20091127 02:20:23

Bugs item #2896713, was opened at 20091112 16:26 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896713&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration error 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 On Ubuntu 9.10 when trying to integrate I get the following: (%i1) integrate(1/(x^3+1),x); 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. It is strange, since on the previous version such error was not present. I am sure it is related to GCL, since with the same version on newly compiled FreeBSD maxima things goe the way they should: (%i1) integrate(1/(x^3+1),x); 2 x  1 2 atan() log(x  x + 1) sqrt(3) log(x + 1) (%o1)   +  +  6 sqrt(3) 3 html garbles the text! (%i2) build_info(); Maxima version: 5.17.1 Maxima build date: 15:58 11/4/2009 host type: i386portbldfreebsd7.0 lispimplementationtype: CLISP lispimplementationversion: 2.47 (20081023) (built 3466356167) (memory 3466357114) The difference is in the LISP!  >Comment By: SourceForge Robot (sfrobot) Date: 20091127 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: 20091112 23:17 Message: I think this bug report is a duplicate of the bug report ID: 2896728 "function sqrt() crashes". I suppose that again a debian package of Maxima is the source of the problems. An installation from souce code or cvs with serveral Lisp compilers does not give any problems. Setting the status to pending and the resolution to duplicate. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2896713&group_id=4933 
From: SourceForge.net <noreply@so...>  20091127 02:20:18

Bugs item #2893299, was opened at 20091106 14:20 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2893299&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration of signum fails miserably Initial Comment: (%i1) plot2d(integrate(signum(x),x,2,y),[y,1,2]); Unrecoverable error: invocation history stack overflow.  >Comment By: SourceForge Robot (sfrobot) Date: 20091127 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: 20091112 13:13 Message: Yes, your are right. On my system (CLISP and Linux) the example of this bug report returns after about 1 hour without an error: (%i1) plot2d(integrate(signum(x),x,2,y),[y,1,2]); plot2d: expression evaluates to nonnumeric value somewhere in plotting range. I think we can close this bug report. Maxima returns a noun form for the integral. That is not a bug. We have a package which does the integration. Unfortunately, Maxima needs a long time to return from plot2d and perhaps runs out of memory, but the user can not expect to get a plot for noun form. Setting the status to pending and the resolution to "Wont fix". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091109 23:17 Message: It's not hung; it's just slow. With the adaptive plotter, maxima is trying very hard to refine the graph because every calculated point is not a number which makes maxima think some kind of discontinuity exists. I think this is a deficiency caused by gcl not quite supporting the needed feature to make it stop early. Perhaps the level to which the adaptive plotter divides intervals should be made smaller so fewer subdivisions are tried?  Comment By: Dieter Kaiser (crategus) Date: 20091109 21:32 Message: First, I think it is not a problem of the integration of signum. Maxima does not find the integral and returns a noun form (without abs_integrate). That is O.K., because we have the abs_integrate package. Here another example: (%i28) integrate(sin(x)*expintegral_ei(x),x,2,y); (%o28) 'integrate(expintegral_ei(x)*sin(x),x,2,y) (%i29) plot2d(%,[y,1,2]); At this point Maxima hangs on my system (Linux and CLISP). I have tried several noun forms of integrals of this type and I have got the problem that plot2d does not return. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20091106 23:22 Message: Workaround (%i1) load(abs_integrate)$ (%i2) plot2d(integrate(signum(x),x,2,y),[y,1,2]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2893299&group_id=4933 
From: SourceForge.net <noreply@so...>  20091127 02:20:16

Bugs item #2892329, was opened at 20091105 01:16 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&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: Wont Fix Priority: 5 Private: No Submitted By: William Holtz (wmholtz) Assigned to: Nobody/Anonymous (nobody) Summary: Plot2d sometimes incorrect when using logscale Initial Comment: Using 5.19.2 on winXP. plot2d([1/(x+1)], [x,1e3,1e3], [logx])$ plot2d([1/(x+1)], [x,1e3,1e3], [gnuplot_preamble, "set logscale x"])$ These should give identical plots, but I the second version gives me a "knee" in the plot that is incorrect. This only happens with certain x ranges. I have attached an image of the incorrect plot. Please let me know if there is additional information I can provide  great program overall!  >Comment By: SourceForge Robot (sfrobot) Date: 20091127 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: 20091112 10:33 Message: As described in the last posting it is expected that the plots are different, because of a different sampling of points for the plot. I think this is not a bug. This can be seen when using the style points to plot the function: plot2d([1/(x+1)], [x,1e3,1e3], [style, points], [gnuplot_preamble, "set logscale x"])$ plot2d([1/(x+1)], [x,1e3,1e3], [style,points], [logx])$ Setting this bug report to pending and the resolution to "Wont Fix". Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20091105 01:31 Message: The issue is how maxima does plots. Basically, plots are done by uniformly sampling the x range. (Roughly). But when you want to do a log plot, the x range should be sampled logarithmically. When you specify logx, maxima knows to do the sampling correctly. That's why you get a nice smooth curve. But with the preamble, maxima doesn't know you're producing a log plot, so it does the normal sampling. That's why you see the knee. The samples selected are at 0.001 and about 0.78. (The sampling is roughly uniform, because maxima has an adaptive algorithm that will sample more if the plot is not smooth enough.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2892329&group_id=4933 
From: SourceForge.net <noreply@so...>  20091125 23:46:42

Bugs item #2031312, was opened at 20080729 14:05 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2031312&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: take macro Initial Comment: For some operators (for example, %sin), 'take' directly calls the simplifying function (it doesn't go through simplfiya). This causes trouble: (%i1) tellsimpafter(sin(x),42); (%o1) [sinrule1,simp%sin] OK: (%i2) sin(x); (%o2) 42 Look what happens when we use 'take': MAXIMA> (take '(%sin) '$x) ( (%SIN SIMP) $X) To get the simplified result, we need to expand: MAXIMA> ($expand (take '(%sin) '$x) 0 0) 42  >Comment By: Dieter Kaiser (crategus) Date: 20091126 00:46 Message: As proposed in this thread, the code which bypasses the simplifier has been cut out form the macro take in mopers.lisp revision 1.10. Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080830 17:18 Message: Logged In: YES user_id=501686 Originator: NO > The resimplify function sets dosimp to true. I don't know what dosimp controls. OK, let's call SIMPLIFYA instead then. > Do you really want to replace all things like (take '(%sin) x) with > (resimplify `((%sin) ,x))? Well, that or (SIMPLIFYA `((%SIN) ,X) T) or (SIMPLIFYAT `((%SIN) ,X)) or something like that. > That would be hundreds of changes I counted about 100 calls to TAKE. Did I miss a lot of them? I'll be happy to change them all to SIMPLIFYA. It's not a big deal. > What's wrong with fixing take? (1) If TAKE is the same as some other simplification function, it is redundant. If it is something else, it causes needless confusion. (2) TAKE is just going to punt to SIMPLIFYA  why not call SIMPLIFYA directly? There's nothing about the name "take" that suggests what it's supposed to do; at least "simplifya" suggests simplification. > I think removing the special cases in take would fix all of it's problems; I'm not opposed to that, although cutting out TAKE is better. Robert  Comment By: Barton Willis (willisbl) Date: 20080824 22:13 Message: Logged In: YES user_id=895922 Originator: YES The resimplify function sets dosimp to true. I don't know what dosimp controls. Do you really want to replace all things like (take '(%sin) x) with (resimplify `((%sin) ,x))? That would be hundreds of changes with almost no benefit (and risk creating new bugs). What's wrong with fixing take? I think removing the special cases in take would fix all of it's problems; something like: (defmacro take (operator &rest args) `(simplifya (list ,operator . ,args) t)  Comment By: Nobody/Anonymous (nobody) Date: 20080824 21:11 Message: Logged In: NO > No, we don't really need the 'take' macro, but 'take' is used multiple > times in at least a dozen files. Fixing 'take' would be less errorprone > than expunging it. Moreover, fixing 'take' is easy. I guess I'm not convinced. TAKE causes headaches if its effect is something different from RESIMPLIFY. So I'll assume it has the same effect. If TAKE is much faster, how does it achieve that? Why not put that same fast logic in RESIMPLIFY and get a systemwide benefit? It seems possible that TAKE is faster than RESIMPLIFY because it handles only special cases. If so let's (1) verify that TAKE has the same effect as RESIMPLIFY for those cases, and (2) renamed TAKE to RESIMPLIFYFOO where FOO is some indication of the narrower domain of this function. Robert Dodier (not logged in)  Comment By: Barton Willis (willisbl) Date: 20080824 13:08 Message: Logged In: YES user_id=895922 Originator: YES No, we don't really need the 'take' macro, but 'take' is used multiple times in at least a dozen files. Fixing 'take' would be less errorprone than expunging it. Moreover, fixing 'take' is easy. By the way, other macros in mopers suffer from the same problem: (%i1) tellsimp(a+b,42); Warning: Putting rules on '+' or '*' is inefficient, and may not work. (%o1) [+rule1,simplus] (%i2) a+b; (%o2) 42 (%i3) :lisp(add '$a '$b); ((MPLUS SIMP) $A $B) I'd guess that efficiency, not simplification, was a primary concern for the 'take' and 'add' macros. A great deal has changed since mopers was written; maybe it's time to revisit the macros in mopers.  Comment By: Robert Dodier (robert_dodier) Date: 20080824 06:15 Message: Logged In: YES user_id=501686 Originator: NO TAKE looks like a convenience hack. Do we really need it? Calling MEVAL or RESIMPLIFY makes it obvious what's going on  I don't see the point of a shortcut which has unpredictable results.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2031312&group_id=4933 
From: SourceForge.net <noreply@so...>  20091124 23:31:12

Bugs item #1646397, was opened at 20070128 13:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646397&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: listofvars includes true Initial Comment: (%i1) listdummyvars : false$ (%i2) e : '(if x < 6 then 5 else %pi)$ (%i3) listofvars(e); (%o3) [x,true] Surely, we don't want 'true' to be included in the list of variables.  >Comment By: Dieter Kaiser (crategus) Date: 20091125 00:31 Message: Fixed in inmis.lisp revision 1.15. Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20070303 03:36 Message: Logged In: YES user_id=501686 Originator: NO The conditional '(if foo then 5 else %pi) is represented as ((MCOND) $FOO 5 T $%PI). listofvars seems to be taking the arguments of MCOND and filtering out $%PI. I guess it should filter out T as well.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646397&group_id=4933 
From: SourceForge.net <noreply@so...>  20091124 23:05:51

Bugs item #2018842, was opened at 20080715 20:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2018842&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: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: unsimplified result from jacobi_p Initial Comment: (%i2) declare(n,integer); (%o2) done (%i3) assume(n >=0); (%o3) [n>=0] (%i4) jacobi_p(n,a,b,x); (%o4) (pochhammer(a+1,n)*sum(pochhammer(n,i)*pochhammer(n+b+a+1,i)*pochhammer(a+1,i)^(1)*i!^(1)*((1x)/2)^i,i,0,n))/n! (%i5) expand(%,0,0); (%o5) (pochhammer(a+1,n)*sum((pochhammer(n,i)*pochhammer(n+b+a+1,i)*(1x)^i)/(pochhammer(a+1,i)*2^i*i!),i,0,n))/n! %o4 and %o4 should be the same  >Comment By: Dieter Kaiser (crategus) Date: 20091125 00:05 Message: Fixed in orthopoly.lisp revision 1.17. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2018842&group_id=4933 
From: SourceForge.net <noreply@so...>  20091124 22:19:29

Bugs item #1190421, was opened at 20050426 18:51 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1190421&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Dodier (robert_dodier) Summary: lisp error in plot3d() Initial Comment: Here is the error: (%i1) plot3d(x**y,[x,0,1],[y,0,1]); Maxima encountered a Lisp error: Error in CATCH [or a callee]: Expected a LONGFLOAT Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2)  >Comment By: Dieter Kaiser (crategus) Date: 20091124 23:19 Message: This error seems to be no longer present in Maxima 5.19post. Setting the status to pending and resolution to "works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20070627 22:44 Message: Logged In: YES user_id=501686 Originator: NO Still present in Maxima 5.12.0 (both Clisp and GCL, in different forms). This is annoying; assigning this report to myself in hope that I'll get around to it soon.  Comment By: Raymond Toy (rtoy) Date: 20050819 20:18 Message: Logged In: YES user_id=28849 The actual problem is that when we compute 0.0^0.0, the function returns T. (I think this was done to support adaptive plotting where nonnumber means a singularity of some sort. But we don't do adaptive 3D plotting.) I'd really like it if we could use Lisp conditions to signal these kinds of errors so we can handle them better.  Comment By: Barton Willis (willisbl) Date: 20050427 04:36 Message: Logged In: YES user_id=895922 Avoiding x=0 and y=0 is a workaround plot3d(x^y,[x,0.01,1],[y,0.01,1]); But the error message ' Error in CATCH [or a callee]: Expected a LONGFLOAT' is goofy. There is something wrong that needs to be fixed. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1190421&group_id=4933 
From: SourceForge.net <noreply@so...>  20091124 22:09:14

Bugs item #1145990, was opened at 20050222 05:24 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1145990&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: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: affine package fails to load, and other strangeness Initial Comment: The affine package fails to load completely or correctly, and then what parts of it are loaded act strangely. load ("affine") appears to try to load everything, but stumbles with some error messages after getting through some of the files. load ("foo.lisp") for each Lisp file succeeds for most of the files but fails on some of them. Trying to execute fast_linsolve after staggering through the loading, I get an error that $POLY_VECTOR is undefined. But that's strange because it's defined in polya.lisp which apparently loaded successfully. Trying to execute grobner_basis I get an error that MUSTREPLACEP is undefined. But that's strange because it's defined in polysmp.lisp which apparently loaded successfully. No idea what's going on here, although my one suggestion is to cut out the autocompilation stuff if it's interfering with just getting the package loaded. Maxima version: 5.9.1 Maxima build date: 21:24 9/23/2004 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 19a similar behavior seen with Maxima version: 5.9.1.1cvs Maxima build date: 21:51 2/10/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.31 (released 20030901)  >Comment By: Dieter Kaiser (crategus) Date: 20091124 23:09 Message: I think this is out of date. We have Maxima 5.19post and the affine package loads without problems. Setting the status to pending and the resolution to "out of date". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20050613 07:57 Message: Logged In: YES user_id=501686 Executing load(affine); with Maxima 5.9.1cvs, clisp 2.33.2, now succeeds, although with lots of warning messages. After that, I can execute simple cases of fast_linsolve; didn't try anything more complicated. Executing load(affine) with Maxima 5.9.1cvs, gcl 2.6.6, barfs on compiling share/affine/sloop.lisp (first file). Didn't investigate.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1145990&group_id=4933 
From: SourceForge.net <noreply@so...>  20091124 02:20:24

Bugs item #2894516, was opened at 20091109 11:54 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2894516&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: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bad ratinal solution Initial Comment: I try to find a real root of x^32*x^2x1. To do that i search a rational number a/b, root of the polynom, id est a couple of integers (a,b) verifying a^32ba^2ab^2=15b^3 ; a classical use of Excel or OO3 calc give me (a/b) with 8 or 14 decimals, and the doubt : is there a RATIONAL root ? I open Wxmaxima and ask realroot(x^32x^2x1) : the answer is rational (see attached file) BUT !!! the given terms a and b don't verify the relation above !!!!!  >Comment By: SourceForge Robot (sfrobot) Date: 20091124 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: Raymond Toy (rtoy) Date: 20091109 15:06 Message: Marking as pending/invalid.  Comment By: Raymond Toy (rtoy) Date: 20091109 15:05 Message: Please read the documentation of what realroots does: Computes rational approximations of the real roots of the polynomial <expr> or polynomial equation <eqn> of one variable, to within a tolerance of <bound>. Coefficients of <expr> or <eqn> If you want to know the exact roots, solve(x^32*x^2x1) will tell you. It appears there is no rational root.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2894516&group_id=4933 
From: SourceForge.net <noreply@so...>  20091123 23:55:31

Bugs item #1447320, was opened at 20060310 17:07 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1447320&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: isolate / disolate / isolate_wrt_times interaction => error Initial Comment: Interactions between isolate, disolate, and isolate_wrt_times somehow causes a Lisp error ("ZEROP: ((RAT SIMP) 1 10) is not a number" and stuff like that). Here is a transcript which shows the error  I wasn't able to find anything simpler or shorter. Not sure what's going on here.  Robert Dodier Maxima 5.9.2.99rc3 http://maxima.sourceforge.net Using Lisp CLISP 2.34 (20050720) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) isolate (expand ((a+b+c)^2), c); 2 2 (%t1) b + 2 a b + a 2 (%o1) c + 2 b c + 2 a c + %t1 (%i2) disolate (%t1, a); Warning  you are redefining the Maxima function intersection 2 (%t2) b 2 (%o2) 2 a b + a + %t2 (%i3) isolate (expand ((a+b+c)^2), c); 2 (%o3) c + 2 b c + 2 a c + %t1 (%i4) expand((a+b)^5); 5 4 2 3 3 2 4 5 (%o4) b + 5 a b + 10 a b + 10 a b + 5 a b + a (%i5) isolate (%o4, a); 5 4 2 3 3 2 4 5 (%o5) b + 5 a b + 10 a b + 10 a b + 5 a b + a (%i6) isolate_wrt_times: true$ (%i7) isolate (%o4, a); (%t7) 5 b Maxima encountered a Lisp error: ZEROP: ((RAT SIMP) 1 10) is not a number Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091124 00:55 Message: This error is no longer present in Maxima 5.19post. It has been fixed in outmis.lisp revision 1.21. In the function memsimilar the test ZEROP is replaced by ZEROP1. The example of this bug report gives: (%i1) isolate (expand ((a+b+c)^2), c); (%t1) b^2+2*a*b+a^2 (%o1) c^2+2*b*c+2*a*c+%t1 (%i2) disolate (%t1, a); (%t2) b^2 (%o2) 2*a*b+a^2+%t2 (%i3) isolate (expand ((a+b+c)^2), c); (%o3) c^2+2*b*c+2*a*c+%t1 (%i4) expand((a+b)^5); (%o4) b^5+5*a*b^4+10*a^2*b^3+10*a^3*b^2+5*a^4*b+a^5 (%i5) isolate (%o4, a); (%o5) b^5+5*a*b^4+10*a^2*b^3+10*a^3*b^2+5*a^4*b+a^5 (%i6) isolate_wrt_times: true$ (%i7) isolate (%o4, a); (%t7) 5*b (%t8) 10*b^3 (%t9) 5*b^4 (%o9) b^5+a^5+%t7*a^4+10*%t2*a^3+%t8*a^2+%t9*a Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060815 05:32 Message: Logged In: YES user_id=501686 In the last line of MEMSIMILAR (src/outmis.lisp), (defun memsimilar (item1 item2 item2ev) (cond ((equal item2ev 0) nil) ((alike1 item1 item2ev) item2) (t (let ((errorsw t) r) (setq r (catch 'errorsw (div item2ev item1))) (and (mnump r) (not (zerop r)) (div item2 r)))))) the MNUMP check fails to protect ZEROP (which barfs on Maxima RAT objects). Probably the ZEROP should be changed to something equivalent to ?r = 0 (i.e. syntactic similarity to 0). Probably need to make sure that catches all kinds of zeros.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1447320&group_id=4933 
From: SourceForge.net <noreply@so...>  20091123 23:40:35

Bugs item #1556627, was opened at 20060911 22:07 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&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: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: solve & sign called on imaginary Initial Comment: This example is ridiculous, but this error shouldn't happen: x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^729120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0 (%i165) solve(%,x); `sign' called on an imaginary argument: sqrt(125*sqrt(6)) Barton  >Comment By: Dieter Kaiser (crategus) Date: 20091124 00:40 Message: I think the error is no longer present in Maxima 5.19post. We had a lot of improvements of the code for complex expressions since the version 5.10. This might be the reason that we no longer get the error. The result is: (%i34) eq; (%o34) x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9 +2304*x^8+9728*x^729120*x^6+48768*x^558560*x^4+56576*x^3 43008*x^2+20992*x4544 = 0 (%i35) solve(eq,x),algebraic:true; (%o35) [x = 1sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1] That is equivalent to the result with algebraic:false: (%i36) solve(eq,x),algebraic:false; (%o36) [x = 1sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5)), x = sqrt(sqrt(6^(3/2)+4*sqrt(125*sqrt(6))+5))+1, x = 1(6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4), x = (6^(3/2)+4*sqrt(125*sqrt(6))+5)^(1/4)+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i, x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)*%i+1, x = 1(6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4), x = (6^(3/2)+4*sqrt(5*sqrt(6)+12)+5)^(1/4)+1] Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20061210 13:19 Message: Logged In: YES user_id=895922 Originator: YES I'm guessing that I had algebraic : true. Then: (%i1) x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^7 29120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0$ (%i2) solve(%i1,x), algebraic : true; `sign' called on an imaginary argument: sqrt(125*sqrt(6))  an error. Quitting. To debug this try debugmode(true); (%i3) solve(%i1,x), algebraic : false; (%o3) [x=1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), < deleted> Maxima version: 5.10.0 Maxima build date: 17:18 10/24/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  Comment By: Robert Dodier (robert_dodier) Date: 20061210 07:09 Message: Logged In: YES user_id=501686 Originator: NO I don't see this error. I get the following from solve(%, x). [x = 1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), x = sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5))+1, x = 1(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4)+1, x = 1sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)), x = sqrt(sqrt(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5))+1, x = 1(4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(52*sqrt(6))*%i6*sqrt(6)+5)^(1/4)+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i, x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i, x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)*%i+1, x = 1(4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4), x = (4*6^(1/4)*sqrt(2*sqrt(6)+5)+6*sqrt(6)+5)^(1/4)+1]$ Above result is from Clisp: Maxima version: 5.10.0cvs Maxima build date: 23:10 11/30/2006 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.38 (20060124) (built 3355931855) (memory 3373942297) I believe I get the same thing from SBCL (looks similar). Maxima version: 5.10.0cvs Maxima build date: 23:9 12/5/2006 host type: i686pclinuxgnu lispimplementationtype: SBCL lispimplementationversion: 1.0  Comment By: Nobody/Anonymous (nobody) Date: 20061118 17:09 Message: Logged In: NO On my copy of wxMaxima, it didn't show any error!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&group_id=4933 
From: SourceForge.net <noreply@so...>  20091122 21:38:19

Bugs item #2901855, was opened at 20091121 14:08 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2901855&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: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: limit(sqrt(x),x,minf) not fully evaluated Initial Comment: Maxima returns a noun form, which can be evaluated in a second step: (%i2) limit(sqrt(x),x,minf); (%o2) %i*('limit(sqrt(x),x,inf)) (%i3) %,nouns; (%o3) %i*inf The limit of sqrt(minf) returns a noun form with a gensymbol: (%i4) limit(sqrt(minf)); (%o4) %i*('limit(sqrt(?g23883),?g23883,inf)) (%i5) %,nouns; (%o5) %i*inf I think the answer infinity is more correct. The answer %i*inf might be correct too. But Maxima can not handle directed infinities. Dieter Kaiser  >Comment By: Dan Gildea (dgildea) Date: 20091122 16:38 Message: Fixed in limit.lisp rev 1.86. (%i6) limit(sqrt(x),x,minf); (%o6) infinity (%i7) limit(sqrt(minf)); (%o7) infinity  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2901855&group_id=4933 
From: SourceForge.net <noreply@so...>  20091122 21:31:58

Bugs item #816797, was opened at 20031002 16:33 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816797&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: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(%i*log(a),a,0) nounform (%i*und problem) Initial Comment: limit(%i*log(a),a,0) => %I*('LIMIT(LOG(a),a,0)) This even though limit(log(a),a,0) => und and limit(%i*und) => und Similarly for other Und cases: limit(%i*exp(1/x),x,0);  >Comment By: Dan Gildea (dgildea) Date: 20091122 16:31 Message: Fixed in limit.lisp rev 1.86. (%i1) limit(%i*log(a),a,0) ; (%o1) infinity (%i2) limit(%i*exp(1/x),x,0); (%o2) und (%i3) limit(%i*exp(1/x),x,0,plus); (%o3) infinity (%i4) limit(%i*exp(1/x),x,0,minus); (%o4) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816797&group_id=4933 
From: SourceForge.net <noreply@so...>  20091122 15:21:35

Bugs item #2196405, was opened at 20081026 05:31 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2196405&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: To be reviewed >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: tellsimp error Initial Comment: I tried to create rules on integrate as follows and get an error when I try to use them. (%i1) outchar:o; (o1) o (%i2) matchdeclare(aa, constantp, bb, constantp, xx, symbolp)$ (%i3) simp:false; (o3) false (%i4) tellsimp('integrate(unit_step(aa*xx+bb),xx),(aa*xx+bb)*unit_step(aa*xx+bb)/aa)$ bb+xx*aa partitions `sum' aa*xx partitions `product' xx*aa Will be matched uniquely since subparts would otherwise be ambigious. (%i5) simp:true; (o5) true (%i6) integrate(unit_step(4*y+41),y); Improper value assignment: xx*aa  an error. To debug this try debugmode(true);  >Comment By: Dieter Kaiser (crategus) Date: 20091122 16:21 Message: I have tried the above example in a fresh Maxima, but can not reproduce the bug (Maxima 5.19post): A fresh Maxima, we have no rules. First we do not switch off simplification: (%i1) rules; (%o1) [] (%i2) machtdeclare(aa,constantp,bb,constantp,xx,symbolp); (%o2) machtdeclare(aa,constantp,bb,constantp,xx,symbolp) (%i3) tellsimp('integrate(unit_step(aa*xx+bb),xx),(aa*xx+bb)*unit_step(aa*xx+bb)/aa); (%o3) [integraterule2,?simpinteg] Maxima gets a noun form, but not an error: (%i4) integrate(unit_step(4*y+41),y); (%o4) 'integrate(unit_step(4*y+41),y) Again with simplification switched off, when defining the rule: (%i5) kill(all); (%o0) done (%i1) machtdeclare(aa,constantp,bb,constantp,xx,symbolp);(%o1) machtdeclare(aa,constantp,bb,constantp,xx,symbolp) (%i2) simp:false; (%o2) false (%i3) tellsimp('integrate(unit_step(aa*xx+bb),xx),(aa*xx+bb)*unit_step(aa*xx+bb)/aa); (%o3) [integraterule3,?simpinteg] (%i4) simp:true; (%o4) true Again a noun form and not an error: (%i5) integrate(unit_step(4*y+41),y); (%o5) 'integrate(unit_step(4*y+41),y) I do not know if something has changed. In a fresh Maxima session the error seems not to be present. Setting this bug report to pending and the status to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2196405&group_id=4933 
From: SourceForge.net <noreply@so...>  20091122 14:58:56

Bugs item #2020362, was opened at 20080717 10:04 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2020362&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: Invalid Priority: 5 Private: No Submitted By: Chien Chang Shun (bagwe) Assigned to: Nobody/Anonymous (nobody) Summary: augcoefmatrix? Initial Comment: My maxima version is 5.15 I am use augcoefmatrix() changes linear equation to coefficient matrix like as (%i01) f1:x13*x2+5*x3=2;f2:4*x1+7*x2x3=8; (%o01) x13*x2+5*x3=2 (%o02) 4*x1+7*x2x3=8 (%i03) augcoefmatrix([f1,f2],[x1,x2,x3]); (%o03) [1 3 5 2] [4 7 1 8] you can see that augmented matrix [2 8],that positive negative is have problem,It should be [2 8]  >Comment By: Dieter Kaiser (crategus) Date: 20091122 15:58 Message: I think all is correct. The matrix of coefficients is constructed from the list of equations of the form equation = 0. For the equations above we can write: (%i54) f1:x13*x2+5*x32=0$ (%i55) f2:4*x1+7*x2x38=0$ (%i56) augcoefmatrix([f1,f2],[x1,x2,x3]); (%o56) matrix([1,3,5,2],[4,7,1,8]) This is the result of the bug report. The example of the documentation shows this behavior too. Setting the status to pending and the resolution to invalid. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2020362&group_id=4933 
From: SourceForge.net <noreply@so...>  20091122 14:12:57

Bugs item #2902012, was opened at 20091122 12:20 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2902012&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  Differential eqns Group: To be reviewed >Status: Pending Resolution: Works For Me Priority: 2 Private: No Submitted By: Andreu Correa Casablanca (castarco) Assigned to: Nobody/Anonymous (nobody) Summary: desolve crashes Initial Comment: Maxima info: Maxima version: 5.17.1 Maxima build date: 14:31 7/13/2009 host type: x86_64unknownlinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (Ubuntu 9.10, 64 bits) the desolve function crashes in this case (in the 5.13 version (included in Ubuntu 9.04) desolve not crashes): eq1: 'diff(x(t), t) = (13/100)*x(t) + (4/100)*y(t) + 3; eq2: 'diff(y(t), t) = (5/100)*x(t) + (13/100)*y(t) + 3; atvalue(x(t), t=0, 0); atvalue(y(t), t=0, 0); desolve([eq1, eq2], [x(t), y(t)]); The error is: Maxima encountered a Lisp error: `desolve' can't handle this case. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091122 15:12 Message: Sorry, I have been wrong too. The solution is not new. I have checked Maxima 5.16.1 and Maxima 5.17.1 too. Both versions get the solution without any problem on a Windows system with GCL 2.6.8 (not 2.6.7). So, we have the second problem, that the Debian package of Maxima 5.17.1 does not work correctly. Dieter Kaiser  Comment By: Andreu Correa Casablanca (castarco) Date: 20091122 14:57 Message: Yes, the fix that I proposes solves my problem. But, obviously only works fine at all with lineal differential equations with constant coeficients, the laplace function doesn't work fine in the 5.17 version. I know that in the 5.19 the problem is solved, but i want to handle the installed apps by aptitude and the 5.17 version its suficient to suply my necessities.  Comment By: Dieter Kaiser (crategus) Date: 20091122 14:44 Message: 1. The message of this bug report is "desolve can't handle this case". This message indicates that the function laplace has not been able to find a solution. This is not a bug, but a missing feature. A trace of Maxima 5.19post shows that new code is responsible for finding a solution. Therefore, the missing feature has been added. Do you get a solution with your fix? 2. Nevertheless, the message is a bit strange. It seems to me that while printing the error message a Lisp error has occurred. It is a known problem that the Debian distribution of Maxima 5.17.1 does not work correctly. It is not a problem of Ubuntu or Maxima. Both work fine together with a lot of different Lisp compilers. It is a problem of the Debian package. It has to be rebuild. Dieter Kaiser  Comment By: Andreu Correa Casablanca (castarco) Date: 20091122 13:50 Message: I have another solution. The problem is not inside Maxima, is in the Linux Kernel :s . (Because virtual address space randomization, activated by default in Ubuntu 9.10). edit (as root) /etc/sysctl.conf and add the line "kernel.randomize_va_space = 1" (without the ") after that, run sysctl p. I found the solution in this thread: https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/303587 I supose the work would be focused on Lisp interpreter compatibility whith the virtual address space randomization.  Comment By: Dieter Kaiser (crategus) Date: 20091122 13:13 Message: This is the build info from my system: Maxima version: 5.19post Maxima build date: 1:11 11/22/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3467837494) With Maxima 5.19post on a Ubunto system I get a solution: (%i7) eq1: 'diff(x(t), t) = (13/100)*x(t) + (4/100)*y(t) + 3$ (%i8) eq2: 'diff(y(t), t) = (5/100)*x(t) + (13/100)*y(t) + 3$ (%i9) atvalue(x(t), t=0, 0)$ (%i10) atvalue(y(t), t=0, 0)$ (%i11) desolve([eq1, eq2], [x(t), y(t)]); (%o11) [x(t) = %e^(13*t/100)*(6912*5^(11/2)*sinh(t/(2*5^(3/2)))/149 51000000*cosh(t/(2*5^(3/2)))/149) /10000 +5100/149, y(t) = %e^(13*t/100)*(1632*5^(13/2)*sinh(t/(2*5^(3/2)))/149 54000000*cosh(t/(2*5^(3/2)))/149) /10000 +5400/149] I think this solution is new, because of a lot of improvements and bug corrections to the code of the functions laplace and specint the last month. Now laplace calls specint, if it can not find a solution. This is the case for this example. It might be useful for you to get the latest Maxima version with all improvements to the code of laplace and specint. The next release Maxima 5.20 will come in December 2009. Setting the status to pending and "Works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2902012&group_id=4933 