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}
(51) 
_{Dec}

S  M  T  W  T  F  S 





1
(6) 
2
(10) 
3

4
(3) 
5
(5) 
6

7
(5) 
8
(3) 
9
(3) 
10
(3) 
11

12
(1) 
13
(1) 
14
(8) 
15
(8) 
16
(3) 
17
(5) 
18

19

20

21

22
(1) 
23

24
(2) 
25
(2) 
26
(2) 
27

28
(1) 
29
(2) 
30

31
(3) 
From: SourceForge.net <noreply@so...>  20080531 21:38:43

Bugs item #1952642, was opened at 20080427 05:05 Message generated for change (Settings changed) 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: Open Resolution: None 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: 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...>  20080531 18:53:11

Bugs item #1965640, was opened at 20080516 22:04 Message generated for change (Comment added) made by crategus 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: Nobody/Anonymous (nobody) 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: Crategus (crategus) Date: 20080531 20: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: 20080527 00: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 23: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 23: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 22: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...>  20080531 15:39:53

Bugs item #1980715, was opened at 20080531 08:39 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=1980715&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong radcansimplification Initial Comment: Maxima version: 5.13.0 Maxima build date: 9:20 12/12/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 radcan(3^(1/6)*9^(1/3)); sqrt(3) and that ist wrong! helfried.kravanja@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1980715&group_id=4933 
From: SourceForge.net <noreply@so...>  20080529 17:07:23

Bugs item #1978090, was opened at 20080529 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=1978090&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: strange limit result Initial Comment: /*wxMaxima 0.7.5 http://wxmaxima.sourceforge.netMaxima 5.15.0 http://maxima.sourceforge.netUsing 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) abs(sin(x))/sqrt(1cos(x)); (%o1) abs(sin(x))/sqrt(1cos(x)) (%i2) limit(%o1, x, 0, minus); (%o2) sqrt(2) (%i3) limit(%o1, x, 0, plus); (%o3) sqrt(2) (%i4) bug_report()$The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browseSubmit bug reports by following the 'Submit New' link on that page.Please include the following build information with your bug report:Maxima version: 5.15.0Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8The above information is also available from the Maxima function build_info().(%i5) amedeo.maddalena@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1978090&group_id=4933 
From: SourceForge.net <noreply@so...>  20080529 15:45:29

Bugs item #1977992, was opened at 20080529 08:45 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=1977992&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: no limit calculation Initial Comment: /*wxMaxima 0.7.1 http://wxmaxima.sourceforge.netMaxima 5.12.0 http://maxima.sourceforge.netUsing 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.This is a development version of Maxima. The function bug_report()provides bug reporting information. Maxima version: 5.12.0Maxima build date: 15:52 7/20/2007host type: i686pclinuxgnulispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.7 (%i1) abs(sin(x))/sqrt(1cos(x)); (%o1) abs(sin(x))/sqrt(1cos(x)) (%i2) limit(%o1, x, 0); (%o2) lim(abs(sin(x))/sqrt(1cos(x)),x,0) amedeo.maddalena@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977992&group_id=4933 
From: SourceForge.net <noreply@so...>  20080528 21:37:31

Bugs item #1977146, was opened at 20080528 23:37 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=1977146&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Marik (robertmarik) Assigned to: Nobody/Anonymous (nobody) Summary: radexpand does not work as explained in documentation Initial Comment: >From maxima discussion list: Maxima manual states the following  When radexpand is false, certain transformations are inhibited. radcan (sqrt (1x)) remains sqrt (1x) and is not simplified to %i sqrt (x1). radcan (sqrt (x^2  2*x + 11)) remains sqrt (x^2  2*x + 1) and is not simplified to x  1.  Neglecting the typo in radcan (sqrt (x^2  2*x + 11)) which should be probably radcan (sqrt (x^2  2*x + 1)), I get the answer x1 also with radexpand:false. Moreover, sqrt(1x) remains sqrt(1x) even with radexpand:true. Is the documentation of radcan obsolete? Robert Marik reponse of Richard Fateman radexpand was inserted by someone else, after the code was written in 1970. I do not know if the documentation or the program is buggy, since I'm not sure what was intended. RJF  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1977146&group_id=4933 
From: SourceForge.net <noreply@so...>  20080526 22:58:36

Bugs item #1965640, was opened at 20080516 22:04 Message generated for change (Comment added) made by crategus 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: Nobody/Anonymous (nobody) 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: Crategus (crategus) Date: 20080527 00: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 23: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 23: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 22: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...>  20080526 19:33:00

Bugs item #1973399, was opened at 20080526 12: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=1973399&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: F(x) := 1/%pi*(atan(x) + %pi/2) Initial Comment: Hello. I have Maxima 5.15.0. Next commands break it. F(x) := (1/%pi)*(atan(x) + %pi/2); 1 %pi (%o1) F(x) :=  (atan(x) + ) %pi 2 (%i2) assume(x>0); (%o2) [x > 0] (%i3) limit(F(x*n/%pi)^n, n, inf); **  Continuable Error Unhandled kernel in tvarlim If you continue (by typing 'continue'): Return from COMMONLISP:BREAK loop The following restarts are also available: MACSYMAQUIT :R1 Maxima toplevel But Maple 11 evaluates it. May be I should set some parameters? Ilia zerone2@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1973399&group_id=4933 
From: SourceForge.net <noreply@so...>  20080525 21:32:39

Bugs item #1220227, was opened at 20050614 05:48 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1220227&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: joe532 (joe532) Assigned to: Nobody/Anonymous (nobody) Summary: MIN is not correct (problem with "is" function) Initial Comment: I have the following problem with MIN : the graph of min below does not match the min of the curves on the second graph. session: f(h,k,l):=(h^k)*((1/h)*k*(1+l)+(dk)*2*l); g(h,k,l):=2*d*l+(h^k)*((1/h)*k*(1l)(dk)*2*l); d:2; l:0.5; plot2d([f((1v)^(1/2),2,l), f((1v),1,l), g(v^(1/2),2,l), g(v,1,l)], [v,0,1])$ plot2d(min(f((1v)^(1/2),2,l), f((1v),1,l), g(v^(1/2),2,l), g(v,1,l)), [v,0,1])$ on maxima Maxima 5.9.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.6 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information.  Comment By: Robert Dodier (robert_dodier) Date: 20060812 12:34 Message: Logged In: YES user_id=501686 Not observed in 5.9.3cvs / Clisp 2.38, GCL 2.6.7, SBCL 0.9.9 on Linux. Seems likely that recent modifications to min/max have fixed this. Marking this report to be retested on Windows  if it does not appear there, we can close this report as fixed. For the record the following plot2d puts the 3 curves of interest together with the min of those 3 on one plot. Should find that the computed min coincides with whichever curve is lowest. f(h,k,l):=(h^k)*((1/h)*k*(1+l)+(dk)*2*l); g(h,k,l):=2*d*l+(h^k)*((1/h)*k*(1l)(dk)*2*l); d:2; l:0.5; plot2d([f((1v)^(1/2),2,l), f((1v),1,l), g(v^(1/2),2,l), g(v,1,l), min(f((1v)^(1/2),2,l), f((1v),1,l), g(v^(1/2),2,l), g(v,1,l))], [v,0,1])$  Comment By: Robert Dodier (robert_dodier) Date: 20050614 10:20 Message: Logged In: YES user_id=501686 OK, I've narrowed the problem. aa: f((1v)^(1/2),2,l); bb: f((1v),1,l); cc: g(v^(1/2),2,l); dd: g(v,1,l); min (aa, bb, cc, dd) => min((0.5/v1.0)*v+2.0, 3.0*sqrt(1v)) OK, that's min (aa, dd). As for bb and dd, bb is equal to dd: ratsimp (bb  dd) => 0 What about cc ? is (cc > aa) => undecided (OK) is (cc > bb) => undecided (OK) is (cc > dd) => true (OOPS, should be undecided) is (cc > dd) => undecided (OK, but why is it different from first time?) trace (ratsimp), then is(cc > aa), is(cc > bb), is(cc > dd), shows ratsimp is called once by "is". On the second is(cc > dd), ratsimp is called twice by "is"; seems like the problem could be in "is". Given that bb is equal to dd, this is a work around: plot2d (min (aa, bb, cc), [v, 0, 1]);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1220227&group_id=4933 
From: SourceForge.net <noreply@so...>  20080525 20:14:18

Bugs item #1384806, was opened at 20051218 20:51 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384806&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 Private: No Submitted By: Waldek Hebisch (hebisch) Assigned to: Nobody/Anonymous (nobody) Summary: factor((x^15+1)^15(x^151)^15) wrong Initial Comment: factor((x^15+1)^15(x^151)^15) gives: 30 180 150 120 2 (3 x + 1) (5 x + 150 x + 951 x 90 60 30 + 1828 x + 1059 x + 102 x + 1) However, the second factor is composite, it is (5*x^60 + 10*x^30 + 1)* (x^120 + 28*x^90 + 134*x^60+ 92*x^30 +1) This happens on Maxima 5.9.2 on AMD64 using Clisp and on 5.9.1 using gcl (both AMD64 and i386)  >Comment By: Dan Gildea (dgildea) Date: 20080525 16:14 Message: Logged In: YES user_id=1797506 Originator: NO fixed in src/factor.lisp rev 1.17 o nprod: loop structure: was returning after finding factor when no tuples left, rather than continuing to next stage/tloop. (%i21) factor((x^15+1)^15(x^151)^15) ; (%o21) 2*(3*x^30+1)*(5*x^60+10*x^30+1)*(x^120+28*x^90+134*x^60+92*x^30+1)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1384806&group_id=4933 
From: SourceForge.net <noreply@so...>  20080524 21:16:18

Bugs item #1965640, was opened at 20080516 22:04 Message generated for change (Comment added) made by crategus 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: Nobody/Anonymous (nobody) 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: Crategus (crategus) Date: 20080524 23: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 23: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 22: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...>  20080524 21:10:47

Bugs item #1965640, was opened at 20080516 22:04 Message generated for change (Comment added) made by crategus 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: Nobody/Anonymous (nobody) 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: Crategus (crategus) Date: 20080524 23: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 22: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...>  20080522 18:32:05

Bugs item #1969790, was opened at 20080522 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=1969790&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: limits and subscripts Initial Comment: Maybe not wrong, but it's weird: (%i24) limit(mu[inf],x,inf); (%o24) limit(mu[x],x,inf) Also: (%i25) mu[x] : 42$ (%i26) limit(mu[inf],x,inf); (%o26) limit(mu[x],x,inf) (%i27) ev(%); (%o27) 42  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1969790&group_id=4933 
From: SourceForge.net <noreply@so...>  20080517 20:43:45

Bugs item #1960200, was opened at 20080508 07:50 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1960200&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integrate function raises "too many contexts" error Initial Comment: When I try to run the following command sequence f1c_2d:x^2*y^2*\(sin(2.*x)+%i*cos(2.*y))*exp(%i*20.*x)*exp(%i*30.*y)$ l:integrate(f1c_2d,x,1.,10.); l:integrate(l,y,5.,15.); I get a "too many contexts" error message after the second call to "integrate". I use maxima 5.15.0 with SBCL Lips. The function to integrate is pretty easy so I do not expect that there is an error at all. regards Eugen Wintersberger eugen.wintersberger@...  >Comment By: Dan Gildea (dgildea) Date: 20080517 16:43 Message: Logged In: YES user_id=1797506 Originator: NO src/sin.lisp revision 1.31 o monstertrig: trying new way to stop recursion: only substitute new variable when total size of expression decreases. Handles oscillation between sin(x+4)*cos(x) <> sin(x)*cos(x4). fixes [ 1960200 ] integrate function raises "too many contexts" error tests/rtestint.mac: new test case  Comment By: Harald Geyer (hgeyer) Date: 20080509 06:43 Message: Logged In: YES user_id=929336 Originator: NO Note that maxima apparently doesn't recover from this kind of error: Once I get the "too many contexts" message any further integration (even something simple like integrate(y,y,5,15) fails with the same error. Also note that this issue is similiar to #1714039 and #1866077 and (the already fixed) #1860487  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1960200&group_id=4933 
From: SourceForge.net <noreply@so...>  20080517 20:40:54

Bugs item #1714039, was opened at 20070507 01:08 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1714039&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in MONSTERTRIG (trig integral) Initial Comment: The following code triggers an error message "Too many contexts". The problem is that $INTEGRATE eventually calls MONSTERTRIG which then calls $INTEGRATE with the integrand unchanged, which calls MONSTERTRIG, etc. DD:3; f(i,j,x,y):=cos(i*(x+y)/2)*sin(j*(xy)/4); pp(x):=cos(x)+cos(2*x); Dint(f,v,a,b):=block([FF:ratsimp(integrate(f,v))],subst(b,v,FF)subst(a,v,FF)); fn(i,j,x,y):=ratsimp(f(i,j,x,y)/ev(sqrt(Dint(Dint(f(i,j,x,y)*f(i,j,x,y),x,4*%pi,4*%pi),y,4*%pi,4*%pi)))); wf(i,x,y):=fn(floor(i/4),mod(i,4)+1,x,y); EP1:genmatrix(ev(aa),DD,DD); g:2; for i from 0 thru DD do (for j from 0 thru DD do aa[i,j]:(Dint(Dint(wf(i,x,y)*wf(j,x,y)*(pp(x)+pp(y)),x,%pi,%pi),y,%pi, %pi))); The bug is not triggered when i=0 and j=0, but it is triggered when i=0 and j=1. See comments in MONSTERTRIG in src/sin.lisp. This problem appeared on the mailing list under the subject "Error message: Too many contexts".  >Comment By: Dan Gildea (dgildea) Date: 20080517 16:40 Message: Logged In: YES user_id=1797506 Originator: NO seems ok in current cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1714039&group_id=4933 
From: SourceForge.net <noreply@so...>  20080517 19:04:42

Bugs item #1635365, was opened at 20070114 14: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=1635365&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: specint calls asksign about internal variable PSEY Initial Comment: assume(p > 0, a > 0); t^(1/2)*%e^(p*ta/t); specint(%,t); => "Is psey positive, negative, or zero?" PSEY is an internal variable, should not be visible to user. See comments in src/hypgeo.lisp about PSEY. >From the comments, PSEY represents the parameter in a Laplace transform. Maybe it will resolve the problem to do assume(psey > 0) or something like that. Ideally that assumption would be attached to the result (after substituting the original parameter symbol for PSEY).  >Comment By: Robert Dodier (robert_dodier) Date: 20080517 13:04 Message: Logged In: YES user_id=501686 Originator: YES I'm inclined to commit the patch suggested by Dieter. What do you think, Ray?  Comment By: Crategus (crategus) Date: 20080517 09:43 Message: Logged In: YES user_id=2039760 Originator: NO I had a look at the PSEYproblem. Must of the questions for the sign of the parameters which are involved in the Laplace transform arise after calling the subroutine hgsimpexec. This routine is part of the file hyp.lisp. In some cases we transfer the parameter PSEY to hgsimpexec. An example is the routine simpktf which will be called for functions involving terms e.g. like %e^(a/t). When we do so, we are asked sometimes for the sign of PSEY. That's the case when hgsimpexec has to calculate a square root and PSEY is involved. In the routine negtest we check the sign of the parameter of the Laplace transform. But because we substitute the parameter with PSEY we lost the information of the sign check. I think, the best we can do, is to give a Maxima a rule for the sign of PSEY. After addition of the following code to the routine negtest in the file hypgeo.lisp, we no longer get a question for the sign of PSEY. The testfile test_eqworld.mac I have appended to the bug report [1965640] no longer stops. ;; We know psey must be positive. psey is a substitution ;; for the parameter a and we have checked the sign. So it is the ;; best to add a rule for the sign of psey. (mfuncall '$assume `((mgreaterp) psey 0)) (return (prog1 (maximasubstitute (mul 1 a) 'psey (ltscale u var 'psey c 0 e f)) ;; We forget the rule after finishing the calculation. (mfuncall '$forget `((mgreaterp) psey 0))))) Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20070117 07:18 Message: Logged In: YES user_id=28849 Originator: NO By not doing the substitution, maxima no longer asks questions about psey. That's good. However, problem 53 in rtest14 and problems 111, 112 in rtesthyp. I think problem 53 is ok, just a different respresntation that maxima didn't simplify. However problems 111 and 112 are more fundamental. It calls LTEP to match a form, but the Laplace variable is p+%i*a instead of a simple variable. Perhaps some changes to LTEP could fix this.  Comment By: Robert Dodier (robert_dodier) Date: 20070114 14:31 Message: Logged In: YES user_id=501686 Originator: YES Another example: assume (a > 0, p > 0); t*bessel_i(0,a*t/2)*bessel_i(1,a*t/2)*%e^(p*t); specint(%,t); => Is (psey  a) (psey + a) positive, negative, or zero?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635365&group_id=4933 
From: SourceForge.net <noreply@so...>  20080517 16:10:12

Bugs item #1958163, was opened at 20080505 12:11 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1958163&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: timedate shows wrong time Initial Comment: timedate() function returns the result that is 1h behind the time of my system/hwclock. Maxima version: 5.13.0 Maxima build date: 13:17 1/19/2008 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 deshko@...  Comment By: Nobody/Anonymous (nobody) Date: 20080517 08:12 Message: Logged In: NO It seems that this is indeed the problem of lisp (gcl, actually). I tried to get timeoftheday in GCL and it gave me wrong (1h behind) time, while cmucl gave correct time. (I am in US now). So, this is not a maxima's bug. Thanks, guys.  Comment By: Robert Dodier (robert_dodier) Date: 20080514 20:18 Message: Logged In: YES user_id=501686 Originator: NO timedate in src/commac.lisp now (r1.52) takes the daylight saving flag into account. The flag was ignored before, which introduces an error of 1 h when daylight saving time is in effect (e.g. summer months in USA). I don't know if daylight saving applies in Belarus. Here is the new version of timedate if someone wants to try it: (defun $timedate () (multiplevaluebind (second minute hour date month year dayofweek dstp tz) (getdecodedtime) (format nil "~2,'0d:~2,'0d:~2,'0d ~[Mon~;Tue~;Wed~;Thu~;Fri~;Sat~;Sun~], ~d/~2,'0d/~d (GMT~@d)" hour minute second dayofweek month date year (if dstp ( 1 tz) ( tz))))) I'll close this report as fixed, which may be optimistic; we can reopen it or open a new one as needs be.  Comment By: Raymond Toy (rtoy) Date: 20080505 13:38 Message: Logged In: YES user_id=28849 Originator: NO timedate basically calls Lisp's getdecodedtime. If the time is wrong, it's a bug in your Lisp. Try this: :lisp (getdecodedtime) There should be 9 things printed. They are, sec, min, hour, date, month, year, dayofweek, daylightsavingstimep, and tz. If they don't match the expected time, your Lisp is not producing the expected time. (FWIW, I get a time of "05:32:00 Tue, 5/06/2008 (GMT+9) with gcl, but cmucl and clisp say 16:36:54 Mon, 5/05/2008 (GMT5). This is much closer to my real time.)  Comment By: Raymond Toy (rtoy) Date: 20080505 13:38 Message: Logged In: YES user_id=28849 Originator: NO timedate basically calls Lisp's getdecodedtime. If the time is wrong, it's a bug in your Lisp. Try this: :lisp (getdecodedtime) There should be 9 things printed. They are, sec, min, hour, date, month, year, dayofweek, daylightsavingstimep, and tz. If they don't match the expected time, your Lisp is not producing the expected time. (FWIW, I get a time of "05:32:00 Tue, 5/06/2008 (GMT+9) with gcl, but cmucl and clisp say 16:36:54 Mon, 5/05/2008 (GMT5). This is much closer to my real time.)  Comment By: Raymond Toy (rtoy) Date: 20080505 13:38 Message: Logged In: YES user_id=28849 Originator: NO timedate basically calls Lisp's getdecodedtime. If the time is wrong, it's a bug in your Lisp. Try this: :lisp (getdecodedtime) There should be 9 things printed. They are, sec, min, hour, date, month, year, dayofweek, daylightsavingstimep, and tz. If they don't match the expected time, your Lisp is not producing the expected time. (FWIW, I get a time of "05:32:00 Tue, 5/06/2008 (GMT+9) with gcl, but cmucl and clisp say 16:36:54 Mon, 5/05/2008 (GMT5). This is much closer to my real time.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1958163&group_id=4933 
From: SourceForge.net <noreply@so...>  20080517 15:44:47

Bugs item #1635365, was opened at 20070114 22:00 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635365&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: specint calls asksign about internal variable PSEY Initial Comment: assume(p > 0, a > 0); t^(1/2)*%e^(p*ta/t); specint(%,t); => "Is psey positive, negative, or zero?" PSEY is an internal variable, should not be visible to user. See comments in src/hypgeo.lisp about PSEY. >From the comments, PSEY represents the parameter in a Laplace transform. Maybe it will resolve the problem to do assume(psey > 0) or something like that. Ideally that assumption would be attached to the result (after substituting the original parameter symbol for PSEY).  Comment By: Crategus (crategus) Date: 20080517 17:43 Message: Logged In: YES user_id=2039760 Originator: NO I had a look at the PSEYproblem. Must of the questions for the sign of the parameters which are involved in the Laplace transform arise after calling the subroutine hgsimpexec. This routine is part of the file hyp.lisp. In some cases we transfer the parameter PSEY to hgsimpexec. An example is the routine simpktf which will be called for functions involving terms e.g. like %e^(a/t). When we do so, we are asked sometimes for the sign of PSEY. That's the case when hgsimpexec has to calculate a square root and PSEY is involved. In the routine negtest we check the sign of the parameter of the Laplace transform. But because we substitute the parameter with PSEY we lost the information of the sign check. I think, the best we can do, is to give a Maxima a rule for the sign of PSEY. After addition of the following code to the routine negtest in the file hypgeo.lisp, we no longer get a question for the sign of PSEY. The testfile test_eqworld.mac I have appended to the bug report [1965640] no longer stops. ;; We know psey must be positive. psey is a substitution ;; for the parameter a and we have checked the sign. So it is the ;; best to add a rule for the sign of psey. (mfuncall '$assume `((mgreaterp) psey 0)) (return (prog1 (maximasubstitute (mul 1 a) 'psey (ltscale u var 'psey c 0 e f)) ;; We forget the rule after finishing the calculation. (mfuncall '$forget `((mgreaterp) psey 0))))) Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20070117 15:18 Message: Logged In: YES user_id=28849 Originator: NO By not doing the substitution, maxima no longer asks questions about psey. That's good. However, problem 53 in rtest14 and problems 111, 112 in rtesthyp. I think problem 53 is ok, just a different respresntation that maxima didn't simplify. However problems 111 and 112 are more fundamental. It calls LTEP to match a form, but the Laplace variable is p+%i*a instead of a simple variable. Perhaps some changes to LTEP could fix this.  Comment By: Robert Dodier (robert_dodier) Date: 20070114 22:31 Message: Logged In: YES user_id=501686 Originator: YES Another example: assume (a > 0, p > 0); t*bessel_i(0,a*t/2)*bessel_i(1,a*t/2)*%e^(p*t); specint(%,t); => Is (psey  a) (psey + a) positive, negative, or zero?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1635365&group_id=4933 
From: SourceForge.net <noreply@so...>  20080516 20:11:09

Bugs item #1965640, was opened at 20080516 22:04 Message generated for change (Comment added) made by crategus 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: Nobody/Anonymous (nobody) 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: Crategus (crategus) Date: 20080516 22: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...>  20080516 20:04:59

Bugs item #1965640, was opened at 20080516 22:04 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=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: Nobody/Anonymous (nobody) 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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1965640&group_id=4933 
From: SourceForge.net <noreply@so...>  20080516 15:40:53

Bugs item #1686457, was opened at 20070322 18:52 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1686457&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: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mario Rodriguez Riotorto (riotorto) Summary: cspline does not work Initial Comment: Maxima version: 5.11.0Maxima build date: 12:25 2/10/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8 I am running Vista on a pc and using wxMaxima with p:matrix([1,0.8619948],[0.5,0.95802009],[0,1.0986123],[0.5,1.2943767]) cspline(p) gives (%o5) 9.14034523948868*10^22*( (71825435496803423232*x^3+215476306490410269696*x^2+407633004344606888418*x+1207048040965873240689)* charfun2(x,inf,0.5)+(102765973994457923520*x^3+154148960991686885280*x^2+ 376969355089246552430*x+1201937400000985205250)*charfun2(x,0,inf)+ (30940538497654500288*x^3+154148960991686885280*x^2+376969273915256356068*x+1201937400000985205250)* charfun2(x,0.5,0)) This is a free or natural cubic spline and x^2 terms are supposed to be zero for the infinite range parts and the middle part which is indicated by charfun2(x,.5,0) is the same as the part corresponding to charfun2(x,0,inf) is the same except for the x^3 coefficient.  >Comment By: Robert Dodier (robert_dodier) Date: 20080516 09:40 Message: Logged In: YES user_id=501686 Originator: NO Closing this report as "rejected". Mario, thanks for looking at it.  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20080515 13:54 Message: Logged In: YES user_id=1270759 Originator: NO I don't see any problems. The abscissas from the given points range from a=1 to b=0.5, and according to the definition of natural cubic splines, if p is the interpolation function, the boundary conditions are p''(a)=p''(b)=0; it's easy to check that the result given by cspline fits this restriction. I don't understand why "x^2 terms are supposed to be zero".  Comment By: Robert Dodier (robert_dodier) Date: 20080514 23:07 Message: Logged In: YES user_id=501686 Originator: NO I don't understand what is the problem here. When I try this with cspline I get foo : (.06565092800000027*x^3+.1969527840000008*x^2 +.3725906320000009*x+1.103283576) *charfun2(x,minf,0.5) +(.09393164799999938*x^3+.1408974719999991*x^2 +.3445629760000002*x+1.0986123) *charfun2(x,0,inf) +(.02828071999999911*x^3+.1408974719999991*x^2+0.344562976*x +1.0986123) *charfun2(x,0.5,0) and when I plot that via draw2d (explicit (foo, x, 2, 1), points ([1, 0.5, 0, 0.5], [0.8619948, 0.95802009, 1.0986123, 1.2943767])); I see the spline is a smooth curve which passes through the points. Can someone point out what is wrong here?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1686457&group_id=4933 
From: SourceForge.net <noreply@so...>  20080515 19:55:15

Bugs item #1686457, was opened at 20070323 01:52 Message generated for change (Comment added) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1686457&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: Nobody/Anonymous (nobody) Assigned to: Mario Rodriguez Riotorto (riotorto) Summary: cspline does not work Initial Comment: Maxima version: 5.11.0Maxima build date: 12:25 2/10/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8 I am running Vista on a pc and using wxMaxima with p:matrix([1,0.8619948],[0.5,0.95802009],[0,1.0986123],[0.5,1.2943767]) cspline(p) gives (%o5) 9.14034523948868*10^22*( (71825435496803423232*x^3+215476306490410269696*x^2+407633004344606888418*x+1207048040965873240689)* charfun2(x,inf,0.5)+(102765973994457923520*x^3+154148960991686885280*x^2+ 376969355089246552430*x+1201937400000985205250)*charfun2(x,0,inf)+ (30940538497654500288*x^3+154148960991686885280*x^2+376969273915256356068*x+1201937400000985205250)* charfun2(x,0.5,0)) This is a free or natural cubic spline and x^2 terms are supposed to be zero for the infinite range parts and the middle part which is indicated by charfun2(x,.5,0) is the same as the part corresponding to charfun2(x,0,inf) is the same except for the x^3 coefficient.  >Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20080515 21:54 Message: Logged In: YES user_id=1270759 Originator: NO I don't see any problems. The abscissas from the given points range from a=1 to b=0.5, and according to the definition of natural cubic splines, if p is the interpolation function, the boundary conditions are p''(a)=p''(b)=0; it's easy to check that the result given by cspline fits this restriction. I don't understand why "x^2 terms are supposed to be zero".  Comment By: Robert Dodier (robert_dodier) Date: 20080515 07:07 Message: Logged In: YES user_id=501686 Originator: NO I don't understand what is the problem here. When I try this with cspline I get foo : (.06565092800000027*x^3+.1969527840000008*x^2 +.3725906320000009*x+1.103283576) *charfun2(x,minf,0.5) +(.09393164799999938*x^3+.1408974719999991*x^2 +.3445629760000002*x+1.0986123) *charfun2(x,0,inf) +(.02828071999999911*x^3+.1408974719999991*x^2+0.344562976*x +1.0986123) *charfun2(x,0.5,0) and when I plot that via draw2d (explicit (foo, x, 2, 1), points ([1, 0.5, 0, 0.5], [0.8619948, 0.95802009, 1.0986123, 1.2943767])); I see the spline is a smooth curve which passes through the points. Can someone point out what is wrong here?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1686457&group_id=4933 
From: SourceForge.net <noreply@so...>  20080515 05:17:36

Bugs item #1588623, was opened at 20061101 07:42 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1588623&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed >Resolution: Fixed Priority: 1 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: romberg with % or %o argument Initial Comment: (%i1) sqrt(1+x^3); (%o1) sqrt(x^3+1) (%i2) romberg(%, x,0,1); Maxima encountered a Lisp error: Also, the command romberg(%o1,x,0,1) gives a Lisp error. This works OK: (%i4) romberg(sqrt(1+x^3), x,0,1); (%o4) 1.111447999508385 (%i1) build_info(); Maxima version: 5.10.0 Maxima build date: 19:9 9/21/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Robert Dodier (robert_dodier) Date: 20080514 23:17 Message: Logged In: YES user_id=501686 Originator: NO romberg was changed to an ordinary function (evaluates arguments like other functions) some time ago. The errors reported here are not observed, and in each case the result is 1.111447999508385 as expected. Closing this report as fixed.  Comment By: Barton Willis (willisbl) Date: 20061108 05:00 Message: Logged In: YES user_id=895922 I agree. It would be good to have a function for big float numerical integration. Not that romberg works with big floats: (%i2) romberg(sin(x^2),x,0,1); (%o2) 0.31026884083166872 (%i3) rombergtol : 1.0b12; (%o3) 1.0b12 (%i4) romberg(sin(x^2),x,0,1); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: ((BIGFLOAT SIMP 56) ...  Comment By: Robert Dodier (robert_dodier) Date: 20061105 09:14 Message: Logged In: YES user_id=501686 I don't recommend trying to fix romberg. The quadpack functions are more extensive implementations of the same basic idea (extrapolation from simple quadrature ruls); quadpack subsumes romberg and goes much farther. I'd like to cut out romberg entirely.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1588623&group_id=4933 
From: SourceForge.net <noreply@so...>  20080515 05:14:10

Bugs item #1625792, was opened at 20070101 12:20 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1625792&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: To be reviewed >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Strange interaction of plot2d and remvalue. Initial Comment: Plot2d behaves very strangely. (%i1) g(s):=block([s__],s__:s,remvalue(s),s__)$ (%i2) g(2); (%o2) 2 (%i3) plot2d(g,[t,1,2]); Warning: Illegal `remvalue' attempt: s Warning: Illegal `remvalue' attempt: s etc... The plot however is fine.  >Comment By: Robert Dodier (robert_dodier) Date: 20080514 23:14 Message: Logged In: YES user_id=501686 Originator: NO Appears to be fixed after testing w/ GCL, CMUCL, and Clisp. Closing this report as fixed.  Comment By: Robert Dodier (robert_dodier) Date: 20070302 19:20 Message: Logged In: YES user_id=501686 Originator: NO I think I fixed this in COERCEFLOATFUN in src/plot.lisp. Marking this for followup to verify.  Comment By: Nobody/Anonymous (nobody) Date: 20070101 12:21 Message: Logged In: NO Follow up on the mailing list by Robert Dodier. On 1/1/07, Michel Van den Bergh <michel.vandenbergh@...> wrote: > But look at the example. g(2) does *not* give a warning but g within > plot2d does give warnings. Michel, it turns out the strangeness is indeed within plot2d. I've made 2 mistakes here. (1) plot2d calls g in a nonstandard way (not via MFUNCALL). So that's the origin of this bit of strangeness. For the record, the bit to repair is COERCEFLOATFUN in src/plot.lisp. (2) When a Maxima function is called via MFUNCALL, the arguments do indeed appear on the values list (therefore REMVALUE is happy). best, Robert  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1625792&group_id=4933 
From: SourceForge.net <noreply@so...>  20080515 05:08:10

Bugs item #1662584, was opened at 20070217 17: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=1662584&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: Closed >Resolution: Fixed Priority: 1 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: error message from find_root Initial Comment: (%i35) find_root(pp); wrong number of args to `interpolate' Maybe this should be 'wrong number of args to `find_root'  >Comment By: Robert Dodier (robert_dodier) Date: 20080514 23:08 Message: Logged In: YES user_id=501686 Originator: NO Seems to have been fixed. Closing this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1662584&group_id=4933 