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}
(80) 
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 22:13:47

Bugs item #1959214, was opened at 20080506 22:36 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate() and array having lisp style name Initial Comment: Dear Developer of Maxima, I found that integrate() returns a wrong result if an array that has a lisp name ``?...'' is used in the argument of integrate(). Here is a demonstration program:  /* * integrate_and_array_of_lisp_name.maxima: * * S.Adachi 2008/05/06 */ display2d:false; integrate(1,?a[1],0,?a[2]); /* Maxima result ?a[1][2] should be ?a[2]. */ /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(integrate_and_array_of_lisp_name.maxima) batching #p/Volumes/HFS+2/home/adachi/work/294/integrate_and_array_of_lisp_name.maxima (%i2) display2d : false (%o2) false (%i3) integrate(1,?a[1],0,?a[2]) (%o3) ?a[1][2] (%o4) "integrate_and_array_of_lisp_name.maxima"  The correct value of this integration is ?a[2]. But Maxima returns ?a[1][2], which is wrong. I think that this is a bug of Maxima. In the following, I want to explain the situation in which I met the above bug of Maxima in order to motivate the kind Maxima developers to take the action to actually fix this bug. When I am writing a program in Maxima, I sometimes need an array that has some name which is unique and is dynamically determined in execution. In such a situation, I write a code like A:?gensym(), apply('array, [A,n]), ... < Work with dynamical array A > .. apply('remarray, [A]) The variable A stores a name ``?g....'' of the dynamical array that is generated. This name ``?g....'' is a lisp style name. In the present case, the work is to prepare a function of elements of the dynamical array and integrate the function. Then, when the written program is executed, it tells me that Maxima has the bug that I am now reporting. I hope that any variable in Maxima should not be discreminated by the reason that the variable simply has a lisp name. If it is so, what I am now reporting is truely a bug of Maxima, which is serious for people who write Maxima programs. Please fix this bug of Maxima. Sincerely yours, Satoshi Adachi P.S. (i) As a temporal workaround to write Maxima programs, I replace the line "A:?gensym()," in the above example by a line "A:eval_string(substring(string(?gensym()),2))," to use a Maxima style name "g...." instead of a lisp style name "?g...." (and keep being carefull not to use any name "g...." for other Maxima variables). This is an ugry workaround. (ii) If there is a better or standard way in Maxima to prepare some dynamical array that has a unique name on fly, please let me know. If someone tells me it, I will be happy.  >Comment By: Robert Dodier (robert_dodier) Date: 20080622 16:13 Message: Logged In: YES user_id=501686 Originator: NO Here is a slightly different workaround. :lisp (defun $gensym () (cadr (dollarify (list (gensym))))) Then you can write A:gensym() instead of A:?gensym() and the generated symbols are Maxima identifiers (because they have the leading $ in the name).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 21:55:41

Bugs item #1954693, was opened at 20080429 23:26 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: 2D display of long denominator of nested fractional Initial Comment: Dear Developers of Maxima, I think that I met a bug of Maxima to display nested fractionals in the 2D style. If the denominator of a nested fractional is long, it is not displayed correctly. The display width controll based on the variable LINEL seems to be not effective in the denominator. Compared to this, the numerator of a nested fractional causes no such problem to be displayed even when the numerator is long. Here, I have prepared a program for demonstration:  /* * denominator_of_nested_fractional_is_not_displayed_correctly.maxima: * * The line length, which is usually controlled by the variable LINEL, * is not recognized in the denominator of a nested fractional, if the * nested fractional has a long denominator. * * S.Adachi 2008/04/29 */ /* Do not use ``display2d:false;'', since this is a problem in displaying a mathematical expression in the 2D style. */ X:product(f(i+1/2),i,0,20); Y:product(g(i+1/2),i,0,20); Z:X/Y; /* A nested fractional; its denominator is not displayed correctly. */ /* END */  This is a problem in displaying mathematical expressions in the 2D style. Accordingly, I cannot attach here the log list that is obtained by running the above program. (If I include in a bug report the mathematical expressions that are displayed in the 2D style by Maxima, the posted bug report becomes a disordered gabage in appearance.) So, please execute the above program by the command maxima b denominator_of_nested_fractional_is_not_displayed_correctly.maxima to see the phenomenon that I am reporting in this letter. I am using a console terminal with line width 80 to run the above program. It is essential for Maxima to display any mathematical expression in a correct mannar. If it is not, we cannot read the output from Maxima. So, please fix this bug. Sincerely yours, Satoshi Adachi  >Comment By: Robert Dodier (robert_dodier) Date: 20080622 15:55 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core.  Comment By: Robert Dodier (robert_dodier) Date: 20080503 23:55 Message: Logged In: YES user_id=501686 Originator: NO Observed in Maxima 5.15.0cvs. NOT observed in 5.9.0  so I guess the display code was modified incorrectly at some point. I can try some different versions, but it will be a while. The line width doesn't appear to be important  I get incorrect output when linel:65, or linel:70, or linel:80.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 17:34:05

Bugs item #1951128, was opened at 20080424 14:18 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951128&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Polynomials Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Volker van Nek (van_nek) Assigned to: Nobody/Anonymous (nobody) Summary: curious warning from allroots(x=0) Initial Comment: (%i4) allroots(x=0); Unexpected error. Treat results with caution. (%o4) [x = 0.0] (%i5) allroots(x=1); (%o5) [x = 1.0] x=0 isn't so special, or?  >Comment By: Robert Dodier (robert_dodier) Date: 20080622 11:34 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.13 src/cpoly.lisp. Closing this report as fixed. Error originates in SCALESL because it tries to divide by degree of polynomial. RPOLYSL and CPOLYSL strip off zero roots before calling SCALESL, decreasing the degree by 1 for each zero root. However, if there are only roots at zero (e.g. x^n = 0 for some n) then SCALESL fails. So avoid calling SCALESL when reduced degree = 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1951128&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 11:33:48

Bugs item #1949337, was opened at 20080422 20:51 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1949337&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  Complex Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: complexnumberp test for floatp Initial Comment: (%i1) x : 3.1 + %i * 1.7; (%o1) 1.7*%i+3.1 This is wrong: (%i2) :lisp(complexnumberp (meval $x) 'floatp); NIL Thi is OK (%i2) :lisp(complexnumberp (meval $x) 'mnump); T I think this is due to the (N 1) check in complexnumberp. Maxima version: 5.14.99rc1 Maxima build date: 11:38 4/12/2008  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1949337&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 11:33:47

Bugs item #1941682, was opened at 20080413 20:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1941682&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: Xmaxima or other UI Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: After a while i get the message "Starting maxima timed out" Initial Comment: After a while I get the message "Starting maxima timed out. Wait longer?" and xmaxima doesn't connect to maxima. Maxima works fine, but it doesn't connect to xmaxima neither wxmaxima (this last gets the message "") I use Ubuntu 7.10, and maxima 5.10.0 and wxmaxima 0.7.1  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 19:13 Message: Logged In: YES user_id=501686 Originator: NO Not enough information to resolve the problem, and no contact info. Closing this report as "won't fix".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1941682&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 10:43:00

Bugs item #1995531, was opened at 20080616 16:49 Message generated for change (Comment added) made by willisbl 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!)  >Comment By: Barton Willis (willisbl) Date: 20080622 05:42 Message: Logged In: YES user_id=895922 Originator: NO Also try makelist(bfloat(bfzeta(1.0b7,20 + 10 * k)),k,1,40). The bug doesn't seem to be just a case of subtractive cancellation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 10:23:42

Bugs item #1954846, was opened at 20080430 10:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Raymond Toy (rtoy) Date: 20080620 15:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 15:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 15:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 14:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 10:10:11

Bugs item #1954846, was opened at 20080430 10:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Raymond Toy (rtoy) Date: 20080620 15:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 14:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 09:45:24

Bugs item #1954846, was opened at 20080430 10:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Raymond Toy (rtoy) Date: 20080620 15:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 15:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 14:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 09:01:55

Bugs item #1995595, was opened at 20080616 17:27 Message generated for change (Comment added) made by robert_dodier 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: Closed >Resolution: Fixed 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.  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 13:52 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.25 src/nset.lisp, r1.40 src/clmacs.lisp (move macro DOMERGEASYM from nset to clmacs). Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995595&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 09:00:19

Bugs item #1927346, was opened at 20080327 12:31 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1927346&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed Resolution: Duplicate Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(2) ./ 2 vs 1/sqrt(2) Initial Comment: It's not wrong, but it's not right either: (%i3) integrate(sin(t),t,%pi/4,3*%pi/4); (%o3) sqrt(2)/2+1/sqrt(2)  >Comment By: Robert Dodier (robert_dodier) Date: 20080621 18:48 Message: Logged In: YES user_id=501686 Originator: NO Closing this report  was marked a duplicate before but not closed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1927346&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 08:47:29

Bugs item #1891216, was opened at 20080211 08:38 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891216&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Assume Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is(if a>0 and a>0 and a>0 ...) => internal error Initial Comment: is(if a>0 and a>0 then 1) => unknown (OK) is(if a>0 and a>0 and a>0 then 1) => Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ((MGREATERP $A (0 DATA (((MGRP ... Same for is(if a>0 and a>0 and a>0 then true else false) i.e. it is not because the return value is a nonboolean Maxima 5.13.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891216&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 08:36:41

Bugs item #1891911, was opened at 20080212 06:03 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891911&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Assume Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(f(a+b+c)) > Lisp error Initial Comment: OK: (%i1) is(f(a)); (%o1) unknown OK: (%i2) is(f(a+b)); (%o2) unknown Not OK (%i3) is(f(a+b+c)); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ($A $B $C) (%i4) build_info();Maxima version: 5.14.0Maxima build date: 21:46 12/27/2007host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8  Comment By: Barton Willis (willisbl) Date: 20080214 06:01 Message: Logged In: YES user_id=895922 Originator: YES This might help find the bug: OK (%i1) notequal((a*z)/10,0)$ (%i2) maybe(%); (%o2) unknown Not OK (%i3) unk((a*z)/10,0)$ (%i4) maybe(%); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bad plist ((RAT  Comment By: Barton Willis (willisbl) Date: 20080212 06:11 Message: Logged In: YES user_id=895922 Originator: YES See also SF bug 1726550 "not bugs." These bugs might be the same.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1891911&group_id=4933 
From: SourceForge.net <noreply@so...>  20080622 08:23:17

Bugs item #1916517, was opened at 20080317 03:40 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1916517&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: (F=0 and G=0) and (F=0 and FG=0) have different solutions. Initial Comment: Dear Developers of Maxima, I met a set of two albebraic equations F = 0 and G = 0 of two variables x and y such that (i) solve([F=0,G=0],[x,y]) returns no solution [] (this is wrong), whereas (ii) solve([F=0,FG=0],[x,y]) returns true solutions. This is strange, since the first set of equations F=0 and G=0 should have the same solutions of the second set of equations F=0 and FG=0. (1) The Maxima program to solve F=0 and FG=0 is  /* * solve_system_of_algebraic_equations_OK.maxima: * * F is a polynomial of x and y, which is degree 3 in x and 2 in y. * G is a polynomial of x and y, which is degree 3 in x and 2 in y. * * solve() and algsys() can solve the system equations F=0 and FG=0. */ display2d:false; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; solutions:solve([F=0,FG=0],[x,y]); /* OK: solutions are found. */  The result is  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(solve_system_of_algebraic_equations_OK.maxima) batching #p/Volumes/HFS+2/home/adachi/work/285/solve_system_of_algebraic_equations_OK.maxima (%i2) display2d : false (%o2) false (%i3) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o3) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i4) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o4) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i5) solutions:solve([F = 0,FG = 0],[x,y]) (%o5) [[x = (sqrt(a)*(a^24*a)+sqrt(a4)*(2*aa^2))/(2*sqrt(a4)), y = 1/(a*sqrt(a^24*a))], [x = (sqrt(a4)*(a^22*a)+sqrt(a)*(a^24*a))/(2*sqrt(a4)), y = 1/(a*sqrt(a^24*a))]] (%o6) "solve_system_of_algebraic_equations_OK.maxima"  =============================================================================== (2) The Maxima program to solve F=0 and G=0 is  /* * solve_system_of_algebraic_equations_NG.maxima: * * F is a polynomial of x and y, which is degree 3 in x and 2 in y. * G is a polynomial of x and y, which is degree 3 in x and 2 in y. * * solve() and algsys() can NOT solve the system equations F=0 and G=0. */ display2d:false; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; solutions:solve([F=0,G=0],[x,y]); /* NG: solutions are NOT found! */  The result is  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(solve_system_of_algebraic_equations_NG.maxima) batching #p/Volumes/HFS+2/home/adachi/work/285/solve_system_of_algebraic_equations_NG.maxima (%i2) display2d : false (%o2) false (%i3) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o3) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i4) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o4) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i5) solutions:solve([F = 0,G = 0],[x,y]) (%o5) [] (%o6) "solve_system_of_algebraic_equations_NG.maxima"  =============================================================================== (3) I also tried algebraic:true to solve F=0 and G=0. The program is  /* * solve_system_of_algebraic_equations_with_algebraic_NG.maxima: * * F is a polynomial of x and y, which is degree 3 in x and 2 in y. * G is a polynomial of x and y, which is degree 3 in x and 2 in y. * * solve() and algsys() can NOT solve the system equations F=0 and G=0. */ display2d:false; algebraic:true; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; solutions:solve([F=0,G=0],[x,y]); /* NG: internal error! */  The result is further strange for me as  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(solve_system_of_algebraic_equations_with_algebraic.maxima) batching #p/Volumes/HFS+2/home/adachi/work/285/solve_system_of_algebraic_equations_with_algebraic.maxima (%i2) display2d : false (%o2) false (%i3) algebraic:true (%o3) true (%i4) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o4) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i5) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o5) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i6) solutions:solve([F = 0,G = 0],[x,y]) Polynomial quotient is not exact  an error. To debug this try debugmode(true);  Sincerely yours, Satoshi Adachi  Comment By: Satoshi Adachi (satoshi_adachi) Date: 20080411 01:01 Message: Logged In: YES user_id=1953419 Originator: YES Dear Mr.Barton Willis (willisbl), Thank you very much for educating me to know how the decifiancy of algsys() that was described in my previous bug report can be overcome. Your information is very helpful! At first, I am sorry to be late in writing this letter of thanks. I had been occupied by duty works until yesterday. Today, I wrote a wrapper routine of algsys(), which is based fully on your suggestion and is named algsys_willisbl(), as follows:  /* * algsys_willisbl.maxima: * * better algsys() suggested by willisbl. * * [Remark] To use algsys_willisbl(), the following preparation is necessary: * * load("topoly"); // for elim() * algebraic:true; * * S.Adachi 2008/04/10 */ algsys_willisbl(eqns_lst, vars_lst) := block([eqns1_lst,eqns2_lst,sols_cand_lst,sols_lst], eqns1_lst:map(lambda([e], if (not atom(e) and operatorp(e,"=")) then lhs(e)rhs(e) else e), eqns_lst), eqns2_lst:first(rest(elim(eqns1_lst, vars_lst))), sols_cand_lst:algsys(eqns2_lst, vars_lst), sols_lst:listify(subset(setify(sols_cand_lst), lambda([sc], every(lambda([a], is(equal(a,0))), ratsimp(subst(sc, eqns1_lst)))))), sols_lst); /* END */  I also wrote a test program for algsys_willisbl() by using the same system of algebraic equations that was described in my previous bug report of algsys() as  /* * test_algsys_willisbl.maxima: * * test algsys_willisbl() by applying it to a system of two algebraic * equations F=0 and G=0, which cannot be solved by algsys(). * * S.Adachi 2008/04/10 */ load(topoly); load("algsys_willisbl.maxima"); algebraic:true; display2d:false; F:2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1; G:x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1; sols1:algsys_willisbl([F,G], [x,y]); sols2:algsys_willisbl([F=0,G=0], [x,y]); sols3:algsys_willisbl([F+1=1,G+2=2], [x,y]); /* END */  The result of executation is as follows:  [Macintosh:~/work/288:1] adachi% maxima b test_algsys_willisbl.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(test_algsys_willisbl.maxima) batching #p/Volumes/HFS+2/home/adachi/work/288/test_algsys_willisbl.maxima (%i2) load(topoly) (%o2) /usr/local/share/maxima/5.14.0cvs/share/contrib/topoly.lisp (%i3) load(algsys_willisbl.maxima) (%o3) algsys_willisbl.maxima (%i4) algebraic : true (%o4) true (%i5) display2d : false (%o5) false (%i6) F:1+x+2*a*x*y+3*x^2*y+2*a*x^2*y^2+2*x^3*y^2 (%o6) 2*x^3*y^2+2*a*x^2*y^2+3*x^2*y+2*a*x*y+x+1 (%i7) G:1+a^2*y+2*a*x*y+x^2*y+a^2*x*y^2+2*a*x^2*y^2+x^3*y^2 (%o7) x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1 (%i8) sols1:algsys_willisbl([F,G],[x,y]) (%o8) [[x = (a*sqrt(a^24*a)a^2+2*a)/2,y = sqrt(a^24*a)/(a^34*a^2)], [x = (a*sqrt(a^24*a)+a^22*a)/2,y = sqrt(a^24*a)/(a^34*a^2)]] (%i9) sols2:algsys_willisbl([F = 0,G = 0],[x,y]) (%o9) [[x = (a*sqrt(a^24*a)a^2+2*a)/2,y = sqrt(a^24*a)/(a^34*a^2)], [x = (a*sqrt(a^24*a)+a^22*a)/2,y = sqrt(a^24*a)/(a^34*a^2)]] (%i10) sols3:algsys_willisbl([1+F = 1,2+G = 2],[x,y]) (%o10) [[x = (a*sqrt(a^24*a)a^2+2*a)/2,y = sqrt(a^24*a)/(a^34*a^2)], [x = (a*sqrt(a^24*a)+a^22*a)/2,y = sqrt(a^24*a)/(a^34*a^2)]] (%o11) "test_algsys_willisbl.maxima" [Macintosh:~/work/288:2] adachi%  I did not apply algsys_willisbl() to any other examples, yet. So, it may have still bugs. Anyway, I become now able to advance my study again without the annoyance caused by algsys(). The knowledge that you gave me is very essential to use algsys() in a better way. Thank you very much. Sincerely yours, Satoshi Adachi  Comment By: Barton Willis (willisbl) Date: 20080317 06:05 Message: Logged In: YES user_id=895922 Originator: NO Thanks for reporting this bug. The function algsys isn't nearly as good as we would like. The best I can offer is my favorite workaround (that might work); it's something like: (%i92) load(topoly)$ (%i93) algebraic : true$ Use 'elim' to triangularize the equationsthis can create spurious solutions: (%i94) elim([F,G],[x,y]); (%o94) [[],[x^4+a^2*x^3a*x^3+a^3*x^2a^2*x^2+a^3*x,x^3*y^2+2*a*x^2*y^2+a^2*x*y^2+x^2*y+2*a*x*y+a^2*y+1]] Use algsys to solve these equations: (%i95) sol : algsys(first(rest(%)),[x,y])$ Try to reject the spurious solutions: (%i96) true_sol : set()$ (%i97) for si in sol do if every(lambda([a], is(equal(a,0))), ratsimp(subst(si,[F,G]))) then true_sol : adjoin(si, true_sol); (%o97) done (%i98) true_sol; (%o98) {[x=(a*sqrt(a^24*a)a^2+2*a)/2,y=sqrt(a^24*a)/(a^34*a^2)], [x=(a*sqrt(a^24*a)+a^22*a)/2,y=sqrt(a^24*a)/(a^34*a^2)]} Two solutions *might* be spurious and two checked out OK. You'll need to inspect the two rejected solutions to see if they are really spurious. And a = 0 and a = 4 might be special cases that need to be checked. Of course, all this should be automatic; unfortunately, algsys isn't there yet. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1916517&group_id=4933 
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 