You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(13) 
S  M  T  W  T  F  S 



1
(2) 
2
(3) 
3
(12) 
4
(12) 
5
(6) 
6
(1) 
7
(2) 
8

9
(3) 
10
(4) 
11
(4) 
12
(6) 
13
(3) 
14
(1) 
15
(4) 
16

17

18

19
(6) 
20
(5) 
21

22
(2) 
23
(1) 
24
(4) 
25

26

27
(1) 
28

29
(2) 
30
(1) 



From: SourceForge.net <noreply@so...>  20100605 21:50:52

Bugs item #1959214, was opened at 20080507 06:36 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&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: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: integrate() and array having lisp style name Initial Comment: Dear Developer of Maxima, I found that integrate() returns a wrong result if an array that has a lisp name ``?...'' is used in the argument of integrate(). Here is a demonstration program:  /* * integrate_and_array_of_lisp_name.maxima: * * S.Adachi 2008/05/06 */ display2d:false; integrate(1,?a[1],0,?a[2]); /* Maxima result ?a[1][2] should be ?a[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(integrate_and_array_of_lisp_name.maxima) batching #p/Volumes/HFS+2/home/adachi/work/294/integrate_and_array_of_lisp_name.maxima (%i2) display2d : false (%o2) false (%i3) integrate(1,?a[1],0,?a[2]) (%o3) ?a[1][2] (%o4) "integrate_and_array_of_lisp_name.maxima"  The correct value of this integration is ?a[2]. But Maxima returns ?a[1][2], which is wrong. I think that this is a bug of Maxima. In the following, I want to explain the situation in which I met the above bug of Maxima in order to motivate the kind Maxima developers to take the action to actually fix this bug. When I am writing a program in Maxima, I sometimes need an array that has some name which is unique and is dynamically determined in execution. In such a situation, I write a code like A:?gensym(), apply('array, [A,n]), ... < Work with dynamical array A > .. apply('remarray, [A]) The variable A stores a name ``?g....'' of the dynamical array that is generated. This name ``?g....'' is a lisp style name. In the present case, the work is to prepare a function of elements of the dynamical array and integrate the function. Then, when the written program is executed, it tells me that Maxima has the bug that I am now reporting. I hope that any variable in Maxima should not be discreminated by the reason that the variable simply has a lisp name. If it is so, what I am now reporting is truely a bug of Maxima, which is serious for people who write Maxima programs. Please fix this bug of Maxima. Sincerely yours, Satoshi Adachi P.S. (i) As a temporal workaround to write Maxima programs, I replace the line "A:?gensym()," in the above example by a line "A:eval_string(substring(string(?gensym()),2))," to use a Maxima style name "g...." instead of a lisp style name "?g...." (and keep being carefull not to use any name "g...." for other Maxima variables). This is an ugry workaround. (ii) If there is a better or standard way in Maxima to prepare some dynamical array that has a unique name on fly, please let me know. If someone tells me it, I will be happy.  >Comment By: Dieter Kaiser (crategus) Date: 20100605 23:50 Message: A Maxima user function gensym has been implemented in mutils.lisp revision 1.10. The documentation is in Miscellaneous.texi revision 1.27. This function can be used for the example of this bug report. I would like to suggest to close this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080623 00:13 Message: Logged In: YES user_id=501686 Originator: NO Here is a slightly different workaround. :lisp (defun $gensym () (cadr (dollarify (list (gensym))))) Then you can write A:gensym() instead of A:?gensym() and the generated symbols are Maxima identifiers (because they have the leading $ in the name).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1959214&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 20:20:11

Bugs item #1969790, was opened at 20080522 20:31 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1969790&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: limits and subscripts Initial Comment: Maybe not wrong, but it's weird: (%i24) limit(mu[inf],x,inf); (%o24) limit(mu[x],x,inf) Also: (%i25) mu[x] : 42$ (%i26) limit(mu[inf],x,inf); (%o26) limit(mu[x],x,inf) (%i27) ev(%); (%o27) 42  >Comment By: Dieter Kaiser (crategus) Date: 20100605 22:20 Message: With revision 1.99 of limit.lisp we get (%i1) limit(mu[inf],x,inf); (%o1) mu[inf] Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1969790&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 18:12:01

Bugs item #2960403, was opened at 20100227 14:57 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: spurious floats in asksign Initial Comment: (%i3) integrate(1/(x^2 + x + b)^2,x); Is b0.25 positive or negative?pos; (%o3) (4*atan((2*x+1)/sqrt(4*b1)))/(4*b1)^(3/2)+(2*x+1)/((4*b1)*x^2+(4*b1)*x+4*b^2b) (%i4) build_info(); Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 (%o4)  >Comment By: Robert Dodier (robert_dodier) Date: 20100605 12:12 Message: For my part, I am inclined to revert r1.18 src/db.lisp. I am guessing the changes in that revision are largely nonfunctional. If there are revisions after 1.18, we'll have to reapply them. But db.lisp is so obscure that at this late date, we are better off avoiding any changes to it.  Comment By: Dieter Kaiser (crategus) Date: 20100308 07:32 Message: A further oberservation: The bug is visible when we put in addition a fact into the assume database: (%i2) assume(notequal(4*b1,0)); (%o2) [notequal(b,1/4)] (%i3) asksign(4*b1); Is b0.25 positive or negative? This is done by the integration routine too. This indicates that we have a problem with the assume database alone. As reported the bug is not present in Maxima 5.18. I have located the problem in the following revision: Revision 1.18  (view) (download) (annotate)  [select for diffs] Fri Apr 3 17:27:07 2009 UTC (11 months ago) by are_muc Branch: MAIN Changes since 1.17: +243 208 lines Diff to previous 1.17 If I go back to revision 1.17 of db.lisp the bug vanishes, but it is present with revision 1.18. Unfortunately, the change seems to be very subtle and about 240 lines have changed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100301 14:27 Message: Some observations: (1) The bug has been introduced between Maxima 5.18 and Maxima 5.19. Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) 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) integrate(1/(x^2 + x + b)^2,x); Is 4 b  1 positive or negative? Maxima 5.19.2 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) 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) integrate(1/(x^2 + x + b)^2,x); Is b  0.25 positive or negative? (2) The bug is not reproducible with asksign alone. We can trace $asksign to see the involved expression: (%i1) :lisp (trace $asksign) ($ASKSIGN) (%i1) integrate(1/(x^2 + x + b)^2,x); 0: ($ASKSIGN ((MPLUS SIMP) 1 ((MTIMES SIMP RATSIMP) 4 $B))) Is b  0.25 positive or negative? That is the expression which is passed to $asksign and it works as expected: (%i3) asksign(ratsimp(4*b+1)); 0: ($ASKSIGN ((MPLUS SIMP) 1 ((MTIMES SIMP RATSIMP) 4 $B))) Is 4 b  1 positive, negative, or zero? Perhaps we have a global switch or flag which is set by the integration routines and changes the behaviour of $asksign. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 17:01:47

Bugs item #2977217, was opened at 20100326 12:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: maxima can not integrate x*exp(1/2*(xm)^2) Initial Comment: Maxima can not integrate the function x*exp(1/2*(xm)^2) Maxima 5.20.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. 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) integrate(x*exp(1/2*(xm)^2),x); 2 (x  m) /   [ 2 (%o1) I x %e dx ] / The correct solution would be (%i2) diff(exp(1/2*x^2+m*x1/2*m^2)+1/2*m*sqrt(%pi)*sqrt(2)*erf(1/2*sqrt(2)*x1/2*m*sqrt(2)),x); 2 2 x m 2 x m  (  )   + m x   sqrt(2) sqrt(2) 2 2 (%o2) m %e  (m  x) %e  >Comment By: Robert Dodier (robert_dodier) Date: 20100605 11:01 Message: Wow, that's pretty surprising. Maxima can solve integrate(exp((1/2)*(x  m)^2), x) so why not this one?  Comment By: uhlst (uhlst) Date: 20100327 08:45 Message: Thank you for showing this "trick" with changevar. Is there a way that Maxima automatically does the correct substitution without giving it a hint with changevar? If e.g. the "1/2" in the exponent is removed, then Maxima has no problem to do the integration. Does Maxima not try itself some substitutions if integrate is called?  Comment By: Aleksas Domarkas (alex108) Date: 20100326 14:40 Message: (%i1) S:'integrate(x*exp(1/2*(xm)^2),x); (%o1) integrate(x*%e^((xm)^2/2),x) (%i2) changevar(S, y=xm, y, x); (%o2) integrate((y+m)*%e^(y^2/2),y) (%i3) ev(%, nouns); (%o3) (sqrt(%pi)*m*erf(y/sqrt(2)))/sqrt(2)%e^(y^2/2) Solution: (%i4) sol:subst(y=xm,%),rootscontract; (%o4) sqrt(%pi/2)*m*erf((xm)/sqrt(2))%e^((xm)^2/2) Test: (%i5) diff(sol,x)first(S)$ (%i6) expand(%); (%o6) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2977217&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 16:03:40

Bugs item #2996106, was opened at 20100503 21:42 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2996106&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: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: at(diff(f(x,y),x,1,y,1),[x=a,y=b]) is wrong Initial Comment: The following is wrong. The equation y=b is substituted into the expression: (%i7) at(diff(f(x,y),x,1,y,1),[x=a,y=b]); (%o7) 'at('diff(f(x,b),x,1,b,1),[x = a,y = b]) The correct result is 'at('diff(f(x,y),x,1,y,1),[x = a,y = b]) The error is present since Maxima 5.20. The problem is in the routine substexceptsecondarg which has been added with revision 1.37 of comm.lisp. A trace of this routine shows the wrong subsitution: (%i7) at(diff(f(x,y),x,1,y,1),[x=a,y=b]); 0: (SUBSTEXCEPTSECONDARG $A $X ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 0: SUBSTEXCEPTSECONDARG returned ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1) 0: (SUBSTEXCEPTSECONDARG $B $Y ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 0: SUBSTEXCEPTSECONDARG returned ((%DERIVATIVE SIMP) (($F SIMP) $X $B) $X 1 $B 1) (%o7) 'at('diff(f(x,b),x,1,b,1),[x = a,y = b]) Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100605 18:03 Message: Fixed in comm.lisp revision 1.52. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2996106&group_id=4933 
From: SourceForge.net <noreply@so...>  20100605 13:59:06

Bugs item #2013668, was opened at 20080708 19:32 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013668&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: floor/ceiling(NaN) => finite number Initial Comment: floor(gamma(250.0)) => an integer near 2*10^308 (floatmax). But gamma(250.0) is returning a NaN, so floor should give an error. Of course it shouldn't, but it's better if other code would be NaNproof. GCL's floor function is the culprit (the CL spec seems to be silent on NaN behavior, though you'd think that (floor NaN) should be an error). simpfloor and company should check explicitly for NaNs. This is easier said than done, since in GCL (= (gammalanczos 250.0) (gammalanczos 260.0)) => t, but NaNs are supposed to compare nonequal to themselves.... What's a reliable test for NaN/inf in GCL? Maxima 5.14.0 GCL Windows  >Comment By: Dieter Kaiser (crategus) Date: 20100605 15:59 Message: As written in the last posting gamma signals an overflow error for GCL and Lisps too. This has changed with revision 1.22 of csimp2.lisp. The example of this bug report no longer gives a wrong answer. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20080922 00:28 Message: gammalanczos no longer returns a float value beyond extreme values (csimp2.lisp, Rev. 1.22). Maxima signals an overflow error. Therefore Maxima no longer calculate a wrong result for floor(gamma(250.0)) too. I think for this special example the bug report could be closed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2013668&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 23:46:20

Bugs item #2998923, was opened at 20100509 15:18 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998923&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: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: partfrac doesn't work correct with keepfloat:true; Initial Comment: Kind of annoying artifact. partfrac() works perfect with CRE, but only partly with FLOAT  >Comment By: Dieter Kaiser (crategus) Date: 20100605 01:46 Message: I think it might be a missing feature that partfrac does not work with keepfloat:true. But it is possible to get a floating point approximation with the function float: (%o1) 7/((0.65*s+1)*s*(1.6*s+1)) (%i2) float(partfrac(expr,s)); rat: replaced 0.65 by 13/20 = 0.65 rat: replaced 1.6 by 8/5 = 1.6 (%o2) 62.26315789473684/(13.0*s+20.0)94.3157894736842/(8.0*s+5.0)+7.0/s Furthermore, the documentation of partfrac seems to be placed in the wrong chapter "Number Theory". It might be better to put the documentation into the chapter "Polynomials". Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998923&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 23:16:30

Bugs item #2723549, was opened at 20090331 18:15 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2723549&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Martin (mhs) Assigned to: Nobody/Anonymous (nobody) Summary: diff display error for nonint. order and derivabbrev: true Initial Comment: for noninteger order of the derivative, diff can't display anything when derivabbrev: true, see example below. (%i1) derivabbrev: false; (%o1) false (%i2) this:diff(f(x), x, n); (%o2) 'diff(f(x),x,n) (%i3) derivabbrev: true; (%o3) true (%i4) this; Maxima encountered a Lisp error: Error in > [or a callee]: $N is not of type (OR RATIONAL LISP:FLOAT). Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20100605 01:16 Message: With the current CVS version of Maxima I can not reproduce the reported problem: Maxima version: 5.20post Maxima build date: 21:58 6/4/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian (%i1) derivabbrev:false$ (%i2) this:diff(f(x),x,n); (%o2) 'diff(f(x),x,n) (%i3) derivabbrev:true$ (%i4) this; (%o4) 'diff(f(x),x,n) Perhaps, it is a problem with an earlier version of Maxima. We have no build_info for this bug report. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2723549&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 21:12:11

Bugs item #1929287, was opened at 20080330 13:34 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1929287&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: None >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 + [0] > [0] Initial Comment: OK: (%i1) 0.0 + 0; (%o1) 0.0 Not OK; (%o2) should be [0.0], not [0] (%i2) 0.0 + [0]; (%o2) [0] Also, 0.0b0 + [0] > [0]. Matrix addition has the same bug: (%i6) 0.0 + matrix([0,0]); (%o6) matrix([0,0])  >Comment By: Dieter Kaiser (crategus) Date: 20100604 23:12 Message: Fixed in simp.lisp revison 1.111. We get (%i2) 0.0+[0]; (%o2) [0.0] (%i3) 0.0+matrix([0,0]); (%o3) matrix([0.0,0.0]) Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080419 18:32 Message: Logged In: YES user_id=501686 Originator: NO I'm guessing that the behavior 0.0 + [0] => [0] comes from the same place as 0.0 + foo => foo, 0.0 + foo(x) => foo(x). Maybe we should disallow the simplification (inexact zero) + (whatever) => (whatever). Not sure what we should do at this point.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1929287&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 19:42:37

Bugs item #3010525, was opened at 20100602 16:58 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010525&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: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Creidieki M. Crouch (creidieki) Assigned to: Nobody/Anonymous (nobody) Summary: abs documentation doesn't explain mapping behavior Initial Comment: The documentation for the abs(expr) function doesn't mention that it maps over structures. (In my testing, it seems to map over lists but not matrices?).  >Comment By: Dieter Kaiser (crategus) Date: 20100604 21:42 Message: As suggested the abs function has been implemented to have the property distribute_over in simp.lisp 1.110. Furthermore, the documentation has been updated in Operators.texi 1.59 and Simplification.texi 1.26. These are the properties of the abs function: (%i2) properties(abs); (%o2) [integral,rule,"distributes over bags",noun,gradef,"system function"] The properties NOUN and DISTRIBUTE OVER BAGS are new. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100604 19:14 Message: I had a look at the implementation of the abs function. I think we should cut out the mapping over bags from the simplifying function simpabs and put the property distribute_over on the property list. In general, we have the possibility to look up the properties of a function with the Maxima command properties. For the abs function we get (%i8) properties(abs); (%o8) [rule, gradef] This is an example for the Bessel J function. We get much more information: (%i9) properties(bessel_j); (%o9) [conjugate function, complex characteristic, limit function, integral, gradef, distributes over bags, rule, noun, transfun] Some time ago we extended the function properties to show more correct the properties. We can even extend it and we should document the function properties better. By the way: I have detected that we support the symbol %mabs. This is a workaround to get the correct simplification of a noun form like 'abs(1). But this is not necessary. The underlying problem is that the properties noun, verb, alias and reversealiase are not implemented correctly for the abs function. When we correct this we no longer need to support the symbol '%mabs. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20100603 07:15 Message: abs automatically maps over lists, matrices, and equations. (%i81) abs ([1, 2]); (%o81) [1, 2] (%i82) abs (matrix ([1, 2])); (%o82) [ 1 2 ] (%i83) abs (1 = 2); (%o83) 1 = 2 There isn't any way to discover that short of reading the source code (which is how I figured it out). That's a bug in the documentation, as pointed out by the original poster. Aside from the documentation, there ought to be a way to easily discover the algebraic properties of functions. This mappingoverobjects is hardwired in the code, it's not a declared property. It's not a bug since it works OK but still it would be better to have discoverable properties.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010525&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 18:46:42

Bugs item #1852344, was opened at 20071217 15:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1852344&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: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sort(rat(...)) internal error Initial Comment: sort(rat([x=1,y=1])) => fatal error Maxima 5.13.0 GCL 2.6.8 Windows XP  >Comment By: Dieter Kaiser (crategus) Date: 20100604 20:46 Message: This bug has been fixed some times ago in simp.lisp revision 1.106. We get the results: (%i1) sort(rat([x=1,y=1])); (%o1) [x = 1,y = 1] (%i2) orderlessp(rat(a=1),rat(b=1)); (%o2) true Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080615 03:34 Message: Logged In: YES user_id=501686 Originator: NO I take it back. orderlessp(rat(a=1),rat(b=1)) => error after all.  Comment By: Robert Dodier (robert_dodier) Date: 20080615 03:26 Message: Logged In: YES user_id=501686 Originator: NO Maxima 5.14.99rc1: sort(rat([x=1, y=1])) => error orderlessp(rat(a=1),rat(b=1)) => true (not an error as observed before)  Comment By: Barton Willis (willisbl) Date: 20071218 19:29 Message: Logged In: YES user_id=895922 Originator: NO Changing ratdisrep to $totaldisrep in $sort makes this bug go away. But I don't know if this is the right thing to do. (defmfun $sort (l &optional (f 'lessthan)) (let ((llist l) comparfun bfun) (unless ($listp llist) (merror "The first argument to `sort' must be a list:~%~M" llist)) (setq llist (copylist (cdr llist)) comparfun (mfunction1 (setq bfun (getopr f)))) (when (member bfun '(lessthan great) :test #'eq) (setq llist (mapcar #'$totaldisrep llist))) (cons '(mlist simp) (sort llist comparfun))))  Comment By: Nobody/Anonymous (nobody) Date: 20071218 16:07 Message: Logged In: NO Re: e: rat(x=1)$ ratp(e) => false; ratp(lhs(e)) => true This is as designed (though it may be surprising that ratp(rat(...)) isn't always true. After all, there is no way to represent relational operators in CRE form. > ratdisrep doesn't convert the left and right sides of e to general form. This is normal. ratdisrep only disreps the top level. You need totaldisrep to disrep all the way down. You get the same thing with rat([x,y]). Which brings up another bug...: rat([(x^21)/(x1)]) => [x1] but rat({(x^21)/(x1)}) => {(x^21)/(x1)} This is precisely *because* ratp(rat({x})) = true! (%i54) rat([(x^21)/(x1)]); Evaluation took 0.00 seconds (0.00 elapsed) (%o54)/R/ [x + 1]  Comment By: Barton Willis (willisbl) Date: 20071218 13:32 Message: Logged In: YES user_id=895922 Originator: NO I think there is a bug / weirdness with the way rat interacts with = expressions. (%i1) e : rat(x=1)$ We have ratp(e) > false and ratp(first(e)) > true. (%i2) ratp(e); (%o2) false (%i3) ratp(first(e)); (%o3) true Also, ratdisrep doesn't convert the left and right sides of e to general form. (%i4) e : ratdisrep(e)$ (%i5) ratp(first(e)); (%o5) true  Comment By: Stavros Macrakis (macrakis) Date: 20071217 20:10 Message: Logged In: YES user_id=588346 Originator: YES This appears to come from orderlessp(rat(a=1),rat(b=1)) => fatal error  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1852344&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 17:14:54

Bugs item #3010525, was opened at 20100602 16:58 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010525&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Creidieki M. Crouch (creidieki) Assigned to: Nobody/Anonymous (nobody) Summary: abs documentation doesn't explain mapping behavior Initial Comment: The documentation for the abs(expr) function doesn't mention that it maps over structures. (In my testing, it seems to map over lists but not matrices?).  >Comment By: Dieter Kaiser (crategus) Date: 20100604 19:14 Message: I had a look at the implementation of the abs function. I think we should cut out the mapping over bags from the simplifying function simpabs and put the property distribute_over on the property list. In general, we have the possibility to look up the properties of a function with the Maxima command properties. For the abs function we get (%i8) properties(abs); (%o8) [rule, gradef] This is an example for the Bessel J function. We get much more information: (%i9) properties(bessel_j); (%o9) [conjugate function, complex characteristic, limit function, integral, gradef, distributes over bags, rule, noun, transfun] Some time ago we extended the function properties to show more correct the properties. We can even extend it and we should document the function properties better. By the way: I have detected that we support the symbol %mabs. This is a workaround to get the correct simplification of a noun form like 'abs(1). But this is not necessary. The underlying problem is that the properties noun, verb, alias and reversealiase are not implemented correctly for the abs function. When we correct this we no longer need to support the symbol '%mabs. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20100603 07:15 Message: abs automatically maps over lists, matrices, and equations. (%i81) abs ([1, 2]); (%o81) [1, 2] (%i82) abs (matrix ([1, 2])); (%o82) [ 1 2 ] (%i83) abs (1 = 2); (%o83) 1 = 2 There isn't any way to discover that short of reading the source code (which is how I figured it out). That's a bug in the documentation, as pointed out by the original poster. Aside from the documentation, there ought to be a way to easily discover the algebraic properties of functions. This mappingoverobjects is hardwired in the code, it's not a declared property. It's not a bug since it works OK but still it would be better to have discoverable properties.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010525&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 11:03:17

Bugs item #3011321, was opened at 20100604 04:00 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&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  Differential eqns Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: diff(log(log(x^2)),x); return incorrect value Initial Comment: hello folks before i begin , let me say that i am not a native english speaker so i am going to do my best i discoveved a bug checking a results of a test yersterday in evaluatting the follow statemen [output] (%i1) diff(log(log(x^2)),x); 1 (%o1)  x log(x) (%i2) [/output] the result of such expression should be 2/(x*(log(x)))  >Comment By: Dieter Kaiser (crategus) Date: 20100604 13:03 Message: Closing this bug report. Dieter Kaiser  Comment By: https://www.google.com/accounts () Date: 20100604 05:42 Message: sorry about that i read wrong , please close this bug, and sorry  Comment By: Raymond Toy (rtoy) Date: 20100604 04:58 Message: log(log(x^2)) = log(2*log(x)) = log(2)+log(log(x)). (Assuming real x > 0). The derivative of log(log(x)) is 1/(x*log(x)). Or perhaps you were expecting maxima to return 2/(x*log(x^2)), which is equivalent to 1/(x*log(x)). Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 05:46:32

Bugs item #3000108, was opened at 20100511 12:26 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3000108&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: uhlst (uhlst) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency of 1x1matrices Initial Comment: I'm not quite sure whether this is a bug or not, but defining two 1x1 matrices and multiplying them with "." returns a scalar and not a matrix. Multiplying them both by "*" gives a matrix. It should in this case either give also a scalar or an error. So the question is, whether Maxima should automatically switch from 1x1 matrices to scalars and back. I think returning a scalar for the "." is ok if the same happens for "*". (%i7) kill(all); (%o0) done (%i1) a: matrix([1]);b: matrix([2]); (%o1) [ 1 ] (%o2) [ 2 ] (%i3) a.b; (%o3) 2 (%i4) a*b; (%o4) [ 2 ] (%i5) c: 2; (%o5) 2 (%i6) c.a; (%o6) [ 2 ] (%i7) c*a; (%o7) [ 2 ]  >Comment By: Robert Dodier (robert_dodier) Date: 20100603 23:46 Message: As I don't see a bug reported here, I'm closing this report. To uhlst: general questions about how to use Maxima should probably be posted to the Maxima mailing list. See: http://maxima.sourceforge.net/maximalist.html  Comment By: uhlst (uhlst) Date: 20100514 00:03 Message: I think, setting doallmxops : false and domxmxops : false will prevent Maxima from carrying out the calculation and it returns a "noun" form. In my opinion, Maxima should give an error as the number of rows of b are less then the number of columns of A in my example. But Maxima seems to have an inherent conversion function which transforms the row vector into a column vector.  Comment By: Barton Willis (willisbl) Date: 20100513 14:27 Message: I think setting doallmxops : false and domxmxops : false will do what you want. Maxima's dot operation is controlled by many sometimes confusing switches. But it's all documented (try ?domxmxops) (%i2) (A: matrix([1,2,3],[4,5,6],[7,8,9]),b:matrix([10,11,12])); (%o2) matrix([10,11,12]) (%i18) A .b,doallmxops : false, domxmxops : false; (%o18) matrix([1,2,3],[4,5,6],[7,8,9]) . matrix([10,11,12])  Comment By: uhlst (uhlst) Date: 20100513 12:29 Message: thank you for pointing me to scalarmatrixp. I was not aware of this option in Maxima. However, I still struggle with the automatic conversion of a row vector to a column vector. Is there also a option to switch this behaviour of? (%i1) display2d: false;A: matrix([1,2,3],[4,5,6],[7,8,9]);b: matrix([10,11,12]); (%o1) false (%o2) matrix([1,2,3],[4,5,6],[7,8,9]) (%o3) matrix([10,11,12]) (%i4) A.b; (%o4) matrix([68],[167],[266])  Comment By: Barton Willis (willisbl) Date: 20100512 03:49 Message: Maybe you would like to set scalarmatrixp to false: (%i4) matrix([a]) . matrix([b]), scalarmatrixp : false; (%o4) matrix([a*b]) (%i5) matrixp(%); (%o5) true (%i6) matrix([a]) . matrix([b]), scalarmatrixp : true; (%o6) a*b  Comment By: uhlst (uhlst) Date: 20100511 23:52 Message: here again the commands with display2d: false (%i2) display2d: false; (%o2) false (%i3) kill(all); (%o0) done (%i1) a: matrix([1],[2],[3]); (%o1) matrix([1],[2],[3]) (%i2) B: matrix([1,2,3],[4,5,6],[7,8,9]); (%o2) matrix([1,2,3],[4,5,6],[7,8,9]) (%i3) a.B; MULTIPLYMATRICES: attempt to multiply nonconformable matrices.  an error. To debug this try: debugmode(true); (%i4) B.(transpose(a)); (%o4) matrix([14],[32],[50]) (%i5) B.transpose(a); (%o5) matrix([14],[32],[50]) (%i6) B.a; (%o6) matrix([14],[32],[50])  Comment By: uhlst (uhlst) Date: 20100511 23:48 Message: perhaps related is the following "automatic" conversion that maxima does (%i15) kill(all); (%o0) done (%i1) a: matrix([1],[2],[3]); [ 1 ] [ ] (%o1) [ 2 ] [ ] [ 3 ] (%i2) B: matrix([1,2,3],[4,5,6],[7,8,9]); [ 1 2 3 ] [ ] (%o2) [ 4 5 6 ] [ ] [ 7 8 9 ] (%i3) a.B; MULTIPLYMATRICES: attempt to multiply nonconformable matrices.  an error. To debug this try: debugmode(true); (%i4) B.a; [ 14 ] [ ] (%o4) [ 32 ] [ ] [ 50 ] (%i5) B.(transpose(a)); [ 14 ] [ ] (%o5) [ 32 ] [ ] [ 50 ] (%i6) B.transpose(a); [ 14 ] [ ] (%o6) [ 32 ] [ ] [ 50 ] so multiplying a column vector with a square matrix from the left does not work but multiplying a matrix with a row vector from the left works.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3000108&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 03:42:21

Bugs item #3011321, was opened at 20100604 02:00 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&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  Differential eqns Group: None >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: diff(log(log(x^2)),x); return incorrect value Initial Comment: hello folks before i begin , let me say that i am not a native english speaker so i am going to do my best i discoveved a bug checking a results of a test yersterday in evaluatting the follow statemen [output] (%i1) diff(log(log(x^2)),x); 1 (%o1)  x log(x) (%i2) [/output] the result of such expression should be 2/(x*(log(x)))  >Comment By: https://www.google.com/accounts () Date: 20100604 03:42 Message: sorry about that i read wrong , please close this bug, and sorry  Comment By: Raymond Toy (rtoy) Date: 20100604 02:58 Message: log(log(x^2)) = log(2*log(x)) = log(2)+log(log(x)). (Assuming real x > 0). The derivative of log(log(x)) is 1/(x*log(x)). Or perhaps you were expecting maxima to return 2/(x*log(x^2)), which is equivalent to 1/(x*log(x)). Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 02:58:08

Bugs item #3011321, was opened at 20100603 22:00 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&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  Differential eqns Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: diff(log(log(x^2)),x); return incorrect value Initial Comment: hello folks before i begin , let me say that i am not a native english speaker so i am going to do my best i discoveved a bug checking a results of a test yersterday in evaluatting the follow statemen [output] (%i1) diff(log(log(x^2)),x); 1 (%o1)  x log(x) (%i2) [/output] the result of such expression should be 2/(x*(log(x)))  >Comment By: Raymond Toy (rtoy) Date: 20100603 22:58 Message: log(log(x^2)) = log(2*log(x)) = log(2)+log(log(x)). (Assuming real x > 0). The derivative of log(log(x)) is 1/(x*log(x)). Or perhaps you were expecting maxima to return 2/(x*log(x^2)), which is equivalent to 1/(x*log(x)). Marking as pending/invalid.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 02:53:47

Bugs item #3010829, was opened at 20100603 00:50 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010829&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: numerical evaluation of elliptic_ec fails for argument > 1 Initial Comment: (%i60) elliptic_ec (1.7); The assertion (AND (>= X 0) (>= Y 0) (>= Z 0) (PLUSP (+ X Y)) (PLUSP (+ X Z)) (PLUSP (+ Y Z))) failed. which appears to originate in the function DRF. Not sure what is the right answer here, but at any rate it shouldn't be a Lisp error.  >Comment By: Raymond Toy (rtoy) Date: 20100603 22:53 Message: Fixed in ellipt.lisp, rev 1.73.  Comment By: Raymond Toy (rtoy) Date: 20100603 18:27 Message: Agreed. Curiously, elliptic_ec(1.7b0) returns a complex number, which appears to be correct. The issue is that the algorithm for floats assumes that m <= 1, but the bfloat algorithm is correct for all values of m. This will be fixed shortly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010829&group_id=4933 
From: SourceForge.net <noreply@so...>  20100604 02:00:37

Bugs item #3011321, was opened at 20100604 02:00 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&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  Differential eqns Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: diff(log(log(x^2)),x); return incorrect value Initial Comment: hello folks before i begin , let me say that i am not a native english speaker so i am going to do my best i discoveved a bug checking a results of a test yersterday in evaluatting the follow statemen [output] (%i1) diff(log(log(x^2)),x); 1 (%o1)  x log(x) (%i2) [/output] the result of such expression should be 2/(x*(log(x)))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3011321&group_id=4933 
From: SourceForge.net <noreply@so...>  20100603 22:38:33

Bugs item #3010820, was opened at 20100603 00:23 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010820&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: numerical evaluation of elliptic_kc fails for rat argument Initial Comment: :lisp (let (($numer t)) ($elliptic_kc '((rat) 1 3))) => Error in SYSTEM::TRACECALL [or a callee]: ((RAT SIMP) 1 3) is not of type (OR RATIONAL LISP:FLOAT). The error appears to be in SIMP%ELLIPTIC_KC or a callee of that. This bug is triggered by anything that calls COERCEFLOATFUN to construct a Lisp function, e.g. plotting, find_root, quadrature. I would guess other elliptic functions might have the same problem but I didn't look.  >Comment By: Raymond Toy (rtoy) Date: 20100603 18:38 Message: Fixed in ellipt.lisp, rev 1.72  Comment By: Raymond Toy (rtoy) Date: 20100603 17:56 Message: This is basically caused by calling float instead of $float in simp%elliptic_kc. As you guessed, there are other places. This will be fixed shortly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010820&group_id=4933 
From: SourceForge.net <noreply@so...>  20100603 22:27:44

Bugs item #3010829, was opened at 20100603 00:50 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010829&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: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: numerical evaluation of elliptic_ec fails for argument > 1 Initial Comment: (%i60) elliptic_ec (1.7); The assertion (AND (>= X 0) (>= Y 0) (>= Z 0) (PLUSP (+ X Y)) (PLUSP (+ X Z)) (PLUSP (+ Y Z))) failed. which appears to originate in the function DRF. Not sure what is the right answer here, but at any rate it shouldn't be a Lisp error.  >Comment By: Raymond Toy (rtoy) Date: 20100603 18:27 Message: Agreed. Curiously, elliptic_ec(1.7b0) returns a complex number, which appears to be correct. The issue is that the algorithm for floats assumes that m <= 1, but the bfloat algorithm is correct for all values of m. This will be fixed shortly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010829&group_id=4933 
From: SourceForge.net <noreply@so...>  20100603 21:56:11

Bugs item #3010820, was opened at 20100603 00:23 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010820&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: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: numerical evaluation of elliptic_kc fails for rat argument Initial Comment: :lisp (let (($numer t)) ($elliptic_kc '((rat) 1 3))) => Error in SYSTEM::TRACECALL [or a callee]: ((RAT SIMP) 1 3) is not of type (OR RATIONAL LISP:FLOAT). The error appears to be in SIMP%ELLIPTIC_KC or a callee of that. This bug is triggered by anything that calls COERCEFLOATFUN to construct a Lisp function, e.g. plotting, find_root, quadrature. I would guess other elliptic functions might have the same problem but I didn't look.  >Comment By: Raymond Toy (rtoy) Date: 20100603 17:56 Message: This is basically caused by calling float instead of $float in simp%elliptic_kc. As you guessed, there are other places. This will be fixed shortly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010820&group_id=4933 
From: SourceForge.net <noreply@so...>  20100603 15:54:37

Bugs item #2998214, was opened at 20100507 09:18 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998214&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cell can't end with a comment Initial Comment: When the last line in a cell is comment, maxima comlains about premature termination of input. To reproduce: Just enter a comment only in a input cell. /*Comment*/ and evaluate. Why do you need that? If you want to do somehting like this: a:99 /*assign a the magic value*/  >Comment By: Robert Dodier (robert_dodier) Date: 20100603 09:54 Message: This is actually a bug in the Maxima parser if I am not mistaken; it is not specific to wxMaxima so far as I know. At one time (maybe it is still true) the parser would barf on a batch script if it ended with a comment. I just tried that with Maxima 5.20.0 + GCL + Windows but the script was loaded successfully. Maybe the bug has been fixed? Need to test on other platforms and Lisp implementations. To the original poster: what does build_info(); report? Here is my test script: x:1; /* comment */  Comment By: Nobody/Anonymous (nobody) Date: 20100527 00:55 Message: Got it. A comment can't be the only text in a field. /*comment*/a:99 and a:99/*comment*/ both work ok. wxMaxima appears to append a semicolon to the line if it is absent. /*comment*/ gets a semicolon appended, then an error message "incorrect syntax: Premature termination of input at ;. /*comment*/; ^" With the caret indicating the closing slash of the comment. Using a $ terminator gets a similar message, no semicolon is appended, and the caret indicates the closing slash as before.  Comment By: Peter Cusack (pogo1) Date: 20100526 19:53 Message: I note that wmMaxima version 0.8.5 helpfully adds a semicolon and that fixes the problem sometimes. I'm still trying to make it reproducibly fail. If the line contains a $ terminator before the comment ( like this B0:i*Mu0/(2*a)/*Field at centre of single turn*/$) then adding the semicolon at the end makes Maxima hang.  Comment By: l_butler () Date: 20100520 02:16 Message: Hi, I think the problem is that Maxima input must be terminated with a semicolon: a:99; /* comment */ a:99 /* comment */; Both are valid inputs that assign 99 to a.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998214&group_id=4933 
From: SourceForge.net <noreply@so...>  20100603 11:37:34

Bugs item #3010131, was opened at 20100601 17:44 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010131&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: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: floor gradef in abs_integrate Initial Comment: OK: (%i1) load(abs_integrate)$ (%i2) diff(floor(z),z); (%o2) %if(%integerp(z),und,0) Not OK: (%i2) declare(x,noninteger); (%o2) done (%i5) load(abs_integrate)$ (%i4) diff(floor(z),z); (%o4) 0  >Comment By: Barton Willis (willisbl) Date: 20100603 06:37 Message: fixed by abs_integrate CVS revision 1.27  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3010131&group_id=4933 
From: Eduardo Liz <eliz@dm...>  20100603 11:23:15

When running Maxima.app, I got the following: The function bug_report() provides bug reporting information. stdin:229:Incorrect syntax: s is not an infix operator Maxima encountered a Lisp error: attempt to THROW to a tag that does not exist: MACSYMAQUIT Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. debugger invoked on a SBINT:SIMPLECONTROLERROR in thread #<THREAD "initial thread" RUNNING {13251131}>: attempt to THROW to a tag that does not exist: RETURNFROMDEBUGGER Type HELP for debugger help, or (SBEXT:QUIT) to exit from SBCL. restarts (invokable by number or by possiblyabbreviated name): 0: [MACSYMAQUIT] Maxima toplevel 1: [CONTINUE ] Ignore runtime option eval "(cluser::run)". 2: [ABORT ] Skip rest of eval and load options. 3: Skip to toplevel READ/EVAL/PRINT loop. 4: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ("no debug information for frame") Please, help. ************************************************** Eduardo Liz Departamento de Matemática Aplicada II E.T.S.E. Telecomunicación Campus Marcosende Universidade de Vigo 36310 Vigo (Spain) ************************************************** 
From: SourceForge.net <noreply@so...>  20100603 06:39:51

Bugs item #3005232, was opened at 20100521 04:27 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3005232&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: Invalid Priority: 5 Private: No Submitted By: Hirotaka NIITSUMA (niitsuma) Assigned to: Nobody/Anonymous (nobody) Summary: Another function local variable affected. Scope broken? Initial Comment: In the following code f local variavle affect g resut  g(x,y):=block([z],[x,z[2]] ); g(1,2); /* => [1, z ] */ f(x,y):=block([z] ,z[1]:x ,z[2]:y ,[x,z[2]] ); f(1,2); /* => [1, 2 ] */ g(1,2); /* =>[1, 2 ] not [1, z_2 ] I except former result */   >Comment By: Robert Dodier (robert_dodier) Date: 20100603 00:39 Message: Actually that is the expected behavior, because array definitions (as with function definitions) are global, even if they appear within a block. I think you can make the array truly local by using the local function, e.g. try something like: f(x, y) := block (local (z), z[1]:x, etc etc); Closing this report as invalid since it is not a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3005232&group_id=4933 