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}
(10) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(1) 
2
(2) 
3
(3) 
4

5
(5) 
6
(1) 
7
(3) 
8
(1) 
9

10
(3) 
11
(5) 
12
(3) 
13

14

15
(5) 
16
(1) 
17
(1) 
18
(7) 
19
(1) 
20
(3) 
21

22

23

24

25

26

27
(3) 
28
(3) 
29
(1) 
30
(5) 






From: SourceForge.net <noreply@so...>  20031130 22:59:25

Bugs item #851765, was opened at 20031130 17:59 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=851765&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sum mishandles assume scopes Initial Comment: assume(i>=a); [i >= a] facts(); [i >= a] so far, so good sum(i,i,a,b)$ facts() [] oops! It removed the assumption is(i>=a) MACSYMA was unable to evaluate the predicate: i >= a The problem is that dosum adds the assumption a<=i<=b, and then removes it when it's done. But it does this in the global database, not a local one. So it also removes any preexisting identical assumption. It also ignores any inconsistent assumptions: assume(a>i) sum(i,i,a,b) => no error message This is sort of defensible on the grounds that the inner 'i' really isn't the same variable as the global 'i' (as though Maxima understood that)... except that it *is* obeying the global assumptions: assume(i<0) sum(abs(i),i,1,a) => 'sum(i,i,1,a)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851765&group_id=4933 
From: SourceForge.net <noreply@so...>  20031130 20:18:08

Bugs item #851425, was opened at 20031129 21:50 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851425&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: error doesn't accept CRE args/FIX Initial Comment: error("Rat:",rat(x)) => fatal error The fix is simple. In errorsize, instead of ((or (null l)..., use ((or (atom l).... It would also be possible to specdisrep. Maxima 5.9.0 gcl 2.5.0 W2k  >Comment By: Barton Willis (willisbl) Date: 20031130 14:18 Message: Logged In: YES user_id=895922 When this bug is fixed, also close bug 588702; these bugs are the same. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851425&group_id=4933 
From: SourceForge.net <noreply@so...>  20031130 04:53:46

Bugs item #851436, was opened at 20031129 23:53 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=851436&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is/equal fails with varying vrbl ordering Initial Comment: is(equal(rat((x+y+a)^3,x),rat((x+y+a)^3,y))) is "unable to evaluate the predicate". This is really annoying. Equal should at least check whether ratsimp(ab)=0. It is also annoying that equal disreps rat expressions for no good reason. Unfortunately, you can't simply add $equal to (mlist mequal) in simpargs because meqp gets confused. But something like that would be good when someone has the time to test thoroughly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851436&group_id=4933 
From: SourceForge.net <noreply@so...>  20031130 04:38:31

Bugs item #851433, was opened at 20031129 23:38 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=851433&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: f+ has incompatible definitions Initial Comment: clmacs defines f+ as nary fixnum addition macro: (defop f+ fixnum +) and it is used in many places that way. But plot.lisp and toddcoxeter.lisp define it as binary expr: plot.lisp: (defbinop f+ + fixnum) toddcoxeter.lisp: (defmacro f+ (a b)...) The binary definition has overridden the nary definition in the built system, so any loads of source code that depend on nary f+ will run into problems. Clearly there needs to be more discipline here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851433&group_id=4933 
From: SourceForge.net <noreply@so...>  20031130 03:51:06

Bugs item #851425, was opened at 20031129 22:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851425&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: error doesn't accept CRE args/FIX Initial Comment: error("Rat:",rat(x)) => fatal error The fix is simple. In errorsize, instead of ((or (null l)..., use ((or (atom l).... It would also be possible to specdisrep. Maxima 5.9.0 gcl 2.5.0 W2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=851425&group_id=4933 
From: SourceForge.net <noreply@so...>  20031129 18:35:18

Bugs item #834729, was opened at 20031102 14: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=834729&group_id=4933 Category: None Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Peter Ulrich Kruppa (pukruppa) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d() produces bad postscript Initial Comment: A statement like (C4) plot2d(x^2,[x,5,5],[PLOT_FORMAT,PS]); should produce a printable postscript file. But maxout.ps simply contains a list of numbers. Please mind: plot3d() works allright. Regards, Uli Kruppa.  Comment By: Robert Dodier (robert_dodier) Date: 20031129 11:35 Message: Logged In: YES user_id=501686 I've rebuilt Maxima using current cvs (as of 20031128). Lisp is clisp 2.31. Now if the line "(or ...)" is commented out, plot2d(x^3,[x,0.5,1.5],[plot_format,ps]); doesn't generate an error, but it just hangs (no postscript output, no ghostview display, no tcl/tk display) until I press ctrlC. The patched version of plot.lisp with the newly rebuilt Maxima yields the expected results with [plot_format, ps], and also with no plot_format specified (shows tcl/tk display), and [plot_format, gnuplot] (executes gnuplot although gnuplot output file appears to be incorrect for the version of gnuplot that is installed), and [plot_format, openmath] (creates output file in openmath format).  Comment By: Robert Dodier (robert_dodier) Date: 20031128 14:52 Message: Logged In: YES user_id=501686 I have found that the following patch will make plot2d(foo,[x,bar,baz],[plot_format,ps]) work the same as plot2d_ps(foo,[x,bar,baz])  I hope that's the intended behavior. The line numbers for plot.lisp are for revision 1.18, tagged 5.9.0 in CVS. There are newer revisions of plot.lisp, however, the newest one (1.32) has the same code for plot2d_ps and the first part of plot2d (modified here).  /usr/share/maxima/5.9.0/src/plot.lisp Sun Feb 9 20:24:27 2003 +++ just_plot2d.lisp Fri Nov 28 14:10:30 2003 @@ 730,3 +4,3 @@ (dolist (v options) ($set_plot_option v))  (or ($listp fun ) (setf fun `((mlist) ,fun))) + ;; (or ($listp fun ) (setf fun `((mlist) ,fun))) (cond ((eq (cadr fun) '$parametric) @@ 734,2 +8,4 @@ (setf fun `((mlist) ,fun)))) + (cond ((eq ($get_plot_option '$PLOT_FORMAT 2) '$ps) + (returnfrom $plot2d (apply '$plot2d_ps fun range options)))) (cond ((eq ($get_plot_option '$PLOT_FORMAT 2) '$openmath) The modified code seems to work correctly with "(or ($listp fun ) (setf fun `((mlist) ,fun)))" commented out, however, I don't understand the function of that line & therefore better understanding is needed. Note that if "(or ($listp ....))" is not commented out, the following error occurs when I attempt to execute plot2d(x^3,[x,0.5,1.5],[plot_format,ps]):  begin debugger output  ***  argument to COMMONLISP:FLOAT should be a real number: ((MLIST SIMP) 0.125) The following restarts are available: R1 = Macsyma toplevel 1. Break [1]> :w EVAL frame for form (COMMONLISP:FLOAT ($REALPART (MEVAL* '((MLIST) ((MEXPT SIMP) $x 3)))) 1.0) 1. Break [1]> :bl Enter the limit for max. frames to print or ':all' for all: 3 EVAL frame for form (COMMONLISP:FLOAT ($REALPART (MEVAL* '((MLIST) ((MEXPT SIMP) $x 3)))) 1.0) APPLY frame for call (:LAMBDA '0.5) EVAL frame for form (APPLY '$PLOT2D_PS FUN RANGE OPTIONS)  end debugger output  It appears to be attempting to evaluate (0.5)^3, and failing.  Comment By: Robert Dodier (robert_dodier) Date: 20031127 11:16 Message: Logged In: YES user_id=501686 The file plot.lisp contains the function plot2d_ps, which appears to work as intended (as described by describe(plot2d_ps))  plot2d_ps invokes gv to show the figure, and creates a PS file, maxout.ps. However, plot2d does not call plot2d_ps. Perhaps one can fix plot2d by having it call plot2d_ps, but the obvious way to do that (copying the 2 lines for the openmath function) yields a runtime error about longfloat types. So the fix must have to be less naive. I'll try something else.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834729&group_id=4933 
From: SourceForge.net <noreply@so...>  20031128 21:52:55

Bugs item #834729, was opened at 20031102 14: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=834729&group_id=4933 Category: None Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Peter Ulrich Kruppa (pukruppa) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d() produces bad postscript Initial Comment: A statement like (C4) plot2d(x^2,[x,5,5],[PLOT_FORMAT,PS]); should produce a printable postscript file. But maxout.ps simply contains a list of numbers. Please mind: plot3d() works allright. Regards, Uli Kruppa.  Comment By: Robert Dodier (robert_dodier) Date: 20031128 14:52 Message: Logged In: YES user_id=501686 I have found that the following patch will make plot2d(foo,[x,bar,baz],[plot_format,ps]) work the same as plot2d_ps(foo,[x,bar,baz])  I hope that's the intended behavior. The line numbers for plot.lisp are for revision 1.18, tagged 5.9.0 in CVS. There are newer revisions of plot.lisp, however, the newest one (1.32) has the same code for plot2d_ps and the first part of plot2d (modified here).  /usr/share/maxima/5.9.0/src/plot.lisp Sun Feb 9 20:24:27 2003 +++ just_plot2d.lisp Fri Nov 28 14:10:30 2003 @@ 730,3 +4,3 @@ (dolist (v options) ($set_plot_option v))  (or ($listp fun ) (setf fun `((mlist) ,fun))) + ;; (or ($listp fun ) (setf fun `((mlist) ,fun))) (cond ((eq (cadr fun) '$parametric) @@ 734,2 +8,4 @@ (setf fun `((mlist) ,fun)))) + (cond ((eq ($get_plot_option '$PLOT_FORMAT 2) '$ps) + (returnfrom $plot2d (apply '$plot2d_ps fun range options)))) (cond ((eq ($get_plot_option '$PLOT_FORMAT 2) '$openmath) The modified code seems to work correctly with "(or ($listp fun ) (setf fun `((mlist) ,fun)))" commented out, however, I don't understand the function of that line & therefore better understanding is needed. Note that if "(or ($listp ....))" is not commented out, the following error occurs when I attempt to execute plot2d(x^3,[x,0.5,1.5],[plot_format,ps]):  begin debugger output  ***  argument to COMMONLISP:FLOAT should be a real number: ((MLIST SIMP) 0.125) The following restarts are available: R1 = Macsyma toplevel 1. Break [1]> :w EVAL frame for form (COMMONLISP:FLOAT ($REALPART (MEVAL* '((MLIST) ((MEXPT SIMP) $x 3)))) 1.0) 1. Break [1]> :bl Enter the limit for max. frames to print or ':all' for all: 3 EVAL frame for form (COMMONLISP:FLOAT ($REALPART (MEVAL* '((MLIST) ((MEXPT SIMP) $x 3)))) 1.0) APPLY frame for call (:LAMBDA '0.5) EVAL frame for form (APPLY '$PLOT2D_PS FUN RANGE OPTIONS)  end debugger output  It appears to be attempting to evaluate (0.5)^3, and failing.  Comment By: Robert Dodier (robert_dodier) Date: 20031127 11:16 Message: Logged In: YES user_id=501686 The file plot.lisp contains the function plot2d_ps, which appears to work as intended (as described by describe(plot2d_ps))  plot2d_ps invokes gv to show the figure, and creates a PS file, maxout.ps. However, plot2d does not call plot2d_ps. Perhaps one can fix plot2d by having it call plot2d_ps, but the obvious way to do that (copying the 2 lines for the openmath function) yields a runtime error about longfloat types. So the fix must have to be less naive. I'll try something else.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834729&group_id=4933 
From: SourceForge.net <noreply@so...>  20031128 20:30:19

Bugs item #850884, was opened at 20031128 15:30 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=850884&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: algsys fails in simple case Initial Comment: eqs: [ v^2  2*v + u^2 + 10*u + 1, v^2  10*v + u^2 + 2*u + 1 ] solve(eqs,[u,v]) => [] But in fact eqs is solvable: eqs1: [ eqs[1], eqs[1]eqs[2] ]; solve(eqs1, [u,v]) => [[u = (sqrt(34) + 6) / 2, v = (sqrt(2)*sqrt(17) + 6) / 2], [u = (sqrt(34)  6) / 2, v = (sqrt(2)*sqrt(17)  6) / 2]] That solution is correct, as you can verify with subst followed by radcan. For that matter, eliminate also works. Maxima 5.9.0/W2k tested with both gcd:subres and gcd:spmod Found starting with a problem report submitted by Kirk Lancaster (27 Nov 2003).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=850884&group_id=4933 
From: SourceForge.net <noreply@so...>  20031128 15:54:19

Bugs item #694179, was opened at 20030226 22:08 Message generated for change (Comment added) made by nissplus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=694179&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 7 Submitted By: Andreas J Guelzow (aguelzow) Assigned to: Nobody/Anonymous (nobody) Summary: Plot menu nonfunctional under sawfish, metacity & Xfce Initial Comment: It appears that under the window managers sawfish, metacity (Gnome 2) & Xfce the menu associated with plots is nonfunctional. The menu appears and disappears upon a click on an item but the required action, eg. configuration, zoom, etc, is _not_ performed. It appears that under KDE, WindowMaker, AfterStep, IceWM, Enlightement, BlackBox and FVWM 2 the menu works fine.  Comment By: Gregory Frascadore (nissplus) Date: 20031128 08:54 Message: Logged In: YES user_id=306040 I saw the same problem with the plot menu under Mac OSX 10.2 using quartzwm and Mac X11 beta. When I tested with twm, the problem went away. Things also work fine under Mac OSX 10.3 (panther) running the release Mac X11. I was able to reproduce the same abnormal behavior with a simple tcl/tk script (tcl/tk 8.4, Fink binary distribution tcltk 8.4.11) so I don't think this is solely an xmaxima problem.  Comment By: Raymond Toy (rtoy) Date: 20030310 16:47 Message: Logged In: YES user_id=28849 FWIW, I have no problems with the openplot plot menus with Sawfish and GNOME on either Solaris 7/8 or RH 7.1. Both have standard GNOME installations.  Comment By: Andreas J Guelzow (aguelzow) Date: 20030310 09:42 Message: Logged In: YES user_id=82168 Since this bug makes maxima unusable under a standard gnome installation, I have raised the priority to `7'.  Comment By: Andreas J Guelzow (aguelzow) Date: 20030310 09:39 Message: Logged In: YES user_id=82168 This is not an xmaxima but apparently a core maxima problem: it also affects the plot windows created from within a terminal invocation of maxima. This bug makes the maxima emacs mode unusable: Plotting a function within emacs brings up the plot window. Closing that window via the window manager hangs emacs, dismissing the window from the context menu is impossible since the context menu is nonfunctional.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=694179&group_id=4933 
From: SourceForge.net <noreply@so...>  20031127 18:16:41

Bugs item #834729, was opened at 20031102 14: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=834729&group_id=4933 Category: None Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Peter Ulrich Kruppa (pukruppa) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d() produces bad postscript Initial Comment: A statement like (C4) plot2d(x^2,[x,5,5],[PLOT_FORMAT,PS]); should produce a printable postscript file. But maxout.ps simply contains a list of numbers. Please mind: plot3d() works allright. Regards, Uli Kruppa.  Comment By: Robert Dodier (robert_dodier) Date: 20031127 11:16 Message: Logged In: YES user_id=501686 The file plot.lisp contains the function plot2d_ps, which appears to work as intended (as described by describe(plot2d_ps))  plot2d_ps invokes gv to show the figure, and creates a PS file, maxout.ps. However, plot2d does not call plot2d_ps. Perhaps one can fix plot2d by having it call plot2d_ps, but the obvious way to do that (copying the 2 lines for the openmath function) yields a runtime error about longfloat types. So the fix must have to be less naive. I'll try something else.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834729&group_id=4933 
From: SourceForge.net <noreply@so...>  20031127 16:59:01

Bugs item #850343, was opened at 20031127 09:58 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=850343&group_id=4933 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Reorganize & clarify description of ev Initial Comment: The ev function is important and widely used, and its description is informative, but the description could be clearer. I suggest that the description be reorganized for greater clarity and comprehensibility. See also bug report #850334  add something about ev(exp, nouns) to the ev description.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=850343&group_id=4933 
From: SourceForge.net <noreply@so...>  20031127 16:44:27

Bugs item #850334, was opened at 20031127 09:44 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=850334&group_id=4933 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: Mention ev(foobar, nouns) in integrate & changevar descript Initial Comment: Noun forms in an expression foobar can be evaluated by ev(foobar, nouns). This is mentioned by describe(nouns) and describe(apply_nouns), although not by describe(ev). I suggest (1) that the description of ev include a mention of ev(foobar, nouns). Since nounform integrals are a common example of noun forms that someone may want to evaluate, I also suggest that the descriptions of (2) integrate and (3) changevar also mention ev(foobar, nouns). Since changevar is often used to convert an integral into a form that is (hopefully) easier to integrate, it seems especially useful to tell how to attempt to evaluate the noun form returned by changevar. Finally I also suggest (4) that we strike the description of apply_nouns, since there is no implementation of it. See also bug report #711539. There may be other contexts in which ev(foobar, nouns) is useful but I haven't looked for them. Stavros Macrakis also suggests (email to mailing list, 25 Nov 2003) that there be documentation specifically on the theme of nouns and verbs. That seems like a larger project, so I'll leave that out of this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=850334&group_id=4933 
From: SourceForge.net <noreply@so...>  20031120 20:58:49

Bugs item #846112, was opened at 20031120 14:58 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=846112&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: scsimp(x,x) / FIX Initial Comment: Consider (C1) scsimp(x+1,x5=0); (D1) 6 Given no rhs, Maxima defaults it to 0 (C2) scsimp(x+1,x5); (D2) 6 The default doesn't work with an atom; this is okay (C3) scsimp(x+1,x=0); (D3) 1 but why an error for this case? (C4) scsimp(x+1,x); Error: $x is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>> Here is a possible fix (DEFMFUN $SCSIMP N (DO ((I N (f1 I)) (ZRS)) ((= 1 I) (SCS (ARG 1) ZRS)) (setq zrs (cons (meqhk (arg i)) zrs)))) With this definition for scsimp, (C7) scsimp(x+1,x); (D7) 1 (C8) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=846112&group_id=4933 
From: SourceForge.net <noreply@so...>  20031120 20:02:45

Bugs item #846078, was opened at 20031120 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=846078&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: facout(a,b) / FIX Initial Comment: facout gives an error when the second argument is an atom (C1) facout(a,b); Error: $b is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>> A fix is (defmfun $facout (x y) (ifn (eq 'mplus (and (consp y) (mop y))) y (mul x (addn (mapcar #'(lambda (l) (div l x)) (cdr y)) t)))) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=846078&group_id=4933 
From: SourceForge.net <noreply@so...>  20031120 02:17:16

Bugs item #842863, was opened at 20031115 21:10 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: qq.lisp is broken (numerical integration) Initial Comment: (C1) load("qq.lisp"); Load failed for C:/maxima/Maxima/share/maxima/5.9.0/share/numeric/qq .lisp  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C2) 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 Barton  >Comment By: Wolfgang Jenkner (wjenkner) Date: 20031120 03:16 Message: Logged In: YES user_id=581700 SBCL was quite right in not accepting the type declaration. Binding something to NIL and then declaring it a FIXNUM is not a good idea. Anyway, fixed.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031118 18:41 Message: Logged In: YES user_id=581700 ad 1) Thanks :) I have added a TRANSLATE property for $QUANC8 (see the URLs in the previous message below). So the last example in the demo (concerning the function p) really shows a speed difference between the interpreted and the translated version as intended, at least for CLISP and SBCL (I haven't tested it with GCL). For SBCL the difference seems quite impressive, actually. This also requires a small patch to numer.lisp (see below) ad 2) I still don't know why SBCL doesn't grok that type declaration. I'll recompile SBCL and see. It would also be a good thing to test the code with CMUCL. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: numer.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/numer.lisp,v retrieving revision 1.1.1.1 diff u r1.1.1.1 numer.lisp  numer.lisp 8 May 2000 06:09:41 0000 1.1.1.1 +++ numer.lisp 18 Nov 2003 17:06:15 0000 @@ 155,6 +155,8 @@ (OR LPROPS MPROPS) (OR MPROPS LPROPS)) (GETL F '(OPERATORS))))) + ((functionp f) + (list 'expr f)) ((consp f) ;(EQ (TYPEP F) 'LIST) (LIST (IF (MEMQ (CAR F) '(FUNCTION LAMBDA NAMEDLAMBDA)) 'EXPR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  Comment By: Barton Willis (willisbl) Date: 20031118 16:49 Message: Logged In: YES user_id=895922 1. Nice work. 2. The load(qq.lisp) bug was already reported (but not resolved) in bug 614631. I think we should commit the fix and close both bugs. Barton  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031118 01:38 Message: Logged In: YES user_id=581700 However, the double integral example in the demo won't work. This shows why $QUANC8 can't be a DEFUN... I rewrote it as (defmspec $quanc8 (form) (setq form (cdr form)) (if (cdddr form) (apply #'callquanc8 (meval `((lambda) ((mlist) ,(cadr form)) ,(car form))) (mapcar #'meval (cddr form))) (apply #'callquanc8 (mapcar #'meval form)))) All examples in the demo seem to work as expected (after lowercasing them). My current versions of the relevant files are http://members.inode.at/wjenkner/maxima/qq.lisp http://members.inode.at/wjenkner/maxima/qq.dem This works in CLISP. SBCL has some problem with the type declarations in QUANC8 (without them it works fine).  Comment By: Barton Willis (willisbl) Date: 20031117 21:42 Message: Logged In: YES user_id=895922 The change ;(DEFUN ($QUANC8 TRANSLATEDMMACRO) (F A B &OPTIONAL (C NIL CP)) ; (IF (NOT CP) ; `((CALLQUANC8) ,F ,A ,B) ; `((CALLQUANC8) ((LAMBDA) ((MLIST) ,A) ,F) ,B ,C))) (defun $quanc8 (f a b &optional (c nil cp)) (if (not cp) (callquanc8 f a b) (callquanc8 `((lambda) ((mlist) ,a) ,f) b c))) allows qq.lisp to load correctly. Here are a few simple tests (C1) load("c:/maximacvs/maxima/share/numeric/qq.lisp"); (D1) c:/maximacvs/maxima/share/numeric/qq.lisp (C2) QUANC8_ABSERR : 1.0e12; (D2) 1.0E12 (C3) quanc8('(1/x),x,1,2); (D3) 0.69314718056001 (C4) %log(2.0d0); (D4) 6.283862319378386E14 (C5) f(x) := block([], mode_declare(x,float), 1/x)$ (C6) compile(f)$ Compiling gazonk0.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=2, Speed=2 Finished compiling gazonk0.lsp. (C7) quanc8(f,1,2); (D7) 0.69314718056001 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 
From: SourceForge.net <noreply@so...>  20031119 14:49:00

Bugs item #835287, was opened at 20031103 14:54 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=835287&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: solve('diff(y,x),'diff(y,x)) fails Initial Comment: (C1) solve('diff(y,x),'diff(y,x)); Error: #:G21849 is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q This one is okay (C2)solve(x,x); (D2) [x = 0] (C3) 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 Barton  >Comment By: Barton Willis (willisbl) Date: 20031119 08:49 Message: Logged In: YES user_id=895922 This same bug appears with solve(x[1],x[1]). The error happens when the function easycases tries to caar an atom; for example (C1) trace(?easy\cases); (D1) [EASY CASES] (C2) solve(x[1],x[1]); 1 Enter ?EASY\CASES [G21847, G21847] Error: #:G21847 is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>> A fix is to check for an atom at the top of easycases; I don't think (car *exp) should ever be an atom, but I put in a check for that as well. Another thing: In easycases, I think ((EQ (CAAR *EXP) 'MEXP) should be ((EQ (CAAR *EXP) 'MEXPT)) Changing this allows equations of the form (exp)^positive integer to be solved sooner. (DEFUN EASYCASES (*EXP *VAR) (COND ((or (atom *exp) (atom (car *exp))) nil) ((EQ (CAAR *EXP) 'MTIMES) (DO ((TERMS (CDR *EXP) (CDR TERMS))) ((NULL TERMS)) (SOLVE (CAR TERMS) *VAR 1)) 'MTIMES) ((EQ (CAAR *EXP) 'MEXPT) (COND ((AND (INTEGERP (CADDR *EXP)) (PLUSP (CADDR *EXP))) (SOLVE (CADR *EXP) *VAR (CADDR *EXP)) 'MEXPRAT))))) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=835287&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 18:15:29

Bugs item #844584, was opened at 20031118 12:15 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=844584&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: E. Gonzalez (silversmith) Assigned to: Nobody/Anonymous (nobody) Summary: Entermatrix problem in Maxima(win).. Initial Comment: Anytime I try to use entermatrix(m,n); i.e. entermatrix(m,n); 4; 1; 2; 3; 4; I wind up having to enter the matrixtype and values for the matrix before receiving the query for them! Is this a problem with the scripting... Or is there a setting that I have not set correctly? Is there anyway to fix this... Thanks...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=844584&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 17:57:58

Bugs item #644764, was opened at 20021127 09:01 Message generated for change (Comment added) made by silversmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=644764&group_id=4933 Category: Xmaxima Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: entermatrix does not work in xmaxima Initial Comment: The command entermatrix(2,2); or with any other arguments causes xmaxima to freeze. If I resize the window it spits out an error message. entermaxima works fine in a terminal shell. Yadin.  Comment By: E. Gonzalez (silversmith) Date: 20031118 11:57 Message: Logged In: YES user_id=912133 I have had a similar problem with the windows version of Maxima and I have had to enter values blindly in order to enter a matrix... With the queries for such values being printed afterwords...  Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20021130 02:53 Message: Logged In: YES user_id=366498 The problem is that entergmatrix dialog lack end of lines on GCL. Try entermatrix in console with clisp and GCL and see the diffrence. In both cases emtermatrix works but with GCL all prompts mount in one line. It seems also that xmaxima requires one more additional EOL. So with xmaxima l clisp emtermatrix works but looks exactly as iwith GCL in console (all prompts in one line). Actually it works also with xmaxima l gcl if you enter all responces blindly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=644764&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 17:41:19

Bugs item #842863, was opened at 20031115 21:10 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: qq.lisp is broken (numerical integration) Initial Comment: (C1) load("qq.lisp"); Load failed for C:/maxima/Maxima/share/maxima/5.9.0/share/numeric/qq .lisp  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C2) 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 Barton  >Comment By: Wolfgang Jenkner (wjenkner) Date: 20031118 18:41 Message: Logged In: YES user_id=581700 ad 1) Thanks :) I have added a TRANSLATE property for $QUANC8 (see the URLs in the previous message below). So the last example in the demo (concerning the function p) really shows a speed difference between the interpreted and the translated version as intended, at least for CLISP and SBCL (I haven't tested it with GCL). For SBCL the difference seems quite impressive, actually. This also requires a small patch to numer.lisp (see below) ad 2) I still don't know why SBCL doesn't grok that type declaration. I'll recompile SBCL and see. It would also be a good thing to test the code with CMUCL. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: numer.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/numer.lisp,v retrieving revision 1.1.1.1 diff u r1.1.1.1 numer.lisp  numer.lisp 8 May 2000 06:09:41 0000 1.1.1.1 +++ numer.lisp 18 Nov 2003 17:06:15 0000 @@ 155,6 +155,8 @@ (OR LPROPS MPROPS) (OR MPROPS LPROPS)) (GETL F '(OPERATORS))))) + ((functionp f) + (list 'expr f)) ((consp f) ;(EQ (TYPEP F) 'LIST) (LIST (IF (MEMQ (CAR F) '(FUNCTION LAMBDA NAMEDLAMBDA)) 'EXPR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  Comment By: Barton Willis (willisbl) Date: 20031118 16:49 Message: Logged In: YES user_id=895922 1. Nice work. 2. The load(qq.lisp) bug was already reported (but not resolved) in bug 614631. I think we should commit the fix and close both bugs. Barton  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031118 01:38 Message: Logged In: YES user_id=581700 However, the double integral example in the demo won't work. This shows why $QUANC8 can't be a DEFUN... I rewrote it as (defmspec $quanc8 (form) (setq form (cdr form)) (if (cdddr form) (apply #'callquanc8 (meval `((lambda) ((mlist) ,(cadr form)) ,(car form))) (mapcar #'meval (cddr form))) (apply #'callquanc8 (mapcar #'meval form)))) All examples in the demo seem to work as expected (after lowercasing them). My current versions of the relevant files are http://members.inode.at/wjenkner/maxima/qq.lisp http://members.inode.at/wjenkner/maxima/qq.dem This works in CLISP. SBCL has some problem with the type declarations in QUANC8 (without them it works fine).  Comment By: Barton Willis (willisbl) Date: 20031117 21:42 Message: Logged In: YES user_id=895922 The change ;(DEFUN ($QUANC8 TRANSLATEDMMACRO) (F A B &OPTIONAL (C NIL CP)) ; (IF (NOT CP) ; `((CALLQUANC8) ,F ,A ,B) ; `((CALLQUANC8) ((LAMBDA) ((MLIST) ,A) ,F) ,B ,C))) (defun $quanc8 (f a b &optional (c nil cp)) (if (not cp) (callquanc8 f a b) (callquanc8 `((lambda) ((mlist) ,a) ,f) b c))) allows qq.lisp to load correctly. Here are a few simple tests (C1) load("c:/maximacvs/maxima/share/numeric/qq.lisp"); (D1) c:/maximacvs/maxima/share/numeric/qq.lisp (C2) QUANC8_ABSERR : 1.0e12; (D2) 1.0E12 (C3) quanc8('(1/x),x,1,2); (D3) 0.69314718056001 (C4) %log(2.0d0); (D4) 6.283862319378386E14 (C5) f(x) := block([], mode_declare(x,float), 1/x)$ (C6) compile(f)$ Compiling gazonk0.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=2, Speed=2 Finished compiling gazonk0.lsp. (C7) quanc8(f,1,2); (D7) 0.69314718056001 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 16:25:25

Bugs item #844521, was opened at 20031118 10:25 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=844521&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: differ.mac has many bugs Initial Comment: differ.mac solves finite difference equations; it has many bugs. And I can't find any user documentation for it either. Specifically It redefines the functions system and eigenvalues (C1) load("differ.mac"); Warning  you are redefining the MACSYMA function EIGENVALUES Warning  you are redefining the MACSYMA function SYSTEM (D1) C:/maxima/Maxima/share/maxima/5.9.0/share/algebra/diff er.mac (C2) display2d : false; (D2) FALSE It solves this one correctly (C3) difference(x[k+1] = x[k] / 5, x[k]); (D3) x[k] = x[0]/5^k But make the equation nonhomogeneous and the solution is wrong (C4) difference(x[k+1] = x[k] / 5 + 1, x[k]); (D4) x[k] = 0 <=== BOGUS I don't think differ.mac can solve nonconstant coefficient equations, but it doesn't check that the coefficients are constant (C5) difference(x[k+1] = k * x[k], x[k]); (D5) x[k] = x[0]*k^k <=== BOGUS It can't solve this degenerate equation (C6) difference(x[k+2] + 2 * x[k+1] + x[k], x[k]); Nonsquare matrix in inverse #0: SYSTEM(eqnlist=[x[k+1] = (x[k+2]+x[k])/2,x[k+1] = x[k+1]],varlist=[x[k+1],x[k]])(differ.mac line 91) #1: second_order_difference(eqn=x[k+1] = (x[k+2]+x [k])/2,var=x[k])(differ.mac line 73) #2: difference(eqn=x[k+2]+2*x[k+1]+x[k],var=x[k]) (differ.mac line 113)  an error. Quitting. To debug this try DEBUGMODE (TRUE);) But the nondegenerate equation is okay (C7) difference(x[k+2] + 8 * x[k+1] + x[k], x[k]); (D7) x[k] = (SQRT(15)4)^k*(SQRT(15)4)*((SQRT(15) + .... differ.mac doesn't check that the equation is linear and may give an incorrect solution when it is (C12) difference(x[k+1]  x[k]^2 + x[k] = 0,x[k]); (D12) x[k] = x[0]*(1)^k((1)^k1)*x[k]^2/2 <== BOGUS Bugs in differ.mac are far too easy to find. I haven't tried recur.mac; maybe it is somewhat better? Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=844521&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 15:57:18

Bugs item #776974, was opened at 20030724 09:35 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776974&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: translation of errcatch Initial Comment: Consider (C1) xdiv(a,b) := block([ret : errcatch(a / b)], if ret = [] then error("shame on you") else inpart (ret,1))$ (C2) xdiv(9,3); (D2) 3 (C3) xdiv(9,0); Division by 0 shame on you #0: xdiv(a=9,b=0) an error. Quitting. To debug this try DEBUGMODE (TRUE);) This is okay, but after translating xdiv, we have a problem (C4) translate(xdiv)$ (C5) xdiv(9,3); (D5) 3 After translation, we no longer get the error "shame on you"  only the Division by 0 error (C6) xdiv(9,0); Division by 0  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C7)  >Comment By: Barton Willis (willisbl) Date: 20031118 09:57 Message: Logged In: YES user_id=895922 The assignment ?errcatch : true eliminates the bug for this case (and maybe in general) (C1) f(x):=errcatch(1/x)$ (C2) f(0); Division by 0 (D2) [] (C3) translate(f); (D3) [f] (C4) f(0); Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C5) ?errcatch; (D5) FALSE Set ?errcatch to true and f(0) evaluates to [ ] as it should. (C6) ?errcatch : true; (D6) TRUE (C7) f(0); Division by 0 (D7) [] Barton  Comment By: Stavros Macrakis (macrakis) Date: 20030725 08:53 Message: Logged In: YES user_id=588346 Simpler example: f(x):=errcatch(1/x)$ f(1) => [1] OK f(0) => ...Division by zero message... [] OK translate(f)$ f(1) => [1] OK f(0) => ...Division by zero message... no return value (error return) On the other hand, the following works correctly: f(x):=(modedeclare(x,fixnum),errcatch(1/x))$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776974&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 15:49:33

Bugs item #842863, was opened at 20031115 14:10 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: qq.lisp is broken (numerical integration) Initial Comment: (C1) load("qq.lisp"); Load failed for C:/maxima/Maxima/share/maxima/5.9.0/share/numeric/qq .lisp  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C2) 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 Barton  >Comment By: Barton Willis (willisbl) Date: 20031118 09:49 Message: Logged In: YES user_id=895922 1. Nice work. 2. The load(qq.lisp) bug was already reported (but not resolved) in bug 614631. I think we should commit the fix and close both bugs. Barton  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031117 18:38 Message: Logged In: YES user_id=581700 However, the double integral example in the demo won't work. This shows why $QUANC8 can't be a DEFUN... I rewrote it as (defmspec $quanc8 (form) (setq form (cdr form)) (if (cdddr form) (apply #'callquanc8 (meval `((lambda) ((mlist) ,(cadr form)) ,(car form))) (mapcar #'meval (cddr form))) (apply #'callquanc8 (mapcar #'meval form)))) All examples in the demo seem to work as expected (after lowercasing them). My current versions of the relevant files are http://members.inode.at/wjenkner/maxima/qq.lisp http://members.inode.at/wjenkner/maxima/qq.dem This works in CLISP. SBCL has some problem with the type declarations in QUANC8 (without them it works fine).  Comment By: Barton Willis (willisbl) Date: 20031117 14:42 Message: Logged In: YES user_id=895922 The change ;(DEFUN ($QUANC8 TRANSLATEDMMACRO) (F A B &OPTIONAL (C NIL CP)) ; (IF (NOT CP) ; `((CALLQUANC8) ,F ,A ,B) ; `((CALLQUANC8) ((LAMBDA) ((MLIST) ,A) ,F) ,B ,C))) (defun $quanc8 (f a b &optional (c nil cp)) (if (not cp) (callquanc8 f a b) (callquanc8 `((lambda) ((mlist) ,a) ,f) b c))) allows qq.lisp to load correctly. Here are a few simple tests (C1) load("c:/maximacvs/maxima/share/numeric/qq.lisp"); (D1) c:/maximacvs/maxima/share/numeric/qq.lisp (C2) QUANC8_ABSERR : 1.0e12; (D2) 1.0E12 (C3) quanc8('(1/x),x,1,2); (D3) 0.69314718056001 (C4) %log(2.0d0); (D4) 6.283862319378386E14 (C5) f(x) := block([], mode_declare(x,float), 1/x)$ (C6) compile(f)$ Compiling gazonk0.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=2, Speed=2 Finished compiling gazonk0.lsp. (C7) quanc8(f,1,2); (D7) 0.69314718056001 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 
From: SourceForge.net <noreply@so...>  20031118 00:38:01

Bugs item #842863, was opened at 20031115 21:10 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: qq.lisp is broken (numerical integration) Initial Comment: (C1) load("qq.lisp"); Load failed for C:/maxima/Maxima/share/maxima/5.9.0/share/numeric/qq .lisp  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C2) 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 Barton  >Comment By: Wolfgang Jenkner (wjenkner) Date: 20031118 01:38 Message: Logged In: YES user_id=581700 However, the double integral example in the demo won't work. This shows why $QUANC8 can't be a DEFUN... I rewrote it as (defmspec $quanc8 (form) (setq form (cdr form)) (if (cdddr form) (apply #'callquanc8 (meval `((lambda) ((mlist) ,(cadr form)) ,(car form))) (mapcar #'meval (cddr form))) (apply #'callquanc8 (mapcar #'meval form)))) All examples in the demo seem to work as expected (after lowercasing them). My current versions of the relevant files are http://members.inode.at/wjenkner/maxima/qq.lisp http://members.inode.at/wjenkner/maxima/qq.dem This works in CLISP. SBCL has some problem with the type declarations in QUANC8 (without them it works fine).  Comment By: Barton Willis (willisbl) Date: 20031117 21:42 Message: Logged In: YES user_id=895922 The change ;(DEFUN ($QUANC8 TRANSLATEDMMACRO) (F A B &OPTIONAL (C NIL CP)) ; (IF (NOT CP) ; `((CALLQUANC8) ,F ,A ,B) ; `((CALLQUANC8) ((LAMBDA) ((MLIST) ,A) ,F) ,B ,C))) (defun $quanc8 (f a b &optional (c nil cp)) (if (not cp) (callquanc8 f a b) (callquanc8 `((lambda) ((mlist) ,a) ,f) b c))) allows qq.lisp to load correctly. Here are a few simple tests (C1) load("c:/maximacvs/maxima/share/numeric/qq.lisp"); (D1) c:/maximacvs/maxima/share/numeric/qq.lisp (C2) QUANC8_ABSERR : 1.0e12; (D2) 1.0E12 (C3) quanc8('(1/x),x,1,2); (D3) 0.69314718056001 (C4) %log(2.0d0); (D4) 6.283862319378386E14 (C5) f(x) := block([], mode_declare(x,float), 1/x)$ (C6) compile(f)$ Compiling gazonk0.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=2, Speed=2 Finished compiling gazonk0.lsp. (C7) quanc8(f,1,2); (D7) 0.69314718056001 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 
From: SourceForge.net <noreply@so...>  20031117 20:42:32

Bugs item #842863, was opened at 20031115 14:10 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: qq.lisp is broken (numerical integration) Initial Comment: (C1) load("qq.lisp"); Load failed for C:/maxima/Maxima/share/maxima/5.9.0/share/numeric/qq .lisp  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C2) 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 Barton  >Comment By: Barton Willis (willisbl) Date: 20031117 14:42 Message: Logged In: YES user_id=895922 The change ;(DEFUN ($QUANC8 TRANSLATEDMMACRO) (F A B &OPTIONAL (C NIL CP)) ; (IF (NOT CP) ; `((CALLQUANC8) ,F ,A ,B) ; `((CALLQUANC8) ((LAMBDA) ((MLIST) ,A) ,F) ,B ,C))) (defun $quanc8 (f a b &optional (c nil cp)) (if (not cp) (callquanc8 f a b) (callquanc8 `((lambda) ((mlist) ,a) ,f) b c))) allows qq.lisp to load correctly. Here are a few simple tests (C1) load("c:/maximacvs/maxima/share/numeric/qq.lisp"); (D1) c:/maximacvs/maxima/share/numeric/qq.lisp (C2) QUANC8_ABSERR : 1.0e12; (D2) 1.0E12 (C3) quanc8('(1/x),x,1,2); (D3) 0.69314718056001 (C4) %log(2.0d0); (D4) 6.283862319378386E14 (C5) f(x) := block([], mode_declare(x,float), 1/x)$ (C6) compile(f)$ Compiling gazonk0.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=2, Speed=2 Finished compiling gazonk0.lsp. (C7) quanc8(f,1,2); (D7) 0.69314718056001 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=842863&group_id=4933 
From: SourceForge.net <noreply@so...>  20031116 18:22:26

Bugs item #836773, was opened at 20031105 21:43 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ntrig is broken Initial Comment: (C4) load("ntrig.mac"); (D4) ?C\:\/maxima\/Maxima\/share\/maxima\/5\.9\.0 \/share\/trigonometry\/ntrig\.mac (C5) sin(6*%pi/5); (D5) (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) (C6) float(%); (D6) 0.58778525229247 (C7) sin(float(6*%pi/5)); (D7) 0.58778525229247 Barton  >Comment By: Wolfgang Jenkner (wjenkner) Date: 20031116 19:21 Message: Logged In: YES user_id=581700 What about combining the two approaches like this. define_variable (usin_list, block([e1 : (sqrt(5)1)/4, e2 : (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)), e3 : (sqrt(5)+1)/4, e4 : sqrt(sqrt(5)+5)/(2*sqrt(2))], [e1, e2, e3, e4, 1, e4, e3, e2, e1, 0]), any)$ usin(n):= /* MODE_DECLARE treats INTEGER like FIXNUM... */ (mode_declare(n,number), /* Note that this works because MOD is supposed to return an integer in [9, 10] here. Sadly, GCL misbehaves (see bug #706562). Normally, this doesn't matter, however: If the argument of SIN is an integer multiple of %pi/2 the usual simplification routines take care of it, so at this point N won't be a multiple of 5. */ if (n : mod(n, 20)) > 0 then usin_list[n] else usin_list[10+n])$ ucos(n):= usin(5n)$  Comment By: Barton Willis (willisbl) Date: 20031115 20:47 Message: Logged In: YES user_id=895922 I wrote testing code for ntrig; both proposed fixes pass all the tests. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20031110 23:07 Message: Logged In: YES user_id=588346 Please test the following replacement for ntrig. /* Some of these simplifications give results with radicals in the denominator. These could be presimplified here, but ratsimp(...),algebraic:true will also take care of it. */ eval_when([translate,batch,demo,load,loadfile], matchdeclare(n,integerp))$ tellsimpafter(sin(n*%pi/10),usin(n))$ tellsimpafter(cos(n*%pi/10),ucos(n))$ tellsimpafter(tan(n*%pi/10),usin(n)/ucos(n))$ tellsimpafter(cot(n*%pi/10),ucos(n)/usin(n))$ tellsimpafter(sec(n*%pi/10),1/ucos(n))$ tellsimpafter(csc(n*%pi/10),1/usin(n))$ usin_list: makelist( [ 0, (sqrt(5)1)/4, sqrt(2)*(sqrt(5)1)*sqrt(sqrt(5)+5)/8, (sqrt(5)+1)/4, sqrt(sqrt(5)+5)/(2*sqrt(2)), 1] [i], i,[1,2,3,4,5,6,5,4,3,2,1,2,3,4,5,6,5,4,3,2] ) /* In the pre11/2003 version, usin_list[3] was (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)). But the new version is better simplified, and simplifies just as well. */ $ usin(n):= (declare(n,integer), n : remainder(n,20), if n<0 then n:n+20, /* Workaround for bug in remainder */ (if n <= 10 then usin_list[n+1] /* 1origin indexing */ else usin_list[n+1]) )$ ucos(n):=usin(n+5)$  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031107 18:51 Message: Logged In: YES user_id=581700 Perhaps simply rewrite USIN(N):= BLOCK([YUK:mod(N,20)], signum(YUK)*(YUK:abs(mod(YUK,10)), IF YUK=1 THEN (SQRT(5)1)/4 ELSE IF YUK=2 THEN (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) ELSE IF YUK=3 THEN (SQRT(5)+1)/4 ELSE IF YUK=4 THEN SQRT(SQRT(5)+5)/(2*SQRT(2))))$ UCOS(N):= USIN(5N)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 