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}
(18) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: SourceForge.net <noreply@so...>  20030516 00:33:53

Bugs item #726420, was opened at 20030423 14:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: floats with missing exponents / really minor Initial Comment: Some software allows the exponent of a float to default to zero. In Maxima, this isn't the case (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ (C3) ?print(%); 4.2E+ (D3) 4.2E+ (C4) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>> Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Not really a bug, but ... Barton  >Comment By: Raymond Toy (rtoy) Date: 20030515 20:33 Message: Logged In: YES user_id=28849 I think the following replacement in nparse.lisp will catch these errors. Help pick out a better error message. (DEFUN SCANDIGITS (DATA CONTINUATION? CONTINUATION) (DO ((C (PARSETYIPEEK) (PARSETYIPEEK)) (L () (CONS C L))) ((NOT (ASCIINUMBERP C)) (COND ((IMEMBER C CONTINUATION?) (FUNCALL CONTINUATION (LIST* (NCONS (FIXNUMCHARUPCASE (PARSETYI))) (NREVERSE L) Data) )) ((null l) (merror "Incomplete number")) (T (MAKENUMBER (CONS (NREVERSE L) DATA))))) (PARSETYI)))  Comment By: Raymond Toy (rtoy) Date: 20030513 00:17 Message: Logged In: YES user_id=28849 I think the following replacement in nparse.lisp will catch these errors. Help pick out a better error message. (DEFUN SCANDIGITS (DATA CONTINUATION? CONTINUATION) (DO ((C (PARSETYIPEEK) (PARSETYIPEEK)) (L () (CONS C L))) ((NOT (ASCIINUMBERP C)) (COND ((IMEMBER C CONTINUATION?) (FUNCALL CONTINUATION (LIST* (NCONS (FIXNUMCHARUPCASE (PARSETYI))) (NREVERSE L) Data) )) ((null l) (merror "Incomplete number")) (T (MAKENUMBER (CONS (NREVERSE L) DATA))))) (PARSETYI)))  Comment By: Barton Willis (willisb) Date: 20030507 11:14 Message: Logged In: YES user_id=570592 Agreed, the internal error is a bug, and I agree that allowing the exponent to default to zero isn't a good thing. Should somebody fix this, all three inputs (C1) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>>:q (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ should generate more or less the same (comphensible) error message.  Comment By: Stavros Macrakis (macrakis) Date: 20030505 18:01 Message: Logged In: YES user_id=588346 I don't see any good reason to allow "4.2d" etc. as a short form of "4.2d0". This is not supported by any programming language I know. What software allows this??? My guess is that it is either (1) some sort of very permissive user front end; (2) a fixed format where spaces are interpreted as zeroes; or (3) an accident/bug of the implementation. On the other hand, the error message given is poor. It should give a normal syntax error, not an internal error. THAT is a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 
From: SourceForge.net <noreply@so...>  20030513 04:17:40

Bugs item #726420, was opened at 20030423 14:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: floats with missing exponents / really minor Initial Comment: Some software allows the exponent of a float to default to zero. In Maxima, this isn't the case (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ (C3) ?print(%); 4.2E+ (D3) 4.2E+ (C4) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>> Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Not really a bug, but ... Barton  >Comment By: Raymond Toy (rtoy) Date: 20030513 00:17 Message: Logged In: YES user_id=28849 I think the following replacement in nparse.lisp will catch these errors. Help pick out a better error message. (DEFUN SCANDIGITS (DATA CONTINUATION? CONTINUATION) (DO ((C (PARSETYIPEEK) (PARSETYIPEEK)) (L () (CONS C L))) ((NOT (ASCIINUMBERP C)) (COND ((IMEMBER C CONTINUATION?) (FUNCALL CONTINUATION (LIST* (NCONS (FIXNUMCHARUPCASE (PARSETYI))) (NREVERSE L) Data) )) ((null l) (merror "Incomplete number")) (T (MAKENUMBER (CONS (NREVERSE L) DATA))))) (PARSETYI)))  Comment By: Barton Willis (willisb) Date: 20030507 11:14 Message: Logged In: YES user_id=570592 Agreed, the internal error is a bug, and I agree that allowing the exponent to default to zero isn't a good thing. Should somebody fix this, all three inputs (C1) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>>:q (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ should generate more or less the same (comphensible) error message.  Comment By: Stavros Macrakis (macrakis) Date: 20030505 18:01 Message: Logged In: YES user_id=588346 I don't see any good reason to allow "4.2d" etc. as a short form of "4.2d0". This is not supported by any programming language I know. What software allows this??? My guess is that it is either (1) some sort of very permissive user front end; (2) a fixed format where spaces are interpreted as zeroes; or (3) an accident/bug of the implementation. On the other hand, the error message given is poor. It should give a normal syntax error, not an internal error. THAT is a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 
From: SourceForge.net <noreply@so...>  20030513 03:57:01

Bugs item #736535, was opened at 20030512 12:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Raymond Toy (rtoy) Summary: half integer bessel_y function Initial Comment: The halfinteger bessel functions of the second kind (the Y functions) evaluate incorrectly. Consider (C1) besselexpand : true; (D1) TRUE (C2) w : bessel_y[1/2](x)$ (C3) display2d : false; (D3) FALSE (C4) ev(w); (D4) SQRT(2)*SIN(x)/(SQRT(%PI)*SQRT(x)) (C5) The sin(x) upstairs should be a cos(x); to fix this, I think we need to swap %sin and %cos in bessselysimp; change the line (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%sin '%cos))) to (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%cos '%sin))) Additionally, the halfinteger bessel functions evaluate to elementary functions too slowly. Consider (D5) ALL (C6) besselexpand : true; Evaluation took 0.00 seconds (0.00 elapsed) (D6) TRUE (C7) w : bessel_j[19/2](x)$ Evaluation took 0.82 seconds (0.82 elapsed) (C8) w : bessel_j[21/2](x)$ Evaluation took 2.47 seconds (2.47 elapsed) (C9) w : bessel_j[23/2](x)$ Evaluation took 43.87 seconds (43.87 elapsed) The time is increasing much too rapidly. Barton  >Comment By: Raymond Toy (rtoy) Date: 20030512 23:57 Message: Logged In: YES user_id=28849 The slow evaluation of the halfinteger functions is caused by a poor choice of algorithms. It computes a larger order derivative to find the answer. Should use a different algorithm such as the one in A&S 10.1.8 and 10.1.9.  Comment By: Raymond Toy (rtoy) Date: 20030512 23:54 Message: Logged In: YES user_id=28849 The slow evaluation of the halfinteger functions is caused by a poor choice of algorithms. It computes a larger order derivative to find the answer. Should use a different algorithm such as the one in A&S 10.1.8 and 10.1.9.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 
From: SourceForge.net <noreply@so...>  20030513 03:54:46

Bugs item #736535, was opened at 20030512 12:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) >Assigned to: Raymond Toy (rtoy) Summary: half integer bessel_y function Initial Comment: The halfinteger bessel functions of the second kind (the Y functions) evaluate incorrectly. Consider (C1) besselexpand : true; (D1) TRUE (C2) w : bessel_y[1/2](x)$ (C3) display2d : false; (D3) FALSE (C4) ev(w); (D4) SQRT(2)*SIN(x)/(SQRT(%PI)*SQRT(x)) (C5) The sin(x) upstairs should be a cos(x); to fix this, I think we need to swap %sin and %cos in bessselysimp; change the line (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%sin '%cos))) to (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%cos '%sin))) Additionally, the halfinteger bessel functions evaluate to elementary functions too slowly. Consider (D5) ALL (C6) besselexpand : true; Evaluation took 0.00 seconds (0.00 elapsed) (D6) TRUE (C7) w : bessel_j[19/2](x)$ Evaluation took 0.82 seconds (0.82 elapsed) (C8) w : bessel_j[21/2](x)$ Evaluation took 2.47 seconds (2.47 elapsed) (C9) w : bessel_j[23/2](x)$ Evaluation took 43.87 seconds (43.87 elapsed) The time is increasing much too rapidly. Barton  >Comment By: Raymond Toy (rtoy) Date: 20030512 23:54 Message: Logged In: YES user_id=28849 The slow evaluation of the halfinteger functions is caused by a poor choice of algorithms. It computes a larger order derivative to find the answer. Should use a different algorithm such as the one in A&S 10.1.8 and 10.1.9.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 
From: SourceForge.net <noreply@so...>  20030513 03:20:04

Bugs item #736538, was opened at 20030512 12:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736538&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barton Willis (willisb) >Assigned to: Raymond Toy (rtoy) Summary: bessel_j with floating point argument Initial Comment: The function bessel_j misbehaves with a floating point argument (C1) bessel_j(0.2,3); Error: #C(0.20000000000000001 0.0) is not of type (OR RATIONAL LISP:FLOAT). Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q (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 Evaluation took 0.00 seconds (0.00 elapsed) This is caused by $bessel receiving a lisp complex number as its first argument  it expects a Maxima number instead. A possible fix is to change (defun $bessel_j (arg order) (if (and (numberp order) (numberp ($realpart arg)) (numberp ($imagpart arg))) ($bessel (complex ($realpart arg) ($imagpart arg)) order) (subfunmakes '$bessel_j (ncons order) (ncons arg)))) to (defun $bessel_j (arg order) (if (and (numberp order) (numberp ($realpart arg)) (numberp ($imagpart arg))) ($bessel arg order) (subfunmakes '$bessel_j (ncons order) (ncons arg)))) Barton  >Comment By: Raymond Toy (rtoy) Date: 20030512 23:20 Message: Logged In: YES user_id=28849 This should be fixed now, in the way you suggest. This brings up an important issue: What is the right way to call Bessel_J? Is it bessel_j(x, n) or bessel_j[n](x) Discussion moved to mailing list.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736538&group_id=4933 
From: SourceForge.net <noreply@so...>  20030513 03:18:15

Bugs item #736530, was opened at 20030512 12:06 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736530&group_id=4933 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) >Assigned to: Raymond Toy (rtoy) Summary: bessel_y with negative float arg Initial Comment: Problem with bessel_y with negative floating point arguments (C1) bessel_y(0.2,3); Error: Caught fatal error [memory may be damaged] Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by CATCH. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q (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 Also, when the argument is a complex float, some (I'm assuming) debugging information gets printed (D2) (C3) bessel_y(0.2 + %i,3); az, aa = 1.019803902718557 1.0737418235E9 fn = 3.0 az, aa = 1.019803902718557 1.0737418235E9 fn = 3.0 (D3)  3.423818579742703 %I  2.529723678563717 (C4) Barton  >Comment By: Raymond Toy (rtoy) Date: 20030512 23:18 Message: Logged In: YES user_id=28849 Both of these issues should be fixed now.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736530&group_id=4933 
From: SourceForge.net <noreply@so...>  20030512 16:32:00

Bugs item #736540, was opened at 20030512 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736540&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: gradef for bessel functions Initial Comment: Consider (C1) display2d : false; Evaluation took 0.00 seconds (0.00 elapsed) (D1) FALSE (C2) diff(bessel_j(x,x),x); Evaluation took 0.00 seconds (0.00 elapsed) (D2) 'DIFF(BESSEL_J[x](x),x,1)BESSEL_J[x](x) +BESSEL_J[x1](x) The derivative in the first term of (d2) is should be with respect to the order of the bessel function  instead it's a _total_ derivative. A good solution isn't easy; in orthopoly, I handle this problem by signaling an error. Thus (from orthopoly) ;; When a user requests the derivative of an a function in this package ;; with respect to the order or some other parameter, return a form ;; ((unk) input from user). We "simplify" this form by printing an error. (defprop unk simpunk operators) (defun simpunk (x y z) (declare (ignore y z)) (merror "Maxima doesn't know the derivative of ~:M with respect the ~:M argument" (nth 2 x) (nth 1 x))) (putprop '$legendre_p '((n x) ((unk) "$first" "$legendre_p") ((mtimes) ((mplus) ((mtimes) n (($legendre_p) ((mplus) 1 n) x)) ((mtimes) 1 n (($legendre_p) n x) x)) ((mexpt) ((mplus) 1 ((mtimes) 1 ((mexpt) x 2))) 1))) 'grad) (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 Evaluation took 0.00 seconds (0.00 elapsed) (D3) (C4) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736540&group_id=4933 
From: SourceForge.net <noreply@so...>  20030512 16:26:16

Bugs item #736538, was opened at 20030512 11:26 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=736538&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_j with floating point argument Initial Comment: The function bessel_j misbehaves with a floating point argument (C1) bessel_j(0.2,3); Error: #C(0.20000000000000001 0.0) is not of type (OR RATIONAL LISP:FLOAT). Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q (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 Evaluation took 0.00 seconds (0.00 elapsed) This is caused by $bessel receiving a lisp complex number as its first argument  it expects a Maxima number instead. A possible fix is to change (defun $bessel_j (arg order) (if (and (numberp order) (numberp ($realpart arg)) (numberp ($imagpart arg))) ($bessel (complex ($realpart arg) ($imagpart arg)) order) (subfunmakes '$bessel_j (ncons order) (ncons arg)))) to (defun $bessel_j (arg order) (if (and (numberp order) (numberp ($realpart arg)) (numberp ($imagpart arg))) ($bessel arg order) (subfunmakes '$bessel_j (ncons order) (ncons arg)))) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736538&group_id=4933 
From: SourceForge.net <noreply@so...>  20030512 16:21:50

Bugs item #736535, was opened at 20030512 11:21 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=736535&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: half integer bessel_y function Initial Comment: The halfinteger bessel functions of the second kind (the Y functions) evaluate incorrectly. Consider (C1) besselexpand : true; (D1) TRUE (C2) w : bessel_y[1/2](x)$ (C3) display2d : false; (D3) FALSE (C4) ev(w); (D4) SQRT(2)*SIN(x)/(SQRT(%PI)*SQRT(x)) (C5) The sin(x) upstairs should be a cos(x); to fix this, I think we need to swap %sin and %cos in bessselysimp; change the line (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%sin '%cos))) to (simplify `((mtimes) 1 ,(besseljyhalforder arg rat order '%cos '%sin))) Additionally, the halfinteger bessel functions evaluate to elementary functions too slowly. Consider (D5) ALL (C6) besselexpand : true; Evaluation took 0.00 seconds (0.00 elapsed) (D6) TRUE (C7) w : bessel_j[19/2](x)$ Evaluation took 0.82 seconds (0.82 elapsed) (C8) w : bessel_j[21/2](x)$ Evaluation took 2.47 seconds (2.47 elapsed) (C9) w : bessel_j[23/2](x)$ Evaluation took 43.87 seconds (43.87 elapsed) The time is increasing much too rapidly. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736535&group_id=4933 
From: SourceForge.net <noreply@so...>  20030512 16:06:01

Bugs item #736530, was opened at 20030512 11:06 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=736530&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: bessel_y with negative float arg Initial Comment: Problem with bessel_y with negative floating point arguments (C1) bessel_y(0.2,3); Error: Caught fatal error [memory may be damaged] Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by CATCH. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q (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 Also, when the argument is a complex float, some (I'm assuming) debugging information gets printed (D2) (C3) bessel_y(0.2 + %i,3); az, aa = 1.019803902718557 1.0737418235E9 fn = 3.0 az, aa = 1.019803902718557 1.0737418235E9 fn = 3.0 (D3)  3.423818579742703 %I  2.529723678563717 (C4) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736530&group_id=4933 
From: SourceForge.net <noreply@so...>  20030512 08:02:01

Bugs item #736358, was opened at 20030512 00: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=736358&group_id=4933 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: .pdf of updated manual? Initial Comment: Hi, this is really not a bug, but a request. I'm very happy to have found the DOE Macsyma reference manual, with updates by Clarkson, on your web site, but wonder whether you could post a .pdf version (as you did with the original edition), for those of us who still prefer curling up with a book & cup of coffee to a monitor & ditto. I'm hoping to make this my summer reading, in a place with superb mountain scenery but no net connection. Thanks, Bill William H. Wing Physics Department University of Arizona Tucson, AZ 85721 wwing@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=736358&group_id=4933 
From: SourceForge.net <noreply@so...>  20030509 00:43:02

Bugs item #734851, was opened at 20030508 16: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=734851&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: pade interfered with by taylor Initial Comment: (C1) taylor(sin(x),x,0,3); (D1) xx^3/6 (C2) pade(d1,2,2); (D2) [6*x/(x^2+6)] Fine so far. (C3) taylor(x,x,0,3); (D3) +x (C4) pade(d1,2,2); (D4) [6/7] What's this?! Pade is being affected by the Taylor calculation in C3?! Presumably there is some global flag being set but not reset.... (C5) taylor(exp(x),x,0,3); (D5) 1+x+x^2/2+x^3/6 (C6) pade(d1,2,2); (D6) [6*x/(x^2+6)] Somehow that restored the thing that was causing the problem.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=734851&group_id=4933 
From: SourceForge.net <noreply@so...>  20030507 15:14:49

Bugs item #726420, was opened at 20030423 13:16 Message generated for change (Comment added) made by willisb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: floats with missing exponents / really minor Initial Comment: Some software allows the exponent of a float to default to zero. In Maxima, this isn't the case (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ (C3) ?print(%); 4.2E+ (D3) 4.2E+ (C4) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>> Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Not really a bug, but ... Barton  >Comment By: Barton Willis (willisb) Date: 20030507 10:14 Message: Logged In: YES user_id=570592 Agreed, the internal error is a bug, and I agree that allowing the exponent to default to zero isn't a good thing. Should somebody fix this, all three inputs (C1) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>>:q (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ should generate more or less the same (comphensible) error message.  Comment By: Stavros Macrakis (macrakis) Date: 20030505 17:01 Message: Logged In: YES user_id=588346 I don't see any good reason to allow "4.2d" etc. as a short form of "4.2d0". This is not supported by any programming language I know. What software allows this??? My guess is that it is either (1) some sort of very permissive user front end; (2) a fixed format where spaces are interpreted as zeroes; or (3) an accident/bug of the implementation. On the other hand, the error message given is poor. It should give a normal syntax error, not an internal error. THAT is a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 
From: SourceForge.net <noreply@so...>  20030506 13:50:33

Bugs item #733271, was opened at 20030506 07: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=733271&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: "integrate" asks if FALSE is pos, neg, or zero Initial Comment: "integrate((1+erf(sqrt(1/u).(u1)))/2,u,0,inf);" asks if FALSE is positive, negative, or zero. That doesn't seem like a meaningful question. Since sqrt(1/u).(u1) increases like sqrt(u), the integrand approaches a positive constant (namely one) and so the answer ought to be INF, I think. I am running Maxima 5.9.0 on RedHat Linux 7.2.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=733271&group_id=4933 
From: SourceForge.net <noreply@so...>  20030506 04:19:48

Bugs item #733071, was opened at 20030506 00:19 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=733071&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 unsimplified result Initial Comment: integrate(exp(x^2%i*2*%pi*x*s),x,minf,inf) => SQRT(%PI)*%E^(%I^2*%PI^2*s^2) Note the unsimplified %i^2.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=733071&group_id=4933 
From: SourceForge.net <noreply@so...>  20030506 01:48:21

Bugs item #733030, was opened at 20030505 21:48 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=733030&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Weird trigexpand interaction /FIX? Initial Comment: makelist(f(sin(x)^2cos(x)^2),f,['trigreduce,'trigexpand]); gives the error "Improper name or value in functional position: 2". The problem is that the internal function sp1add is somehow modifying the fluid variable "arg", which is also used by makelist. I found this using: (trace (sp1add :entry (if (boundp 'arg) (list 'sp1add arg)) :exit (if (boundp 'arg) (list 'sp1add arg)))) I do not understand how arg is being modified. The code clearly *binds* arg in the let*. The subfunctions are not modifying arg. I have been unable to reproduce this problem using source. When I load sp1add from source, it works fine; also if I compile sp1add. Perhaps there is some problem with the nonstandard let* function? or with the compiler it was built on? I am grasping at straws. Maxima 5.9.0 mingw Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=733030&group_id=4933 
From: SourceForge.net <noreply@so...>  20030506 00:49:10

Bugs item #733003, was opened at 20030505 20:49 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=733003&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: atan2(2,0.3) gives nonfloat answer /FIX Initial Comment: atan2(a,b) should be an approximate number (float or bfloat) whenever one of the arguments is approximate and the other is either approximate or an exact number. This is not currently true. All the following give results involving %PI: atan2(1.0,1), atan2(1.0b0,1.0), atan2( 2/3,1.0b0) etc. The attached code fixes this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=733003&group_id=4933 
From: SourceForge.net <noreply@so...>  20030505 22:01:13

Bugs item #726420, was opened at 20030423 14:16 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: floats with missing exponents / really minor Initial Comment: Some software allows the exponent of a float to default to zero. In Maxima, this isn't the case (C1) 4.2d; (D1) 4.2D+ (C2) 4.2e; (D2) 4.2E+ (C3) ?print(%); 4.2E+ (D3) 4.2E+ (C4) 4.2b; Error: Unexpected end of #<stringinput stream from "">. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MREADRAW. Type :H for Help. MAXIMA>> Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Not really a bug, but ... Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20030505 18:01 Message: Logged In: YES user_id=588346 I don't see any good reason to allow "4.2d" etc. as a short form of "4.2d0". This is not supported by any programming language I know. What software allows this??? My guess is that it is either (1) some sort of very permissive user front end; (2) a fixed format where spaces are interpreted as zeroes; or (3) an accident/bug of the implementation. On the other hand, the error message given is poor. It should give a normal syntax error, not an internal error. THAT is a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=726420&group_id=4933 
From: SourceForge.net <noreply@so...>  20030503 22:10:51

Bugs item #731969, was opened at 20030503 15:10 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=731969&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: Maxima can't do simple integral? Initial Comment: (C1) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/? atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Submit New' link on that page. Please include the following build information with your bug report:  Maxima version: 5.9.0.rc4 Maxima build date: 12:4 1/30/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  The above information is also available from the Maxima function build_info(). (D1) (C2) display2d:FALSE; (D2) FALSE (C3) f(x):=exp(a*x)*sqrt(1exp(2*a*x)); (D3) f(x):=EXP(a*x)*SQRT(1EXP(2*a*x)) (C4) integrate(f(x),x); (D4) 'INTEGRATE(%E^(a*x)*SQRT(1%E^(2*a*x)),x) (C5) exp(a*x)*sqrt(1exp(2*a*x))/(2*a)+asin(exp(a*x))/ (2*a); (D5) ASIN(%E^(a*x))/(2*a)+%E^(a*x)*SQRT(1%E^ (2*a*x))/(2*a) (C6) diff(%,x)f(x),radcan; (D6) 0 (C7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=731969&group_id=4933 
From: SourceForge.net <noreply@so...>  20030502 20:20:08

Bugs item #709037, was opened at 20030324 21:56 Message generated for change (Comment added) made by kratt5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=709037&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: powerseries fails Initial Comment: powerseries(1/(2*a*x+1),x,0) gives Unable to expand. But the general case powerseries(1/(q*x+r),x,0) works just fine, as does powerseries(1/(a*x+1),x,0). The problem appears to be in the pattern linpat in sratexpnd (series.lisp), but I don't understand the Schatchen pattern language well enough to fix it. Maxima 5.9.0 GCL 2.5.0 mingw Windows 2000  Comment By: Martin Rubey (kratt5) Date: 20030502 20:20 Message: Logged In: YES user_id=651552 Although I don't understand Schatchen either, here's a fix: diff p series.lisp series.lisp.~1.1.1.1.~ *** series.lisp Fri May 2 22:14:30 2003  series.lisp.~1.1.1.1.~ Mon May 8 08:09:41 2000 *************** *** 132,142 **** (linpat '((mtimes) ((coefftt) (cc notzerofree var)) ((mexpt) ((mplus) ((coeffpt)  (c freevar) ; kratt5  ; if (c freevar) comes after (w m1 ...notzerofree var))) it won't recognise  ; ((mtimes) a b var) (w m1 ((mexpt) (x equal var) ! (m notzerofree var)))) ((coeffpp) (a freevar))) (n notzerofree var))))) (cond ((and (not (equal n 1)) (smono n var))  132,140  (linpat '((mtimes) ((coefftt) (cc notzerofree var)) ((mexpt) ((mplus) ((coeffpt) (w m1 ((mexpt) (x equal var) ! (m notzerofree var))) ! (c freevar)) ((coeffpp) (a freevar))) (n notzerofree var))))) (cond ((and (not (equal n 1)) (smono n var)) Martin  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=709037&group_id=4933 
From: SourceForge.net <noreply@so...>  20030430 17:35:45

Bugs item #727542, was opened at 20030425 15:35 Message generated for change (Comment added) made by kratt5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727542&group_id=4933 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) >Summary: powerseries wrong/fix Initial Comment: (C51) gf:2*(1751144*x4882*x^3+4324*x^42072*x^5+416*x^6+3189*x^2)/ (2*x1)^3/(4*x1)/(x1)^3$ (C52) taylor(gf,x,0,3); 2 3 (D52)/T/ 350 + 2262 x + 11634 x + 53650 x + . . . (C53) taylor(powerseries(gf,x,0),x,0,3); 2 3 (D53)/T/ 470 + 2862 x + 13524 x + 58750 x + . . . maybe this is related to sum(x^i,i,0,inf),x:0 giving 0, but I don't know... I checked D53 with Maple, so it seems that powerseries is wrong, not taylor. I converted the result of powerseries to the rational function again, and obtained: 2*(9407436*x41588*x^322066*x^5+40253*x^4+416*x^81816*x^7+7076*x^6+24227*x^2) /(2*x1)^3/(4*x1)/(x2)^2/(x1)^3 The difference between the two is 160*'SUM((I+1)*2^I*x^I,I,0,INF)160*'SUM((I+1)*2^(I2)*x^I,I,0,INF) so the reason might be a simple typo ( instead of + or the like)... Should be possible to correct this... Martin  >Comment By: Martin Rubey (kratt5) Date: 20030430 17:35 Message: Logged In: YES user_id=651552 Here is the fix. It's a typo, as I expected... should really be applied as soon as possible since it gets everything wrong, where the partial fraction expansion contains (a*x+c)^(2)... Martin diff c series.lisp series.lisp.~1.1.1.1.~ *** series.lisp Wed Apr 30 19:32:58 2003  series.lisp.~1.1.1.1.~ Mon May 8 08:09:41 2000 *************** *** 248,255 **** 0)) ((= 2 n) (psp2form (m* (m+ 1 *index) ! (m^ a (m* 1 (m+ 2 *index))) ;; kratt5 ! (m^ (m* 1 c) *index)) ;; kratt5 (if (equal m 1) *index (m* *index m)) 0)) (t (psp2form (m* (do ((nn (f1 n) (f1 nn))  248,255  0)) ((= 2 n) (psp2form (m* (m+ 1 *index) ! (m^ c (m* 1 (m+ 2 *index))) ! (m^ (m* 1 a) *index)) (if (equal m 1) *index (m* *index m)) 0)) (t (psp2form (m* (do ((nn (f1 n) (f1 nn))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727542&group_id=4933 
From: SourceForge.net <noreply@so...>  20030429 08:13:59

Bugs item #729399, was opened at 20030429 01:13 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=729399&group_id=4933 Category: Xmaxima Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: entermatrix on Windows v5.9.0 Initial Comment: When running entermatrix it does not show the prompt texts, but waits for further user input. If you type the data blindly, only when you are finished entering the data will it parse the input and show the prompts AFTERWARDS. See a simple session below: (C1) entermatrix(2,2); [ENTER] 4;1;2;3;4; [ENTER] Response AFTER this is: Is the matrix 1. Diagonal 2. Symmetric 3. Antisymmetric 4. General Answer 1, 2, 3 or 4 : Row 1 Column 1: Row 1 Column 2: Row 2 Column 1: Row 2 Column 2: Matrix entered. [ 1 2 ] (D1) [ ] [ 3 4 ] Notice that it shows the prompts AFTER completing user input. Tibor Futo  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=729399&group_id=4933 
From: SourceForge.net <noreply@so...>  20030425 23:59:54

Bugs item #727811, was opened at 20030426 01: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=727811&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jesper Harder (harder) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for mactex.lisp Initial Comment: `tex' does not translate `and', `or', `not' and `#' to valid TeX expressions. Currently we get this: tex('(a # b)); => $$a # b$$ tex('(a and b)); => $$a(\and)b$$ tex('(a or b)); => $$a(\or)b$$ tex('(not a)); => $$\not a$$ Which are all invalid. `\not', `\and', `\or' and `#' should be replaced with `\neg', `\land', `\lor' and `\ne'. Additionally `or' and `and' should be texinfix not texnary. After applying the attached patch we get this: tex('(a # b)); => $$a\ne b$$ tex('(a and b)); => $$a\land b$$ tex('(a or b)); => $$a(\lor )b$$ tex('(not a)); => $$\neg\,a$$ The parens in `or' still aren't quite right, but at least it's valid TeX.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727811&group_id=4933 
From: SourceForge.net <noreply@so...>  20030425 15:35:19

Bugs item #727542, was opened at 20030425 15:35 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=727542&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: powerseries wrong Initial Comment: (C51) gf:2*(1751144*x4882*x^3+4324*x^42072*x^5+416*x^6+3189*x^2)/ (2*x1)^3/(4*x1)/(x1)^3$ (C52) taylor(gf,x,0,3); 2 3 (D52)/T/ 350 + 2262 x + 11634 x + 53650 x + . . . (C53) taylor(powerseries(gf,x,0),x,0,3); 2 3 (D53)/T/ 470 + 2862 x + 13524 x + 58750 x + . . . maybe this is related to sum(x^i,i,0,inf),x:0 giving 0, but I don't know... I checked D53 with Maple, so it seems that powerseries is wrong, not taylor. I converted the result of powerseries to the rational function again, and obtained: 2*(9407436*x41588*x^322066*x^5+40253*x^4+416*x^81816*x^7+7076*x^6+24227*x^2) /(2*x1)^3/(4*x1)/(x2)^2/(x1)^3 The difference between the two is 160*'SUM((I+1)*2^I*x^I,I,0,INF)160*'SUM((I+1)*2^(I2)*x^I,I,0,INF) so the reason might be a simple typo ( instead of + or the like)... Should be possible to correct this... Martin  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727542&group_id=4933 
From: SourceForge.net <noreply@so...>  20030425 13:38:33

Bugs item #727032, was opened at 20030424 19:29 Message generated for change (Comment added) made by lical You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727032&group_id=4933 Category: Lisp Core Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Too long integral result: integrate((9/cos(7*x)^2),x); Initial Comment: Hi, I think that: integrate((9/cos(7*x)^2),x); should give: 9*tan(7*x)/7 but I get a very long result that I don't know if is correct (i think not because if i try to derive it I don't get the original function...). Details about Maxima version:  Maxima Version: 5.9.0 Maxima Build date: 16:22 4/1/2003 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.29 (released 20020725) (built 3258193367) (memory 3258195754)   Comment By: Ricardo (lical) Date: 20030425 15:38 Message: Logged In: YES user_id=474377 So it is not a bug then... Excuse me if I disturbed :( Anyway, wouldn't it be interesting getting 9*tan(7*x)/7 instead of that long one? Thanks for your comment.  Comment By: Barton Willis (willisb) Date: 20030425 00:08 Message: Logged In: YES user_id=570592 I believe the antiderivative is correct; it's possible to show that the derivative of the antiderivative equals the integrand. But the simplification isn't automatic. (C1) display2d : false; (D1) FALSE (C2) f : 9 / (cos(7*x))^2; (D2) 9/COS(7*x)^2 (C3) integrate(f,x); (D3) 18*SIN(14*x)/(7*SIN(14*x)^2+7*COS(14*x)^2+14*COS (14*x)+7) (C4) diff(%,x)f; (D4) 252*COS(14*x)/(7*SIN(14*x)^2+7*COS(14*x)^2+14*COS (14*x)+7)+3528*SIN(14*x)^2/(7*SIN(14*x)^2+7*COS(14*x) ^2+14*COS(14*x)+7)^29/COS(7*x)^2 (C5) rat(exponentialize(%)); (D5) 0 Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=727032&group_id=4933 