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

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

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

9
(1) 
10
(1) 
11
(2) 
12

13
(1) 
14
(2) 
15
(17) 
16
(5) 
17
(2) 
18
(4) 
19

20
(1) 
21

22
(22) 
23
(5) 
24

25

26
(1) 
27

28
(4) 
29
(1) 
30






From: SourceForge.net <noreply@so...>  20080622 06:38:10

Bugs item #1913588, was opened at 20080313 09:06 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913588&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: algsys hangs Initial Comment: algsys hangs on the following input: eq1 : a*x + c*y + d*y^2/2 = 0; eq2 : b*x + e*x^2 + f*y  g*y^3 = h; algsys([eq1,eq2],[x,y]); System information: Maxima version: 5.12.0 Maxima build date: 15:52 7/20/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  Comment By: Barton Willis (willisbl) Date: 20080314 04:09 Message: Logged In: YES user_id=895922 Originator: NO A workaround is to eliminate x and solve the quartic for y; something like (%i14) eliminate([eq1,eq2],[x]); (%o14) [d^2*e*y^4+(4*c*d*e4*a^2*g)*y^3+(4*c^2*e2*a*b*d)*y^2+(4*a^2*f4*a*b*c)*y4*a^2*h] (%i15) solve(%,y) Of course, Maxima should not need any help.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1913588&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 06:23:41

Bugs item #1892341, was opened at 20080212 18:00 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1892341&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) >Summary: taylor message about something assumed to be 0 in integral Initial Comment: Dear Developers of Maxima, I found that a simple integration about trigonometric functions yields some strange message as follows:  [wisdom3:~/work/280:1] adachi% cat message_assumed_to_be_zero_in_taylor_from_simple_integrations.maxima integrate((1+cos(t))^5,t,0,2*%pi); [wisdom3:~/work/280:2] adachi% maxima b message_assumed_to_be_zero_in_taylor_from_simple_integrations.maxima 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(message_assumed_to_be_zero_in_taylor_from_simple_integrations.maxima) batching #p/Volumes/HFS+2/home/adachi/work/280/message_assumed_to_be_zero_in_taylor_from_simple_integrations.maxima 5 (%i2) integrate((cos(t) + 1) , t, 0, 2 %pi) 9 yy Assumed to be zero in `taylor' 9 yy Assumed to be zero in `taylor' 63 %pi (%o2)  4  The result of calculation is correct. But the strange message "yy^9 Assumed to be zero in `taylor'" is printed twice. This message is at least useless for end users. Please fix the routine for the above integration. Thank you very much for developing Maxima. Sincerely yours Satoshi Adachi  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 16:15 Message: Logged In: YES user_id=501686 Originator: NO Not sure what we can do about this. We can suppress the message, I guess, but it probably represents a proviso or restriction on an intermediate result, which, ideally, would be carried through to the final result. I guess taylor and integrate share responsibility here; taylor doesn't construct a proviso object of any kind, and integrate probably isn't equipped to handle such a thing anyway.  Comment By: Raymond Toy (rtoy) Date: 20080213 07:18 Message: Logged In: YES user_id=28849 Originator: NO FWIW, maxima eventually calls intsc1 to evaluate this integral. This in turn eventually calls zto%pi2, which uses residues inside the unit circle to compute this integral. Scrat convert the exponentializes the integrand and also changes the variable of integration to yy. I guess the computation of the residues (via RES) uses Taylor series. Note that if the exponent is changed from 5 to 4, the warning isn't given. I do not know why taylor produces the warning.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1892341&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 06:16:53

Bugs item #1907921, was opened at 20080305 05:22 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1907921&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: Yes Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: User manual function help Initial Comment: The help for the inverse Laplace transform function ilt has an error. It currently reads Function: ilt (expr, t, s) It should read Function: ilt (expr, s, t) Submitted by Pieter van der Walt pwvdwalt@... or pwvdwalt@...  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 16:27 Message: Logged In: YES user_id=501686 Originator: NO Duplicate of [ 1947806 ] ilt documented variable order incorrect. Closing this report as such.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1907921&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 06:09:30

Bugs item #1950294, was opened at 20080423 21:41 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1950294&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: more on integrate(1/cosh(a*x)^2,x,inf,inf) Initial Comment: integrate(1/cosh(3*x)^2,x,inf,inf); returns Division by 0  an error. To debug this try debugmode(true); integrate(1/cosh(4*x)^2,x,inf,inf); returns << Expression too long to display! >> Eric  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 19:41 Message: Logged In: YES user_id=501686 Originator: NO Observed in 5.15.0cvs. integrate(1/cosh(a*x)^2,x,inf,inf); => asksign about a; response=p => 0, obviously incorrect When asksign response is n, then p (2nd question about exp(a)  1), integrate prints "Principal value" and the result is 2/a, which might be correct (to guess from quad_qags results). But various other combinations of asksign responses give 0. integrate(1/cosh(3*x)^2,x,inf,inf); => division by 0 as reported above integrate(1/cosh(4*x)^2,x,inf,inf); => very long expression w/ trig and hyperbolic functions %, numer; =>  1.599481181895906E+15 obviously incorrect  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1950294&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 05:51:48

Bugs item #872433, was opened at 20040107 15:00 Message generated for change (Comment added) made by guno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=872433&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: rncombine broken Initial Comment: The function rncombine is broken. (C1) load("rncomb")$ Lines d2 and d3 are okay, but d4 is bogus (C2) rncombine(x+y/x); (D2) y/x+x (C3) rncombine(x+y/x); (D3) y/x+x (C4) rncombine(y+x/y); (D4) y+x (C5) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Notes: 1. The function rncombine is supposed to work like combine, except that it combines terms that have denominators that differ by a numerical factor. 2. When rncombine is fixed, either the function should autoload, or the user documentation should explain that one must first load rncomb.mac. Barton  Comment By: guno (guno) Date: 20080620 17:14 Message: Logged In: YES user_id=1709853 Originator: NO hi maxima/share/simplification/rncomb.mac contains the function rncombine1 from lineno 35 to lineno 50 this function contains the bug the factor multiplied in line 44 to flist is cancelled out again in line 48 if the "if" branch is taken but it is not cacelled out if the if branch is not taken. this is the bug. one can repair this by deleting line 44 and by changing line 48 to then flist:denomthru(cons(flist*flist_denom,lsplitdum*flist_denom))/flist_denom, now the function will work correct. can anybody do this? 35 rncombine1(list):=block( 36 [flist,splitdum,lsplitdum,flist_denom], 37 if list=[] then return(0), 38 flist:first(list), 39 if length(list)=1 40 then return(if inpart(num(flist),0)="+" 41 then rncombine1(args(num(flist)))/denom(flist) 42 else flist), 43 flist_denom:(flist_denom:denom(flist))/numfactor(flist_denom), 44 flist:flist*flist_denom, 45 splitdum:predpartition(rest(list), 46 lambda([dum],numberp(denom(dum)/flist_denom))), 47 if (lsplitdum:last(splitdum))#[] 48 then flist:denomthru(cons(flist,lsplitdum*flist_denom))/flist_denom, 49 flist+rncombine1(first(splitdum)))$ 50 guenter  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=872433&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 05:47:20

Bugs item #1923119, was opened at 20080322 11:09 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1923119&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: 1/sqrt(8)  sqrt(8) / 8 /> 0 Initial Comment: (%i17) 1/sqrt(8)  sqrt(8) / 8; (%o17) 1/(2*sqrt(2))1/2^(3/2) (%i18) expand(%,0,0); (%o18) 0 Here I think (%o17) is unsimplifiedthe expand(%,0,0) shouldn't be required.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1923119&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 05:45:18

Bugs item #1941444, was opened at 20080413 11:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1941444&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Crategus (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent use of global $DEBUGMODE Initial Comment: I think there is a small inconsistency with the global variable $DEBUGMODE. ********** The documentation says: Option variable: debugmode Default value: false When a Maxima error occurs, Maxima will start the debugger if debugmode is true. ... ********** Intern in the code Maxima only uses the global *MDEBUG*. When you assign the value TRUE or FALSE to $DEBUGMODE the global *MDEBUG* will be set with the assignfunction DEBUGMODE1() and all is correct. But, there is also the undocumented function $DEBUGMODE(). In the case of an error the user gets the information " an error. To debug this try debugmode(true)". So the user knows about the function, too. If you call this function the global *MDEBUG* will be set correctly as in the case above. But now the global $DEBUGMODE is not set to the new value. A program which tests the global $DEBUGMODE might not be sure if Maxima is in debugmode or not. The value of $DEBUGMODE depends on the way we have entered the debugmode. A correction in suprv1.lisp might be: (defmfun $debugmode (x) (setq $debugmode x) ; New line: Set the global $debugmode, too. (debugmode1 nil x)) Here is the assignfunction from suprv1.lisp which sets the global *MDEBUG*: (defun debugmode1 (assignvar y) (declare (ignore assignvar)) (setq *mdebug* (setq *rset y))) Crategus  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 19:08 Message: Logged In: YES user_id=501686 Originator: NO Applied suggested change to $DEBUGMODE as r1.70 src/suprv1.lisp. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1941444&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 05:35:15

Bugs item #1898852, was opened at 20080221 08:46 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1898852&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: Open Resolution: None Priority: 5 Private: No Submitted By: David Ronis (ronis) Assigned to: Nobody/Anonymous (nobody) Summary: ev doesn't work as expected with subscripted variables Initial Comment: f(l,m):=A[l,m]+B[l,m]+A[l+1,m]; ev(f(l,m), A[l,m]=0); A[l,m] still appears in the result. However, f(l,m); ev(%, A[l,m]=0 ); works as expected.  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 16:20 Message: Logged In: YES user_id=501686 Originator: NO For the record, my comments on this problem 20080221: Well, the mechanism for saving and restoring local variables handles only simple variables (not subscripted variables). ev substitutes for subscripted variables instead. But substitution doesn't have quite the same effect, as you have observed. See $EV in src/mlisp.lisp. This is a bug; I guess it could be fixed by making MBIND and friends happy with subscripted variables. Dunno if that would cause trouble elsewhere.  Comment By: Stavros Macrakis (macrakis) Date: 20080413 21:08 Message: Logged In: YES user_id=588346 Originator: NO Thanks for the bug report. EV is a very funny function, and often produces peculiar surprises like this. I hope we'll be able to fix this at some point, but in the meantime, I'd suggest you use subst to evaluate things like this: subst([a[l,m]=0],f(l,m)) instead of ev.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1898852&group_id=4933 
From: SourceForge.net <noreply@so...>  20080620 00:59:38

Bugs item #1965640, was opened at 20080516 16:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1965640&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Crategus (crategus) >Assigned to: Raymond Toy (rtoy) Summary: Problems with $specint Initial Comment: I would like to open a bug report to collect the results of investigations of the function $specint. To get an overview of the problems with $specint I have taken the 99 tabulated Laplace transforms from the website of EqWorld. 55 of the 99 examples fail with the original code. I have divided the problems in the following cases: 1. Maxima has no algorithm: In most cases Maxima gives an internal symbol like otherdefinttofollownegtest or arbpowfailed. This is a known problem. In some cases we get a correct noun form of the unevaluated integral. At last there are many problems which gives a wrong answer. A lot of examples include terms like t^(1) ... or t^(1/2) ... Maxima can't calculat these integrals but we know solutions. A simple type of integral Maxima can't evaluate is the division by the sum of constants: (%i7) specint(%e^(s*t)/(x+y),t); (%o7) otherdefinttofollownegtest In this cases the exponential function is hidden in a summation. I have found a correction which works generally and gives the correct result: (%i7) specint(%e^(s*t)/(x+y),t); (%o7) (1/(x+y)*s) 2. Maxima has an algorithm for a special function but don't give the correct result: We get no results for functions like bessel_k, bessel_y, log, erf, erfc etc. For all these functions Laplace transforms are tabulated. Beside the test of EqWorld I tried to get results for the internal functions %l[n,a](x)  the Laguerre function  or %he[n](x)  the Hermite function. But I dont' get the expected result. Here the example for the Laguerre function: (%i6) kill(all); (%o0) done (%i1) assume(s>0,n>0),declare(n,integer); (%o1) [s > 0,n > 0] (%i2) specint(%e^(2*t)*%l[n,0](t),t); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: $N is not of type NUMBER. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. After correction of the code (the correction is not included in the diff appended to the next post): (%i6) kill(all); (%o0) done (%i1) assume(s>0,n>0),declare(n,integer); (%o1) [s > 0,n > 0] (%i2) specint(%e^(s*t)*%l[n,0](t),t); (%o2) (11/s)^n/s In the case of the Laguerre function I have found a bug in the transformation. After correction, Maxima gives the expected result shown above for the Laguerre function. There may be further bugs. Or limitations of the algorithmen prevend the calculation of results. At least, these limitations should be documented for the user. 3. Maxima gets extra factors or terms in the result A simple example is the bessel_i function. Here we get an additional phase factor: %e^(%i*%pi*v/(1)^(v2/2) in all calculations. This factor vanish when we introduce a small correction to the code. In other cases the problem seems to be more difficult. Dieter Kaiser  >Comment By: Raymond Toy (rtoy) Date: 20080619 20:59 Message: Logged In: YES user_id=28849 Originator: NO I have now applied the hypgeo patch. However, as you mention, there are failures in rtest14 now. Can you correct that? Also, do you want test_eqworld, test_A&S, and ltexp tests to be part of the testsuite?  Comment By: Crategus (crategus) Date: 20080614 19:51 Message: Logged In: YES user_id=2039760 Originator: YES I try to extend $SPECINT to allow Maxima to give more results. I implemented the following five cases for a sum of Exponentials functions: 7'. Extension of the algorithm c * t^1 * (%e^(a*t)%e^(b*t)) c * t^(3/2) * (%e^(a*t)  %e^(b*t)) c * t^2 * (1  2 * %e^(a*t) + %e^(2*a*t)) c * t^1 * (1  2 * %e^(a*t) + %e^(2*a*t)) c * t^1 * (1  %e^(2*a*t)) The first code I used to implement the first of the above cases wasn't general enough and buggy (I think it worked accidentally). I had to redesign it a bit. All tabulated integrals by EqWorld and A&S with Trigonometric and Hyperbolic functions and a factor of t^1 and t^2 expand in a sum of the above cases. The sum with a factor t^(3/2) I have added because A&S has a tabulated result. Examples with a factor t^1 are: (%i7) specint(%e^(s*t)*sin(a*t)/t,t); (%o7) %i*log((s%i*a)/(s+%i*a))/2 (%i8) specint(%e^(s*t)*sinh(a*t)/t,t); (%o8) log((sa)/(s+a))/2 (%i9) specint(%e^(s*t)*(1cos(a*t))/t,t); (%o9) log(a^2/s^2+1)/2 (%i10) specint(%e^(s*t)*(1cosh(a*t))/t,t); (%o10) log(1a^2/s^2)/2 (%i11) specint(%e^(s*t)*sin(a*t)^2/t,t); (%o11) log(4*a^2/s^2+1)/4 This is an example with a factor t^2: (%i12) specint(%e^(s*t)*sin(a*t)^2/t^2,t); (%o12) ((s+2*%i*a)*log(s+2*%i*a)+(s2*%i*a)*log(s2*%i*a)2*s*log(s))/4 These examples include the integrals from the bug report [1477965] which now have correct results. I have attached a diff. Furthermore I had to update the test files from EqWorld and A&S because we get more results instead of noun forms. The testsuite has no problems with the extension of the code. Dieter Kaiser File Added: diff_hypgeo.txt  Comment By: Crategus (crategus) Date: 20080606 14:38 Message: Logged In: YES user_id=2039760 Originator: YES Because of some changes in the code to return noun forms, I had to update the tests of EqWorld too. File Added: test_eqworld.mac  Comment By: Crategus (crategus) Date: 20080606 14:35 Message: Logged In: YES user_id=2039760 Originator: YES In addition I have attached the examples by A&S. File Added: test_A&S.mac  Comment By: Crategus (crategus) Date: 20080606 14:31 Message: Logged In: YES user_id=2039760 Originator: YES I have finished a first look through about 130 examples of Laplace transforms which are tabulated by A&S. A lot of the integrals are allready tested. But sometimes even know integrals gives new problems, because A&S scale the integrals different from EqWorld. A lot of the integrals give a noun form. But as described earlier we get additional results too. Two problems remain open. Maxima gives a result for the functions sin(2*sqrt(k*t))/sqrt(%pi*t) and sinh(2*sqrt(k*t))/sqrt(%pi*t). But the results seems to be wrong. Maxima gets an additional factor erf(sqrt(k). To get the results I had to add further modifications to the code of $SPECINT: 10.' Return noun form in $SPECINT To get more noun forms I have added a flag which will be tested in $SPECINT. A&S gives some examples which show that this method isn't general enough. Because we add up the symbols in the routine DISTRDEFEXEC we sometimes get 0 as a result. That is wrong. A more general and fast to implement solution is to set a global variable if we have to return a noun form. The disadvantage of this simple method is that Maxima sometimes get a solution for a part of a sum. This solution we loose with this method. Perhaps this problem has to be discussed more deeply. For a general solution we have to program a more complex algorithm. 12. Bug in LTW A&S gives examples with the Laguerre and Hermite functions. In both cases the algorithm of $SPECINT don't work. For the Laguerre function it is possible to correct the code. In the routine LTW the Laguerre functions is transformed to a Whittaker W function. Correct is a Whittaker M function. In addition the correct Gamma factors have to be used. The Factorial function don't work generally. Up to now I haven't found the reason for the problems with the Hermite function. I have attached an updated diff. The testsuite has no problems with the changes. Dieter Kaiser File Added: diff_hypgeo.txt  Comment By: Crategus (crategus) Date: 20080531 14:53 Message: Logged In: YES user_id=2039760 Originator: YES I have done further work on $specint. The test file test_eqworld.mac with 99 examples now gives 98 results or a correct noun form. A few examples have to be verified mathematically. Some examples gives factors which doesn't agree with the tabulated results. I am searching for the reasons. These small discrepancies can be very useful to detect some further problems with the used algorithm. There remains one problem with the tests from EqWorld. Maxima gets a result, but I can't verify it. This wrong result is difficult to understand. Perhaps we have an error in the routine hgfsimpexec. I have collected the examples of A&S in a test file. We get about 130 integrals. With the orginal code 65 example pass the test. 66 example give a wrong result or not the correct noun form. With the changes up to now 91 examples of A&S pass the test. There are 40 examples remaining which gives an error. For most of the examples we have no algorithm, but Maxima don't give a correct noun form. To get the results up to now, I have done the modifications described in this thread and added the following one: 1'. More general algorithm to handle a constant denominator Under point 1 I described a change to handle integrals of the typ "something/(a+b+ ...)", where the denominator is a constant. It is necessary to handle the case of a constant denominator more general. So I have added an algorithm to the function DEFINTEGRATE. 10. Return noun form in $SPECINT It is not possible to construct the noun form easy and in all places of the code. It is more simple to test a flag in the routine $SPECINT and then if necessary to return the noun form. If added at some places code to return the flag 'hypreturnnounform. This method could be used at any places of the code. 11. Routine A*X^M+C and EXECARGMATCH The pattern match for the argument of the hypergeometric function is too general. We match cases like a*x^2+b*x+c, but we have no algorithm for such an argument. In some cases Maxima gives a result which is wrong. After specialization of the pattern we get a Lisp error in the routine EXECARGMATCH. We have to return a list if the pattern match fails. The testsuite of Maxima has no problems with the changes. We only get three different noun forms (Problems 55, 150 and 157 in rtest14.mac). I have attached an updated diff. Dieter Kaiser File Added: diff_hypgeo.txt  Comment By: Crategus (crategus) Date: 20080526 18:58 Message: Logged In: YES user_id=2039760 Originator: YES $SPECINT can not evaluate Laplace transforms for expressions with Logarithmic functions. The reason is that $SPECINT try to integrate the Hypergeometric representation (z1)*2F1(1,1;2;1z) of the Logarithmic function. But this doesn't work, because 2F1(1,1;2;1z) doesn't satisfy the condition for the Laplace transform of a Hypergeometric function pFq. 9. I have extended $SPECINT with an additional routine LTLOG which calculates the Laplace transform for expressions like c*t^(v1)*log(a*t). Further extensions can be added to calculate integrals with log(1+a*x), log(a+x) and log(x)^2. The formula I have got uses the scaling law f(a*t) > 1/a*F(s/a) for Laplace transformations. There is a difference between the scaled results I get with my formula and the results of the Maxima function LAPLACE. Are the results of LAPLACE correct? Is something wrong with the scaled formula? I have added an updated diff. Dieter Kaiser File Added: diff_hypgeo.txt  Comment By: Crategus (crategus) Date: 20080524 17:16 Message: Logged In: YES user_id=2039760 Originator: YES I have attached the test file for the routine LTEXP. File Added: test_hypgeo_LTEXP.mac  Comment By: Crategus (crategus) Date: 20080524 17:10 Message: Logged In: YES user_id=2039760 Originator: YES I have collected examples to test only the routine LTEXP and the code for doing the Laplace transforms. I have found 30 examples tabulated by EqWorld and A&S testing this routine. With the original code 17 examples fail. The first changes showed in this thread reduce this to 6 examples. Correcting a bug in LTEXP all examples work. 8. Bug in LTEXP and in the following routines F29P149, F36P147 and F37P147 The reason for the 6 remaining errors is a bug in the calculation of the Laplace transform in the routines LTEXP, F29P146, F36P147 and F37P147. The constant term is missing. Additionally it is useful to check v=0 before calling F36P147 and F37P147. For v <>0 we have no Laplace transform. Without this check we can get wrong results. BUT: For 3 examples I have an additional factor in the result of Maxima which is not present in tabulated result of EqWorld. In one case the factor is %e^(s^2/(s*a)) and in two cases the factor is 4. Furthermore, there is one case Maxima get a different sign of a term. Because the algorithm works very well in all other cases, I think there are errors in the table of EqWorld. But, it is better to verify thesw cases independly. Second: I have changed code in the routine LTEXP and F35P147 to get the results for expression with sqrt(t) in the exponent (Point 6). The changed code works very well and gives a lot of additional results involving trigonometric and hyperbolic functions with sqrt(t) as argument. But, I haven't verified why this does work mathematically. I have attached a file with an update of the changes. Dieter Kaiser File Added: diff_hypgeo.txt  Comment By: Crategus (crategus) Date: 20080516 16:11 Message: Logged In: YES user_id=2039760 Originator: YES As a first step to improve the code of $specint I would like to present 7 changes: 1. Function DEFEXEC If we cant't find a parameter, we apply $factor to the expression. Now Maxima finds the result for expressions like t/(x+y) > 1/(s^2(x+y)) where x and y are free of the integration variable. 2. Function ARBPOW1 I have specialized the pattern match to be sure that in the expression c*t^v the parameter c is free of the integration variable. This condition now will fail if we enter $specint with expression like u(t) or t^(1/2)*(a+t)^(1) and with the changes below we get nice and correct noun forms. 3. Function LTSFLOG Because we have specialized the pattern match we add at the end of the function as return value a noun form. 4. Function LTARBPOW A lot of integrals fail at this point. We add as the return value a noun form. 5. Function LTSFLOG, Condition ONEI This is an example how we can avoid additional phase factors. If we use %i directly in the calculation all additional phase factors in the calculations vanish and the results are correct. There are more places we can apply this change to obtain easier results. 6. Bug in LTEXP and F35P147 I have found a bug in the routine ltexp and f35p147. This bug prevents the calculation of integrals with e.g. sin(2*sqrt(a*t)). $SPECINT gives the result 0. Here the output of Maxima after correction: (%i6) radcan(specint(%e^(s*t)*sin(2*sqrt(a*t)),t)); (%o6) sqrt(%pi)*sqrt(a)*%e^(a/s)/s^(3/2) That is perfectly the tabulated expression and $SPECINT now works for a lot of other integrals too. 7. Extension of the algorithm To show how we can extend the algorithm of $SPECINT to calculate further integrals, I have added code to calculate integrals of the form t^1*(%e^(a*t)%e^(b*t)). The code works also for integrals like t^1*sin(a*t). Here an example (%i4) specint(%e^(s*t)*t^1*sin(a*t),t); (%o4) %i*(log(s%i*a)log(s+%i*a))/2 That's equivalent to the tabulated answer atan(a/s). With this changes problems 55, 150 and 157 of rtest14.mac will produce different results. In all cases the noun form is improved and now more correct. The numbers of correct results of the test file test_eqworld.mac is increased to 87. When Maxima can't evaluate the integral but returns a correct noun form I declared the test as "(OK noun form)". There are 12 remaining examples which fails. This examples mostly include the log or erf function. I think there is something wrong with the mathematic. I have added a diff to show the above described changes to the code. Hint: The test file will stop 5 times and ask for the sign of the internal variable psey. That's a known bug. I have this bug not remarked as an error, because the results are correct. I try to find the reason of the bug. Dieter Kaiser File Added: diff_hypgeo.txt  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1965640&group_id=4933 
From: SourceForge.net <noreply@so...>  20080618 04:34:21

Bugs item #1881281, was opened at 20080128 10:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1881281&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: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lost socket connection Initial Comment: I get a "lost socket connection" each time I run this script. The only thing that is changing is the interval that I'm trying to plot my function over. /* wxMaxima 0.7.4 http://wxmaxima.sourceforge.net Maxima 5.14.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (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) if showtime#false then showtime:false else showtime:all$ Evaluation took 0.00 seconds (0.00 elapsed) (%i2) f(a,T,t):=if t<T then 1exp((t)^b) else (1exp((T)^b))*exp((tT)^b); Evaluation took 0.00 seconds (0.00 elapsed) (%o2) f(a,T,t):=if t<T then 1exp(t^b) else (1exp(T^b))*exp((tT)^b) (%i3) g(b,T):='first('quad_qag(f(a,T,t),t,0,30,1e6,300))/T; Evaluation took 0.00 seconds (0.00 elapsed) (%o3) g(b,T):=first(quad_qag(f(a,T,t),t,0,30,9.9999999999999995*10^7,300))/T (%i4) wxplot2d([g(1,T)], [T,1,2], [nticks,5]); (%t4) << Graphics >> Evaluation took 6.83 seconds (6.83 elapsed) (%o4) (%i5) wxplot2d([g(1,T)], [T,1,3], [nticks,5]); (%t5) << Graphics >> Evaluation took 10.72 seconds (10.72 elapsed) (%o5) (%i6) wxplot2d([g(1,T)], [T,1,10], [nticks,5]); CLIENT: Lost socket connection ... Restart maxima with 'Maxima>Restart maxima'.  >Comment By: Robert Dodier (robert_dodier) Date: 20080617 22:34 Message: Logged In: YES user_id=501686 Originator: NO Looks like the definition of f has a typo  should probably read f(b, T, t) := ... since variable "a" does not appear in the function body. Also the call to quad_qag is problematic  there is supposed to be a "key" argument after the range of integration. If I had to guess, I would suspect that g is returning a nonnumeric value and that is confusing wxplot2d. But I don't really know. I can't tell what's going on here, and there is no contact info. Closing this report as "rejected".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1881281&group_id=4933 
From: SourceForge.net <noreply@so...>  20080618 03:35:52

Bugs item #1882416, was opened at 20080129 23:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1882416&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: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't plot Initial Comment: (%i1) plot2d([x^2, x^3, x^4 x +1] ,[x,10,10]); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Broken pipe Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. and aplying debuggerhook nothing happens, sfxenon@...  >Comment By: Robert Dodier (robert_dodier) Date: 20080617 21:35 Message: Logged In: YES user_id=501686 Originator: NO Sent email to sfxenon@... to ask for more info. I've marked this report "pending" so that it will be closed automatically in 2 weeks if there is no further progress on it. With the information at hand, there isn't enough to go on.  Comment By: Barton Willis (willisbl) Date: 20080130 04:23 Message: Logged In: YES user_id=895922 Originator: NO It works for me (Maxima 5.14.0). Do other plot2d commands work  say plot2d(x,[x,1,1])? What is the output of build_info? (%i4) build_info(); Maxima version: 5.14.0 Maxima build date: 21:46 12/27/2007 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=1882416&group_id=4933 
From: SourceForge.net <noreply@so...>  20080618 03:26:54

Bugs item #1880986, was opened at 20080128 00:43 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1880986&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: Nobody/Anonymous (nobody) Assigned to: Andrej Vodopivec (andrejv) Summary: gnuplot_replot(s) function is not available Initial Comment: Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8 gnuplot_replot(s) is for sending the gnuplot command to gnuplot from maxima,and replots the gnuplot graph, but i found it doesn't work. for example plot2d(sin(x),[x,8,8]); \* get the sin(x) graph\* gnuplot_replot("set xlabel 'xxx'"); the gnuplot_replot(s) function doesn't work, the sin(x) graph, whose xlable is still "x" instead of "xxx" . i found every time i must close the gnuplot graph,then maxima begin to evalute the following commands after plot2d and plot3d. so if don't close the gnuplot graph after plot2d or plot3d command,the gnuplot_replot(s) isn't evaluted, i can't get the graph reploted. yjq94111@...  >Comment By: Robert Dodier (robert_dodier) Date: 20080617 21:26 Message: Logged In: YES user_id=501686 Originator: NO Closing this report as "won't fix" per comment by andrejv.  Comment By: Andrej Vodopivec (andrejv) Date: 20080128 10:36 Message: Logged In: YES user_id=1179910 Originator: NO gnuplot_replot requires gnuplot_pipes plot format. This is not yet implemented on windows. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1880986&group_id=4933 
From: SourceForge.net <noreply@so...>  20080618 03:24:42

Bugs item #1877589, was opened at 20080122 12:48 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1877589&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ev(sin(x/2),nouns) => sin(.5*x) Initial Comment: ev(sin(3),nouns)=0.909 OK ev(sin(x/2),nouns) => sin(0.5 * x) WRONG ev(sin(x+2.0b0),nouns) => sin(x+2.0) WRONG My guess is that it is trying to ensure that e.g. sin(%pi/5) gets evaluated numerically, but why is it using resimplify rather than $float? And if the result isn't a float/complex float, why isn't it returning the original argument? And I do wonder where that strange name ''MAKE comes from.... Frankly, I think we'd be better off if we completely got rid of this weird business of using the verb form to evaluate numerically. PS I noticed all this because $erf needs to be included in the list  see bug 1877522.  >Comment By: Robert Dodier (robert_dodier) Date: 20080617 21:24 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.64 src/mlisp.lisp (disable verbification => numerical evaluation scheme). With current CVS version, ev(sin(3),nouns); => sin(3) ev(sin(x/2),nouns); => sin(x/2) ev(sin(x+2.0b0), nouns); => sin(x + 2.0b0) I think these are all OK. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1877589&group_id=4933 
From: SourceForge.net <noreply@so...>  20080617 18:12:34

Bugs item #1996354, was opened at 20080617 13:12 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=1996354&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: unsimplifed result from expand Initial Comment: (%i52) (%e^(2*sqrt(2))*(%e^(2*sqrt(2))+2*%e^sqrt(2)+1)^2)/16+(%e^(2*sqrt(2))*(%e^(2*sqrt(2)) 2*%e^sqrt(2)+1)^2)/16(%e^(2*sqrt(2))*(%e^(2*sqrt(2))1)^2)/8$ /* should be 1 */ (%i53) expand(%); (%o53) %e^(2^(3/2)2*sqrt(2))/2+1/2 (%i54) expand(%,0,0); (%o54) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1996354&group_id=4933 
From: SourceForge.net <noreply@so...>  20080617 04:07:40

Bugs item #1952642, was opened at 20080427 05:05 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1952642&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: 5 Private: No Submitted By: Andrej Vodopivec (andrejv) Assigned to: Barton Willis (willisbl) Summary: fourier_elim Initial Comment: (%i1) load(fourier_elim)$ (%i2) fourier_elim([abs(x)<1], [x]); (%o2) [1<x,x<1] < OK (%i3) fourier_elim([abs(x)>1], [x]); (%o3) [1<x] < should be [x<1] or [1<x] Andrej  >Comment By: Barton Willis (willisbl) Date: 20080616 23:07 Message: Logged In: YES user_id=895922 Originator: NO fixed by fourier_elim.lisp cvs revision 1.4; appended regression test to rtest_fourier_elim.  Comment By: Barton Willis (willisbl) Date: 20080428 06:00 Message: Logged In: YES user_id=895922 Originator: NO In the function m>, the code needs an additional line: ((and (opequalp a 'mabs) ($freeof 'mabs '$min '$max b)) (setq a (first (margs a))) (opapply 'mor (list (opapply 'mand (list (m> 0 b))) (opapply 'mand (list (m>= b 0) (m> a b))) (opapply 'mand (list (m>= b 0) (m> (neg a) b)))))) I'll check in this fix after I test it. Thanks for the bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1952642&group_id=4933 
From: SourceForge.net <noreply@so...>  20080616 23:27:17

Bugs item #1995595, was opened at 20080616 18:27 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=1995595&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: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sign(max(7,x)  max(6,x)) > error Initial Comment: (%i1) sign(max(7,x)  max(6,x)); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: MACSYMATOPLEVEL [or a callee] requires less than seven arguments.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995595&group_id=4933 
From: SourceForge.net <noreply@so...>  20080616 21:49:33

Bugs item #1995531, was opened at 20080616 17: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=1995531&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeta errors near 0.0 / 0.0b0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 
From: SourceForge.net <noreply@so...>  20080616 21:48:46

Bugs item #1995528, was opened at 20080616 17:46 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995528&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: Deleted Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: zeta fails for floats/bfloats near 0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995528&group_id=4933 
From: SourceForge.net <noreply@so...>  20080616 21:48:22

Bugs item #1995528, was opened at 20080616 17:46 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995528&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: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: zeta fails for floats/bfloats near 0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995528&group_id=4933 
From: SourceForge.net <noreply@so...>  20080616 21:46:10

Bugs item #1995528, was opened at 20080616 14:46 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=1995528&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: zeta fails for floats/bfloats near 0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995528&group_id=4933 
From: SourceForge.net <noreply@so...>  20080615 20:34:49

Bugs item #1811968, was opened at 20071012 04:27 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1811968&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: echelon error Initial Comment: The "echelon()" function calculates a matrix which cannot be arrived at by elementary row operations. Look, the rank even changes! PK  >Comment By: Andrej Vodopivec (andrejv) Date: 20080615 22:34 Message: Logged In: YES user_id=1179910 Originator: NO Then rank function already sets algebraic to true in case there are algebraic numbers in the matrix. Attached a patch which does the same for the echelon function. File Added: matrix.lisp.patch  Comment By: Robert Dodier (robert_dodier) Date: 20080615 03:05 Message: Logged In: YES user_id=501686 Originator: NO Here's the content of the jpeg. b:matrix([1/2, sqrt(3)/2, 1, 0], [sqrt(3)/2, 1/2, 0, 1], [1, 0, 1, sqrt(3)/2], [0, 1, sqrt(3)/2, 1/2]); rank(b); => 3 echelon(b); => matrix([1,sqrt(3),2,0],[0,1,sqrt(3)/2,1/2],[0,0,1,0],[0,0,0,1]) rank(echelon(b)); => 4 triangularize(b); => matrix([1,sqrt(3),2,0],[0,2,sqrt(3),1],[0,0,6,0],[0,0,0,0])  Comment By: Barton Willis (willisbl) Date: 20071013 03:26 Message: Logged In: YES user_id=895922 Originator: NO A workaround is to set algebraic to true. Maybe echelon (and rank) should set algebraic to true. PS Instead of a jpg file, next time send a text only bug report: (1) it's easy to do (2) it doesn't require that the reader do any retyping (3) it has no security risks for the reader (4) it's much more likely that somebody will read your report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1811968&group_id=4933 
From: SourceForge.net <noreply@so...>  20080615 16:11:54

Bugs item #1376860, was opened at 20051209 04:53 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1376860&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: specint(gammaincomplete(v,a*t)*exp(p*t),t) seems wrong Initial Comment: (%i12) assume(v>0,p>0); (%o12) [v>0,p>0] (%i13) specint(gammaincomplete(v,a*t)*exp(p*t),t); SIMP2F1WILLCONTINUEIN (%o13) a^v*(p+a)^(v1)*gamma(v+1)*%f[2,1]([v+1,3/2],[2],p/(p+a)) Compare this with (%i14) specint(gammagreek(v,a*t)*exp(p*t),t); (%o14) a^v*p^(v1)*gamma(v+1)/((a/p+1)^v*v) This matches formula 34, p 179 in Tables of Transforms. Considering gammaincomplete = gamma(n)gammagreek, the expression for gammaincomplete seems wrong. It might still be right if the hypergeometric function simplifies, but maxima can't, and I can't think of any way to simplify it either.  Comment By: Crategus (crategus) Date: 20080615 18:11 Message: Logged In: YES user_id=2039760 Originator: NO I would like to suggest the following algorithm to get an evaluated integral for the Gammaincomplete function: (defun gammaincompletetohypergeometric (a x) (if (eq (asksign a) '$zero) ;; The representation as Whittaker W function for a=0 (mul* (power x (div (sub a 1) 2)) (power '$%e (div x 2)) ($whittaker_w (div (sub a 1) 2) (div a 2) x)) ; sign of (div a 2) correct? ;; In all other cases the representation as Hypergeometric 1F1 function (sub (list '(%gamma) a) (mul (power x a) (inv a) ($hypergeometric (list '(mlist) a) (list '(mlist) (add a 1)) (mul 1 x)))))) This routine has to be replaced for GAMMAINCOMPLETETW and called in the routine FRACTEST2. The idea is to use the Hypergeometric Function 1F1 when the parameter A is not equal to zero. That is equivalent to use gamma(a)  gammagreek(a,x) for the evaluation. Now we use the transformation to Whittaker W only for a=0, but for this case we get a nice result too. Here some examples with the above routine: (%i1) assume(s>0,a>0); (%o1) [s > 0,a > 0] We get the expected simple answer for gammaincomplete: (%i2) radcan(specint(%e^(s*t)*gammaincomplete(a,t),t)); (%o2) (a*gamma(a)*(s+1)^agamma(a+1))/(a*s*(s+1)^a) If we take a=0 we get a nice and correct result too: (%i3) radcan(specint(%e^(s*t)*gammaincomplete(0,t),t)); (%o3) log(s+1)/s The function %ei uses the code of gammaincomplete with a=0: (%i4) radcan(specint(%e^(s*t)*%ei(t),t)); (%o4) log(1s)/s For special values like a=1/2 or a=1 both algorithm get simple expressions. The results calulated with 1F1 are identical to the results of the orginal code which use the transformation to Whittaker W: (%i5) radcan(specint(%e^(s*t)*gammaincomplete(1/2,t),t)); (%o5) (sqrt(%pi)*sqrt(s+1)sqrt(%pi))/(s*sqrt(s+1)) (%i6) radcan(specint(%e^(s*t)*gammaincomplete(1,t),t)); (%o6) 1/(s+1) In the above code I have used the routines $hypergeometric and $whittaker_w. I have introduced this functions to make the code more expressive. It is easy to use the alternavtives %f and %w. Furthermore $specint has to be extended to integrate %f. The testsuite has no problems with this alogorithm. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20060212 20:15 Message: Logged In: YES user_id=28849 The fix for transforming %w causes this return the result in terms of the associated Legendre function Q. Somewhat better, but I do not know if this is equivalent.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1376860&group_id=4933 
From: SourceForge.net <noreply@so...>  20080615 16:02:40

Bugs item #1866077, was opened at 20080107 11:41 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1866077&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: monstertrig: too many contexts Initial Comment: In [ 1860487 ] MONSTERTRIG endless recursion, I don't actually get endless recursion. It stops with an error saying too many contexts. But if you try to do the integral again, maxima stops instantly (as indicated by tracing monstertrig) with the same error message about too many contexts. Not good.  >Comment By: Robert Dodier (robert_dodier) Date: 20080615 10:02 Message: Logged In: YES user_id=501686 Originator: NO [ 1860487 ] MONSTERTRIG endless recursion has been fixed and closed, and I don't observe this bug (5.14.99rc1 + GCL + Windows), so I'm closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1866077&group_id=4933 
From: SourceForge.net <noreply@so...>  20080615 15:59:06

Bugs item #1869296, was opened at 20080111 06:01 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1869296&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([1,2],[6],1) bogus Initial Comment: (%i248) hgfred([1,2],[6],1); (%o248) (5*(2/((11)^3*1)+4/((11)^2*1^2)12/((11)*1^3)(24*log(11))/1^424/1^4(24*log(11)*(11))/1^5)*(11)^3)/6 (%i249) ratsimp(%); log(0) has been generated. The correct result is a quotient of products of gamma functions.  >Comment By: Robert Dodier (robert_dodier) Date: 20080615 09:59 Message: Logged In: YES user_id=501686 Originator: NO Observed in 5.14.99rc1. Agreed that result is bogus.  Comment By: Barton Willis (willisbl) Date: 20080111 08:23 Message: Logged In: YES user_id=895922 Originator: YES 5/3 is the correct value; in general, we have A&S 15.1.20, page 556: http://www.convertit.com/Go/ConvertIt/Reference/AMS55.ASP?Res=150&Page=556 >I still think that hgfred is intended for simplification without numerical >evaluation. I agree. If would be OK with me if hgfred returned a nounform for things like hgfred([1,2],[6],1). It's just that I don't like it when hgfred returns something that is bogus.  Comment By: Raymond Toy (rtoy) Date: 20080111 08:07 Message: Logged In: YES user_id=28849 Originator: NO What is the answer supposed to be? Do you know what hgfred([1,2],[6],x) is supposed to return? limit(hgfred([1,2],[6],x),x,1) > 5/3. Based on the code, it computes hgfred([1,2],[6],x) in terms of hgfred([1,1],[2],x) by appropriate differentiation. (See derivint and comments in hyp.lisp.) Since hgfred([1,1],[2],x) is log(1x)/x, I don't see how gamma functions appear. I still think that hgfred is intended for simplification without numerical evaluation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1869296&group_id=4933 
From: SourceForge.net <noreply@so...>  20080615 08:18:18

Bugs item #1994295, was opened at 20080615 10:18 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=1994295&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: errormsg Initial Comment: The variable errormsg controls if the error message is printed. There are some bugs when setting errormsg locally: (%i1) errormsg; (%o1) true (%i2) 1/x, errormsg=false; (%o2) 1/x (%i3) errormsg; (%o3) false (%i1) errormsg; (%o1) true (%i2) divide(x) := block([errormsg:false], 1/x); (%o2) divide(x):=block([errormsg:false],1/x) (%i3) divide(x); (%o3) 1/x (%i4) errormsg; (%o4) false Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1994295&group_id=4933 