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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




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

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

14
(4) 
15

16
(2) 
17

18
(5) 
19
(3) 
20

21
(3) 
22

23
(1) 
24

25

26
(1) 
27

28
(1) 
29
(2) 
30
(4) 
31


From: SourceForge.net <noreply@so...>  20081030 23:58:29

Bugs item #2171237, was opened at 20081016 05:44 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171237&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: 3 Private: No Submitted By: Barton Willis (willisbl) >Assigned to: Barton Willis (willisbl) Summary: load(basic) warnings Initial Comment: In a fresh Maxima, load("basic") gives warnings about redefining functions. These functions aren't built in, so I think the warnings are spurious. As far as I know, the warnings don't cause problems, they are only distracting. (%i1) load("basic")$ Warning  you are redefining the Maxima function prog1 Warning  you are redefining the Maxima function symbolcheck Warning  you are redefining the Maxima function push Warning  you are redefining the Maxima function pop Warning  you are redefining the Maxima function tr_ev  >Comment By: Barton Willis (willisbl) Date: 20081030 18:58 Message: I think the eval_when and herald_package statements should be cutthat eliminates the warnings. The stuff to autoload stuff needs to be somewhere else. /* eval_when([translate,batch,demo], if get('sharem,'version) = false then load(autolo))$ herald_package(basic)$ */  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171237&group_id=4933 
From: SourceForge.net <noreply@so...>  20081030 23:22:41

Bugs item #2208303, was opened at 20081029 15:51 Message generated for change (Comment added) made by parismb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&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  Trigonometry Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Paris MilesBrenden (parismb) Assigned to: Raymond Toy (rtoy) Summary: Problem with jacobi_dn and elliptic_kc Initial Comment: Entering the following in v 5.16.2: jacobi_dn(elliptic_kc(m)*t,m) Produces as output: jacobi_cn(elliptic_kc(m)*t,m) This simplification is not valid, and messes up numerous calculations. How do we/you fix it?  >Comment By: Paris MilesBrenden (parismb) Date: 20081030 17:22 Message: Thank you, I will use the CVS version. Paris  Comment By: Raymond Toy (rtoy) Date: 20081030 07:59 Message: Fixed in ellipt.lisp, rev 1.28  Comment By: Raymond Toy (rtoy) Date: 20081029 15:57 Message: Oops. That's a typo in the simplification code. This will be fixed right away. If you can, use the CVS version. If not, a small patch can be provided that fixes this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&group_id=4933 
From: SourceForge.net <noreply@so...>  20081030 17:23:30

Bugs item #2210087, was opened at 20081030 18:23 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=2210087&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: integrate((x+1)^2.0,x) loops endlessly Initial Comment: Maxima can integrate expressions like (x+1)^n where n is an integer or a floating point representation of an integer, e.g. integrate((x+1)^8.0,x). But this does not work for the floating point numbers 2.0, 3.0, ..., 5.0 as an exponent. Maxima loops endlessly. The reason is the following code in DIFFDIV (the bug is marked): (cond ((and (mexptp exp) (mplusp (cadr exp)) (integerp2 (caddr exp)) ; here the bug (< (caddr exp) 6) (> (caddr exp) 0)) (return (integrator (expandexpt (cadr exp) (caddr exp)) var)))) The function INTEGERP2 checks for an integer or an floating point representation of an integer. If the value is between 0 and 6 the expression is expanded with the function EXPANDEXPT and the integrator is called again. But this does not work with a floating point representation of an integer, because for this case the expression is not expanded by the function EXPANDEXPT. The integrator gets again the same expression and loops endlessly. To possible corrections: 1. Convert the floating point exponent to an integer and then call EXPANDEXPT. 2. Do not test for a floating point respresentation and change INTEGERP2 to INTEGERP. Now for a floating point exponent betweeen 0.0 and 6.0 the result is given in the form (1/n)*(x+1)^(n+1) where 1/n and (n+1) are floating point numbers. I think solution 2 is better, because we get the results with the expected floating point numbers. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2210087&group_id=4933 
From: SourceForge.net <noreply@so...>  20081030 13:59:53

Bugs item #2208303, was opened at 20081029 17:51 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&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  Trigonometry Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Paris MilesBrenden (parismb) Assigned to: Raymond Toy (rtoy) Summary: Problem with jacobi_dn and elliptic_kc Initial Comment: Entering the following in v 5.16.2: jacobi_dn(elliptic_kc(m)*t,m) Produces as output: jacobi_cn(elliptic_kc(m)*t,m) This simplification is not valid, and messes up numerous calculations. How do we/you fix it?  >Comment By: Raymond Toy (rtoy) Date: 20081030 09:59 Message: Fixed in ellipt.lisp, rev 1.28  Comment By: Raymond Toy (rtoy) Date: 20081029 17:57 Message: Oops. That's a typo in the simplification code. This will be fixed right away. If you can, use the CVS version. If not, a small patch can be provided that fixes this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&group_id=4933 
From: SourceForge.net <noreply@so...>  20081029 21:57:39

Bugs item #2208303, was opened at 20081029 17:51 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paris MilesBrenden (parismb) >Assigned to: Raymond Toy (rtoy) Summary: Problem with jacobi_dn and elliptic_kc Initial Comment: Entering the following in v 5.16.2: jacobi_dn(elliptic_kc(m)*t,m) Produces as output: jacobi_cn(elliptic_kc(m)*t,m) This simplification is not valid, and messes up numerous calculations. How do we/you fix it?  >Comment By: Raymond Toy (rtoy) Date: 20081029 17:57 Message: Oops. That's a typo in the simplification code. This will be fixed right away. If you can, use the CVS version. If not, a small patch can be provided that fixes this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&group_id=4933 
From: SourceForge.net <noreply@so...>  20081029 21:51:55

Bugs item #2208303, was opened at 20081029 15:51 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=2208303&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paris MilesBrenden (parismb) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with jacobi_dn and elliptic_kc Initial Comment: Entering the following in v 5.16.2: jacobi_dn(elliptic_kc(m)*t,m) Produces as output: jacobi_cn(elliptic_kc(m)*t,m) This simplification is not valid, and messes up numerous calculations. How do we/you fix it?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2208303&group_id=4933 
From: SourceForge.net <noreply@so...>  20081028 03:36:09

Bugs item #2202764, was opened at 20081028 03:36 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=2202764&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Taylor Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor series of sqrt(1+xy) Initial Comment: Taylor expansion results of f:sqrt(1+xy) depends on sequence: (1) taylor(f,y,0,1); taylor(%,x,0,1) works properly: 1y/2+...+(1/2+y/4+...)*x+... (2) taylor(f,x,0,1); taylor(%,y,0,1) generates bad results: 1x/2+...+(1/2+x/4+...)*y+... The square of the "bad result" is 1+xy, but it is not the narrow definition of sqrt(), which should be positive in this case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2202764&group_id=4933 
From: SourceForge.net <noreply@so...>  20081026 04:31:01

Bugs item #2196405, was opened at 20081026 00: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=2196405&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: tellsimp error Initial Comment: I tried to create rules on integrate as follows and get an error when I try to use them. (%i1) outchar:o; (o1) o (%i2) matchdeclare(aa, constantp, bb, constantp, xx, symbolp)$ (%i3) simp:false; (o3) false (%i4) tellsimp('integrate(unit_step(aa*xx+bb),xx),(aa*xx+bb)*unit_step(aa*xx+bb)/aa)$ bb+xx*aa partitions `sum' aa*xx partitions `product' xx*aa Will be matched uniquely since subparts would otherwise be ambigious. (%i5) simp:true; (o5) true (%i6) integrate(unit_step(4*y+41),y); Improper value assignment: xx*aa  an error. To debug this try debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2196405&group_id=4933 
From: SourceForge.net <noreply@so...>  20081023 14:34:08

Bugs item #2176843, was opened at 20081018 13:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&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: f90 does not use correct continuation character Initial Comment: Example usage: (%i1) load("f90"); (%i2) f90(long_expression); where long_expression is long enough to need more than one line of fortran, results in fixed format fortran output with the continuation character being 1,2,3,... instead of & as if should be for fortran90 or higher. The correct behaviour is described in the documentation, but is not exhibited by f90. I am using Maxima version 5.15.0, which is packaged with Fedora 9.  Comment By: Nobody/Anonymous (nobody) Date: 20081023 14:33 Message: An example workaround posted at: http://jstults.blogspot.com/2008/10/maximacodesfortran90forme.html Just write out the matrix elementwise.  Comment By: Harald Geyer (hgeyer) Date: 20081019 01:12 Message: The Problem seems to be that f90 calls back to the standard core fortran code, especially the function $fortmx in the case where it outputs a matrix. $fortmx calls fortranprint instead of f90print.  Comment By: Nobody/Anonymous (nobody) Date: 20081018 15:09 Message: f90 only uses the incorrect continuation character when trying to output a matrix expression. (%i1) f90( long_matrix_expression ); Produces output with oldstyle continuation, but (%i2) f90( long_matrix_expression[1] ); Produces the correct type of output for the element of the matrix requested.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&group_id=4933 
From: SourceForge.net <noreply@so...>  20081021 13:05:15

Bugs item #2184396, was opened at 20081021 22:05 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=2184396&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong factorization of sqrt() Initial Comment: Dear Developers of Maxima, I found a wrong behavihor of sqrt(). It is a principle that sqrt(X*Y) should not be factorized to sqrt(X)*sqrt(Y) unless X and Y can be judged to be nonnegative. I found a case in which this principle is broken. Here is a program for demonstration:  /* * wrong_factorization_of_sqrt.maxima: * * S.Adachi 2008/10/01 */ display2d:false; /* real for 1 <= x <= 2 */ correct:sqrt((11/x)*(2/x1)); /* real for 2sqrt(2) <= x <= 2+sqrt(2) */ INCORRECT:sqrt((1(2sqrt(2))/x)*((2+sqrt(2))/x1)); INCORRECT_AT_2:at(INCORRECT,[x=2]); SHOULD_BE_POSITIVE:float(INCORRECT_AT_2); /* END */  The result of execution is as follows:  Maxima 5.14.0cvs http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) batch(wrong_factorization_of_sqrt.maxima) batching #p/Volumes/HFS+2/home/adachi/work/307/wrong_factorization_of_sqrt.maxima (%i2) display2d : false (%o2) false (%i3) correct:sqrt((11/x)*(2/x1)) (%o3) sqrt((11/x)*(2/x1)) (%i4) INCORRECT:sqrt((1(2sqrt(2))/x)*((sqrt(2)+2)/x1)) (%o4) sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) (%i5) INCORRECT_AT_2:at(INCORRECT,[x = 2]) (%o5) sqrt((2sqrt(2))/21)*sqrt(1(sqrt(2)+2)/2) (%i6) SHOULD_BE_POSITIVE:float(INCORRECT_AT_2) (%o6) 0.70710678118655 (%o7) "wrong_factorization_of_sqrt.maxima"  At first, as is seen from (%i2) and (%o2), sqrt(11/x)*(2/x1)) is not factorized to sqrt(...)*sqrt(...) in any automatic way. This is the correct behavihor. Next, as is seen from (%i3) and (%o3), sqrt(1(2sqrt(2))/x)*((2+sqrt(2))/x1)) is factorized to sqrt((2sqrt(2))/x1)*sqrt(1(sqrt(2)+2)/x) in an automatic way. THIS IS AN INCORRECT BEHAVIOR. This expression is nonnegative for 2sqrt(2) <= x <= 2+sqrt(2). However, as is demonstrated by (%i4)(%o5), the calculated expression takes a negative value at x=2. Please stop the incorrect factorization of sqrt(X*Y) to sqrt(X)*sqrt(Y). Sincerely yours, Satoshi Adachi  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2184396&group_id=4933 
From: SourceForge.net <noreply@so...>  20081021 12:52:28

Bugs item #2159499, was opened at 20081011 11:11 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&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  Floating point Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Full bigfloat precision for Gamma after the second call Initial Comment: In a lot of cases (for some not) we get the full bigfloat precison for the Gamma function not in a first call but in a second call to the function: (%i4) fpprintprec:3; (%o4) 3 That is the first call. We get the full precision. If we have a fresh maxima and increase fpprec the first time we always get the full precision. (%i5) fpprec:64; (%o5) 64 (%i6) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o6) 3.11b62 Increasing fpprec. First call. Missing precision. (%i7) fpprec:128; (%o7) 128 (%i8) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o8) 1.91b91 Second call. Full precision. (%i9) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o9) 5.43b126 Increasing fpprec. First call. Missing precision. (%i10) fpprec:256; (%o10) 256 (%i11) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o11) 1.03b182 Now the second call. (%i12) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o12) 1.21b253 Increasing fpprec. Now full precsion in the first call. (%i13) fpprec:300; (%o13) 300 (%i14) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o14) 1.97b297 And again. Increasing fpprec. Missing precesion in the first call. (%i15) fpprec:512; (%o15) 512 (%i16) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o16) 3.0b365 Dieter Kaiser  >Comment By: Raymond Toy (rtoy) Date: 20081021 08:52 Message: Link to email thread on this topic: http://www.math.utexas.edu/pipermail/maxima/2008/013946.html  Comment By: Dieter Kaiser (crategus) Date: 20081021 06:59 Message: After a bug fix in float.lisp the effect that we do not get the full precision in a first call to gamma has vanished. Log Message of the bug fix in float.lisp: 1. bug fix for fppi1 helper function fprt18231_ (dependence on $fpprec caused wrong results when fpprec was changed by an other function) 2. another version of fprt18231_ added, which was tested to be faster in clisp and sbcl (author: Raymond Toy) Closing this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20081012 18:11 Message: I have studied the effect in more detail and detected that we have the problem only for a negative argument to bffac. That is true for gamma(0.5b0). The reflection formula calculates: bfloat(%pi*z/sin(%pi*z))/bffac(z,fpprec) If we add an additional bfloat to be sure that the argument of the sin function has the correct precision the described effect that we need a second call to get the full precision vanish. The modified line of code is bfloat(%pi*z/sin(bfloat(%pi*z)))/bffac(z,fpprec) I have not really understand the effect, but it seems to me that it works. Perhaps there is a problem with the sin function. Any comment? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&group_id=4933 
From: SourceForge.net <noreply@so...>  20081021 10:59:50

Bugs item #2159499, was opened at 20081011 17:11 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&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  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: Full bigfloat precision for Gamma after the second call Initial Comment: In a lot of cases (for some not) we get the full bigfloat precison for the Gamma function not in a first call but in a second call to the function: (%i4) fpprintprec:3; (%o4) 3 That is the first call. We get the full precision. If we have a fresh maxima and increase fpprec the first time we always get the full precision. (%i5) fpprec:64; (%o5) 64 (%i6) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o6) 3.11b62 Increasing fpprec. First call. Missing precision. (%i7) fpprec:128; (%o7) 128 (%i8) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o8) 1.91b91 Second call. Full precision. (%i9) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o9) 5.43b126 Increasing fpprec. First call. Missing precision. (%i10) fpprec:256; (%o10) 256 (%i11) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o11) 1.03b182 Now the second call. (%i12) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o12) 1.21b253 Increasing fpprec. Now full precsion in the first call. (%i13) fpprec:300; (%o13) 300 (%i14) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o14) 1.97b297 And again. Increasing fpprec. Missing precesion in the first call. (%i15) fpprec:512; (%o15) 512 (%i16) gamma(bfloat(1/2))bfloat(gamma(1/2)); (%o16) 3.0b365 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20081021 12:59 Message: After a bug fix in float.lisp the effect that we do not get the full precision in a first call to gamma has vanished. Log Message of the bug fix in float.lisp: 1. bug fix for fppi1 helper function fprt18231_ (dependence on $fpprec caused wrong results when fpprec was changed by an other function) 2. another version of fprt18231_ added, which was tested to be faster in clisp and sbcl (author: Raymond Toy) Closing this bug report. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20081013 00:11 Message: I have studied the effect in more detail and detected that we have the problem only for a negative argument to bffac. That is true for gamma(0.5b0). The reflection formula calculates: bfloat(%pi*z/sin(%pi*z))/bffac(z,fpprec) If we add an additional bfloat to be sure that the argument of the sin function has the correct precision the described effect that we need a second call to get the full precision vanish. The modified line of code is bfloat(%pi*z/sin(bfloat(%pi*z)))/bffac(z,fpprec) I have not really understand the effect, but it seems to me that it works. Perhaps there is a problem with the sin function. Any comment? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2159499&group_id=4933 
From: SourceForge.net <noreply@so...>  20081019 16:11:34

Bugs item #2180110, was opened at 20081019 18:11 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=2180110&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: GCL do not signal an overflow converting bigfloat to float Initial Comment: With GCL we do not get overflow errors when converting bigfloat numbers into float numbers which are obviously too big to fit in a float number: This is a correct example: (%i11) float(gamma(150b0)); (%o11) 3.8089226376305632E+260 The following bigfloat numbers are too big. The result is unpredicable and wrong: (%i12) float(gamma(250b0)); (%o12) 4.0014303970800103E127 (%i13) float(gamma(2500b0)); (%o13) 5.0208574388889818E+9 I have observed this for GCL 2.6.8. CLISP 2.44 gives an overflow error. The problem is the Lisp function scalefloat which is called by fp2flo in the file float.lisp. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2180110&group_id=4933 
From: SourceForge.net <noreply@so...>  20081019 01:12:49

Bugs item #2176843, was opened at 20081018 15:15 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&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: f90 does not use correct continuation character Initial Comment: Example usage: (%i1) load("f90"); (%i2) f90(long_expression); where long_expression is long enough to need more than one line of fortran, results in fixed format fortran output with the continuation character being 1,2,3,... instead of & as if should be for fortran90 or higher. The correct behaviour is described in the documentation, but is not exhibited by f90. I am using Maxima version 5.15.0, which is packaged with Fedora 9.  >Comment By: Harald Geyer (hgeyer) Date: 20081019 03:12 Message: The Problem seems to be that f90 calls back to the standard core fortran code, especially the function $fortmx in the case where it outputs a matrix. $fortmx calls fortranprint instead of f90print.  Comment By: Nobody/Anonymous (nobody) Date: 20081018 17:09 Message: f90 only uses the incorrect continuation character when trying to output a matrix expression. (%i1) f90( long_matrix_expression ); Produces output with oldstyle continuation, but (%i2) f90( long_matrix_expression[1] ); Produces the correct type of output for the element of the matrix requested.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&group_id=4933 
From: SourceForge.net <noreply@so...>  20081019 00:46:25

Bugs item #650527, was opened at 20021208 21:22 Message generated for change (Comment added) made by hgeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=650527&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Polynomials Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac, keepfloat: true ERROR Initial Comment: partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; gives Error: Out of bignum stack space  >Comment By: Harald Geyer (hgeyer) Date: 20081019 02:46 Message: I can confirm that it work's as expected on clisp and gcl too. (Using some 5.16.0cvs version) Thus closing this report.  Comment By: Dan Gildea (dgildea) Date: 20081018 23:07 Message: OK now with sbcl: (%i3) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; (%o3) 0.5/(x1)0.5/(x+1) Can someone check clisp and gcl?  Comment By: Robert Dodier (robert_dodier) Date: 20060909 16:47 Message: Logged In: YES user_id=501686 Observed in Maxima 5.9.3cvs. Error message differs depending on Lisp implementation (all on Linux):  Clisp 2.38: (%i1) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; Inverse of zero divisor?  SBCL 0.9.9: (%i1) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value 1.0 is not of type FIXNUM.  GCL 2.6.7: (%i1) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; Factor ran out of primes.  SBCL, GCL, and Clisp all give same result when keepfloat = false: (%i6) partfrac (1 / (x  1.0) / (x + 1.0), x), keepfloat : false; `rat' replaced 1.0 by 1/1 = 1.0 `rat' replaced 1.0 by 1/1 = 1.0 (%o6) 1/(2*(x1))1/(2*(x+1))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=650527&group_id=4933 
From: SourceForge.net <noreply@so...>  20081018 21:10:51

Bugs item #2024777, was opened at 20080722 11:19 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2024777&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: find_root() gives completely wrong result Initial Comment: I am using Maxima 5.15.0 under Windows. find_root((655/656)^n = 0.5, n, 1, 1000) gives 114.8, which is completely wrong. Fortunately, I checked the answer (always a good habit, I know!). Either of the following expressions give the correct answer, which is 454.4 find_root(float(655/656)^n = 0.5, n, 1, 1000); float(log(0.5)/log(655/656)); Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 email: tow_force at hotmail.com  >Comment By: Dan Gildea (dgildea) Date: 20081018 17:10 Message: Seems to be specific to GCL. Problem is caused by floating point overflow computing 655^1000.0. (%i7) find_root((655/656)^n = 0.5, n, 1, 1000) ; (%o7) find_root(655^n/656^n = 0.5,n,1.0,1000.0) (%i8) build_info(); Maxima version: 5.15.0 Maxima build date: 10:24 6/17/2008 host type: i386redhatlinuxgnu lispimplementationtype: SBCL lispimplementationversion: 1.0.17  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2024777&group_id=4933 
From: SourceForge.net <noreply@so...>  20081018 21:07:15

Bugs item #650527, was opened at 20021208 15:22 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=650527&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Polynomials Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac, keepfloat: true ERROR Initial Comment: partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; gives Error: Out of bignum stack space  >Comment By: Dan Gildea (dgildea) Date: 20081018 17:07 Message: OK now with sbcl: (%i3) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; (%o3) 0.5/(x1)0.5/(x+1) Can someone check clisp and gcl?  Comment By: Robert Dodier (robert_dodier) Date: 20060909 10:47 Message: Logged In: YES user_id=501686 Observed in Maxima 5.9.3cvs. Error message differs depending on Lisp implementation (all on Linux):  Clisp 2.38: (%i1) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; Inverse of zero divisor?  SBCL 0.9.9: (%i1) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value 1.0 is not of type FIXNUM.  GCL 2.6.7: (%i1) partfrac(1/(x1.0)/(x+1.0),x),keepfloat:true; Factor ran out of primes.  SBCL, GCL, and Clisp all give same result when keepfloat = false: (%i6) partfrac (1 / (x  1.0) / (x + 1.0), x), keepfloat : false; `rat' replaced 1.0 by 1/1 = 1.0 `rat' replaced 1.0 by 1/1 = 1.0 (%o6) 1/(2*(x1))1/(2*(x+1))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=650527&group_id=4933 
From: SourceForge.net <noreply@so...>  20081018 21:03:03

Bugs item #2171229, was opened at 20081016 06:41 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171229&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: factor runs out of primes Initial Comment: (%i21) factor(product(rat(x)i,i,1,65)); Factor ran out of primes. (%i22) build_info(); Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dan Gildea (dgildea) Date: 20081018 17:02 Message: Fixed in factor.lisp 1.18. combine variable smallprimes (which went up to 61) with *smallprimes* (which goes up to 9973). Ideally there would be no hardcoded limit.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171229&group_id=4933 
From: SourceForge.net <noreply@so...>  20081018 15:09:53

Bugs item #2176843, was opened at 20081018 13:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: f90 does not use correct continuation character Initial Comment: Example usage: (%i1) load("f90"); (%i2) f90(long_expression); where long_expression is long enough to need more than one line of fortran, results in fixed format fortran output with the continuation character being 1,2,3,... instead of & as if should be for fortran90 or higher. The correct behaviour is described in the documentation, but is not exhibited by f90. I am using Maxima version 5.15.0, which is packaged with Fedora 9.  Comment By: Nobody/Anonymous (nobody) Date: 20081018 15:09 Message: f90 only uses the incorrect continuation character when trying to output a matrix expression. (%i1) f90( long_matrix_expression ); Produces output with oldstyle continuation, but (%i2) f90( long_matrix_expression[1] ); Produces the correct type of output for the element of the matrix requested.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&group_id=4933 
From: SourceForge.net <noreply@so...>  20081018 13:15:07

Bugs item #2176843, was opened at 20081018 13:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: f90 does not use correct continuation character Initial Comment: Example usage: (%i1) load("f90"); (%i2) f90(long_expression); where long_expression is long enough to need more than one line of fortran, results in fixed format fortran output with the continuation character being 1,2,3,... instead of & as if should be for fortran90 or higher. The correct behaviour is described in the documentation, but is not exhibited by f90. I am using Maxima version 5.15.0, which is packaged with Fedora 9.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2176843&group_id=4933 
From: SourceForge.net <noreply@so...>  20081016 10:44:51

Bugs item #2171237, was opened at 20081016 05:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171237&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: load(basic) warnings Initial Comment: In a fresh Maxima, load("basic") gives warnings about redefining functions. These functions aren't built in, so I think the warnings are spurious. As far as I know, the warnings don't cause problems, they are only distracting. (%i1) load("basic")$ Warning  you are redefining the Maxima function prog1 Warning  you are redefining the Maxima function symbolcheck Warning  you are redefining the Maxima function push Warning  you are redefining the Maxima function pop Warning  you are redefining the Maxima function tr_ev  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171237&group_id=4933 
From: SourceForge.net <noreply@so...>  20081016 10:41:43

Bugs item #2171229, was opened at 20081016 05:41 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=2171229&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: factor runs out of primes Initial Comment: (%i21) factor(product(rat(x)i,i,1,65)); Factor ran out of primes. (%i22) build_info(); Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171229&group_id=4933 
From: SourceForge.net <noreply@so...>  20081014 21:19:36

Bugs item #2158174, was opened at 20081010 17:10 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2158174&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  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: The Henman (rvh2007) >Assigned to: Dan Gildea (dgildea) Summary: Bug in Limit of a function Initial Comment: Try (%i1) kill(all); (eq0) done (%i1) assume_pos:true; (eq1) true (%i2) (declare(n,integer),assume(sigma>0,equal(n1, 0))); (eq2) [sigma>0,equal(n,1)] (%i3) f(x):=(sqrt(2)/(2*sqrt(%pi)*sqrt(sigma)))*exp((x^2/(2*sigma))); (eq3) f(x):=sqrt(2)/(2*sqrt(%pi)*sqrt(sigma))*exp(x^2/(2*sigma)) (%i4) integrate(f(x),x,minf,inf); (eq4) 1 (%i5) integrate(x^2*f(x), x, minf, inf)(integrate(x*f(x), x, minf, inf))^2; (eq5) sigma (%i6) integrate(x*f(a*xb^2),x,minf,inf); (eq6) b^2/a^2 (%i7) limit(integrate((a*x^3+b*x^2+c*x+d)*f(x^n), x, minf, inf), sigma,0); (eq7) 0 (%i8) limit(integrate((a*x^3+b*x^2+c*x+d)*f(x), x, minf, inf), sigma,0); (eq8) d Output 7 is 0 and output 8 is d. They can't both be right since input 2 declares n=1, so they are equivilent. Rich Hennessy Maxima version: 5.16.3 Maxima build date: 22:48 8/24/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dan Gildea (dgildea) Date: 20081014 17:19 Message: Duplicate of [ 707253 ] limit(x^y,x,0) (y=0) => 0. Fixed in simp.lisp 1.58 and limit.lisp 1.56.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2158174&group_id=4933 
From: SourceForge.net <noreply@so...>  20081014 21:17:56

Bugs item #707253, was opened at 20030320 19:48 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=707253&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  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) >Assigned to: Dan Gildea (dgildea) Summary: limit(x^y,x,0) (y=0) => 0 Initial Comment: limit(x^y,x,0) Is y pnz? zero => 0 This should be 1! Why? Because the question is asking about a property of y which is independent of x. That is, we fix y=0 and THEN take the limit. With y=0, x^y=1 for all nonzero x, and so limit(x^y,x,0)=1. Tlimit also gets this wrong.  >Comment By: Dan Gildea (dgildea) Date: 20081014 17:17 Message: Fixed in simp.lisp 1.58 and limit.lisp 1.56.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=707253&group_id=4933 
From: SourceForge.net <noreply@so...>  20081014 14:14:35

Bugs item #2166223, was opened at 20081014 14:14 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=2166223&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: is(ind<1) gives error Initial Comment: is(ind<1) gives an error: The sign of ind is undefined  an error. To debug this try debugmode(true); It should give <unknown>. Maxima 5.15.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2166223&group_id=4933 