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}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(1) 
2

3
(4) 
4
(1) 
5
(5) 
6
(4) 
7
(2) 
8

9
(100) 
10
(57) 
11
(1) 
12
(11) 
13
(2) 
14
(2) 
15
(2) 
16

17
(5) 
18
(1) 
19

20

21

22

23

24
(1) 
25

26
(2) 
27
(4) 
28
(1) 
29

30
(5) 






From: SourceForge.net <noreply@so...>  20060430 17:50:14

Bugs item #1479409, was opened at 20060430 12:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479409&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: Maxima thinks pochhammer is real Initial Comment: (%i1) load("orthopoly")$ (%i2) pochhammer(1+%i*2,n); (%o2) pochhammer(2*%i+1,n) (%i3) imagpart(%); (%o3) 0 < Bogus! Also, conjugate should commute with pochhammer, but it doesn't: (%i4) conjugate(%o2); (%o4) conjugate(pochhammer(2*%i+1,n)) Finally, the simplification (%i5) pochhammer(x,n); (%o5) 1/((1)^n*pochhammer(1x,n)) is not wrong, but goofy. (I think this simplification should only happen when n is an positive integer  not declared to be an integer or assumed positive.) I have fixes for all these things that I'll submit after testing. My fixes will convert pochhammer to a simplifying function. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479409&group_id=4933 
From: SourceForge.net <noreply@so...>  20060430 11:55:46

Bugs item #1479149, was opened at 20060429 21:13 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration with trigonometric function and following diff Initial Comment: integrate(k*x/f(x),x), knumber, f(x)thrigonometric function  sin(x)^2, cos(x)^2, Sin(x)^3 etc. gives a very poor result. axiom gives a better and short result. following diff(%,x) gives a non simply formula. So, maxima has a problem with a trigonometric function ;)  >Comment By: Barton Willis (willisbl) Date: 20060430 06:55 Message: Logged In: YES user_id=895922 Did Maxima give an incorrect result for any of these integrals? Maxima does gives a lengthy formula for integrate(x / sin(x)^2,x), but it seems to be correct: (%i1) integrate(x / sin(x)^2,x)$ (%i2) diff(%,x)  x/sin(x)^2$ (%i3) exponentialize(%)$ (%i4) ratsimp(%); (%o4) 0 In addition to exponentialize and ratsimp, Maxima has functions trigsimp, trigreduce, and trigexpand. Did you try using these functions to convert the antiderivatives into the form you were looking for? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&group_id=4933 
From: SourceForge.net <noreply@so...>  20060430 11:34:45

Bugs item #1479151, was opened at 20060429 21:24 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima don't use a   Initial Comment: Example: integrate(1/x,x) gives a log(x), but must be gives a log(abs(x)). May be, maxima don't verify permissible value anyhere.  >Comment By: Barton Willis (willisbl) Date: 20060430 06:34 Message: Logged In: YES user_id=895922 If you want integrate(1/x,x) = log(abs(x)), set the option variable 'logabs' to true: (%i1) logabs : true$ (%i2) integrate(1/x,x); (%o2) log(abs(x)) (%i3) logabs : false$ (%i4) integrate(1/x,x); (%o4) log(x) Since integrate(1/x,x) = log(abs(x)) isn't correct off the real axis, the default for 'logabs' is false. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&group_id=4933 
From: SourceForge.net <noreply@so...>  20060430 02:24:14

Bugs item #1479151, was opened at 20060429 19:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima don't use a   Initial Comment: Example: integrate(1/x,x) gives a log(x), but must be gives a log(abs(x)). May be, maxima don't verify permissible value anyhere.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479151&group_id=4933 
From: SourceForge.net <noreply@so...>  20060430 02:13:58

Bugs item #1479149, was opened at 20060429 19:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Integration with trigonometric function and following diff Initial Comment: integrate(k*x/f(x),x), knumber, f(x)thrigonometric function  sin(x)^2, cos(x)^2, Sin(x)^3 etc. gives a very poor result. axiom gives a better and short result. following diff(%,x) gives a non simply formula. So, maxima has a problem with a trigonometric function ;)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1479149&group_id=4933 
From: SourceForge.net <noreply@so...>  20060428 19:56:26

Bugs item #1477965, was opened at 20060427 13:31 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1477965&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: specint bug Initial Comment: specint(exp(s*t)*(1cos(a*t))/t,t); returns 0, whereas the expression to integrate is always positive. laplace((1cos(a*t))/t,t,s) returns the correct result, log((a^2+s^2)/s^2) [A&S 29.3.108]. A similar bug affects specint(exp(s*t)*(1cosh(a*t))/t,t); [A&S 29.3.109]. and specint(exp(s*t)*sin(t)/t); [A&S 29.3.109] Entered by Edmond.Orignac <at> wanadoo <dot> fr  Comment By: Nobody/Anonymous (nobody) Date: 20060428 12:56 Message: Logged In: NO Maxima version: 5.9.3 Maxima build date: 22:48 4/16/2006 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: CVS release19a 19arelease20040728 + minimal debian patches Version information missing from my bug report of yesterday.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1477965&group_id=4933 
From: SourceForge.net <noreply@so...>  20060427 20:32:02

Bugs item #1477965, was opened at 20060427 13:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1477965&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: specint bug Initial Comment: specint(exp(s*t)*(1cos(a*t))/t,t); returns 0, whereas the expression to integrate is always positive. laplace((1cos(a*t))/t,t,s) returns the correct result, log((a^2+s^2)/s^2) [A&S 29.3.108]. A similar bug affects specint(exp(s*t)*(1cosh(a*t))/t,t); [A&S 29.3.109]. and specint(exp(s*t)*sin(t)/t); [A&S 29.3.109] Entered by Edmond.Orignac <at> wanadoo <dot> fr  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1477965&group_id=4933 
From: SourceForge.net <noreply@so...>  20060427 14:07:33

Bugs item #1477696, was opened at 20060427 10:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1477696&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: 2*3*2^k is 6*2^k Initial Comment: Current CVS (2006/04/27) has 2*3*2^k becoming 6*2^k. Should this be 3*2^(k+1)? It would be nice, but.... What about a*b^k where a is a large number? Do we want to check if a contains any powers of b so we can return a new result of the form (a/b^k)*b^(k+1)?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1477696&group_id=4933 
From: SourceForge.net <noreply@so...>  20060427 14:04:06

Bugs item #1385307, was opened at 20051219 11:41 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1385307&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 2*2^k doesn't simplify Initial Comment: a*a^k => a^(k+1) OK but 2*2^k => 2*2^k ??? Is this intentional behavior (under control of one of our wonderfully obscure switches)? Or a bug? Maxima 5.9.2 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)  >Comment By: Raymond Toy (rtoy) Date: 20060427 10:04 Message: Logged In: YES user_id=28849 As far as I can tell, there is no switch, obscure or otherwise, to control this. It's an oversight in the code. See simp.lisp version 1.20, which fixes this case, and also handles some others like 3/4*2^k. There are still other issues like 2*3*2^k is 6*2^k instead of 3*2^(k+1). I'm closing this bug as fixed, and adding a new bug.  Comment By: Nobody/Anonymous (nobody) Date: 20060130 17:36 Message: Logged In: NO May be subst(2,a,a*a^k);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1385307&group_id=4933 
From: SourceForge.net <noreply@so...>  20060427 13:48:33

Bugs item #624061, was opened at 20021016 08:18 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=624061&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: strange bug (probably) in numer Initial Comment: Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 (C2) display2D:false$ (C3) f(x):=x^310*x^2+28.5*x21$ (C4) rhs(solve(f(x),x)[1]),rectform,numer; RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 0.5 by 1//2 = 0.5 RAT replaced 4.18055555555556 by 301//72 = 4.18055555555556 (D4) 3.897114317029973*%I+0.75 ******** which is wrong ******* (C5) y:rhs(solve(f(x),x)[1]),rectform$ RAT replaced 28.5 by 57//2 = 28.5 (C6) y,numer; (D6) 3.318006917974609 ******* which is correct ****** M.At.Stanev reports with Maxima 5.5 (C1) f(x):=x^310*x^2+28.5*x21; (D1) ... (C2) rhs(solve(f(x),x)[1]),rectform,numer; (D2) 12.01301985645547*%I+10.38424295325536 Martin  >Comment By: Raymond Toy (rtoy) Date: 20060427 09:48 Message: Logged In: YES user_id=28849 Closing this. I think the results are what you might expect from numerical roundoff.  Comment By: Stavros Macrakis (macrakis) Date: 20021118 11:18 Message: Logged In: YES user_id=588346 First thing to note: in "foo,numer,rectform", the "numer" and the "rectform" actually have very different meanings. Numer sets the numer flag *during* the evaluation of foo, whereas rectform simply calls rectform on the result of the evaluation of foo. That is, "foo,numer,rectform" is equivalent to rectform (ev(foo,numer)). Thus, solve(...),numer,rectform calculates the roots with numerical, not symbolic, intermediate results, then takes the rectform of that. On the other hand, y:solve(...),rectform$ y,numer; calculates the solutions numerically, then takes the symbolic rectform, then evaluates numerically. So it is not surprising that the two results will be slightly different.  Comment By: Martin Rubey (kratt5) Date: 20021118 10:34 Message: Logged In: YES user_id=651552 I replaced f* by * in mul2* in 5.9.0rc3, but got still different behaviour using the two approaches  the difference is rather small now, so it might be ok, but I do not understand why there is a difference... (C1) f(x):=x^310*x^2+28.5*x21$ (C2) rhs(solve(f(x),x)[1]),rectform,numer; RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 0.5 by 1//2 = 0.5 RAT replaced 4.18055555555556 by 301//72 = 4.18055555555556 (D2) 2.220446049250313E16 %I + 3.318006917974608  whereas  (C3) y:rhs(solve(f(x),x)[1]),rectform$ RAT replaced 28.5 by 57//2 = 28.5 (C4) y,numer; (D4) 3.318006917974609  Comment By: Stavros Macrakis (macrakis) Date: 20021021 19:32 Message: Logged In: YES user_id=588346 The problem is in the function MUL2*, which uses f* to multiply nonfixnums: (MUL2* 1 150.5) returns 269521184. The correction is to replace "f*" by "*" in MUL2* (in opers.lisp).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=624061&group_id=4933 
From: SourceForge.net <noreply@so...>  20060426 15:17:59

Bugs item #864085, was opened at 20031221 13:02 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=864085&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: x=> should give syntax error Initial Comment: x=> parses as ((MEQUAL SIMP) $x $>) There are in fact TWO problems here (though probably from the same source). First of all, the expression is syntactically illegal, just like x=+, x=<, etc. Secondly, the parser is generating $>, which should never be generated. The three forms of > are &> (string ">"), mgreaterp (verb), and %greaterp (noun).  >Comment By: Robert Dodier (robert_dodier) Date: 20060426 09:17 Message: Logged In: YES user_id=501686 Fixed by r1.25 src/nparse.lisp (cut DEFNUD for $>). Change is present in 5.9.2 and later.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=864085&group_id=4933 
From: SourceForge.net <noreply@so...>  20060426 15:00:13

Bugs item #1471657, was opened at 20060417 04:32 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471657&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: a new bug in mactex.lisp Initial Comment: This bug was discovered by Kostas Oikonomou, who uses the TeXmacs interface. But it is really a bug in texmexpt. Just do this: :lisp (tex '((mexpt) $a ((mminus) ((mplus) $b $c))) nil nil 'mparen 'mparen) and you get (A ^ { B + C }) The sum B+C is not in parenthes, though it should be. To fix this bug, a simple change in mactex.lisp is sufficient. In the function texmexpt, replace the line (tex (cadr x) '("^ { ")(cons " }" r) 'mparen 'mparen)) by the line (tex (cadr x) '("^ { ")(cons " }" r) 'mminus 'mparen))  >Comment By: Robert Dodier (robert_dodier) Date: 20060426 08:59 Message: Logged In: YES user_id=501686 Suggested patch applied and committed as r1.40 src/mactex.lisp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471657&group_id=4933 
From: SourceForge.net <noreply@so...>  20060424 08:20:38

Bugs item #1475354, was opened at 20060424 01:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1475354&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: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: factorisation univariate polynomial in extension Initial Comment: Un bug dans 5.9.2 (sur portable VAIO) qui n'existe pas dans 5.6. (sur portable DELL) (voir plus bas) : (%i1) f:x^8  4*x^7  x^6 + 15*x^5  3*x^4  16*x^3 + 4*x^2 + 4*x  1$ (%i2) factor(f,ev(f,x=x1)); 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. ======================= NO Problem si f:x^2+1$ et dans (sur un DELL): (avec display2d: false; pour interfacer avec latex) ======================================== GCL (GNU Common Lisp) Version(2.4.1) Thu Apr 4 10:08:23 CST 2002 Licensed under GNU Library General Public License Contains Enhancements by W. Schelter Maxima 5.6 Thu Apr 4 10:08:07 CST 2002 (with enhancements by W. Schelter). (C7) factor(f,ev(f,x=x1)); (D7) (xx1)*(x1^73*x1^65*x1^5+15*x1^4+8*x1^318*x1^23*x1+x+3) *(x^5*x1^7+3*x^4*x1^7+2*x^3*x1^75*x^2*x1^7x*x1^7+x1^7+3*x^5*x1^6 10*x^4*x1^65*x^3*x1^6+17*x^2*x1^6+2*x*x1^63*x1^6 +5*x^5*x1^511*x^4*x1^513*x^3*x1^5+17*x^2*x1^5+8*x*x1^5 5*x1^515*x^5*x1^4+45*x^4*x1^4+26*x^3*x1^475*x^2*x1^4 11*x*x1^4+15*x1^48*x^5*x1^3+13*x^4*x1^3+28*x^3*x1^3 18*x^2*x1^320*x*x1^3+8*x1^3+18*x^5*x1^251*x^4*x1^2 31*x^3*x1^2+84*x^2*x1^2+13*x*x1^218*x1^2+4*x^5*x1 6*x^4*x117*x^3*x1+8*x^2*x1+13*x*x14*x1+x^67*x^5 +9*x^4+14*x^317*x^26*x+5) Annick Valibouze, UniversitÃ© Pierre et Marie Curie  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1475354&group_id=4933 
From: SourceForge.net <noreply@so...>  20060418 23:48:30

Bugs item #852413, was opened at 20031202 07:33 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=852413&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: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor(2^31i) extremely slow/FIX Initial Comment: Number to factor Time 2^311 44 secs 2^3119 20 secs 2^3161 3.6 secs 2^31325 3.3 secs These are absurd numbers, considering how much time it takes for other primes near 2^31: 2^312275 0.1 secs (dominated by overhead) 2^3121757 0.2 secs Surprisingly, numbers > 2^31 (bignums) are also fast: 2^31+11 0.1 secs It turns out that there is a bug in fixnumcfactor, which can be seen by running it interpreted: load("rat3d.lisp")$ factor(2^3161); Error: 2147673649 is not of type FIXNUM. The problem is that (f* divisor divisor) can be greater than maxfixnum. The solution is simple  calculate the maximum divisor using isqrt whenever the factorand is changed. This also has the benefit of making the calculation a little faster for all integers. (defmfun fixnumcfactor (x) (declare (fixnum x)) (prog ((divisor 2) ; current trial divisor (tt 0) ; exponent of divisor (k 2) ; increment of divisor (ans nil) ; result list (maxdivisor 0) ; max divisor to try (intfaclim (if (and $intfaclim (typep $intfaclim 'fixnum)) $intfaclim mostpositivefixnum))) (declare (fixnum divisor tt k maxdivisor intfaclim)) (setq maxdivisor (min (isqrt x) intfaclim)) sett (setq tt 0) loop (cond ((f= 0 (fixnumremainder x divisor)) (setq tt (f+ 1 tt)) (setq x (the fixnum (quot x divisor))) (go loop))) (cond ((> tt 0) (setq ans (cons divisor (cons tt ans)) maxdivisor (min (the fixnum (isqrt x)) intfaclim)))) (cond ((f= divisor 2) (setq divisor 3)) ((f= divisor 3) (setq divisor 5)) (t (setq divisor (f+ divisor k)) (cond ((f= k 2) (setq k 4)) (t (setq k 2))))) (cond ((f> divisor maxdivisor) (return (cond ((f> x 1) (list* x 1 ans)) (t ans))))) (go sett))) With the new code, all numbers < 2^31 factor fast. In fact, we can factor all 2^311000 < i < 2^311 in 4.2 seconds. Maxima 5.9.0 gcl 2.5.0 W2k  >Comment By: Andrej Vodopivec (andrejv) Date: 20060419 01:48 Message: Logged In: YES user_id=1179910 This code is not present in current CVS sources. andrej  Comment By: Stavros Macrakis (macrakis) Date: 20031207 00:37 Message: Logged In: YES user_id=588346 Ray, perhaps cmucl doesn't obey the fixnum declare in fixnum cfactor, and is doing everything in general arithmetic?  Comment By: Raymond Toy (rtoy) Date: 20031206 22:36 Message: Logged In: YES user_id=28849 Hmm, I don't see this slowdown with CMUCL with CVS maxima. All of the examples take 0.05 sec or less on a fairly slow 450 MHz sparc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=852413&group_id=4933 
From: SourceForge.net <noreply@so...>  20060417 17:49:02

Bugs item #1471861, was opened at 20060417 19:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471861&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: FrancoB (franco68tn) Assigned to: Nobody/Anonymous (nobody) Summary: limit(abs(sin(x)/x),x,0); Initial Comment: Maxima cannot calculate the following limit: limit(abs(sin(x)/x),x,0); > unevaluated but it can calculate the following limits: limit(abs(sin(x)/x),x,0,minus); > 1 limit(abs(sin(x)/x),x,0,plus); > 1 Is this a bug? Franco Buratti (Italy) bufranz@... Maxima version: 5.9.2 Maxima build date: 9:5 10/12/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471861&group_id=4933 
From: SourceForge.net <noreply@so...>  20060417 16:14:19

Bugs item #1471813, was opened at 20060417 12:07 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471813&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(x^2 + 4)^(3/2),x,0,inf); Initial Comment: (%i1) integrate(1/(x^2 + 4)^(3/2),x,0,inf); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Error in doargcounterror: DESTRUCTURINGBIND NIL NIL (L ... Let's try the integral from minf to inf: (%i2) integrate(1/(x^2 + 4)^(3/2),x,minf,inf); Is x positive or negative? pos; (%o2) 1/2 The question is silly, but 1/2 is the correct value for the integral. (%i3) build_info(); Maxima version: 5.9.2.19cvs Maxima build date: 9:42 4/10/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (%o3) Barton  >Comment By: Raymond Toy (rtoy) Date: 20060417 12:14 Message: Logged In: YES user_id=28849 Try with the CVS version. It returns 1/4 for the first integral, but still asks about x for the second integral.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471813&group_id=4933 
From: SourceForge.net <noreply@so...>  20060417 16:07:22

Bugs item #1471813, was opened at 20060417 11:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471813&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(1/(x^2 + 4)^(3/2),x,0,inf); Initial Comment: (%i1) integrate(1/(x^2 + 4)^(3/2),x,0,inf); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Error in doargcounterror: DESTRUCTURINGBIND NIL NIL (L ... Let's try the integral from minf to inf: (%i2) integrate(1/(x^2 + 4)^(3/2),x,minf,inf); Is x positive or negative? pos; (%o2) 1/2 The question is silly, but 1/2 is the correct value for the integral. (%i3) build_info(); Maxima version: 5.9.2.19cvs Maxima build date: 9:42 4/10/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 (%o3) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471813&group_id=4933 
From: SourceForge.net <noreply@so...>  20060417 15:31:45

Bugs item #1471048, was opened at 20060415 18:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471048&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: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d doesn't work with "gnuplot_curve_titles" option Initial Comment: Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 When I try to execute a command like this: plot2d( [discrete, xx, yy], [gnuplot_curve_titles, "my_func"] ); maxima siply does nothing, it doesn't produce any output or any graphic, nothing. At it's the same with all plot2d forms when I use gnuplot_curve_titles option.  >Comment By: Raymond Toy (rtoy) Date: 20060417 11:31 Message: Logged In: YES user_id=28849 The syntax is wrong. describe(plot_options) will give the correct syntax, which is [gnuplot_curve_titles, "title 'my title'"] Changed status to Pending.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471048&group_id=4933 
From: SourceForge.net <noreply@so...>  20060417 10:32:38

Bugs item #1471657, was opened at 20060417 03:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471657&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: a new bug in mactex.lisp Initial Comment: This bug was discovered by Kostas Oikonomou, who uses the TeXmacs interface. But it is really a bug in texmexpt. Just do this: :lisp (tex '((mexpt) $a ((mminus) ((mplus) $b $c))) nil nil 'mparen 'mparen) and you get (A ^ { B + C }) The sum B+C is not in parenthes, though it should be. To fix this bug, a simple change in mactex.lisp is sufficient. In the function texmexpt, replace the line (tex (cadr x) '("^ { ")(cons " }" r) 'mparen 'mparen)) by the line (tex (cadr x) '("^ { ")(cons " }" r) 'mminus 'mparen))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471657&group_id=4933 
From: SourceForge.net <noreply@so...>  20060415 22:02:54

Bugs item #1471048, was opened at 20060415 15:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471048&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d doesn't work with "gnuplot_curve_titles" option Initial Comment: Maxima version: 5.9.3 Maxima build date: 0:52 3/20/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 When I try to execute a command like this: plot2d( [discrete, xx, yy], [gnuplot_curve_titles, "my_func"] ); maxima siply does nothing, it doesn't produce any output or any graphic, nothing. At it's the same with all plot2d forms when I use gnuplot_curve_titles option.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1471048&group_id=4933 
From: SourceForge.net <noreply@so...>  20060415 18:52:50

Bugs item #1470598, was opened at 20060414 18:00 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1470598&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults with exponentiation on amd64 Initial Comment: Maxima version: 5.9.1 Maxima build date: 3:30 2/26/2005 host type: x86_64unknownlinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6 (%i1) is((255/256)^(2^22) < (1/(256!))); Segmentation fault (%i1) (2*x)^(2^24); Segmentation fault It doesn't seem a stack overflow.. maybe it is a problem related to exponentiation? or maybe the amd64 arch?  >Comment By: Raymond Toy (rtoy) Date: 20060415 14:52 Message: Logged In: YES user_id=28849 The first example works fine with cmucl on Mac OS X. It does the user if he really wants to compute the large exponentiation, and if you say yes, it finally returns true, as expected. I think this is a gcl issue.  Comment By: Raymond Toy (rtoy) Date: 20060414 18:30 Message: Logged In: YES user_id=28849 Considering that 2^(2^24) has about 5 million digits, perhaps the seg fault comes from trying to convert 2^(2^24) from the internal binary representation to a decimal representation? Or perhaps gcl can't handle a bignum with some 16 million bits?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1470598&group_id=4933 
From: SourceForge.net <noreply@so...>  20060414 22:30:13

Bugs item #1470598, was opened at 20060414 18:00 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1470598&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults with exponentiation on amd64 Initial Comment: Maxima version: 5.9.1 Maxima build date: 3:30 2/26/2005 host type: x86_64unknownlinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6 (%i1) is((255/256)^(2^22) < (1/(256!))); Segmentation fault (%i1) (2*x)^(2^24); Segmentation fault It doesn't seem a stack overflow.. maybe it is a problem related to exponentiation? or maybe the amd64 arch?  >Comment By: Raymond Toy (rtoy) Date: 20060414 18:30 Message: Logged In: YES user_id=28849 Considering that 2^(2^24) has about 5 million digits, perhaps the seg fault comes from trying to convert 2^(2^24) from the internal binary representation to a decimal representation? Or perhaps gcl can't handle a bignum with some 16 million bits?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1470598&group_id=4933 
From: SourceForge.net <noreply@so...>  20060414 22:00:52

Bugs item #1470598, was opened at 20060414 15:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1470598&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults with exponentiation on amd64 Initial Comment: Maxima version: 5.9.1 Maxima build date: 3:30 2/26/2005 host type: x86_64unknownlinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.6 (%i1) is((255/256)^(2^22) < (1/(256!))); Segmentation fault (%i1) (2*x)^(2^24); Segmentation fault It doesn't seem a stack overflow.. maybe it is a problem related to exponentiation? or maybe the amd64 arch?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1470598&group_id=4933 
From: SourceForge.net <noreply@so...>  20060413 22:14:00

Bugs item #1385311, was opened at 20051219 17:46 Message generated for change (Settings changed) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1385311&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: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: GosperSum(1+n^a) should use Ask Initial Comment: GosperSum(1+n^a,n,1,k); Maxima was unable to evaluate the predicate: max(a, 0) < 2 #0: integerLinear(expr=n^a+1,var=n) #1: intLinSep(expr=n^a+1,k=n)(norm.mac line 79) #2: makeGosperFormVerboseOpt(expr=((n+1)^a+1)/(n^a+1),k=n,mode=1)(makeGosperForm.mac line 148) GosperSum should be using Ask Maxima 5.9.2 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) load("zeilberger/loadzeilberger.mac");  >Comment By: Andrej Vodopivec (andrejv) Date: 20060414 00:13 Message: Logged In: YES user_id=1179910 Fixed in CVS. GosperSum returns nonGosper_summable. This is correct since the example is summable only if a is a fixed integer. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1385311&group_id=4933 
From: SourceForge.net <noreply@so...>  20060413 22:08:53

Bugs item #1385309, was opened at 20051219 17:44 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1385309&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: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: GosperSum division by 0 Initial Comment: GosperSum(1+2^n,n,1,k); => Division by 0 #0: intLinPolyNorm(expr=2*2^n+1,k=n)(norm.mac line 26) #1: intLinNorm(expr=2*2^n+1,k=n)(norm.mac line 45) #2: intLinNormList(exprlist=[2*2^n+1],k=n)(norm.mac line 135) Maxima 5.9.2 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) load("zeilberger/loadzeilberger.mac");  >Comment By: Andrej Vodopivec (andrejv) Date: 20060414 00:08 Message: Logged In: YES user_id=1179910 Fixed in CVS. GosperSum returns nonGosper_summable for both examples, which is correct. Andrej  Comment By: Stavros Macrakis (macrakis) Date: 20051219 17:48 Message: Logged In: YES user_id=588346 Similar error (but different line number in intLinNorm): GosperSum(n^a,n,1,k) => Division by 0 #0: intLinPolyNorm(expr=(n+1)/n,k=n)(norm.mac line 26) #1: intLinNorm(expr=((n+1)/n)^a,k=n)(norm.mac line 39) #2: intLinNormList(exprlist=[((n+1)/n)^a],k=n)(norm.mac line 135)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1385309&group_id=4933 