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}
(45) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1

2

3

4
(2) 
5

6

7
(1) 
8
(7) 
9

10

11

12

13

14

15

16
(1) 
17

18
(4) 
19
(1) 
20

21
(1) 
22

23

24
(2) 
25

26
(3) 
27
(1) 
28

29

30
(1) 
From: <noreply@so...>  20021130 08:53:50

Bugs item #644764, was opened at 20021127 15:01 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: Vadim V. Zhytnikov (vvzhy) Date: 20021130 08: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: <noreply@so...>  20021127 15:01:59

Bugs item #644764, was opened at 20021127 07:01 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.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=644764&group_id=4933 
From: <noreply@so...>  20021126 19:16:11

Bugs item #625278, was opened at 20021018 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum bug Initial Comment: Hi! Unfortunately I have found a bug in simpsum (it seems): (C1) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),simpsum; (D1) 3 ***************** wrong ********************** (C2) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),sum; (D2) 2 ***************** correct ******************** ***************** however : ****************** (C3) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),simpsum; (D3) x (C4) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),sum; (D4) x (C5) bug_report(); Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Martin  Comment By: Martin Rubey (kratt5) Date: 20021126 19:16 Message: Logged In: YES user_id=651552 sorry, below was a typo (a parenthesis didn't get deleted) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 19:04 Message: Logged In: YES user_id=651552 > Can you explain why there is a conditionalization > for #+cl there? I don't see any reason for this > code to depend on common lisp or not. My thought > on fixing the code previously displayed was to > just remove #cl > RJF Yes, I can explain it. It's there because I was very stupid. Here is the right fix: (and THANK YOU, I feel a little ashamed...) diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n) (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 13:49 Message: Logged In: YES user_id=651552 OK, I got the bug now: The fix is rather obvious (except that I had to dig through all of sum, see below) and the bug is rather serious (I can produce lots of everyday examples, (C1) sum(f(k)+1,k,1,n),simpsum; (D2) n so I propose to include it in 5.9.0 !!! I didn't change some things I would like to, I think this is for after 5.9.0... fix and explanation below Martin fix diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 930,939d923 < ; this is to deal with linearity Kratt5, 26.11.2002 < ((let (*a *n (var *var*)) < (cond ((prog2 (m2 e '((mtimes) ((coefftt) (var* (set) *a freevar)) < ((coefftt) (var* (set) *n true))) < nil) < (not (equal *a 1))) < ;; we have to return T, so that sum is exited if the test was successful < (prog2 (sum *n (list '(mtimes) y *a)) < T))))) < ;; 943,944c927 < #+cl (adusum (list '(mtimes) e y)) ;; Kratt5 26.11.2002 < ;; nil  > nil end fix I tested it with Maxima version: 5.9.0rc3 Maxima build date: 13:52 11/18/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 explanation  (lisp level) the structure of $sum is roughly as follows: $sum: argcheck, call dosum with meval'd bounds dosum: didn't look at this too much after this, meval calls simpsum **** if you type 'sum(f(k),k,1,n),simpsum; meval calls only simpsum **** $simpsum: call simpsum1 simpsum1: checks lo=hi, otherwise exp not depending on the summation index, otherwise if $simpsum, call simpsum2 **** simpsum2 is found in combin.lisp **** simpsum2: sets up a variable *plus, which will contain all the stuff which is added together at the end calls sumsum sumsum: returns the part of the expression it was able to sum up (this is the contents of the variable "usum"), all the rest (the contents of the variable "sum") is put into the variable *plus, which is then used by simpsum2 calls sum sum: adsum's and adusum's the sum of e. It's result is discarded. (at least I think that this function is only called by sumsum, but there are lots of places where a variable is called "sum"...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 
From: <noreply@so...>  20021126 19:04:43

Bugs item #625278, was opened at 20021018 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum bug Initial Comment: Hi! Unfortunately I have found a bug in simpsum (it seems): (C1) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),simpsum; (D1) 3 ***************** wrong ********************** (C2) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),sum; (D2) 2 ***************** correct ******************** ***************** however : ****************** (C3) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),simpsum; (D3) x (C4) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),sum; (D4) x (C5) bug_report(); Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Martin  Comment By: Martin Rubey (kratt5) Date: 20021126 19:04 Message: Logged In: YES user_id=651552 > Can you explain why there is a conditionalization > for #+cl there? I don't see any reason for this > code to depend on common lisp or not. My thought > on fixing the code previously displayed was to > just remove #cl > RJF Yes, I can explain it. It's there because I was very stupid. Here is the right fix: (and THANK YOU, I feel a little ashamed...) diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n) (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 13:49 Message: Logged In: YES user_id=651552 OK, I got the bug now: The fix is rather obvious (except that I had to dig through all of sum, see below) and the bug is rather serious (I can produce lots of everyday examples, (C1) sum(f(k)+1,k,1,n),simpsum; (D2) n so I propose to include it in 5.9.0 !!! I didn't change some things I would like to, I think this is for after 5.9.0... fix and explanation below Martin fix diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 930,939d923 < ; this is to deal with linearity Kratt5, 26.11.2002 < ((let (*a *n (var *var*)) < (cond ((prog2 (m2 e '((mtimes) ((coefftt) (var* (set) *a freevar)) < ((coefftt) (var* (set) *n true))) < nil) < (not (equal *a 1))) < ;; we have to return T, so that sum is exited if the test was successful < (prog2 (sum *n (list '(mtimes) y *a)) < T))))) < ;; 943,944c927 < #+cl (adusum (list '(mtimes) e y)) ;; Kratt5 26.11.2002 < ;; nil  > nil end fix I tested it with Maxima version: 5.9.0rc3 Maxima build date: 13:52 11/18/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 explanation  (lisp level) the structure of $sum is roughly as follows: $sum: argcheck, call dosum with meval'd bounds dosum: didn't look at this too much after this, meval calls simpsum **** if you type 'sum(f(k),k,1,n),simpsum; meval calls only simpsum **** $simpsum: call simpsum1 simpsum1: checks lo=hi, otherwise exp not depending on the summation index, otherwise if $simpsum, call simpsum2 **** simpsum2 is found in combin.lisp **** simpsum2: sets up a variable *plus, which will contain all the stuff which is added together at the end calls sumsum sumsum: returns the part of the expression it was able to sum up (this is the contents of the variable "usum"), all the rest (the contents of the variable "sum") is put into the variable *plus, which is then used by simpsum2 calls sum sum: adsum's and adusum's the sum of e. It's result is discarded. (at least I think that this function is only called by sumsum, but there are lots of places where a variable is called "sum"...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 
From: <noreply@so...>  20021126 13:49:23

Bugs item #625278, was opened at 20021018 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum bug Initial Comment: Hi! Unfortunately I have found a bug in simpsum (it seems): (C1) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),simpsum; (D1) 3 ***************** wrong ********************** (C2) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),sum; (D2) 2 ***************** correct ******************** ***************** however : ****************** (C3) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),simpsum; (D3) x (C4) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),sum; (D4) x (C5) bug_report(); Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Martin  Comment By: Martin Rubey (kratt5) Date: 20021126 13:49 Message: Logged In: YES user_id=651552 OK, I got the bug now: The fix is rather obvious (except that I had to dig through all of sum, see below) and the bug is rather serious (I can produce lots of everyday examples, (C1) sum(f(k)+1,k,1,n),simpsum; (D2) n so I propose to include it in 5.9.0 !!! I didn't change some things I would like to, I think this is for after 5.9.0... fix and explanation below Martin fix diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 930,939d923 < ; this is to deal with linearity Kratt5, 26.11.2002 < ((let (*a *n (var *var*)) < (cond ((prog2 (m2 e '((mtimes) ((coefftt) (var* (set) *a freevar)) < ((coefftt) (var* (set) *n true))) < nil) < (not (equal *a 1))) < ;; we have to return T, so that sum is exited if the test was successful < (prog2 (sum *n (list '(mtimes) y *a)) < T))))) < ;; 943,944c927 < #+cl (adusum (list '(mtimes) e y)) ;; Kratt5 26.11.2002 < ;; nil  > nil end fix I tested it with Maxima version: 5.9.0rc3 Maxima build date: 13:52 11/18/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 explanation  (lisp level) the structure of $sum is roughly as follows: $sum: argcheck, call dosum with meval'd bounds dosum: didn't look at this too much after this, meval calls simpsum **** if you type 'sum(f(k),k,1,n),simpsum; meval calls only simpsum **** $simpsum: call simpsum1 simpsum1: checks lo=hi, otherwise exp not depending on the summation index, otherwise if $simpsum, call simpsum2 **** simpsum2 is found in combin.lisp **** simpsum2: sets up a variable *plus, which will contain all the stuff which is added together at the end calls sumsum sumsum: returns the part of the expression it was able to sum up (this is the contents of the variable "usum"), all the rest (the contents of the variable "sum") is put into the variable *plus, which is then used by simpsum2 calls sum sum: adsum's and adusum's the sum of e. It's result is discarded. (at least I think that this function is only called by sumsum, but there are lots of places where a variable is called "sum"...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 
From: <noreply@so...>  20021124 22:33:11

Bugs item #643259, was opened at 20021124 16:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643259&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp([rat(x)], [rat(x)]) Initial Comment: The orderlessp function often halts with a (nondescriptive) error message if one or more of its arguments are lists or matrices containing CRE expressions. The Maxima documentation for orderlessp doesn't mention this limitation. If you need to order expressions that might involve lists or matrices containing CRE expressions, apply totaldisrep to each argument of the ordering predicate. Here's an example Maxima 5.5 Tue Dec 5 16:55:33 2000 (with enhancements by W. Schelter). Licensed under the GNU Public License (see file COPYING) (C4) xorderlessp(x,y) := orderlessp(totaldisrep(x), totaldisrep(y)); (D4) xorderlessp(x, y) := ORDERLESSP(TOTALDISREP(x), TOTALDISREP(y)) /* xorderlessp works okay on lists with CRE elements */ (C5) xorderlessp([rat(x)],[rat(x)]); (D5) FALSE (C6) orderlessp([rat(x)], [rat(x)]); Error: 1 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>> Either the documentation should warn the user not to use orderlessp or ordergreatp on lists or matrices that contain CRE elements, or these functions should apply totaldisrep to each argument. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643259&group_id=4933 
From: <noreply@so...>  20021124 22:11:52

Bugs item #643254, was opened at 20021124 16:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643254&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp([rat(x)], [rat(x)]) Initial Comment: The orderlessp function often halts with a (nondescriptive) error message if one or more of its arguments are lists or matrices containing CRE expressions. The Maxima documentation for orderlessp doesn't mention this limitation. If you need to order expressions that might involve lists or matrices containing CRE expressions, apply totaldisrep to each argument of the ordering predicate. Here's an example Maxima 5.5 Tue Dec 5 16:55:33 2000 (with enhancements by W. Schelter). Licensed under the GNU Public License (see file COPYING) (C4) xorderlessp(x,y) := orderlessp(totaldisrep(x), totaldisrep(y)); (D4) xorderlessp(x, y) := ORDERLESSP(TOTALDISREP(x), TOTALDISREP(y)) /* xorderlessp works okay on lists with CRE elements */ (C5) xorderlessp([rat(x)],[rat(x)]); (D5) FALSE (C6) orderlessp([rat(x)], [rat(x)]); Error: 1 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>> Either the documentation should warn the user not to use orderlessp or ordergreatp on lists or matrices that contain CRE elements, or these functions should apply totaldisrep to each argument. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643254&group_id=4933 
From: <noreply@so...>  20021121 16:04:26

Bugs item #641952, was opened at 20021121 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=641952&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pedro Fortuny Ayuso (pfortuny) Assigned to: Nobody/Anonymous (nobody) Summary: embedded plots and line numbers Initial Comment: Start xmaximalocal and at any time, plot something with the "embedded" option. The (C) of the following line appears before the (D) corresponding to the plot. Ex: (C1) plot2d(sin(x),[x,3,3]); ########[nice plot graphic] ########[But look now at the numbers:] (C2) 10; (D1)10; (D2) 10 (C3) bug_report(); ######skipped  Maxima version: 5.9.0rc3 Maxima build date: 17:31 11/21/2002 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.27 (released 20010717) (built 3223394505) (memory 3246885081)   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=641952&group_id=4933 
From: <noreply@so...>  20021119 19:48:23

Bugs item #635627, was opened at 20021108 13:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: subst([...] is orderdependent Initial Comment: I would have expected subst([a=...,b=...],...) to substitute a and b simultaneously (like Lisp Sublis), but it does not, and it simplifies along the way. Here are some cases where it matters. The most obvious case is subst([b=c,a=b],b) => c This means that subst cannot be used to permute variables, e.g. subst([x=y,y=x],...) That is not good.  But there are other cases:  subst([a=0,b=0],atan2(a,b)) Depending on the answers to a>0 etc., this can return 0 or %pi, whereas subst([b=0,a=0],...) can return pi/2 or  pi/2. I believe that it should give the error: atan2(0.0) has been generated.  subst(["="="+","["="*"],[x=1,x=2]); gives (x+1) * (x+2) as expected, but subst(["["="*","="="+"],[x=1,x=2]); gives x^2+2 ((It would have been nice if minus were nary, so that I could use "="=""...))  These two cases can be worked around by turning simp off temporarily, e.g. subst(["["="*","="="+"],[x=1,x=2]), simp:false; but the workaround for the first case is much clumsier: subst([x=x0,y=x,x0=y],...)  >Comment By: Stavros Macrakis (macrakis) Date: 20021119 14:48 Message: Logged In: YES user_id=588346 Sublis is broken for operators, e.g. sublis(["+"="*"],x+y) And the online documentation (describe) of subst does not mention the parallel substitution issue. I do not think we need both subst([...]) and sublis([...]...). My guess is that sublis was defined before subst was extended to cover the multiple substitution case.  Comment By: Nobody/Anonymous (nobody) Date: 20021116 11:43 Message: Logged In: NO The info tells you to use SUBLIS if you want to do substitution in parallel.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 
From: <noreply@so...>  20021118 21:35:58

Bugs item #640332, was opened at 20021118 16:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=640332&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Need to specdisrep more systematically Initial Comment: There are lots of places where the Poisson representation isn't handled properly, and a few where Rat isn't handled properly. I'm not sure if anyone cares about Poisson representation, to tell the truth, but it would be nice if specrepcheck were used more consistently.... Of course, it would be even better if representationspecific routines were called, but we can start with specrepcheck. For example: diff(rat(x),rat(x)) => 1 OK but diff(x,rat(x)) => 0 BAD diff(intopois(U),U) => fatal error taylor(intopois(sin(U),U,0,3) => fatal error ratsimp(intopois(sin(U))) => internal error  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=640332&group_id=4933 
From: <noreply@so...>  20021118 16:18:48

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

Bugs item #624061, was opened at 20021016 12:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=624061&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: strange bug (probably) in numer Initial Comment: Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 (C2) display2D:false$ (C3) f(x):=x^310*x^2+28.5*x21$ (C4) rhs(solve(f(x),x)[1]),rectform,numer; RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 0.5 by 1//2 = 0.5 RAT replaced 4.18055555555556 by 301//72 = 4.18055555555556 (D4) 3.897114317029973*%I+0.75 ******** which is wrong ******* (C5) y:rhs(solve(f(x),x)[1]),rectform$ RAT replaced 28.5 by 57//2 = 28.5 (C6) y,numer; (D6) 3.318006917974609 ******* which is correct ****** M.At.Stanev reports with Maxima 5.5 (C1) f(x):=x^310*x^2+28.5*x21; (D1) ... (C2) rhs(solve(f(x),x)[1]),rectform,numer; (D2) 12.01301985645547*%I+10.38424295325536 Martin  Comment By: Martin Rubey (kratt5) Date: 20021118 15:34 Message: Logged In: YES user_id=651552 I replaced f* by * in mul2* in 5.9.0rc3, but got still different behaviour using the two approaches  the difference is rather small now, so it might be ok, but I do not understand why there is a difference... (C1) f(x):=x^310*x^2+28.5*x21$ (C2) rhs(solve(f(x),x)[1]),rectform,numer; RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 28.5 by 57//2 = 28.5 RAT replaced 0.5 by 1//2 = 0.5 RAT replaced 4.18055555555556 by 301//72 = 4.18055555555556 (D2) 2.220446049250313E16 %I + 3.318006917974608  whereas  (C3) y:rhs(solve(f(x),x)[1]),rectform$ RAT replaced 28.5 by 57//2 = 28.5 (C4) y,numer; (D4) 3.318006917974609  Comment By: Stavros Macrakis (macrakis) Date: 20021021 23:32 Message: Logged In: YES user_id=588346 The problem is in the function MUL2*, which uses f* to multiply nonfixnums: (MUL2* 1 150.5) returns 269521184. The correction is to replace "f*" by "*" in MUL2* (in opers.lisp).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=624061&group_id=4933 
From: <noreply@so...>  20021118 04:03:41

Bugs item #639880, was opened at 20021117 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=639880&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ode2 internal error for invalid input Initial Comment: ode2('diff(y,x,3)=0,y,x) => $STATUS is invalid as a function I realize that ode2 is only supposed to handle 1st and 2nd order, but it should fail more gracefully. Same error for similarly for ode2('diff(y,x)^2=1,y,x); (Maxima 5.5)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=639880&group_id=4933 
From: <noreply@so...>  20021116 16:43:27

Bugs item #635627, was opened at 20021108 10:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: subst([...] is orderdependent Initial Comment: I would have expected subst([a=...,b=...],...) to substitute a and b simultaneously (like Lisp Sublis), but it does not, and it simplifies along the way. Here are some cases where it matters. The most obvious case is subst([b=c,a=b],b) => c This means that subst cannot be used to permute variables, e.g. subst([x=y,y=x],...) That is not good.  But there are other cases:  subst([a=0,b=0],atan2(a,b)) Depending on the answers to a>0 etc., this can return 0 or %pi, whereas subst([b=0,a=0],...) can return pi/2 or  pi/2. I believe that it should give the error: atan2(0.0) has been generated.  subst(["="="+","["="*"],[x=1,x=2]); gives (x+1) * (x+2) as expected, but subst(["["="*","="="+"],[x=1,x=2]); gives x^2+2 ((It would have been nice if minus were nary, so that I could use "="=""...))  These two cases can be worked around by turning simp off temporarily, e.g. subst(["["="*","="="+"],[x=1,x=2]), simp:false; but the workaround for the first case is much clumsier: subst([x=x0,y=x,x0=y],...)  Comment By: Nobody/Anonymous (nobody) Date: 20021116 08:43 Message: Logged In: NO The info tells you to use SUBLIS if you want to do substitution in parallel.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 
From: <noreply@so...>  20021108 21:17:02

Bugs item #635708, was opened at 20021108 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635708&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Bad display of unsimplified expr Initial Comment: f(n):=IF n = 0 THEN 1 ELSE 91919*gg(x^n+f(EV(n 1,SIMP))) simp:false; Now calculate and display f(6)*f(6) (with the display window fairly narrow, say 60 columns wide). displa generates lines that are wider than the window, which wrap around and make the display illegible (especially the exponents). I realize that unsimplified expressions are an unusual case.... I ran across this problem during a debugging session where I turned of SIMP to check something.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635708&group_id=4933 
From: <noreply@so...>  20021108 18:35:05

Bugs item #635627, was opened at 20021108 13:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: subst([...] is orderdependent Initial Comment: I would have expected subst([a=...,b=...],...) to substitute a and b simultaneously (like Lisp Sublis), but it does not, and it simplifies along the way. Here are some cases where it matters. The most obvious case is subst([b=c,a=b],b) => c This means that subst cannot be used to permute variables, e.g. subst([x=y,y=x],...) That is not good.  But there are other cases:  subst([a=0,b=0],atan2(a,b)) Depending on the answers to a>0 etc., this can return 0 or %pi, whereas subst([b=0,a=0],...) can return pi/2 or  pi/2. I believe that it should give the error: atan2(0.0) has been generated.  subst(["="="+","["="*"],[x=1,x=2]); gives (x+1) * (x+2) as expected, but subst(["["="*","="="+"],[x=1,x=2]); gives x^2+2 ((It would have been nice if minus were nary, so that I could use "="=""...))  These two cases can be worked around by turning simp off temporarily, e.g. subst(["["="*","="="+"],[x=1,x=2]), simp:false; but the workaround for the first case is much clumsier: subst([x=x0,y=x,x0=y],...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 
From: <noreply@so...>  20021108 18:17:41

Bugs item #635616, was opened at 20021108 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635616&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: defint infloop with algebraic:false Initial Comment: expr: 1/(2*x^2sqrt(5)1) integrate(expr,x,0,inf) => takes forever (infloop?) but if you set algebraic:true (the default value is false), it returns 0 quickly. Is the user supposed to know that algebraic must be set to true in cases like this? It seems a lot to ask, especially since I doubt it's documented anywhere....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635616&group_id=4933 
From: <noreply@so...>  20021108 17:47:04

Bugs item #635606, was opened at 20021108 12:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635606&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(abs(log(x))) internal error, UND Initial Comment: Maxima 5.5/Windows/gcl limit(abs(log(x)),x,0) Error: The tag LIMIT is undefined. Should of course be INF. More controversially, perhaps, limit(log(x),x,0) gives UND  I believe it should give INFINITY; after all, limit(log (x),x,0,minus) gives INFINITY.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635606&group_id=4933 
From: <noreply@so...>  20021108 15:44:07

Bugs item #635549, was opened at 20021108 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635549&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: CMUCL & system Initial Comment: Under CMUCL, I think the output of system goes to /dev/null. I changed this by changing the $system to [in macsys.lisp] #+cmu (defun $system (&rest args) (ext:runprogram "/bin/sh" (list "c" (apply '$sconcat args)) :output t)) Now, things like system("ls") work fine for me using maxima in a Xemacs shell, but under xmaxima I still don't get any output from system. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635549&group_id=4933 
From: <noreply@so...>  20021108 06:57:46

Bugs item #635357, was opened at 20021108 01:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635357&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor infinite loop Initial Comment: expr: (%i*a1)/(a^2+1)^2 factor(expr) runs forever but factor((%i*a1)/(a^2+1)) works fine, as does gfactor(expr)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635357&group_id=4933 
From: <noreply@so...>  20021108 05:17:26

Bugs item #635338, was opened at 20021108 00:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635338&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp bug Initial Comment: In Maxima 5.5/Windows/gcl expr: 4*(SQRT(5)1)/(SQRT(5)*(102*SQRT(5))* ((4*x+SQRT(5)+1)^2/(102*SQRT(5))+1)) 4*(SQRT(5)+1)/(SQRT(5)*(2*SQRT(5)+10)* ((4*xSQRT(5)+1)^2/(2*SQRT(5)+10)+1)) (SQRT(5)+3)*(4*x+SQRT(5)+1)/ ((10*SQRT(5)+10)*(2*x^2+(SQRT(5)+1)*x+2)) +(SQRT(5)3)*(4*xSQRT(5)+1)/ ((1010*SQRT(5))*(2*x^2+(1SQRT(5))*x+2)) +1/(5*(x1)) expr,x=1.1,numer => 1.638... exprsimp: ratsimp(expr) exprsimp,x=1.1,numer => 0.384...n (!!!) Other simplifications do not run into this problem, e.g. ratsimp(factor(expr)), ratsimp(rat(expr)), which nicely yield 1/(x^51).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635338&group_id=4933 
From: <noreply@so...>  20021107 16:31:08

Bugs item #635045, was opened at 20021107 10:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635045&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: derivatives of acsc, ... Initial Comment: Maxima's formulae for the derivatives of acsc, asec, acsch, and asech are incorrect in the left half plane. To illustrate, we should have asin(1/x)  acsc(x) = 0 for all x # 0; however, (C2) ratsimp(diff(asin(1/x)  acsc(x),x)); (D2) SQRT(x^21)*(ABS(x)x)/(x^4x^2) This only vanishes for x > 0. I've attached a diff file for comm.lisp that fixes these problems. And I attached an rtest file that tests the derivatives of the inverse trig functions. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635045&group_id=4933 
From: <noreply@so...>  20021104 18:33:27

Bugs item #633367, was opened at 20021104 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=633367&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reimar Finken (reimar) Assigned to: Nobody/Anonymous (nobody) Summary: assoc_leg_cos bug Initial Comment: assoc_leg_cos (which is called only by spherical_harmonic()) gives an error when the x parameter is a number and not a symbol: (C2) spherical_harmonic(1,0,0,0); 0 0 has been generated #0: assoc_leg_cos(n=1,m=0,x=0)(specfun.mac line 591) #1: spherical_harmonic(n=1,m=0,theta=0,phi=0)(specfun.mac line 607)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C3) assoc_leg_cos(1,0,0); 0 0 has been generated #0: assoc_leg_cos(n=1,m=0,x=0)(specfun.mac line 591)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) The error occurs before the ultraspherical() function is called on line 591 in specfun.mac, but after the c value has correctly been evaluated in the if branch before.  >Comment By: Reimar Finken (reimar) Date: 20021104 18:33 Message: Logged In: YES user_id=641546 The expression sin (x)^m, which evaluated to 0^0, was causing the problems. Splitting this line into the two different if branches (taking care of the m=0 case) solved the problem. Patch attached.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=633367&group_id=4933 
From: <noreply@so...>  20021104 17:07:22

Bugs item #633367, was opened at 20021104 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=633367&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reimar Finken (reimar) Assigned to: Nobody/Anonymous (nobody) Summary: assoc_leg_cos bug Initial Comment: assoc_leg_cos (which is called only by spherical_harmonic()) gives an error when the x parameter is a number and not a symbol: (C2) spherical_harmonic(1,0,0,0); 0 0 has been generated #0: assoc_leg_cos(n=1,m=0,x=0)(specfun.mac line 591) #1: spherical_harmonic(n=1,m=0,theta=0,phi=0)(specfun.mac line 607)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C3) assoc_leg_cos(1,0,0); 0 0 has been generated #0: assoc_leg_cos(n=1,m=0,x=0)(specfun.mac line 591)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) The error occurs before the ultraspherical() function is called on line 591 in specfun.mac, but after the c value has correctly been evaluated in the if branch before.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=633367&group_id=4933 