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}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(1) 
2

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

12
(3) 
13

14
(3) 
15
(1) 
16

17
(1) 
18
(4) 
19
(1) 
20
(1) 
21

22

23

24
(1) 
25
(1) 
26
(3) 
27
(3) 
28
(1) 
29
(8) 
30
(4) 


From: SourceForge.net <noreply@so...>  20061118 16:09:59

Bugs item #1556627, was opened at 20060911 13:07 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: solve & sign called on imaginary Initial Comment: This example is ridiculous, but this error shouldn't happen: x^1616*x^15+120*x^14560*x^13+1800*x^124128*x^11+6688*x^107040*x^9+2304*x^8+9728*x^729120*x^6+48768*x^558560*x^4+56576* x^343008*x^2+20992*x4544=0 (%i165) solve(%,x); `sign' called on an imaginary argument: sqrt(125*sqrt(6)) Barton  Comment By: Nobody/Anonymous (nobody) Date: 20061118 08:09 Message: Logged In: NO On my copy of wxMaxima, it didn't show any error!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1556627&group_id=4933 
From: SourceForge.net <noreply@so...>  20061118 15:52:56

Bugs item #1598874, was opened at 20061118 07:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1598874&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: Xmaxima or other UI Group: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Winkill.exe path is not properly set Initial Comment: Maxima version: 5.10.0Maxima build date: 17:18 10/24/2006host type: i686pcmingw32lispimplementationtype: GNU Common Lisp (GCL)lispimplementationversion: GCL 2.6.8 When I tried to cancel an ongoing operation by pressing the "Cancel" (Interrupt current computation) button on the toolbar of wxMaxima, it raised the error: "Execution of command '\winkill.exe'INT 3280 failed." This file is present in "bin" directory of Maxima. I copied to the root and the command started working. This can be fixed easily I suppose. Thanks for this wonderful program. :) Sunil Sangwal sangwal77 AT yahoo.com  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1598874&group_id=4933 
From: SourceForge.net <noreply@so...>  20061117 16:32:48

Bugs item #1598460, was opened at 20061117 11:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1598460&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: Open Resolution: None Priority: 5 Private: No Submitted By: David Ronis (ronis) Assigned to: Nobody/Anonymous (nobody) Summary: CVS broken Initial Comment: I've been following maxima for years via CVS. I upgraded yesterday (I'd done so about 23 weeks prior to that). I did bootstrap configure (also with prefix=/usr/local) make clean make all make check make install (as root of course). Everything above worked, and the testsuite reported no errors. However, maxima is broken. Basically, it seems that ${prefix} appears in chunks of the code, not /usr/local. Here's a sample session: Script started on Fri Nov 17 11:27:17 2006 {ronispc:41} maxima Maxima 5.10.0cvs http://maxima.sourceforge.net Using Lisp CLISP 2.39 (20060716) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) describe("trigsimp"); setupinfo: "maxima.info" not found in ("/${prefix}/share/info/") (%o1) false (%i2) sin(x)**2+cos(x)**2; 2 2 (%o2) sin (x) + cos (x) (%i3) trigsimp(%); Could not find `trgsmp.mac' using paths in file_search_maxima,system (combined values: [/home/ronis/.maxima/###.{mac,mc}, /${prefix}/share/maxima/5.10.0cvs/share/###.{mac,mc}, /${prefix}/share/maxima/\ 5.10.0cvs/share/{affine,algebra,algebra/charsets,algebra/solver,calculus,combi\ natorics,contrib,contrib/boolsimp,contrib/descriptive,contrib/diffequations,co\ ntrib/diffequations/tests,contrib/distrib,contrib/ezunits,contrib/format,contr\ ib/gentran,contrib/gentran/test,contrib/Grobner,contrib/lurkmathml,contrib/max\ imaMathML,contrib/mcclim,contrib/numericalio,contrib/pdiff,contrib/prim,contri\ b/rand,contrib/sarag,contrib/simplex,contrib/simplex/Tests,contrib/solve_rec,c\ ontrib/state,contrib/stringproc,contrib/unit,contrib/Zeilberger,diffequations,\ lbfgs,linearalgebra,integequations,integration,macro,matrix,misc,numeric,ortho\ poly,physics,simplification,sym,tensor,tensor/tests,trigonometry,utils,vector}\ /###.{mac,mc}] ) #0: trigsimp(?_l=[sin(x)^2+cos(x)^2])  an error. To debug this try debugmode(true); (%i4) bug_report(); The Maxima bug database is available at http://sourceforge.net/tracker/?atid=104933&group_id=4933&func=browse Submit bug reports by following the 'Submit New' link on that page. Please include the following build information with your bug report:  Maxima version: 5.10.0cvs Maxima build date: 11:25 11/17/2006 host type: i686pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.39 (20060716) (built 3362425257) (memory 3372769517)  The above information is also available from the Maxima function build_info(). David P.S., I posted this to the list last night, but got no reply, sorry for the duplication.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1598460&group_id=4933 
From: SourceForge.net <noreply@so...>  20061115 19:09:57

Bugs item #1597215, was opened at 20061115 11:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1597215&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: >=5.9.3 lisp error "out of range" Initial Comment: >=scimathematics/maxima5.9.3 with clisp, gcl, sbcl as licp compilers, exit (make check fails) with lisp error: Maxima encountered a Lisp error: AREF: index 0 for "" is out of range If I set LC_ALL to C then maxima works with gcl and sbcl, but switch in debug mode with clisp: ***  invalid byte #xD0 in CHARSET:ASCII conversion The following restarts are available: ABORT :R1 ABORT ABORT :R2 ABORT ABORT :R3 ABORT ABORT :R4 ABORT ABORT :R5 ABORT ABORT :R6 ABORT My localce: localhost ~ # locale LANG=ru_RU.UTF8 LC_CTYPE="ru_RU.UTF8" LC_NUMERIC=POSIX LC_TIME="ru_RU.UTF8" LC_COLLATE="ru_RU.UTF8" LC_MONETARY="ru_RU.UTF8" LC_MESSAGES="ru_RU.UTF8" LC_PAPER="ru_RU.UTF8" LC_NAME="ru_RU.UTF8" LC_ADDRESS="ru_RU.UTF8" LC_TELEPHONE="ru_RU.UTF8" LC_MEASUREMENT="ru_RU.UTF8" LC_IDENTIFICATION="ru_RU.UTF8" LC_ALL= OS  gentoo linux, lisp: [ebuild R ] devlisp/sbcl0.9.17 USE="unicode doc ldb source threads" [ebuild R ] devlisp/gcl2.6.7r1 USE="X ansi custreloc dlopen gprof readline debug doc emacs tcltk" [ebuild R ] devlisp/clisp2.39 USE="X pcre readline zlib fastcgi newclx postgres"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1597215&group_id=4933 
From: SourceForge.net <noreply@so...>  20061114 14:11:21

Bugs item #1594977, was opened at 20061112 10:17 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: limit(n/(n^2+1), n, inf); Initial Comment: I think limit should change inf to minf before doing the calculation: (%i1) limit(n/(n^2+1), n, inf); (%o1) inf/(inf^2+1) (%i2) limit(n/(n^2+1), n, minf); (%o2) 0 Andrej  >Comment By: Andrej Vodopivec (andrejv) Date: 20061114 15:11 Message: Logged In: YES user_id=1179910 Attached a patch which does this. Testsuite reports no errors. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&group_id=4933 
From: SourceForge.net <noreply@so...>  20061114 03:20:14

Bugs item #1577267, was opened at 20061014 09:59 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1577267&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: Problem not in Maxima Group: None >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Windows DEP Execution Problem Initial Comment: CPU: AMD64 dualcore OS: Windows XP Maxima: 5.10.0 DEP (Data Execution Prevention) is turned on. maxima.bat fails to execute maxima.exe. XMaxima and wxMaxima report a missing connection to Maxima. There is no warning, no hint to the real problem. I was confused, Filemon/Regmon did not help. In the wxMaxima discussion forum I found the solution. Workaround: include the full program path of maxima.exe C:\Program Files\Maxima5.10.0\lib\maxima\5.10.0\binarygcl\maxima.exe in the list of DEP exceptions (Control Panel>System>Advanced>Performance>DEP) Problem: It seems that the LISP interpreter in maxima.exe is executing binary code in data sections. This should be fixed.  >Comment By: SourceForge Robot (sfrobot) Date: 20061113 19:20 Message: Logged In: YES user_id=1312539 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: Robert Dodier (robert_dodier) Date: 20061030 07:32 Message: Logged In: YES user_id=501686 Assigning category="Problem not in Maxima" and resolution=rejected and status=pending (will be closed automatically in 2 weeks). Notes: (1) I posted a note about this problem to the gcldevel mailing list, with no reply as of this writing. (2) But I did find this statement by Camm Maguire. Not sure exactly what this means. "GCL does not require executable stack, but does require nonrandomized sbrk. GCL autodetects when the OS is trying to do this and resets its 'personality'. All GCL apps work is such a mode on the latest security setups." (from http://groups.google.com/group/comp.lang.lisp/msg/f062ed80b68cbcda) (3) I added a note about Windows DEP to the wiki page for Runtime problems: http://maxima.sourceforge.net/wiki/index.php/Runtime%20problems  Comment By: Raymond Toy (rtoy) Date: 20061016 06:23 Message: Logged In: YES user_id=28849 I don't know about GCL in particular, but I believe this is how most Lisp implementations work.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1577267&group_id=4933 
From: SourceForge.net <noreply@so...>  20061114 03:20:14

Bugs item #1586927, was opened at 20061029 17:25 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1586927&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  Plotting Group: None >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: to plotting the coordinates x,y are blur Initial Comment: Maxima version: 5.10.0 Maxima build date: 10:46 10/8/2006 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  The problem rise when I change the windows graphics into the other in minimal mode and I Clicking in the graph the coordinates x,y are blur and disapear the problem when maximize the window. I atacched both windows in a file bmp José Luis González fotonluz@...  >Comment By: SourceForge Robot (sfrobot) Date: 20061113 19:20 Message: Logged In: YES user_id=1312539 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: Robert Dodier (robert_dodier) Date: 20061030 06:35 Message: Logged In: YES user_id=501686 It turns out this bug is already known in the Gnuplot bug tracker. See: http://sourceforge.net/tracker/index.php?func=detail&aid=1520692&group_id=2055&atid=102055 Marking this report with resolution=rejected (because the bug is in Gnuplot and there is no way for Maxima to work around it), and status=pending (so that it will remain open for 2 weeks before being closed automatically, in case the original poster comes back).  Comment By: Robert Dodier (robert_dodier) Date: 20061029 22:49 Message: Logged In: YES user_id=501686 I have observed the same behavior sometimes. Just to clarify for the benefit of other readers, the coordinates of the mouse pointer are supposed to be displayed in the lower lefthand corner, but instead some blickies are displayed. The jpeg attached to this report shows the behavior very clearly. This is probably a Gnuplot bug  I'll forward this report to their bug tracker in hope of getting some resolution.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1586927&group_id=4933 
From: SourceForge.net <noreply@so...>  20061112 20:27:11

Bugs item #1595208, was opened at 20061112 12:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1595208&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Exponent representation Initial Comment: Could you add a short sentence at the Introduction that the numbers on the right above are the exponents? That wasn't clear to me at first. (%i1) factor(10!); 8 4 2 (%o1) 2 3 5 7 Also the PDF files produce a 404. Thanks!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1595208&group_id=4933 
From: SourceForge.net <noreply@so...>  20061112 15:23:57

Bugs item #1483203, was opened at 20060506 21:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483203&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: GCL confused by trailing whitespace in input Initial Comment: Trailing whitespace in input causes GCL to forget to print the next input prompt. E.g. (%i1) a : 100; < there is a space character after the semicolon here (%o1) 100 a; (%o2) 100 (%i3) a : 200$ < there is a space character after the dollar sign here a; (%o4) 200 Same behavior for Maxima 5.9.3cvs / GCL 2.6.7 / Linux, and Maxima 5.9.3 / GCL 2.6.7 / Win XP. Behavior not observed with SBCL or Clisp. Could be readline strangeness, although Clisp has readline and it is OK (i.e., input prompts are printed as expected).  >Comment By: Robert Dodier (robert_dodier) Date: 20061112 08:23 Message: Logged In: YES user_id=501686 An attempt was made (see http://maxima.cvs.sourceforge.net/maxima/maxima/src/nparse.lisp?view=log) to fix this problem by calling a local NEWLINE function instead of GCL SI::NEWLINE. However, it appears that leads to problems with GCL 2.8.0. See the message dated 2006/11/11 from Vadim Zhytnikov, "Re: Rev 1.31 of src/nparse.lisp breaks windows build of CVS HEAD". (Might be able to find it at: http://news.gmane.org/gmane.comp.mathematics.maxima.general)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1483203&group_id=4933 
From: SourceForge.net <noreply@so...>  20061112 09:17:18

Bugs item #1594977, was opened at 20061112 10:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: limit(n/(n^2+1), n, inf); Initial Comment: I think limit should change inf to minf before doing the calculation: (%i1) limit(n/(n^2+1), n, inf); (%o1) inf/(inf^2+1) (%i2) limit(n/(n^2+1), n, minf); (%o2) 0 Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594977&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 23:02:30

Bugs item #1528658, was opened at 20060725 23:52 Message generated for change (Comment added) made by tlecomte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528658&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  Plotting Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Timothée Lecomte (tlecomte) Assigned to: Nobody/Anonymous (nobody) Summary: maxima abuses of "gnuplot persist" Initial Comment: Deat maxima developpers, A few days ago andrei_dubovik reported on gnuplot's bug tracker that maxima was not working properly with gnuplot CVS, in particular with the new wxWidgets terminal (which provides antialiased output, arguably nicer that the X11 terminal). Here is the original report : http://sourceforge.net/tracker/index.php?func=detail&aid=1527701&group_id=2055&atid=102055 And the conclusion is that maxima is abusing "gnuplot persist". The "persist" option was designed to be be used when you pipe a script to gnuplot, like that : gnuplot persist script maxima seem to rely on the fact that the implementation of "persist" with the x11 terminal makes gnuplot exits immediately after the end of the input, while the windows stay opened because they are managed by a separate process. However, gnuplot does not behave the same on Windows, neither with the new wxWidgets terminal both on Windows and Unix, because in these case gnuplot is a single process and can't exit until all windows are closed. Maxima should rather use gnuplot in one of the following two ways :  use persist but don't care about gnuplot after it is launched, ie don't wait for it.  talk to gnuplot through a pipe that is opened and kept opened for the whole maxima session. I think octave does that. As a temporary workaround, andrei_dubovik did the following : "I've created ~/.gnuplot that includes set term wxt persist Also I've created an executable shell script named gnuplot that includes /usr/local/bin/gnuplot $2& and placed this script into a directory that is earlier in $PATH then /usr/local/bin, so maxima calls my wrapper rather then gnuplot itself (there should be an option in maxima for gnuplot command name, but I don't know it). So, the bash takes the task of spawning processes in this case and it works now." Best regards, Timothée  >Comment By: Timothée Lecomte (tlecomte) Date: 20061111 00:02 Message: Logged In: YES user_id=1333817 I have fixed the new wxWidgets terminal in gnuplot so that it will use fork() and satisfy Maxima. This bug doesn't exist anymore. (The suggestion to use a pipe is still valid, but not critical)  Comment By: Robert Dodier (robert_dodier) Date: 20060727 20:45 Message: Logged In: YES user_id=501686 Assign category = Lisp Core  Plotting.  Comment By: Timothée Lecomte (tlecomte) Date: 20060726 00:26 Message: Logged In: YES user_id=1333817 I must add that if you choose the second alternative (hint hint), ie drive gnuplot through a pipe that you keep open, you will get the whole range of mousing capabilities that gnuplot offers. With "persist" and the x11 terminal, you only get the mouse coordinates. By keeping gnuplot opened, you get zooming, 3d rotation, a ruler, copy to clipboard, etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1528658&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 21:51:51

Bugs item #965926, was opened at 20040603 13:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp exponentially slow on lists Initial Comment: trigsimp of a [] list can sometimes take time exponential in the length of the list. For example: trigsimp(makelist(sin(i)^2+cos(i)^2,i,1,N)) for N=4,5,... takes 0.12, 0.52, 1.50, 4.45, 13.97 secs. Also for sin(i)^2. Of course, it should take linear time. This doesn't happen  >Comment By: Raymond Toy (rtoy) Date: 20061110 16:51 Message: Logged In: YES user_id=28849 Fixed. trigsimp3 modified to handle each element of the list one at a time instead of trying to do the entire list all at once.  Comment By: Raymond Toy (rtoy) Date: 20061109 12:50 Message: Logged In: YES user_id=28849 This is probably due to the way trigsimp1 and improve work (share/trigonometry/trgsmp.mac). It looks like caused by trigsimp1 and improve, which cause quadratic behavior, I think. I think if trigsimp3 is modified to map(trigsimp1, num(expn))/map(trigsimp1,denom(expn), things will work much faster. Some care must be taken in case expn is not a list, but that's not too difficult.  Comment By: Stavros Macrakis (macrakis) Date: 20040603 13:22 Message: Logged In: YES user_id=588346 Oops, "this doesn't happen" should continue... in other cases, like sin(1)^2, sin(x)^2+cos(x)^2, etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 19:46:18

Bugs item #1594330, was opened at 20061110 13:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x*(atan(x)%pi/2),x,inf) Initial Comment: Maxima returns the nounform. The limit is 1.  >Comment By: Raymond Toy (rtoy) Date: 20061110 14:46 Message: Logged In: YES user_id=28849 Fixed.  Comment By: Raymond Toy (rtoy) Date: 20061110 13:12 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule on the form x/(1/(atan(x)%pi2)). Differentiating the parts just makes things even more complicated. If maxima had used the form (atan(x)%pi/2)/(1/x), one differentiation would have sufficed to produce 1. LHOPNUMDEN needs to handle this case better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 19:45:54

Bugs item #1469411, was opened at 20060412 13:29 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(t^2*exp(4*t/38*exp(t)),t,inf) is wrong Initial Comment: Maxima returns the noun form for the limit. But the limit should be 0 because 8*exp(t) decreases so fast that the exp term is basically exp(4*t/3) and maxima knows that limit(t^2*exp(4*t/3),t,inf) is 0.  >Comment By: Raymond Toy (rtoy) Date: 20061110 14:45 Message: Logged In: YES user_id=28849 Fixed.  Comment By: Raymond Toy (rtoy) Date: 20061109 23:54 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule to evaluate this limit. LHOPNUMDEN is a heuristic that decides what should be the numerator and denominator. For this problem, it changes the expression to the equivalent exp(4*t/3+8*exp(t))/(t^(2)) However, as we differentiate this, the numerator and denominator become more complex. If we left it in the form t^2/exp(4*t/3+8*exp(t)), the derivative of the numerator becomes simpler. If we modify LHOPNUMDEN so that this form is kept, maxima can determine the limit to be 0. This can be done by moving the clause (or (polyinx num var ()) ...) from near the end to just before test for the numerator containing %e. This allows this to work and the test suite passes. I'm sure there are expressions where this change in the heuristic will break other limits.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 18:12:26

Bugs item #1594330, was opened at 20061110 13:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x*(atan(x)%pi/2),x,inf) Initial Comment: Maxima returns the nounform. The limit is 1.  >Comment By: Raymond Toy (rtoy) Date: 20061110 13:12 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule on the form x/(1/(atan(x)%pi2)). Differentiating the parts just makes things even more complicated. If maxima had used the form (atan(x)%pi/2)/(1/x), one differentiation would have sufficed to produce 1. LHOPNUMDEN needs to handle this case better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 18:08:35

Bugs item #1594330, was opened at 20061110 13:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x*(atan(x)%pi/2),x,inf) Initial Comment: Maxima returns the nounform. The limit is 1.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1594330&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 16:28:59

Bugs item #1590528, was opened at 20061104 11:27 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1590528&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: Deleted Resolution: None Priority: 1 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: Does debugmode(true) actually do anything? Initial Comment: debugmode(true)$ integrate((4*x^2+8*x+4)/(17*x^4+64*x^3+96*x^2+64*x+16),x,0,inf); This should give a division by zero error, and we enter debug mode: (dbm:1) :bt (dbm:1) I tried this with gcl, clisp, and cmucl. Nothing really seems to happen. Does debugmode work for anything? At least with CMUCL, it doesn't seem to matter too much, because I can press Cc to get to CMUCL's debugger which can then produce backtraces and such.  >Comment By: Raymond Toy (rtoy) Date: 20061110 11:28 Message: Logged In: YES user_id=28849 I've removed just the "Quitting" part, and cleaned up some of the prompts. Closing this bug.  Comment By: Raymond Toy (rtoy) Date: 20061106 09:37 Message: Logged In: YES user_id=28849 After reading your comments and the examples in the user manual, I see that debugmode is useful. I also agree that we should change the "Quitting" part. However, I propose to leave the debugmode(true) part in. Even though it can't debug Lisp functions and such, it's quite useful because execution stops at the error and I can press Cc (in CMUCL) and use CMUCL's debugger to figure out where the problem is. I suppose I could use (setf *breakonsignals* t), but this is still useful.  Comment By: Robert Dodier (robert_dodier) Date: 20061105 11:11 Message: Logged In: YES user_id=501686 Maxima debugmode can print a backtrace of functions defined in Maxima by := . So far as I can tell, debugmode doesn't know anything about functions defined by defun or defmfun or defmspec. Given that most functions in Maxima are defined by defun, defmfun, and defmspec, it is not very informative to use debugmode. Since debugmode is useful in a certain context (namely debugging userdefined functions) I think we should keep it, but let's change "  an error. Quitting. To debug this try debugmode(true);" to just "  an error." (i.e. cut out the recommendation to use debugmode, which is usually not helpful, and also the "Quitting." because, in fact, Maxima is not executing (quit) nor quit()).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1590528&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 15:34:38

Bugs item #1285104, was opened at 20050908 12:53 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1285104&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp and trigreduce & square roots Initial Comment: Sometimes trigsimp and trigreduce seem to make assumptions of the sign of variables. Consider: (%i1) sqrt(r^2 * cos(x)^2 + r^2 * sin(x)^2); (%o1) sqrt(r^2*sin(x)^2+r^2*cos(x)^2) (%i2) trigsimp(%o1); (%o2) r < should be r (%i3) trigreduce(%o1); (%o3) r < should be r (%i4) trigreduce(sqrt(r^2)); (%o4) abs(r) < OK here (%i5) trigsimp(sqrt(r^2)); (%o5) abs(r) < OK here too And oh my! Using z instead of r makes the problem go away. (%i9) sqrt(z^2 * cos(x)^2 + z^2 * sin(x)^2); (%o9) sqrt(sin(x)^2*z^2+cos(x)^2*z^2) (%i10) trigsimp(%); (%o10) abs(z) < OK here as well! (%i6) build_info(); Maxima version: 5.9.1.1cvs Maxima build date: 14:5 8/30/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 Barton  >Comment By: Raymond Toy (rtoy) Date: 20061110 10:34 Message: Logged In: YES user_id=28849 What radcan returns seems to depend on the order of the variables. radcan(sqrt(c^2*cos(b)^2+c^2*sin(b)^2)) > sqrt(sin(b)^2+cos(b)^2)*abs(c) radcan(sqrt(a^2*cos(b)^2+a^2*sin(b)^2)) > a*sqrt(sin(b)^2+cos(b)^2) This seems to be true for any variables ordered in this way. FR1 returns different things in these two cases. For the first, FR1 factors c^2*cos(b)^2+c^2*sin(b)^2 to (sin(b)^2+cos(b)^2)*c^2. In the second, it's not factored out. Don't know why.  Comment By: Robert Dodier (robert_dodier) Date: 20060812 21:07 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Raymond Toy (rtoy) Date: 20051005 09:41 Message: Logged In: YES user_id=28849 Neat. It appears to be a bug in radcan. radcan(sqrt(r^2*cos(x)^2+r^2*sin(x)^2)) returns just r*stuff, but with r replaced with z, it returns abs(z)*stuff. Tracing radcan and friends, I see that fr1 returns something different for the r version. I don't know why.  Comment By: Barton Willis (willisbl) Date: 20050910 05:35 Message: Logged In: YES user_id=895922 A possible fix: (defun sp1expt (b e) (cond ((mexptp b) (power b e)) ;;(sp1expt (cadr b) (m* e (caddr b)))) < (sp1expt x^2 1/2) > x The old code calls sp1expt after it does (a^b)^c > a^(bc). I'm not sure if that second call to sp1expt ever makes a difference. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1285104&group_id=4933 
From: SourceForge.net <noreply@so...>  20061110 04:54:08

Bugs item #1469411, was opened at 20060412 13:29 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: limit(t^2*exp(4*t/38*exp(t)),t,inf) is wrong Initial Comment: Maxima returns the noun form for the limit. But the limit should be 0 because 8*exp(t) decreases so fast that the exp term is basically exp(4*t/3) and maxima knows that limit(t^2*exp(4*t/3),t,inf) is 0.  >Comment By: Raymond Toy (rtoy) Date: 20061109 23:54 Message: Logged In: YES user_id=28849 Maxima uses L'Hospital's rule to evaluate this limit. LHOPNUMDEN is a heuristic that decides what should be the numerator and denominator. For this problem, it changes the expression to the equivalent exp(4*t/3+8*exp(t))/(t^(2)) However, as we differentiate this, the numerator and denominator become more complex. If we left it in the form t^2/exp(4*t/3+8*exp(t)), the derivative of the numerator becomes simpler. If we modify LHOPNUMDEN so that this form is kept, maxima can determine the limit to be 0. This can be done by moving the clause (or (polyinx num var ()) ...) from near the end to just before test for the numerator containing %e. This allows this to work and the test suite passes. I'm sure there are expressions where this change in the heuristic will break other limits.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1469411&group_id=4933 
From: SourceForge.net <noreply@so...>  20061109 23:45:35

Bugs item #635606, was opened at 20021108 12:47 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635606&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(abs(log(x))) internal error, UND Initial Comment: Maxima 5.5/Windows/gcl limit(abs(log(x)),x,0) Error: The tag LIMIT is undefined. Should of course be INF. More controversially, perhaps, limit(log(x),x,0) gives UND  I believe it should give INFINITY; after all, limit(log (x),x,0,minus) gives INFINITY.  >Comment By: Stavros Macrakis (macrakis) Date: 20061109 18:45 Message: Logged In: YES user_id=588346 re limit(abs(log(x)),x,0) If we're working over real x and the complex log function, then if x>0, it should clearly be inf. If x<0, log(x) is not real, but abs(log(x)) is, and sure enough limit(abs(log(x)),x,0,minus) gives inf. This is I believe correct. And it's all consistent with limit(abs(log(x)),x,0) => inf. If on the other hand you take the position that limit operates on real functions, then negative x are not part of the domain of log(x), so we should look only at the limit for x>0, which also gives us the result inf. But limit is actually happy to return imaginary results, e.g. limit(sqrt(x),x,1) => %i. By the way, currently, limit(log(x),x,0,minus) gives minf+%i*%pi, which makes some sort of intuitive sense, but isn't really a valid expression  it should be infinity.  Comment By: Raymond Toy (rtoy) Date: 20061108 21:49 Message: Logged In: YES user_id=28849 The error no longer occurs in current CVS. It returns UND, after asking if x is positive or negative. Why should the answer be INF? log(x) is undefined for negative real x.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635606&group_id=4933 
From: SourceForge.net <noreply@so...>  20061109 17:50:15

Bugs item #965926, was opened at 20040603 13:21 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp exponentially slow on lists Initial Comment: trigsimp of a [] list can sometimes take time exponential in the length of the list. For example: trigsimp(makelist(sin(i)^2+cos(i)^2,i,1,N)) for N=4,5,... takes 0.12, 0.52, 1.50, 4.45, 13.97 secs. Also for sin(i)^2. Of course, it should take linear time. This doesn't happen  >Comment By: Raymond Toy (rtoy) Date: 20061109 12:50 Message: Logged In: YES user_id=28849 This is probably due to the way trigsimp1 and improve work (share/trigonometry/trgsmp.mac). It looks like caused by trigsimp1 and improve, which cause quadratic behavior, I think. I think if trigsimp3 is modified to map(trigsimp1, num(expn))/map(trigsimp1,denom(expn), things will work much faster. Some care must be taken in case expn is not a list, but that's not too difficult.  Comment By: Stavros Macrakis (macrakis) Date: 20040603 13:22 Message: Logged In: YES user_id=588346 Oops, "this doesn't happen" should continue... in other cases, like sin(1)^2, sin(x)^2+cos(x)^2, etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=965926&group_id=4933 
From: SourceForge.net <noreply@so...>  20061109 17:32:14

Bugs item #1370433, was opened at 20051130 17:38 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1370433&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: trigsimp(sqrt(%i2)) != sqrt(trigsimp(%i2)) Initial Comment:  Maxima version: 5.9.2 Maxima build date: 9:5 10/12/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  ################################################## # Start problem with sqrt and trigsimp: # # # # (%i2) 2*(cos(x)^2sin(x)^2)+2; # # 2 2 # # (%o2) 2 (cos (x)  sin (x)) + 2 # # (%i3) trigsimp(sqrt(%i2)); # # (%o3)  2 abs(cos(x)) # # (%i4) sqrt(trigsimp(%i2)); # # (%o4) 2 abs(cos(x)) # # # # End problem with sqrt and trigsimp. # ##################################################  >Comment By: Raymond Toy (rtoy) Date: 20061109 12:32 Message: Logged In: YES user_id=28849 This bug is caused by the call to radcan in trigsimp (share/trigonometry/trgsmp.mac). For the case trigsimp(sqrt(%i2)), radcan converts sqrt(2*(cos(x)^2sin(x)^2)+2) int sqrt(2)*%i*sqrt(sin(x)^2cos(x)^21). I don't think this is what we want. Perhaps replacing radcan with ratsimp would be better.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1370433&group_id=4933 
From: SourceForge.net <noreply@so...>  20061109 15:34:46

Bugs item #1448605, was opened at 20060312 21:26 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1448605&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: Fix for 5.9.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey Pikul (jpikul) Assigned to: Nobody/Anonymous (nobody) Summary: atan returns illegal value Initial Comment: (%i1) atan(tan(4)); (%o1) 4 (should be 4  %pi, or 0.858407346 as a float) (%i2) declare(z,complex); (%o2) done (%i3) atan(tan(z)); (%o3) z (see below) atan(tan(z)) ==> z is only true if %pi/2<z<%pi/2, so this should return atan(tan(z)) unless qualified with: assume(z<%pi/2,z>%pi/2); Maxima version: 5.9.2 Maxima build date: 9:5 10/12/2005 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7  >Comment By: Raymond Toy (rtoy) Date: 20061109 10:34 Message: Logged In: YES user_id=28849 This simplification is controlled by the variable triginverses. It defaults to all, which is documented to convert atan(tan(x)) to x. I think this is not a bug.  Comment By: Nobody/Anonymous (nobody) Date: 20060313 10:38 Message: Logged In: NO Looks like SIMP%ASIN etc in src/trigo.lisp make the same type of simplification  afoo(foo(x)) => x for foo in {sin, cos, ...}.  Comment By: Nobody/Anonymous (nobody) Date: 20060313 00:46 Message: Logged In: NO Source of this bug seems to be SIMP%ATAN in src/trigi.lisp, in particular this line: (if (eq (caar y) '%tan) (cadr y)) where y is the argument of atan. It seems likely that the other simplification functions in the same file might suffer from similar naive assertions about function inverses. Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1448605&group_id=4933 
From: SourceForge.net <noreply@so...>  20061109 14:00:30

Bugs item #626721, was opened at 20021022 03:15 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626721&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: logarc of atan2 wrong Initial Comment: res : logarc(atan2(y,x))$ rectform(res),y=1,x=1; => %pi/4 BUT atan2(1,1) => 3*%pi/4 The fix is to change the formula in $logarc and in simpatan2. Currently, logarc(atan2(y,x)) => logarc(atan (y/x)), which gives incorrect results as above. This formula should be replaced by %i*log((y+%i*x)/sqrt(x^2+y^2))  >Comment By: Raymond Toy (rtoy) Date: 20061109 09:00 Message: Logged In: YES user_id=28849 Fixed as suggested, with slight correction.  Comment By: Raymond Toy (rtoy) Date: 20061108 23:26 Message: Logged In: YES user_id=28849 Oops. I think the formula was intended to be %i*log((x+%i*y)/sqrt(x^2+y^2)). That produces the correct values. At least factor(rectform(<formula>)) produces atan2(y/r,x/r) with r = sqrt(x^2+y^2). It would be nice if atan2 simplified out the denominator to leave only atan2(y,x).  Comment By: Raymond Toy (rtoy) Date: 20061108 23:13 Message: Logged In: YES user_id=28849 Isn't this formula also wrong? For y=1, x=1, the formula becomes %i*log((1%i)/sqrt(2)). But log is the principal log so we still get %pi/4. I think it would be better to make atan2 be in the range (%pi,%pi].  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626721&group_id=4933 
From: SourceForge.net <noreply@so...>  20061109 04:26:30

Bugs item #626721, was opened at 20021022 03:15 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626721&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: logarc of atan2 wrong Initial Comment: res : logarc(atan2(y,x))$ rectform(res),y=1,x=1; => %pi/4 BUT atan2(1,1) => 3*%pi/4 The fix is to change the formula in $logarc and in simpatan2. Currently, logarc(atan2(y,x)) => logarc(atan (y/x)), which gives incorrect results as above. This formula should be replaced by %i*log((y+%i*x)/sqrt(x^2+y^2))  >Comment By: Raymond Toy (rtoy) Date: 20061108 23:26 Message: Logged In: YES user_id=28849 Oops. I think the formula was intended to be %i*log((x+%i*y)/sqrt(x^2+y^2)). That produces the correct values. At least factor(rectform(<formula>)) produces atan2(y/r,x/r) with r = sqrt(x^2+y^2). It would be nice if atan2 simplified out the denominator to leave only atan2(y,x).  Comment By: Raymond Toy (rtoy) Date: 20061108 23:13 Message: Logged In: YES user_id=28849 Isn't this formula also wrong? For y=1, x=1, the formula becomes %i*log((1%i)/sqrt(2)). But log is the principal log so we still get %pi/4. I think it would be better to make atan2 be in the range (%pi,%pi].  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626721&group_id=4933 