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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2
(9) 
3
(5) 
4

5
(5) 
6
(4) 
7

8

9
(3) 
10

11
(7) 
12
(7) 
13

14

15
(2) 
16
(1) 
17

18
(1) 
19
(2) 
20

21
(2) 
22

23
(6) 
24
(5) 
25
(2) 
26
(2) 
27

28

29
(7) 
30



From: SourceForge.net <noreply@so...>  20100906 06:23:34

Bugs item #3060166, was opened at 20100906 07:23 Message generated for change (Tracker Item Submitted) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3060166&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: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: und documentation is incorrect Initial Comment: Maxima 5.22.1 http://maxima.sourceforge.net using Lisp CMU Common Lisp CVS 20a 20arelease + minimal debian patches (20A Unicode) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) ? und  Constant: und `und' represents an undefined result. See also `limit'. Example: (%i1) limit (1/x, x, 0); (%o1) und There are also some inexact matches for `und'. Try `?? und' to see them. (%o1) true (%i2) limit(1/x,x,0); (%o2) infinity (%i3) ? infinity  Constant: infinity `infinity' represents complex infinity.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3060166&group_id=4933 
From: SourceForge.net <noreply@so...>  20100905 23:50:25

Bugs item #2555641, was opened at 20090201 14:43 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2555641&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: no doc for subnumsimp Initial Comment: There is no user documentation for the option variable subnumsimp (used in comm.lisp/subst1).  >Comment By: Dieter Kaiser (crategus) Date: 20100906 01:50 Message: Documentation has been added in Operators.texi revision 1.60. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2555641&group_id=4933 
From: SourceForge.net <noreply@so...>  20100905 20:38:26

Bugs item #2171237, was opened at 20081016 12:44 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171237&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: load(basic) warnings Initial Comment: In a fresh Maxima, load("basic") gives warnings about redefining functions. These functions aren't built in, so I think the warnings are spurious. As far as I know, the warnings don't cause problems, they are only distracting. (%i1) load("basic")$ Warning  you are redefining the Maxima function prog1 Warning  you are redefining the Maxima function symbolcheck Warning  you are redefining the Maxima function push Warning  you are redefining the Maxima function pop Warning  you are redefining the Maxima function tr_ev  >Comment By: Dieter Kaiser (crategus) Date: 20100905 22:38 Message: Fixed in basic.mac revision 1.3. Closing this bug report as fixed. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20081031 00:58 Message: I think the eval_when and herald_package statements should be cutthat eliminates the warnings. The stuff to autoload stuff needs to be somewhere else. /* eval_when([translate,batch,demo], if get('sharem,'version) = false then load(autolo))$ herald_package(basic)$ */  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2171237&group_id=4933 
From: SourceForge.net <noreply@so...>  20100905 20:30:21

Bugs item #2779656, was opened at 20090423 18:07 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2779656&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: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: not "read_xpm" Initial Comment: command read_xpm not work How read image files (*.bmp, *.jpg, *.xpm, *.png) from command line? >From menu this work fine. 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  >Comment By: Dieter Kaiser (crategus) Date: 20100905 22:30 Message: It is not really clear from this bug report, what the problem is. There is no example. There is no answer to the last posting. Setting the status to pending and the resolution to "out of date". Dieter Kaiser  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20090423 20:53 Message: Does your xpm file contain transparent regions? If I recall correctly, this was one of the weak aspects of function read_xpm. In general, package 'picture' needs extra work; it contains a minimal image processing support to help package 'draw' in rendering images. Don't expect much of it, at least in its present state. No Maxima package contains routines for reading bmp, jpg and png images.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2779656&group_id=4933 
From: SourceForge.net <noreply@so...>  20100905 12:01:04

Bugs item #2068007, was opened at 20080822 20:15 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2068007&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: Includes proposed fix >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Dr. Schorsch (xorx) Assigned to: Nobody/Anonymous (nobody) Summary: Working directory for plot output is not defined Initial Comment: Problem ======= Using WXMaxima on Windows XP the working directory for gnuplot file output is badly defined or undefined. > plot2d (sin(x), [x, 5, 5], [gnuplot_term,ps], [gnuplot_out_file,"test.ps"]); Does write its output to somewhere or even to nowhere. At least I could not find it. The documentation gives no information about this. One could assume that this file is written to the directory where the maximafile resides or otherwise to the users tempdirectory. WorkAround ============ The following command does write the file to the expected location, but it is very unconvenient to specify an absolute path: > plot2d (sin(x), [x, 5, 5], [gnuplot_term,ps], [gnuplot_out_file,"C:/mytemp/test.ps"]); Proposed Improvement ==================== Make path names for plot output relative to the documents path. This would allow to specify files as follows: [gnuplot_out_file,"../MyPlots/test.ps"]); Software used ============= Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20100905 14:01 Message: A comment has been added in Input.texi revision 1.79 about the behavior of Maxima to use the current working directory to store a file. It might be a feature request to change the current behavior of Maxima. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100905 13:26 Message: When a filename is passed to functions like PLOT2D, SAVE, or WRITEFILE and the filename is not a complete pathname, Maxima stores the file in the current working directory. The current working directory depends on the system like Windows or Linux and on the installation. When I start a Maxima console from an installed icon which starts maxima.bat, the current working directory on my system is 'c:/Dokumente und Einstellungen/Dieter/'. This is a default choice for a current working directory on Windows. When I start wxMaxima the current working directory is 'd:/Programme/Maxima5.22.1/wxMaxima/'. This is the path I have installed Maxima 5.22. The current working directory can be configured in the property menu of the icon, which starts the program. On a Linux system I always start at first a terminal, change to a suitable directory and then I start Maxima from the terminal. The last directory becomes the current working directory. Here are some examples to get these informations. At first the plot of the example: (%i1) plot2d(sin(x),[x,5,5],[gnuplot_term,ps],[gnuplot_out_file,'mytest.ps']); (%o1) The Maxima function FILE_SEARCH can locate the file. But it does not return a full pathame. This indicates that the file is stored in the current working directory, otherwise FILE_SEARCH will return a full pathname: (%i2) file_search('mytest.ps'); (%o2) mytest.ps We can use the Lisp function TRUENAME to get in addition the full pathname. (%i3) ?truename(file_search('test.ps')); (%o3) /home/dieter/workspace/maxima/test.ps The file is stored in the current working directory '/home/dieter/workspace/', that is the directory I have started Maxima on my Linux system. We can extract the directory the following way: (%i4) pathname_directory(?truename(file_search('test.ps'))); (%o4) /home/dieter/workspace/maxima/ We have an undocumented function DIRECTORY which shows the current working directory on a Linux system when called with an empty string. On a Windows system with GCL the function shows a list of files and directories of the current working directory: (%i5) directory(''); (%o5) [/home/dieter/workspace/maxima/] We have two global Lisp variables *maximatempdir* and *maximauserdir*. When we do not pass a filename to the function PLOT2D, the output of gnuplot is stored in the directroy named by *maximatempdir*. I would tend to say that the current behavior to store files in the current working directory might be not what a user expects, but this behavior is not a bug. We might improve the documentation on this point. Another point might be to improve FILE_SEARCH and other file input/output functions to return always a full pathname. Further remarks: Because, the undocumented function DIRECTORY behaves different on Linux and Windows I hesitated to document it. Perhaps, we should do an implementation which is more independent from the underlying system and Lisp or cut it out. Furthermore, we have the function LOAD_SEARCH_DIR. This function prints the value of the global Lisp variable *defaultpathnamedefaults*. On SBCL this global Lisp variable is set to the current working directory, but not on other Lisp's like CLISP and GCL. On the latter Lisp's the variable *defaultpathnamedefaults* is NIL. I think this function should be cut out too. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2068007&group_id=4933 
From: SourceForge.net <noreply@so...>  20100905 11:26:48

Bugs item #2068007, was opened at 20080822 20:15 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2068007&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: Includes proposed fix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dr. Schorsch (xorx) Assigned to: Nobody/Anonymous (nobody) Summary: Working directory for plot output is not defined Initial Comment: Problem ======= Using WXMaxima on Windows XP the working directory for gnuplot file output is badly defined or undefined. > plot2d (sin(x), [x, 5, 5], [gnuplot_term,ps], [gnuplot_out_file,"test.ps"]); Does write its output to somewhere or even to nowhere. At least I could not find it. The documentation gives no information about this. One could assume that this file is written to the directory where the maximafile resides or otherwise to the users tempdirectory. WorkAround ============ The following command does write the file to the expected location, but it is very unconvenient to specify an absolute path: > plot2d (sin(x), [x, 5, 5], [gnuplot_term,ps], [gnuplot_out_file,"C:/mytemp/test.ps"]); Proposed Improvement ==================== Make path names for plot output relative to the documents path. This would allow to specify files as follows: [gnuplot_out_file,"../MyPlots/test.ps"]); Software used ============= Maxima version: 5.15.0 Maxima build date: 17:36 4/20/2008 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Dieter Kaiser (crategus) Date: 20100905 13:26 Message: When a filename is passed to functions like PLOT2D, SAVE, or WRITEFILE and the filename is not a complete pathname, Maxima stores the file in the current working directory. The current working directory depends on the system like Windows or Linux and on the installation. When I start a Maxima console from an installed icon which starts maxima.bat, the current working directory on my system is 'c:/Dokumente und Einstellungen/Dieter/'. This is a default choice for a current working directory on Windows. When I start wxMaxima the current working directory is 'd:/Programme/Maxima5.22.1/wxMaxima/'. This is the path I have installed Maxima 5.22. The current working directory can be configured in the property menu of the icon, which starts the program. On a Linux system I always start at first a terminal, change to a suitable directory and then I start Maxima from the terminal. The last directory becomes the current working directory. Here are some examples to get these informations. At first the plot of the example: (%i1) plot2d(sin(x),[x,5,5],[gnuplot_term,ps],[gnuplot_out_file,'mytest.ps']); (%o1) The Maxima function FILE_SEARCH can locate the file. But it does not return a full pathame. This indicates that the file is stored in the current working directory, otherwise FILE_SEARCH will return a full pathname: (%i2) file_search('mytest.ps'); (%o2) mytest.ps We can use the Lisp function TRUENAME to get in addition the full pathname. (%i3) ?truename(file_search('test.ps')); (%o3) /home/dieter/workspace/maxima/test.ps The file is stored in the current working directory '/home/dieter/workspace/', that is the directory I have started Maxima on my Linux system. We can extract the directory the following way: (%i4) pathname_directory(?truename(file_search('test.ps'))); (%o4) /home/dieter/workspace/maxima/ We have an undocumented function DIRECTORY which shows the current working directory on a Linux system when called with an empty string. On a Windows system with GCL the function shows a list of files and directories of the current working directory: (%i5) directory(''); (%o5) [/home/dieter/workspace/maxima/] We have two global Lisp variables *maximatempdir* and *maximauserdir*. When we do not pass a filename to the function PLOT2D, the output of gnuplot is stored in the directroy named by *maximatempdir*. I would tend to say that the current behavior to store files in the current working directory might be not what a user expects, but this behavior is not a bug. We might improve the documentation on this point. Another point might be to improve FILE_SEARCH and other file input/output functions to return always a full pathname. Further remarks: Because, the undocumented function DIRECTORY behaves different on Linux and Windows I hesitated to document it. Perhaps, we should do an implementation which is more independent from the underlying system and Lisp or cut it out. Furthermore, we have the function LOAD_SEARCH_DIR. This function prints the value of the global Lisp variable *defaultpathnamedefaults*. On SBCL this global Lisp variable is set to the current working directory, but not on other Lisp's like CLISP and GCL. On the latter Lisp's the variable *defaultpathnamedefaults* is NIL. I think this function should be cut out too. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2068007&group_id=4933 
From: SourceForge.net <noreply@so...>  20100903 22:09:02

Bugs item #3058604, was opened at 20100903 07:46 Message generated for change (Comment added) made by schmoffel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&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: Johannes Putzke (schmoffel) Assigned to: Nobody/Anonymous (nobody) Summary: inf calc Initial Comment: Hi guys, I wrote a small batch file and it does not take an end with the calculation: Here some information:  Maxima version: 5.21.1 Maxima build date: 21:54 8/30/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.42  The problem accours in the function E_i(t), when it calls ix(t,z). After some debuggin I got this message:  rat: replaced 333.333333333333 by 1000/3 = 333.333333333333 Trace exiting E_i level 1 Entering a Maxima break point. Type 'exit;' to resume. _exit; (1 EXIT $E_i (#1=(MTIMES . #2=(SIMP)) 600000 ((%INTEGRATE . #2#) (#1# ((MPLUS SIMP #3=(14 #4="/home/eule/Projekte/Bachelorarbeit/Berechnungen/lampnew.mac" SRC $E_i 14)) 1000000 (#1# 2 ((MEXPT SIMP #3#) $Z 2))) (#5=(MEXPT . #2#) ((MPLUS SIMP #3#) 1000000 ((MEXPT SIMP #3#) $Z 2)) 2) (#5# ((MPLUS SIMP #6=(6 #4# SRC $IX 6)) 1 (#1# (#7=(RAT SIMP) 1 320000000000000000000000000) (#5# ((MPLUS SIMP #6#) $T (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8=(#7# 1 2)))) 5))) 1) ((MEXPT SIMP #6#) $%E (#1# 10000 (#9=(MPLUS . #2#) (#1# 1 $T) (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8#)))))) $Z 0 ((MTIMES SIMP #10=(8 #4# SRC $HX 8)) 2.222222222222222e9 ((MPLUS SIMP #10#) ((MTIMES SIMP #10#) 90000000000000000 $T) (#1# 1.5e11 (#5# (#9# 3.0 (#1# 90000000000 ((MEXPT SIMP #10#) $T 2))) #8#))))))  at this point the program doesn't react anymore. Its reproduceable and I have idea, whats it is.  >Comment By: Johannes Putzke (schmoffel) Date: 20100903 22:09 Message: I attatched a new file. In the previous I had a small mistake. in: ipx(t,z) := diff(ix(t,t),t,1); you have to change the parameters from ix(t,t) to ix(t,z). Now the error comes a little bit earlier, but its the same. @crategus : I don't think the integration question has something to do with it. when you run the new batch file, you can see, that after the questions a lot of parameters are handeld. But after a while, it stops and cpuusage goes to 100%. Very strange @rtoy: Yes. The problem is, that i have to calculate a little bit more with symbolic functions. This is just a small extract from a bigger file. In addition, I need the output for some of the symbolic calculations. Do someone know how I can do maxima a little bit more communicative, means print more messages? And how can I assign maxima to answer the integration question automatically?  Comment By: Dieter Kaiser (crategus) Date: 20100903 19:06 Message: When I enter all of the definitions of this example and I try to get a numerical value for E_di(t), I get an error: (%i18) E_di(1.0); diff: second argument must be a variable; found 1.0 #0: ipx(t=1.0,z=z) #1: E_di(t=1.0)  an error. To debug this try: debugmode(true); When I try to get a result for a symbolic value I get a question from integrate. This might be the reason the example seems to hang. (%i19) E_di(x); Is sqrt(3*(30000000000*x^2+1))600000*x positive, negative, or zero? p; (%o19) (5.399999999999998e+75*x^7+sqrt(9.e+10*x^2+3.0) *(9.e+69*x^6+3.999999999999997e+59*x^4 1.777777777777776e+49*x^2 7.901234567901232e+38) +5.999999999999999e+65*x^5 +2.133333333333333e+55*x^3 +2.37037037037037e+44*x) *sqrt(1.333333333333333e+11*x*sqrt(9.e+10*x^2+3.0) +5.e+16*x^2+1333333.333333333) *(100000000*(x/(300000000*sqrt(x^2+1000000))1) *%e^(10000*(sqrt(x^2+1000000)/300000000x)) /(1/(320000000000000000000000000*(xsqrt(x^2+1000000)/300000000)^5) +1) +(1x/(300000000*sqrt(x^2+1000000))) *%e^(10000*(sqrt(x^2+1000000)/300000000x)) /(6400000000000000000000*(xsqrt(x^2+1000000)/300000000)^6 *(1/(320000000000000000000000000 *(xsqrt(x^2+1000000)/300000000)^5) +1) ^2)) /(5*(8.099999999999997e+89*x^8+1.44e+80*x^6+9.599999999999996e+69*x^4 +2.844444444444443e+59*x^2 +3.160493827160493e+48)) I think we do not have a bug, but the problem has to be reformulated to give the expected answers. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100903 12:43 Message: I think maxima is getting stuck doing an adaptive plot of E_i(t) and the integration in E_i(t) is probably causing the problem. In E_i(t), you may want to replace integrate(...) with quad_qags(...)[1]. This will numerically integrate the expression instead of trying to do it symbolically. When I do this, I get a nice plot of E_i(t). Can't do this for E_di(t), because you compute the symbolic derivative later in E_dip(t). But maxima has no problem plotting E_di(t).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&group_id=4933 
From: SourceForge.net <noreply@so...>  20100903 19:48:10

Bugs item #3058324, was opened at 20100902 20:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100903 21:48 Message: Closing this bug report as invalid. We have no bug. When we bind *printcircle* to NIL only the readability of the output file is changed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100902 22:55 Message: Sorry, I was too fast. You are right. It is no problem to load a file which is stored with *printcircle* bind to T. The only difference is, that the file is more readable, when the data is stored with *printcircle* bind to NIL. So, should we revert the change I have already done? Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20100902 22:44 Message: I'm not convinced there is actually a problem here. The Lisp input reader knows how to deal with those #1=... references, right? So the file is actually readable as it stands, if I'm not mistaken. Or is it not guaranteed that Sexpressions with such references are readable?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100903 19:06:02

Bugs item #3058604, was opened at 20100903 09:46 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&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: Johannes Putzke (schmoffel) Assigned to: Nobody/Anonymous (nobody) Summary: inf calc Initial Comment: Hi guys, I wrote a small batch file and it does not take an end with the calculation: Here some information:  Maxima version: 5.21.1 Maxima build date: 21:54 8/30/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.42  The problem accours in the function E_i(t), when it calls ix(t,z). After some debuggin I got this message:  rat: replaced 333.333333333333 by 1000/3 = 333.333333333333 Trace exiting E_i level 1 Entering a Maxima break point. Type 'exit;' to resume. _exit; (1 EXIT $E_i (#1=(MTIMES . #2=(SIMP)) 600000 ((%INTEGRATE . #2#) (#1# ((MPLUS SIMP #3=(14 #4="/home/eule/Projekte/Bachelorarbeit/Berechnungen/lampnew.mac" SRC $E_i 14)) 1000000 (#1# 2 ((MEXPT SIMP #3#) $Z 2))) (#5=(MEXPT . #2#) ((MPLUS SIMP #3#) 1000000 ((MEXPT SIMP #3#) $Z 2)) 2) (#5# ((MPLUS SIMP #6=(6 #4# SRC $IX 6)) 1 (#1# (#7=(RAT SIMP) 1 320000000000000000000000000) (#5# ((MPLUS SIMP #6#) $T (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8=(#7# 1 2)))) 5))) 1) ((MEXPT SIMP #6#) $%E (#1# 10000 (#9=(MPLUS . #2#) (#1# 1 $T) (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8#)))))) $Z 0 ((MTIMES SIMP #10=(8 #4# SRC $HX 8)) 2.222222222222222e9 ((MPLUS SIMP #10#) ((MTIMES SIMP #10#) 90000000000000000 $T) (#1# 1.5e11 (#5# (#9# 3.0 (#1# 90000000000 ((MEXPT SIMP #10#) $T 2))) #8#))))))  at this point the program doesn't react anymore. Its reproduceable and I have idea, whats it is.  >Comment By: Dieter Kaiser (crategus) Date: 20100903 21:06 Message: When I enter all of the definitions of this example and I try to get a numerical value for E_di(t), I get an error: (%i18) E_di(1.0); diff: second argument must be a variable; found 1.0 #0: ipx(t=1.0,z=z) #1: E_di(t=1.0)  an error. To debug this try: debugmode(true); When I try to get a result for a symbolic value I get a question from integrate. This might be the reason the example seems to hang. (%i19) E_di(x); Is sqrt(3*(30000000000*x^2+1))600000*x positive, negative, or zero? p; (%o19) (5.399999999999998e+75*x^7+sqrt(9.e+10*x^2+3.0) *(9.e+69*x^6+3.999999999999997e+59*x^4 1.777777777777776e+49*x^2 7.901234567901232e+38) +5.999999999999999e+65*x^5 +2.133333333333333e+55*x^3 +2.37037037037037e+44*x) *sqrt(1.333333333333333e+11*x*sqrt(9.e+10*x^2+3.0) +5.e+16*x^2+1333333.333333333) *(100000000*(x/(300000000*sqrt(x^2+1000000))1) *%e^(10000*(sqrt(x^2+1000000)/300000000x)) /(1/(320000000000000000000000000*(xsqrt(x^2+1000000)/300000000)^5) +1) +(1x/(300000000*sqrt(x^2+1000000))) *%e^(10000*(sqrt(x^2+1000000)/300000000x)) /(6400000000000000000000*(xsqrt(x^2+1000000)/300000000)^6 *(1/(320000000000000000000000000 *(xsqrt(x^2+1000000)/300000000)^5) +1) ^2)) /(5*(8.099999999999997e+89*x^8+1.44e+80*x^6+9.599999999999996e+69*x^4 +2.844444444444443e+59*x^2 +3.160493827160493e+48)) I think we do not have a bug, but the problem has to be reformulated to give the expected answers. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20100903 14:43 Message: I think maxima is getting stuck doing an adaptive plot of E_i(t) and the integration in E_i(t) is probably causing the problem. In E_i(t), you may want to replace integrate(...) with quad_qags(...)[1]. This will numerically integrate the expression instead of trying to do it symbolically. When I do this, I get a nice plot of E_i(t). Can't do this for E_di(t), because you compute the symbolic derivative later in E_dip(t). But maxima has no problem plotting E_di(t).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&group_id=4933 
From: SourceForge.net <noreply@so...>  20100903 12:43:36

Bugs item #3058604, was opened at 20100903 03:46 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&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: Johannes Putzke (schmoffel) Assigned to: Nobody/Anonymous (nobody) Summary: inf calc Initial Comment: Hi guys, I wrote a small batch file and it does not take an end with the calculation: Here some information:  Maxima version: 5.21.1 Maxima build date: 21:54 8/30/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.42  The problem accours in the function E_i(t), when it calls ix(t,z). After some debuggin I got this message:  rat: replaced 333.333333333333 by 1000/3 = 333.333333333333 Trace exiting E_i level 1 Entering a Maxima break point. Type 'exit;' to resume. _exit; (1 EXIT $E_i (#1=(MTIMES . #2=(SIMP)) 600000 ((%INTEGRATE . #2#) (#1# ((MPLUS SIMP #3=(14 #4="/home/eule/Projekte/Bachelorarbeit/Berechnungen/lampnew.mac" SRC $E_i 14)) 1000000 (#1# 2 ((MEXPT SIMP #3#) $Z 2))) (#5=(MEXPT . #2#) ((MPLUS SIMP #3#) 1000000 ((MEXPT SIMP #3#) $Z 2)) 2) (#5# ((MPLUS SIMP #6=(6 #4# SRC $IX 6)) 1 (#1# (#7=(RAT SIMP) 1 320000000000000000000000000) (#5# ((MPLUS SIMP #6#) $T (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8=(#7# 1 2)))) 5))) 1) ((MEXPT SIMP #6#) $%E (#1# 10000 (#9=(MPLUS . #2#) (#1# 1 $T) (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8#)))))) $Z 0 ((MTIMES SIMP #10=(8 #4# SRC $HX 8)) 2.222222222222222e9 ((MPLUS SIMP #10#) ((MTIMES SIMP #10#) 90000000000000000 $T) (#1# 1.5e11 (#5# (#9# 3.0 (#1# 90000000000 ((MEXPT SIMP #10#) $T 2))) #8#))))))  at this point the program doesn't react anymore. Its reproduceable and I have idea, whats it is.  >Comment By: Raymond Toy (rtoy) Date: 20100903 08:43 Message: I think maxima is getting stuck doing an adaptive plot of E_i(t) and the integration in E_i(t) is probably causing the problem. In E_i(t), you may want to replace integrate(...) with quad_qags(...)[1]. This will numerically integrate the expression instead of trying to do it symbolically. When I do this, I get a nice plot of E_i(t). Can't do this for E_di(t), because you compute the symbolic derivative later in E_dip(t). But maxima has no problem plotting E_di(t).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&group_id=4933 
From: SourceForge.net <noreply@so...>  20100903 07:46:26

Bugs item #3058604, was opened at 20100903 07:46 Message generated for change (Tracker Item Submitted) made by schmoffel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&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: Johannes Putzke (schmoffel) Assigned to: Nobody/Anonymous (nobody) Summary: inf calc Initial Comment: Hi guys, I wrote a small batch file and it does not take an end with the calculation: Here some information:  Maxima version: 5.21.1 Maxima build date: 21:54 8/30/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.42  The problem accours in the function E_i(t), when it calls ix(t,z). After some debuggin I got this message:  rat: replaced 333.333333333333 by 1000/3 = 333.333333333333 Trace exiting E_i level 1 Entering a Maxima break point. Type 'exit;' to resume. _exit; (1 EXIT $E_i (#1=(MTIMES . #2=(SIMP)) 600000 ((%INTEGRATE . #2#) (#1# ((MPLUS SIMP #3=(14 #4="/home/eule/Projekte/Bachelorarbeit/Berechnungen/lampnew.mac" SRC $E_i 14)) 1000000 (#1# 2 ((MEXPT SIMP #3#) $Z 2))) (#5=(MEXPT . #2#) ((MPLUS SIMP #3#) 1000000 ((MEXPT SIMP #3#) $Z 2)) 2) (#5# ((MPLUS SIMP #6=(6 #4# SRC $IX 6)) 1 (#1# (#7=(RAT SIMP) 1 320000000000000000000000000) (#5# ((MPLUS SIMP #6#) $T (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8=(#7# 1 2)))) 5))) 1) ((MEXPT SIMP #6#) $%E (#1# 10000 (#9=(MPLUS . #2#) (#1# 1 $T) (#1# (#7# 1 300000000) (#5# ((MPLUS SIMP #6#) 1000000 ((MEXPT SIMP #6#) $Z 2)) #8#)))))) $Z 0 ((MTIMES SIMP #10=(8 #4# SRC $HX 8)) 2.222222222222222e9 ((MPLUS SIMP #10#) ((MTIMES SIMP #10#) 90000000000000000 $T) (#1# 1.5e11 (#5# (#9# 3.0 (#1# 90000000000 ((MEXPT SIMP #10#) $T 2))) #8#))))))  at this point the program doesn't react anymore. Its reproduceable and I have idea, whats it is.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058604&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 20:55:55

Bugs item #3058324, was opened at 20100902 20:52 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20100902 22:55 Message: Sorry, I was too fast. You are right. It is no problem to load a file which is stored with *printcircle* bind to T. The only difference is, that the file is more readable, when the data is stored with *printcircle* bind to NIL. So, should we revert the change I have already done? Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20100902 22:44 Message: I'm not convinced there is actually a problem here. The Lisp input reader knows how to deal with those #1=... references, right? So the file is actually readable as it stands, if I'm not mistaken. Or is it not guaranteed that Sexpressions with such references are readable?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 20:44:07

Bugs item #3058324, was opened at 20100902 12:52 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  >Comment By: Robert Dodier (robert_dodier) Date: 20100902 14:44 Message: I'm not convinced there is actually a problem here. The Lisp input reader knows how to deal with those #1=... references, right? So the file is actually readable as it stands, if I'm not mistaken. Or is it not guaranteed that Sexpressions with such references are readable?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 18:52:39

Bugs item #3058324, was opened at 20100902 20:52 Message generated for change (Tracker Item Submitted) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: $save must bind *printcircle* to NIL Initial Comment: The function $save saves LispExpressions. Therefore, the global Lisp variable *printcircle* must be bound to NIL. This is an example for wrong output: (%i1) display2d:false$ (%i2) assume(a>0,b>0)$ (%i3) save("maxima.log",all); (%o3) "/home/dieter/workspace/maxima/maxima.log" (%i4) printfile("maxima.log"); ;;; * Mode: LISP; package:maxima; syntax:commonlisp; * (inpackage :maxima) (DSKSETQ $%I1 '((MSETQ) $DISPLAY2D NIL)) (ADDLABEL '$%I1) (DSKSETQ $%O1 NIL) (ADDLABEL '$%O1) (DSKSETQ $%I2 '(($ASSUME) (#1=(MGREATERP) $A 0) (#1# $B 0))) (ADDLABEL '$%I2) (DSKSETQ $%O2 '((MLIST . #1=(SIMP)) ((MGREATERP . #1#) $A 0) ((MGREATERP . #1#) $B 0))) [...] (%o4) "maxima.log" Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058324&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 17:54:48

Bugs item #3056276, was opened at 20100830 16:24 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x^2) with domain:complex Initial Comment: abs(x)^2,domain:real => x^2 OK abs(x^2),domain:real => x^2 OK abs(x)^2,domain:complex => abs(x)^2 OK abs(x^2),domain:complex => x^2 NO! Should be abs(x)^2 The abs(x)^2 behavior is not documented by the docstring, but makes sense and should also apply to the abs(x^2) case.  >Comment By: Stavros Macrakis (macrakis) Date: 20100902 13:54 Message: Dieter, Barton: yes, declare(x,complex) handles this case. Barton: Do we have a policy for what domain : complex means? It is documented to only deal with powers. The abs case seems like a reasonable extension... but of course lots of things could be 'reasonable extensions'.  Comment By: Barton Willis (willisbl) Date: 20100901 22:58 Message: Declaring x to be complex allows Maxima to return the correct value: (%i1) declare(x,complex)$ (%i2) abs(x^2),domain:complex; (%o2) abs(x)^2 (%i3) abs(x^2),domain:real; (%o3) abs(x)^2 Do we have a policy for what domain : complex means?  Comment By: Stavros Macrakis (macrakis) Date: 20100831 17:14 Message: Maybe one way to simplify the logic here is to consider that domain:complex means that all variables are implicitly declared complex (unless explicitly declared otherwise).  Comment By: Dieter Kaiser (crategus) Date: 20100831 17:07 Message: For the record: Both examples are correct for a symbol declared to be complex: (%i2) declare(z,complex)$ (%i3) abs(z^2),domain:real; (%o3) abs(z)^2 (%i4) abs(z^2),domain:complex; (%o4) abs(z)^2 The wrong simplification of abs(x^2) for a complex domain happens in the simplifier simpabs for the Abs function. The simplifier does not respect the global value of $domain. I think this bug report shows a general problem. Almost all functions in Maxima do not respect the concept of a real and complex domain. There are only some functions which take into account this concept. One example is the simplifier simpexpt for the power function. In Maxima core code I have counted 10 tests of the variable $domain. 9 of these tests are in simpexpt or related functions and 1 test we have in $rootscontract. We have the two functions risplit and $defint which set the global variable $domain to a value. In Maxima share code I have counted one test of the variable $complex. I had a look only at Lisp code. Perhaps, it is necessary to decide if it is desirable to fully implement the concept of a real and domain complex or to cut out the few examples of code, which we have. We always can declare symbols to be complex. This concept is implemented much more complete. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 17:41:06

Bugs item #3058290, was opened at 20100902 13:41 Message generated for change (Tracker Item Submitted) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058290&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: tan(%pi*integer) simplification Initial Comment: declare(nnn,integer)$ tan(nnn*%pi) => unsimplified tan(2*nnn*%pi) => 0 But tan has zeroes for all integral multiples of %pi, not just even ones.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058290&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 17:35:39

Bugs item #3058208, was opened at 20100902 16:38 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Christopher Fair (quenyen314) Assigned to: Nobody/Anonymous (nobody) Summary: Error in identity Initial Comment: cos(%pi) + i*sin(%pi) evaluates to 1....that is an error it should be cos(%pi)+%i*sin(%pi) evaluating to 1...... On a related note the ln(1) should evaluate to %i*%pi....it does not...%e^(%i*%pi) correctly evaluates to 1 though  >Comment By: Dieter Kaiser (crategus) Date: 20100902 19:35 Message: I do not see a problem. sin(%pi) is 0 and cos(%pi) is 1. Therefore, both of your examples have the value 1. log(1) does not evaluate to %i*%pi by default. But it is possible to set the option variable lognegint or to use the function rectform: (%i4) log(1),lognegint; (%o4) %i*%pi (%i5) rectform(log(1)); (%o5) %i*%pi Furthermore, it is possible to set the option variable lognegint globally: (%i6) lognegint:true; (%o6) true (%i7) log(1); (%o7) %i*%pi Closing this bug report as invalid. Dieter Kaiser  Comment By: Christopher Fair (quenyen314) Date: 20100902 16:40 Message: btw....I made a mistake in that it should be log(1) in maxima log is natural log not ln  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 14:40:50

Bugs item #3058208, was opened at 20100902 08:38 Message generated for change (Comment added) made by quenyen314 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&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: Christopher Fair (quenyen314) Assigned to: Nobody/Anonymous (nobody) Summary: Error in identity Initial Comment: cos(%pi) + i*sin(%pi) evaluates to 1....that is an error it should be cos(%pi)+%i*sin(%pi) evaluating to 1...... On a related note the ln(1) should evaluate to %i*%pi....it does not...%e^(%i*%pi) correctly evaluates to 1 though  >Comment By: Christopher Fair (quenyen314) Date: 20100902 08:40 Message: btw....I made a mistake in that it should be log(1) in maxima log is natural log not ln  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 14:38:59

Bugs item #3058208, was opened at 20100902 08:38 Message generated for change (Tracker Item Submitted) made by quenyen314 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&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: Christopher Fair (quenyen314) Assigned to: Nobody/Anonymous (nobody) Summary: Error in identity Initial Comment: cos(%pi) + i*sin(%pi) evaluates to 1....that is an error it should be cos(%pi)+%i*sin(%pi) evaluating to 1...... On a related note the ln(1) should evaluate to %i*%pi....it does not...%e^(%i*%pi) correctly evaluates to 1 though  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3058208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100902 02:58:26

Bugs item #3056276, was opened at 20100830 15:24 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: abs(x^2) with domain:complex Initial Comment: abs(x)^2,domain:real => x^2 OK abs(x^2),domain:real => x^2 OK abs(x)^2,domain:complex => abs(x)^2 OK abs(x^2),domain:complex => x^2 NO! Should be abs(x)^2 The abs(x)^2 behavior is not documented by the docstring, but makes sense and should also apply to the abs(x^2) case.  >Comment By: Barton Willis (willisbl) Date: 20100901 21:58 Message: Declaring x to be complex allows Maxima to return the correct value: (%i1) declare(x,complex)$ (%i2) abs(x^2),domain:complex; (%o2) abs(x)^2 (%i3) abs(x^2),domain:real; (%o3) abs(x)^2 Do we have a policy for what domain : complex means?  Comment By: Stavros Macrakis (macrakis) Date: 20100831 16:14 Message: Maybe one way to simplify the logic here is to consider that domain:complex means that all variables are implicitly declared complex (unless explicitly declared otherwise).  Comment By: Dieter Kaiser (crategus) Date: 20100831 16:07 Message: For the record: Both examples are correct for a symbol declared to be complex: (%i2) declare(z,complex)$ (%i3) abs(z^2),domain:real; (%o3) abs(z)^2 (%i4) abs(z^2),domain:complex; (%o4) abs(z)^2 The wrong simplification of abs(x^2) for a complex domain happens in the simplifier simpabs for the Abs function. The simplifier does not respect the global value of $domain. I think this bug report shows a general problem. Almost all functions in Maxima do not respect the concept of a real and complex domain. There are only some functions which take into account this concept. One example is the simplifier simpexpt for the power function. In Maxima core code I have counted 10 tests of the variable $domain. 9 of these tests are in simpexpt or related functions and 1 test we have in $rootscontract. We have the two functions risplit and $defint which set the global variable $domain to a value. In Maxima share code I have counted one test of the variable $complex. I had a look only at Lisp code. Perhaps, it is necessary to decide if it is desirable to fully implement the concept of a real and domain complex or to cut out the few examples of code, which we have. We always can declare symbols to be complex. This concept is implemented much more complete. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3056276&group_id=4933 