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}
(83) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(6) 
2
(2) 
3

4

5

6

7
(6) 
8
(2) 
9

10
(1) 
11
(1) 
12
(3) 
13
(1) 
14
(8) 
15
(3) 
16
(5) 
17
(1) 
18

19

20
(2) 
21
(6) 
22
(3) 
23
(1) 
24
(1) 
25
(5) 
26
(5) 
27

28
(3) 
29

30

31
(2) 

From: SourceForge.net <noreply@so...>  20090731 19:03:23

Bugs item #2830468, was opened at 20090731 20:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2830468&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: integration Initial Comment: Some time ago I have report bug: 2797885 and it was fixed. Today I have downloaded source 5.18.1 and build maxima and there is the same problem. Probably I don't know something...  >Comment By: Dieter Kaiser (crategus) Date: 20090731 21:03 Message: The bug has been fixed in May 2009. That is after the release of Maxima 5.18.1. Therefore the fix is not part of this release. The fix is part of the current CVS Version and will be part of the next release which will come at the beginning of August. Setting this bug report to pending. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2830468&group_id=4933 
From: SourceForge.net <noreply@so...>  20090731 18:39:41

Bugs item #2830468, was opened at 20090731 18:39 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2830468&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: integration Initial Comment: Some time ago I have report bug: 2797885 and it was fixed. Today I have downloaded source 5.18.1 and build maxima and there is the same problem. Probably I don't know something...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2830468&group_id=4933 
From: SourceForge.net <noreply@so...>  20090728 14:01:21

Bugs item #2828399, was opened at 20090728 14:01 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2828399&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: Failure of Taylor expansion Initial Comment: When I apply the function 'taylor(function,z,..., ...)' to a function containing the d/dz operator, it works correctly. However if the differential is of another variable it fails. Thus: ================================= (%i1) G : diff(a(x,z),z,1); d (%o1)  (a(x, z)) dz (%i2) H : taylor(G,z,0,1); ! ! 2 ! d ! d ! (%o2)/T/  (a(x, z))! + ( (a(x, z))! ) z + . . . dz ! 2 ! !z = 0 dz ! !z = 0 ================================= works, but: ================================= (%i3) G : diff(a(x,z),x,1); d (%o3)  (a(x, z)) dx (%i4) H : taylor(G,z,0,1); d (%o4)/T/  (a(x, z)) + . . . dx ================================= fails. Regards, David Webb.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2828399&group_id=4933 
From: SourceForge.net <noreply@so...>  20090728 02:20:26

Bugs item #596204, was opened at 20020816 18:34 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=596204&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: Installation Group: None >Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: James Amundson (amundson) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler warnings Initial Comment: The Maxima build generates many compiler warnings for alll lisps. They should be eliminated if at all possible.  >Comment By: SourceForge Robot (sfrobot) Date: 20090728 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20090713 21:40 Message: At least with GCL 2.6.8 and CLISP 2.44 there are no longer "many" compiler warnings. Most of the warnings might have gone over the last years. GCL gives no warnings and CLISP only a few. I think this bug report is out of date. Perhaps a new bug report can be opened,when we have more specific problems. Closing this bug report as "out of date". Setting status to "pending". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=596204&group_id=4933 
From: SourceForge.net <noreply@so...>  20090728 00:21:21

Bugs item #2795799, was opened at 20090523 05:55 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795799&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: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Robert Dodier (robert_dodier) Summary: lsquares_estimates_approximate ignores initial Initial Comment: The following example is selfexplanatory. >> load(lsquares)$ >> M:matrix( [1900,75.995], [1910,91.972], [1920,105.711], [1930,123.203], [1940,131.669], [1950,150.697], [1960,179.323], [1970,203.212], [1980,226.505], [1990,249.633], [2000,281.422] )$ mse:lsquares_mse(M,[x,y],y=a*exp(b*(x1900)));  The problem appears to be that lsquares_estimates_approximate ignores the initial value passed to it: lsquares_estimates_approximate(mse,'[a,b],initial=[82,0.01],iprint=[1,3]); ************************************************* VECTOR X= 1.000000000000000D+00 1.000000000000000D+00 GRADIENT VECTOR G= 1.313813415094471D+86 1.313813414823674D+88 You can see that the initial vector X is [1,1], although [82,0.01] is passed. The minimisation diverges because of the poor initial condiition. If you redefine mse so that [1,1] is a reasonable initial value, you will get an estimate: mse:subst([a=82*a,b=0.01*b],mse)$ lsquares_estimates_approximate(mse,'[a,b],iprint=[1,3]); THE MINIMIZATION TERMINATED WITHOUT DETECTING ERRORS. IFLAG = 0 [[a = 1.005034579667296, b = 1.243184045872825]]  >Comment By: Robert Dodier (robert_dodier) Date: 20090727 18:21 Message: Fixed by r1.8 share/contrib/lsquares.mac: changes initial_guess to initial. Closing this report as fixed.  Comment By: Leo Butler (l_butler) Date: 20090523 11:51 Message: Robert, In the documentation, the initial guess is specified by 'initial =' while in lsquares.mac, you use 'initial_guess'. If you change 'initial_guess' to 'initial', this fixes the problem  Function: lsquares_estimates_approximate (<MSE>, <a>, initial = <L>, tol = <t>) lsquares_estimates_approximate (MSE, parameters, [optional_args]) := block ([initial_guess : makelist (1, i, 1, length (parameters)), iprint : [1, 0], tol : 1e3], with_parameters (optional_args, lbfgs (MSE, parameters, initial_guess, tol, iprint), [%%])); Leo  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2795799&group_id=4933 
From: SourceForge.net <noreply@so...>  20090726 22:21:36

Bugs item #2827474, was opened at 20090726 23:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2827474&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(log(sec(x)),x) > lisp error Initial Comment: (%i4) integrate(log(sec(x)),x); Maxima encountered a Lisp error: (%i5) build_info(); Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 (%o5)  >Comment By: Dieter Kaiser (crategus) Date: 20090727 00:21 Message: With the current CVS version and in a fresh Maxima this problem is not present: Maxima version: 5.18post Maxima build date: 0:14 7/27/2009 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.44.1 (20080223) (built 3436700604) (memory 3457635278) (%i4) integrate(log(sec(x)),x); (%o4) (x*log(sin(2*x)^2+cos(2*x)^2+2*cos(2*x)+1) +2*%i*x*atan2(sin(2*x),cos(2*x)+1)%i*li[2](%e^(2*%i*x))%i*x^2) /2 +x*log(sec(x)) I have not checked the result. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2827474&group_id=4933 
From: SourceForge.net <noreply@so...>  20090726 21:52:35

Bugs item #2827474, was opened at 20090726 16:52 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2827474&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(log(sec(x)),x) > lisp error Initial Comment: (%i4) integrate(log(sec(x)),x); Maxima encountered a Lisp error: (%i5) build_info(); Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 (%o5)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2827474&group_id=4933 
From: SourceForge.net <noreply@so...>  20090726 12:32:19

Bugs item #2827331, was opened at 20090726 07:32 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2827331&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: resultant & algebraic : true > quotient not exact Initial Comment: I should look for a smaller example... With algebraic = false, OK: (%i1) resultant(658952*x^3+((1776*sqrt(37)9647)*((1776*sqrt(37)9647)^(1/3))^2+82369*(1776*sqrt(37)9647)^(1/3)+4036081)*x^2+ ((7104*sqrt(37)38588)*((1776*sqrt(37)9647)^(1/3))^2+329476*(1776*sqrt(37)9647)^(1/3)+6260044)*x+(7104*sqrt(37)38588)*((1776*sqrt(37)9647)^(1/3))^2+329476* (1776*sqrt(37)9647)^(1/3)+5601092,((1776*sqrt(37)+9647)*((1776*sqrt(37)9647)^(1/3))^282369*(1776*sqrt(37)9647)^(1/3)4036081)*x^2+ ((14208*sqrt(37)+77176)*((1776*sqrt(37)9647)^(1/3))^2658952*(1776*sqrt(37)9647)^(1/3)12520088)*x+(21312*sqrt(37)+115764)*((1776*sqrt(37)9647)^(1/3))^2988428* (1776*sqrt(37)9647)^(1/3)16803276,x); (%o1) 63259392*((1776*sqrt(37)9647)^(4/3)*(149550664320828645840*sqrt(37)+996465692476197624289)+(1776*sqrt(37)9647)^(5/3)*(7886642286489394848*sqrt(37)+51019025130868750039)+(1776*sqrt(37)9647)^2*(410349627024955632*sqrt(37)+2552620562180128391)+(1776*sqrt(37)9647)^(8/3)*(14375957813878848*sqrt(37)+87447323236375873)+(231659666025286464*sqrt(37)1408621778456986940)*(1776*sqrt(37)9647)^(7/3)+(1709100058195259761248*sqrt(37)8501072671220284640149)*(1776*sqrt(37)9647)+(33676814212905551079504*sqrt(37)143294929822723634925032)*(1776*sqrt(37)9647)^(2/3)+1561894994314649401389451*(1776*sqrt(37)9647)^(1/3)+15098241559200034610148158) Simplify to zero (%i2) ratsimp(expand(%)); (%o2) 0 With algebraic : true, error: (%i3) resultant(658952*x^3+((1776*sqrt(37)9647)*((1776*sqrt(37)9647)^(1/3))^2+82369*(1776*sqrt(37)9647)^(1/3)+4036081)*x^2+ ((7104*sqrt(37)38588)*((1776*sqrt(37)9647)^(1/3))^2+329476*(1776*sqrt(37)9647)^(1/3)+6260044)*x+(7104*sqrt(37)38588)*((1776*sqrt(37)9647)^(1/3))^2+329476* (1776*sqrt(37)9647)^(1/3)+5601092,((1776*sqrt(37)+9647)*((1776*sqrt(37)9647)^(1/3))^282369*(1776*sqrt(37)9647)^(1/3)4036081)*x^2+ ((14208*sqrt(37)+77176)*((1776*sqrt(37)9647)^(1/3))^2658952*(1776*sqrt(37)9647)^(1/3)12520088)*x+(21312*sqrt(37)+115764)*((1776*sqrt(37)9647)^(1/3))^2988428* (1776*sqrt(37)9647)^(1/3)16803276,x), algebraic : true; quotient is not exact  an error. To debug this try debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2827331&group_id=4933 
From: SourceForge.net <noreply@so...>  20090726 07:18:33

Bugs item #2805251, was opened at 20090612 00:45 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2805251&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: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Absence of extract_categories.sh and others in maxima5.18.1 Initial Comment: Dear Developers of Maxima, Today, I built maxima5.18.1 from its source code. The usual procedure configure > make > make install failed at the last stage "make install" as follows:  ... ... Making install in doc Making install in info pattern=`printf "\r$"` ; \ bad_files=`find . name '*.texi' print  xargs grep E l e "$pattern"` ; \ [ z "$bad_files" ]  ( echo "WARNING: The following files have DOSstyle EOLs: $bad_files" ; \ echo "Run /doc/info/fix_crlf to fix the problem." ) pattern=`printf "\t"` ; \ bad_files=`find . name '*.texi' print  xargs grep E l e "$pattern"` ; \ [ z "$bad_files" ]  ( echo "WARNING: The following files have unexpanded Tabs: $bad_files" ; \ echo "Run /doc/info/fix_tab to fix the problem." ) make[4]: Nothing to be done for `installexecam'. sh extract_categories.sh maxima sh: extract_categories.sh: No such file or directory make[4]: *** [maxima.html] Error 127 make[3]: *** [installam] Error 2 make[2]: *** [installrecursive] Error 1 make[1]: *** [installrecursive] Error 1 make: *** [installrecursive] Error 1  This failure is caused by the absence of three files extract_categories.sh extract_categories1.awk extract_categories1.sed in the directory "maxima5.18.1/doc/info". To fix this problem, I have copied these three files from maxima5.17.1 to maxima5.18.1. Then, "make install" succeeds as is expected. Please include the above three files in the distribution of the source code of the current version of Maxima. Also please check that your procedure to pack a distrbution of the source code of Maxima from its current source tree does not forget the above three files to include. Sincerely yours, Satoshi Adachi  >Comment By: Robert Dodier (robert_dodier) Date: 20090726 01:18 Message: Resolved by r1.69 doc/info/Makefile.am (put category scripts on list of files for tarball). Closing this report as fixed.  Comment By: Satoshi Adachi (satoshi_adachi) Date: 20090623 02:31 Message: Dear Mr. Robert Dodier, Thank you for your investigation. My answer to each of your equations is as follows: >From where did you obtain the source code? > As usual, the source code is obtained from sourceforge. Did you obtain it from CVS or from a tar.gz? > From maxima5.18.1.tar.gz. Are the maxima_*.html files present in the source code you obtained? > (i) Yes! When the intact source tree is prepared by the command sequence "zcat maxima5.18.1.tar.gz  tar xvf  ". The files "maxima_*.html" EXIST in the directory "maxima5.18.1/doc/info". *** Now, I understand what is the cause of my trouble. *** (ii) When "./configure; make clean" is executed in the directory "maxima5.18.1", I found that all of the files "doc/info/maxima_*.html" are deleted. I also found that "make distclean" also deletes all of these files. >From this experiment, the extract_categories scripts seem to be necessary in the source code distribution of Maxima. Otherwise, once "make clean" is executed, the source code tree becomes defective to build and install the Maxima system. Please fix this problem in any way. Sincerely yours, Satoshi Adachi  Comment By: Robert Dodier (robert_dodier) Date: 20090618 17:10 Message: The extract_categories scripts are to build the category system in the html documentation. The tar.gz file is supposed to contain the generated documentation files, so it is not necessary to run the extract_categories scripts. So it appears that either (1) your tar.gz doesn't contain the html files, or (2) make is trying to rebuild some files (the html files) when it doesn't need to. >From where did you obtain the source code? Did you obtain it from CVS or from a tar.gz? Are the maxima_*.html files present in the source code you obtained? What is your operating system?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2805251&group_id=4933 
From: SourceForge.net <noreply@so...>  20090726 04:25:38

Bugs item #2826632, was opened at 20090724 09:30 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2826632&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor of double diff error Initial Comment: taylor(diff(f(x,y),x,1,y,1),x,0,1); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bind stack overflow.  >Comment By: Robert Dodier (robert_dodier) Date: 20090725 22:25 Message: Looks like TAYLOR2 calls TSDIFF which calls TAYLOR2 ... Here are the frames at the bottom of the stack. 43576: (TAYLOR2 ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 43577: (TSDIFF (($F SIMP) $X $Y) ($X 1 $Y 1) ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 43578: (TAYLOR2 ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 43579: (TSDIFF (($F SIMP) $X $Y) ($X 1 $Y 1) ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 43580: (TAYLOR2 ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 43581: (TAYLOR3 ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1)) 43582: (TAYLOR1 ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1) ((($X ((1 . 1)) 0 NIL)))) 43583: (TAYLOR* ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1) ($X 0 1)) 43584: ($TAYLOR ((%DERIVATIVE SIMP) (($F SIMP) $X $Y) $X 1 $Y 1) $X 0 1) 43585: (MEVAL1 #<unavailable argument>) 43586: (MEVAL (($TAYLOR) (($DIFF) (($F) $X $Y) $X 1 $Y 1) $X 0 1)) 43587: (MEVAL* (($TAYLOR) (($DIFF) (($F) $X $Y) $X 1 $Y 1) $X 0 1)) 43588: (TOPLEVELMACSYMAEVAL (($TAYLOR) (($DIFF) (($F) $X $Y) $X 1 $Y 1) $X 0 1)) 43589: (CONTINUE #<SYNONYMSTREAM :SYMBOL SBSYS:*STDIN* {9136819}> NIL) 43590: (MACSYMATOPLEVEL #<SYNONYMSTREAM :SYMBOL SBSYS:*STDIN* {9136819}> NIL) 43591: (RUN) 43592: (SBINT:SIMPLEEVALINLEXENV (RUN) #<NULLLEXENV>) 43593: (SBIMPL::PROCESSEVALOPTIONS ("(cluser::run)")) 43594: (SBIMPL::TOPLEVELINIT) 43595: ((LABELS SBIMPL::RESTARTLISP))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2826632&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 22:12:26

Bugs item #660948, was opened at 20030102 05:23 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&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  Complex Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of exp(%i*...) Initial Comment: There are some weirdnesses and inconsistencies in the simplification of exp(%i*...). First, let's look at the case exp(%i*%pi*q). If q is (m/n) with n in {1,2,3,4,6}, it returns a solution in rationals and radicals, e.g. for q=11/3, we get 1/2SQRT (3)*%I/2. For other n's, it reduces q to the range (1,+1]. If q is a float which is exactly m/n as above, it rationalizes it: exp(%i*%pi*.25) => SQRT(2)*%I/2+SQRT(2)/2 I am not comfortable with this, because a floating point number is supposed to be an approximation, and we're getting an exact result here. It does the same thing for x^1.0 and (x^3)^float(1/3), though not for x^0.5 or x^2.0 or (x^3)^float(5/3). However, it does a weird thing if q is very near m/n: exp(%i*%pi*.166666666) => (%I/2+SQRT(3)/2)*%E^(6.666666663157628E10*%I*% PI) Of course this is accurate, but it seems pointless and bizarre. It is also inconsistent in its handling of purely floating exponents: exp(%i*%pi*.333) => %E^(0.333*%I*%PI) (OK) but exp(%i*%pi*5.333) => %E^(667*%I*%PI/1000) (why rationalized here?) Now let's look at the case exp(%i*q). If q = 1.0 exactly, it acts as though q=1: exp(%i*1.0) => %e^%i. This follows the (in my opinion anomalous) case x^1.0 => x, as above. I don't know why this should be; after all, 2^1.0 => 2.0, not 2. And for other floats, it does no reduction at all to (pi,pi]: exp(%i*ev(%pi,numer)) => %E^(3.141592653589793*%I) exp(%i*ev(%pi*100,numer)) => %E^(314.1592653589793*%I) exp(%i*300.0) => exp(%i*300.0) All this needs to be made consistent and clear. In my opinion, floats should NEVER be coerced to exact numbers, unless the user asks for it (e.g. by converting to Rat form).  >Comment By: Dieter Kaiser (crategus) Date: 20090726 00:12 Message: I think the problems of this bug report are no longer present. These are the results for the given examples: No rationalizing of float numbers: (%i2) exp(%i*%pi*0.25); (%o2) %e^(0.25*%i*%pi) No simplification to an exact result: (%i3) x^1.0; (%o3) x^1.0 (%i4) (x^3)^float(1/3); (%o4) x^1.0 More examples for float numbers: (%i5) exp(%i*%pi*0.166666666); (%o5) %e^(0.166666666*%i*%pi) (%i6) exp(%i*%pi*5.333); (%o6) %e^(5.333*%i*%pi) The exp function with a complex float argument evaluate numerically: (%i7) exp(%i*1.0); (%o7) .8414709848078965*%i+.5403023058681398 (%i8) exp(%i*ev(%pi,numer)); (%o8) 1.224500708041116E16*%i1.0 (%i9) exp(%i*ev(%pi*100,numer)); (%o9) 1.961926030129856E15*%i+1.0 (%i10) exp(%i*300.0); (%o10) .9997558399011495*%i.02209661927868395 Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 20:07:34

Bugs item #2825092, was opened at 20090722 00:45 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825092&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: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: %pi^2.0b0 does not evaluate numerically Initial Comment: Maxima evaluates numeric constants numerically, if the exponent is a floating point number or $numer is T: (%i3) %pi^2.0; (%o3) 9.869604401089358 (%i4) %gamma^2.0; (%o4) .3331779238077187 (%i5) %pi^2,numer; (%o5) 9.869604401089358 (%i6) %gamma^2,numer; (%o6) .3331779238077187 But it does not work if the exponent is a bigfloat number (only %e works): (%i9) %pi^2.0b0; (%o9) %pi^2.0b0 (%i10) %gamma^2.0b0; (%o10) %gamma^2.0b0 This is a piece of code in simpexpt, which will change this: (t (let ((y (mget gr '$numer))) ;; Check for a numeric constant. (and y (floatp y) (or (floatp pot) ;; The exponent is a bigfloat. Convert base to bigfloat. (and ($bfloatp pot) (member gr *builtinnumericconstants*) (setq y ($bfloat gr))) (and $numer (integerp pot))) ;; The evaluation is done in exprtl. (return (exptrl y pot)))))) (%i12) %pi^2.0b0; (%o12) 9.869604401089359b0 (%i13) %gamma^2.0b0; (%o13) 3.331779238077187b1 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20090725 22:07 Message: With revision 1.87 of simp.lisp all numeric constants are evaluated numerically, if the exponent is a bigfloat number. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825092&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 20:05:01

Bugs item #2825082, was opened at 20090722 00:20 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825082&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: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: %pi^1.0b0 > floating point value Initial Comment: The exponent is a bigfloat number, but a floating point number is returned: (%i16) %pi^1.0b0; (%o16) 3.141592653589793 (%i17) %gamma^1.0b0; (%o17) .5772156649015329 The only case which is handled correctly is %e: (%i18) %e^1.0b0; (%o18) 2.718281828459045b0 That is the piece of code in simpexpt, which can handle the other numeric constants too: ((onep1 pot) ;; Exponent is One. (let ((y (mget gr '$numer))) (if (and y (floatp y) (or $numer (not (equal pot 1)))) ;; Base is a numeric constant with a floating point value or ;; $numer is TRUE and the Exponent is not the integer One. (return (if (and (member gr *builtinnumericconstants*) (equal pot bigfloatone)) ;; Convert numeric constant to bigfloat value. ($bfloat gr) ;; Can we reach this point? y)) ;; Handle other cases in exptrl. (return (exptrl gr pot))))) We get: (%i16) %pi^1.0b0; (%o16) 3.141592653589793b0 (%i17) %gamma^1.0b0; (%o17) 5.772156649015329b1 (%i18) %phi^1.0b0; (%o18) 1.618033988749895b0 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20090725 22:05 Message: With revision 1.87 of simp.lisp all numeric constants return a bigfloat number, if the exponent is bigfloat one. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825082&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 15:32:54

Bugs item #2824928, was opened at 20090721 14:17 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824928&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: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: limit(sqrt(z)/b^z,z,inf) Initial Comment: The following limit is not correct for b>1 and b<=0; (%i1) limit(sqrt(z)/b^z,z,inf); (%o1) inf Maxima knows the correct answer for b>1: (%i10) assume(b>1)$ (%i11) limit(sqrt(z)/b^z,z,inf); (%o11) 0 Dieter Kaiser  >Comment By: Dan Gildea (dgildea) Date: 20090725 11:32 Message: Fixed in limit.lisp rev 1.73 decided to return noun form rather than asking user questions.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824928&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 14:29:51

Bugs item #2824909, was opened at 20090721 19:19 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&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: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: exp(%i*%pi/4) not simplified Initial Comment: The following expression is not fully simplified: (%i3) exp(%i*%pi/4); (%o3) %i/sqrt(2)+sqrt(2)/2 We have to do an extra simplification: (%i4) expand(%,0,0); (%o4) %i/sqrt(2)+1/sqrt(2) The reason is, that the routine spang1 in csimp.lisp returns the value of the global special variable sqrt2//2. The value is not correctly simplified by hand: (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) We have the same problem with the variable sqrt2//2 (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) There are two solutions: 1. Correct the value of the global variables. 2. Do not use the global variables, but use code which simplifies accordingly, e.g. sqrt2//2 > (div 1 ($sqrt 2)) The global variables sqrt2//2, sqrt//2, sqrt3//2, sqrt3//2 are definied in trigi.lisp. All variables are used only one time in csimp.lisp. I think it is the best to cut out these four variables and to insert the code directly in the routine spang1. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20090725 16:29 Message: The suggested change (2) has been committed with revision 1.19 of csimp.lisp. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&group_id=4933 
From: SourceForge.net <noreply@so...>  20090724 15:30:30

Bugs item #2826632, was opened at 20090724 11:30 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2826632&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor of double diff error Initial Comment: taylor(diff(f(x,y),x,1,y,1),x,0,1); Maxima encountered a Lisp error: Error in PROGN [or a callee]: Bind stack overflow.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2826632&group_id=4933 
From: SourceForge.net <noreply@so...>  20090723 05:37:06

Bugs item #2796194, was opened at 20090524 15:12 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&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: Works For Me Priority: 5 Private: No Submitted By: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: error doing a Fourier transform Initial Comment: (%i1) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Robert Dodier (robert_dodier) Date: 20090722 23:37 Message: Reopening this item. I still see it. Appears to be triggered because TVARLIM does not have a case for MPLUS expressions.  Comment By: SourceForge Robot (sfrobot) Date: 20090721 20:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20090707 12:46 Message: This no longer appears to happen in the CVS version. (The result isn't great since it contains a lot of limit expressions, but the Lisp error is gone. I did not check to see if the answer makes sense or not.) Marking as pending/worksforme  Comment By: Rich Hennessy (rvh2007) Date: 20090524 15:18 Message: I get this same error in my pwdefint() function in pw.mac. I don't think it is a problem with pwdefint(). See the second case. (%i1) pwdefint(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. case 2: (%i1) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) load(abs_integrate); (%o2) C:/Maxima5.18.1/share/maxima/5.18.1/share/contrib/integration/abs_integrate.mac (%i3) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&group_id=4933 
From: SourceForge.net <noreply@so...>  20090722 02:20:28

Bugs item #2796194, was opened at 20090524 21:12 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Rich Hennessy (rvh2007) Assigned to: Nobody/Anonymous (nobody) Summary: error doing a Fourier transform Initial Comment: (%i1) integrate(%pi*exp(2*%pi*t)*exp(2*%pi*x*t*%i),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: SourceForge Robot (sfrobot) Date: 20090722 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20090707 18:46 Message: This no longer appears to happen in the CVS version. (The result isn't great since it contains a lot of limit expressions, but the Lisp error is gone. I did not check to see if the answer makes sense or not.) Marking as pending/worksforme  Comment By: Rich Hennessy (rvh2007) Date: 20090524 21:18 Message: I get this same error in my pwdefint() function in pw.mac. I don't think it is a problem with pwdefint(). See the second case. (%i1) pwdefint(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. case 2: (%i1) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i2) load(abs_integrate); (%o2) C:/Maxima5.18.1/share/maxima/5.18.1/share/contrib/integration/abs_integrate.mac (%i3) integrate(%pi*exp(2*%pi*abs(t))*exp(2*%pi*%i*x*t),t,minf,inf); Maxima encountered a Lisp error: Unhandled kernel in tvarlim Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. (%i4)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2796194&group_id=4933 
From: SourceForge.net <noreply@so...>  20090722 02:20:21

Bugs item #2800086, was opened at 20090602 16:34 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2800086&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: echelon problem Initial Comment: Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 I typed in the following commands in Maxima: (%i1) A:matrix([1,2,2,b1],[2,2,3,b2],[3,4,5,b3]); [ 1 2 2 b1 ] [ ] (%o1) [ 2 2 3 b2 ] [ ] [ 3 4 5 b3 ] (%i2) echelon(A); [ 1 2 2 b1 ] [ ] [ 1 b2  2 b1 ] (%o2) [ 0 1    ] [ 2 2 ] [ ] [ 0 0 0 1 ] (%i3) algebraic:true; (%o3) true (%i4) echelon(A); [ 1 2 2 b1 ] [ ] [ 1 b2  2 b1 ] (%o4) [ 0 1    ] [ 2 2 ] [ ] [ 0 0 0 1 ] But shouldn't the result be: [ 1 2 2 b1 ] [ ] [ 1 b2  2 b1 ] [ 0 1    ] [ 2 2 ] [ ] [ 0 0 0 b2  b3 + b1 ]  >Comment By: SourceForge Robot (sfrobot) Date: 20090722 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20090707 18:44 Message: The documentation for echelon says the first nonzero element in each row is a one. Maxima is producing that result, and is the same as your "expected" result if the last row is divided by b2b3+b1. Marking as pending/invalid. If you disagree with this analysis, please update this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2800086&group_id=4933 
From: SourceForge.net <noreply@so...>  20090722 02:20:20

Bugs item #2815766, was opened at 20090702 12:57 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2815766&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: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: strange results from eigenvalues Initial Comment: large matrices like matrix([72126.5,25007.8,7670.53],[25007.8,8670.74,2659.53],[7670.53,2659.53,818.809]) produce strange outputs: (%i32) eigenvalues(T); rat: replaced 25007.8 by 125039/5 = 25007.8 rat: replaced 2.0400004650900003E+7 by 20400005/1 = 2.0400005E+7 rat: replaced 25007.8 by 125039/5 = 25007.8 rat: replaced 818.809 by 72874/89 = 818.8089887640449 rat: replaced 7670.53 by 767053/100 = 7670.53 rat: replaced 6.6508994334000006E+7 by 66508994/1 = 6.6508994E+7 rat: replaced 7670.53 by 767053/100 = 7670.53 rat: replaced 8670.74 by 433537/50 = 8670.74 rat: replaced 7073099.8209 by 35365499/5 = 7073099.8 rat: replaced 818.809 by 72874/89 = 818.8089887640449 rat: replaced 8670.74 by 433537/50 = 8670.74 rat: replaced 72126.5 by 144253/2 = 72126.5 (%o32) [[((sqrt(3)*%i)/21/2)*((3*sqrt(12608488167242884134811801138679920231)*%i)/(3960500000*sqrt(2))+2838509476210882261900497/140993800000)^(1/3)+(58619247149883207*((sqrt(3)*%i)/21/2))/(79210000*((3*sqrt(12608488167242884134811801138679920231)*%i)/(3960500000*sqrt(2))+2838509476210882261900497/140993800000)^(1/3))+60531903/2225,((sqrt(3)*%i)/21/2)*((3*sqrt(12608488167242884134811801138679920231)*%i)/(3960500000*sqrt(2))+2838509476210882261900497/140993800000)^(1/3)+(58619247149883207*((sqrt(3)*%i)/21/2))/(79210000*((3*sqrt(12608488167242884134811801138679920231)*%i)/(3960500000*sqrt(2))+2838509476210882261900497/140993800000)^(1/3))+60531903/2225,((3*sqrt(12608488167242884134811801138679920231)*%i)/(3960500000*sqrt(2))+2838509476210882261900497/140993800000)^(1/3)+58619247149883207/(79210000*((3*sqrt(12608488167242884134811801138679920231)*%i)/(3960500000*sqrt(2))+2838509476210882261900497/140993800000)^(1/3))+60531903/2225],[1,1,1]] ovtave gives followin: octave.exe:3> t = >[72126.5, 25007.8, 7670.53; > 25007.8, 8670.74, 2659.53; > 7670.53, 2659.53, 818.809]; octave.exe:4> eig(t) ans = 8.2521e004 3.0311e+000 8.1613e+004  >Comment By: SourceForge Robot (sfrobot) Date: 20090722 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Raymond Toy (rtoy) Date: 20090707 18:24 Message: Marking as pending/invalid so this will be closed automatically in two weeks. I don't think there's anything wrong here. If you disagree, please comment on this.  Comment By: Raymond Toy (rtoy) Date: 20090702 13:30 Message: In what way is the result strange? Eigenvalues the floats to rationals and does a symbolic calculation. Hence the long answer. If you want a float result, you can use float and rectform to get [[6.912159733474255e11 %i + 2.999728814902483, .03218669009947916  6.548361852765083e11 %i, 81613.01707325905  2.442490654175344e15 %i], [1.0, 1.0, 1.0]] (These aren't quite the same as octave.) If you numeric results, you can try dgeev. This produces [81613.01707247499, 8.252057359223741e4, 3.031102319243371] This is probably the same routine that octave uses to find eigenvalues.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2815766&group_id=4933 
From: SourceForge.net <noreply@so...>  20090721 22:45:27

Bugs item #2825092, was opened at 20090722 00:45 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825092&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: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: %pi^2.0b0 does not evaluate numerically Initial Comment: Maxima evaluates numeric constants numerically, if the exponent is a floating point number or $numer is T: (%i3) %pi^2.0; (%o3) 9.869604401089358 (%i4) %gamma^2.0; (%o4) .3331779238077187 (%i5) %pi^2,numer; (%o5) 9.869604401089358 (%i6) %gamma^2,numer; (%o6) .3331779238077187 But it does not work if the exponent is a bigfloat number (only %e works): (%i9) %pi^2.0b0; (%o9) %pi^2.0b0 (%i10) %gamma^2.0b0; (%o10) %gamma^2.0b0 This is a piece of code in simpexpt, which will change this: (t (let ((y (mget gr '$numer))) ;; Check for a numeric constant. (and y (floatp y) (or (floatp pot) ;; The exponent is a bigfloat. Convert base to bigfloat. (and ($bfloatp pot) (member gr *builtinnumericconstants*) (setq y ($bfloat gr))) (and $numer (integerp pot))) ;; The evaluation is done in exprtl. (return (exptrl y pot)))))) (%i12) %pi^2.0b0; (%o12) 9.869604401089359b0 (%i13) %gamma^2.0b0; (%o13) 3.331779238077187b1 Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825092&group_id=4933 
From: SourceForge.net <noreply@so...>  20090721 22:20:06

Bugs item #2825082, was opened at 20090722 00:20 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825082&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: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: %pi^1.0b0 > floating point value Initial Comment: The exponent is a bigfloat number, but a floating point number is returned: (%i16) %pi^1.0b0; (%o16) 3.141592653589793 (%i17) %gamma^1.0b0; (%o17) .5772156649015329 The only case which is handled correctly is %e: (%i18) %e^1.0b0; (%o18) 2.718281828459045b0 That is the piece of code in simpexpt, which can handle the other numeric constants too: ((onep1 pot) ;; Exponent is One. (let ((y (mget gr '$numer))) (if (and y (floatp y) (or $numer (not (equal pot 1)))) ;; Base is a numeric constant with a floating point value or ;; $numer is TRUE and the Exponent is not the integer One. (return (if (and (member gr *builtinnumericconstants*) (equal pot bigfloatone)) ;; Convert numeric constant to bigfloat value. ($bfloat gr) ;; Can we reach this point? y)) ;; Handle other cases in exptrl. (return (exptrl gr pot))))) We get: (%i16) %pi^1.0b0; (%o16) 3.141592653589793b0 (%i17) %gamma^1.0b0; (%o17) 5.772156649015329b1 (%i18) %phi^1.0b0; (%o18) 1.618033988749895b0 Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825082&group_id=4933 
From: SourceForge.net <noreply@so...>  20090721 18:17:01

Bugs item #2824928, was opened at 20090721 20:17 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824928&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: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: limit(sqrt(z)/b^z,z,inf) Initial Comment: The following limit is not correct for b>1 and b<=0; (%i1) limit(sqrt(z)/b^z,z,inf); (%o1) inf Maxima knows the correct answer for b>1: (%i10) assume(b>1)$ (%i11) limit(sqrt(z)/b^z,z,inf); (%o11) 0 Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824928&group_id=4933 
From: SourceForge.net <noreply@so...>  20090721 17:26:47

Bugs item #2824909, was opened at 20090721 19:19 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&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: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) >Summary: exp(%i*%pi/4) not simplified Initial Comment: The following expression is not fully simplified: (%i3) exp(%i*%pi/4); (%o3) %i/sqrt(2)+sqrt(2)/2 We have to do an extra simplification: (%i4) expand(%,0,0); (%o4) %i/sqrt(2)+1/sqrt(2) The reason is, that the routine spang1 in csimp.lisp returns the value of the global special variable sqrt2//2. The value is not correctly simplified by hand: (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) We have the same problem with the variable sqrt2//2 (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) There are two solutions: 1. Correct the value of the global variables. 2. Do not use the global variables, but use code which simplifies accordingly, e.g. sqrt2//2 > (div 1 ($sqrt 2)) The global variables sqrt2//2, sqrt//2, sqrt3//2, sqrt3//2 are definied in trigi.lisp. All variables are used only one time in csimp.lisp. I think it is the best to cut out these four variables and to insert the code directly in the routine spang1. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&group_id=4933 
From: SourceForge.net <noreply@so...>  20090721 17:19:16

Bugs item #2824909, was opened at 20090721 19:19 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&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: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: exp(%i*%pi/4 not simplified Initial Comment: The following expression is not fully simplified: (%i3) exp(%i*%pi/4); (%o3) %i/sqrt(2)+sqrt(2)/2 We have to do an extra simplification: (%i4) expand(%,0,0); (%o4) %i/sqrt(2)+1/sqrt(2) The reason is, that the routine spang1 in csimp.lisp returns the value of the global special variable sqrt2//2. The value is not correctly simplified by hand: (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) We have the same problem with the variable sqrt2//2 (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) There are two solutions: 1. Correct the value of the global variables. 2. Do not use the global variables, but use code which simplifies accordingly, e.g. sqrt2//2 > (div 1 ($sqrt 2)) The global variables sqrt2//2, sqrt//2, sqrt3//2, sqrt3//2 are definied in trigi.lisp. All variables are used only one time in csimp.lisp. I think it is the best to cut out these four variables and to insert the code directly in the routine spang1. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&group_id=4933 