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

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{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 