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}
(53) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(5) 
2
(1) 
3
(4) 
4
(4) 
5
(2) 
6
(1) 
7
(2) 
8
(3) 
9
(4) 
10
(5) 
11
(4) 
12
(8) 
13
(3) 
14

15
(6) 
16
(3) 
17
(5) 
18
(7) 
19
(1) 
20
(1) 
21
(2) 
22
(1) 
23
(1) 
24

25
(2) 
26
(12) 
27
(2) 
28
(1) 
29
(2) 
30
(11) 
31



From: SourceForge.net <noreply@so...>  20080704 21:46:03

Bugs item #1954846, was opened at 20080430 16:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Dieter Kaiser (crategus) Date: 20080704 23:45 Message: Logged In: YES user_id=2039760 Originator: NO Sorry, but I have omitted to check arg to be an CL number. The correct code would be: ((and $besselexpand (setq ratorder (maxnumericratiop order 2))) (cond ((and (numberp arg) (= arg 0)) (if (> ratorder 0) 0 '$infinity)) ( t ;; When order is a fraction with a denominator of 2, we ;; can express the result in terms of elementary ;; functions. ;; ;; I[1/2](z) = sqrt(2/%pi/z)*sinh(z) ;; I[1/2](z) = sqrt(2/%pi/z)*cosh(z) (besselihalforder ratorder arg)))) Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080704 23:10 Message: Logged In: YES user_id=2039760 Originator: NO If the gloabal flag BESSELEXPAND is FALSE we get for all Bessel functions with a Rational order and a zero as argument a noun form with the CVS code 1.58. (In previous versions a lot of the zero checks were not implemented.) But, if we set the global flag BESSELEXPAND to TRUE the Bessel function will be expanded and then evaluated for the argument zero. We get for all Bessel functions the described error. I think it is a question of convention and the desired behaviour of Maxima what we should do. The code to catch the zero argument is only implemented for CL numbers. The last time the code was extended to look more carefully for zero arguments didn't extend this to Maxima Rational, Bigfloat numbers or even expression which might simplify. In my opinion the reason to look only for CL numbers is, that only for such numbers we do the numerical evaluation. We check for a zero argument to prevent Lisp Errors in the numerical slatec routines. At this point we need to do the simplification for the Bessel function with zero argument. In the case of Rational numbers it depends on the flag BESSELEXPAND what we should do. In my opinion it is the best to check for the zero argument before we actually do the expansion. If we try to simplify all Bessel functions with zero argument in advance we get a lot of problems and questions, too. The reason is that the result of the simplification with an argument of zero depends on the sign of the order and is different for complex and real order of the Bessel function. Here an example what we can do in simpbesseli: ((and $besselexpand (setq ratorder (maxnumericratiop order 2))) (cond ((= arg 0) ;; We don't do the expansion for a zero argument. (if (> ratorder 0) 0 '$infinity)) (t ;; When order is a fraction with a denominator of 2, we ;; can express the result in terms of elementary ;; functions. ;; ;; I[1/2](z) = sqrt(2/%pi/z)*sinh(z) ;; I[1/2](z) = sqrt(2/%pi/z)*cosh(z) (besselihalforder ratorder arg)))) We no longer get the divison by zero error. Here the results: (%i7) besselexpand:false; (%o7) false (%i8) bessel_i(1/2,0); (%o8) bessel_i(1/2,0) (%i9) bessel_i(1/2,0); (%o9) bessel_i(1/2,0) (%i10) besselexpand:true; (%o10) true (%i11) bessel_i(1/2,0); (%o11) 0 (%i12) bessel_i(1/2,0); (%o12) infinity This check for a zero argument before we expand the Bessel function could be implemented for all other Bessel functions too. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20080620 21:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 21:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 21:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 20:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080704 21:10:14

Bugs item #1954846, was opened at 20080430 16:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_i(1/2,0) > divide by zero error Initial Comment: bessel_i(1/2,0) produces an error. I think it should be 0 since bessel_i(1/2,x) is sqrt(2/%pi)*sinh(x)/sqrt(x).  >Comment By: Dieter Kaiser (crategus) Date: 20080704 23:10 Message: Logged In: YES user_id=2039760 Originator: NO If the gloabal flag BESSELEXPAND is FALSE we get for all Bessel functions with a Rational order and a zero as argument a noun form with the CVS code 1.58. (In previous versions a lot of the zero checks were not implemented.) But, if we set the global flag BESSELEXPAND to TRUE the Bessel function will be expanded and then evaluated for the argument zero. We get for all Bessel functions the described error. I think it is a question of convention and the desired behaviour of Maxima what we should do. The code to catch the zero argument is only implemented for CL numbers. The last time the code was extended to look more carefully for zero arguments didn't extend this to Maxima Rational, Bigfloat numbers or even expression which might simplify. In my opinion the reason to look only for CL numbers is, that only for such numbers we do the numerical evaluation. We check for a zero argument to prevent Lisp Errors in the numerical slatec routines. At this point we need to do the simplification for the Bessel function with zero argument. In the case of Rational numbers it depends on the flag BESSELEXPAND what we should do. In my opinion it is the best to check for the zero argument before we actually do the expansion. If we try to simplify all Bessel functions with zero argument in advance we get a lot of problems and questions, too. The reason is that the result of the simplification with an argument of zero depends on the sign of the order and is different for complex and real order of the Bessel function. Here an example what we can do in simpbesseli: ((and $besselexpand (setq ratorder (maxnumericratiop order 2))) (cond ((= arg 0) ;; We don't do the expansion for a zero argument. (if (> ratorder 0) 0 '$infinity)) (t ;; When order is a fraction with a denominator of 2, we ;; can express the result in terms of elementary ;; functions. ;; ;; I[1/2](z) = sqrt(2/%pi/z)*sinh(z) ;; I[1/2](z) = sqrt(2/%pi/z)*cosh(z) (besselihalforder ratorder arg)))) We no longer get the divison by zero error. Here the results: (%i7) besselexpand:false; (%o7) false (%i8) bessel_i(1/2,0); (%o8) bessel_i(1/2,0) (%i9) bessel_i(1/2,0); (%o9) bessel_i(1/2,0) (%i10) besselexpand:true; (%o10) true (%i11) bessel_i(1/2,0); (%o11) 0 (%i12) bessel_i(1/2,0); (%o12) infinity This check for a zero argument before we expand the Bessel function could be implemented for all other Bessel functions too. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20080620 21:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 21:07 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Raymond Toy (rtoy) Date: 20080620 21:06 Message: Logged In: YES user_id=28849 Originator: YES Doesn't seem get a divide by zero error anymore in latest CVS. It returns the noun form. But bessel_i(v,x) ~ (1/z*x)^v/gamma(v+1) for small x, it should be 0. I think the bug is in simpbesseli in the lines: ((or (and (numberp order) (> order 0)) (integerp order)) 0) ((and (numberp order) (< order 0)) '$infinity) Perhaps numberp should be changed to mnump and (> order 0) should be (great order 0)  Comment By: Barton Willis (willisbl) Date: 20080502 20:05 Message: Logged In: YES user_id=895922 Originator: NO See A&S 9.1.7: http://www.convertit.com/Go/Convertit/Reference/AMS55.ASP?Res=150&Page=360 For n > 0, bessel_j(n,0) = 0 (n needn't be integer). Maxima doesn't use this simplification for noninteger n.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954846&group_id=4933 
From: SourceForge.net <noreply@so...>  20080704 17:52:07

Bugs item #2010843, was opened at 20080704 12:52 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=2010843&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Includes proposed fix Status: Open Resolution: None Priority: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: diff of Taylor poly Initial Comment: Stanislav Maslovski discovered this bug and reported to the mailing list: >============= 8< =============== >(%i1) display2d:false; > >(%o1) false >(%i2) sqrt((f  z^2/4/f)^2 + (dz)^2) + sqrt((f  z^2/4/f)^2 + (zpz)^2); > >(%o2) sqrt((zpz)^2+(fz^2/(4*f))^2)+sqrt((fz^2/(4*f))^2+(dz)^2) >(%i3) taylor(%, [z, zp, d], 0, 4); > >(%o3) 2*f+(z^2+(2*zp2*d)*z+zp^2+d^2)/(2*f) > +((2*zp+2*d)*z^3+(5*zp^25*d^2)*z^2+(4*zp^3+4*d^3)*zzp^4d^4) > /(8*f^3) >(%i4) diff(%, z); > >Maxima encountered a Lisp error: > > Error in PROGN [or a callee]: Bad plist (($ZP ((4 . 1)) 0 A possible fix is to change oldget to (defun oldget (plist tag) (oldget plist tag)) Currently oldget is a macro: `(getf (cdr ,plist) ,tag)); here I changed it to a function (maybe it needs to b a macro, I don't know). After rebuilding, the bug is gone and the testsuite reports no errors. There are other bug reports related to a "bad plist" Maybe these bugs are related. Barton ____________________  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2010843&group_id=4933 
From: SourceForge.net <noreply@so...>  20080704 12:27:35

Bugs item #2010590, was opened at 20080704 12:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2010590&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: vect.mac extension ruins invert function Initial Comment: Hi, just spotted the following erroneous behaviour: after loading "vect.mac" file, the function invert signals "division by 0" error. However, if set the property (get 'MNCTIMES 'opers) back to NIL it seems the function invert gets corrected. D. potapov at adam dot com dot au  Details: deniska@...:~$ maxima Maxima 5.15.0 http://maxima.sourceforge.net Using Lisp CLISP 2.41 (20061013) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) invert(matrix([2, 2, 1], [3, 1, 1], [3, 3, 1])); [ 1 1 3 ] [      ] [ 5 2 10 ] [ ] [ 1 1 ] (%o1) [ 0    ] [ 2 2 ] [ ] [ 3 2 ] [  0  ] [ 5 5 ] (%i2) load("vect"); (%o2) /home/deniska/maxima5.15.0/share/maxima/5.15.0/share/vector/vect.mac (%i3) invert(matrix([2, 2, 1], [3, 1, 1], [3, 3, 1])); Division by 0  an error. To debug this try debugmode(true); (%i4) :lisp (setf (get 'MNCTIMES 'opers) nil) NIL (%i4) invert(matrix([2, 2, 1], [3, 1, 1], [3, 3, 1])); [ 1 1 3 ] [      ] [ 5 2 10 ] [ ] [ 1 1 ] (%o4) [ 0    ] [ 2 2 ] [ ] [ 3 2 ] [  0  ] [ 5 5 ]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2010590&group_id=4933 