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}
(13) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2
(2) 
3
(1) 
4

5

6
(4) 
7

8

9
(3) 
10
(1) 
11
(4) 
12
(3) 
13

14
(4) 
15
(6) 
16

17
(6) 
18
(6) 
19
(4) 
20
(10) 
21
(6) 
22
(3) 
23
(2) 
24
(1) 
25
(1) 
26
(11) 
27
(6) 
28
(4) 
29
(11) 
30
(2) 
31






From: SourceForge.net <noreply@so...>  20071230 14:04:05

Bugs item #1629043, was opened at 20070105 15:13 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629043&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  Assume Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume: < doesn't imply notequal Initial Comment: assume(r<1)$ is(equal(r,1)) => unknown (???) Maxima 5.11.0 GCL 2.6.8 Windows 2k  >Comment By: Dan Gildea (dgildea) Date: 20071230 09:04 Message: Logged In: YES user_id=1797506 Originator: NO Works in current cvs. (%i1) assume(r<1)$ (%i2) is(equal(r,1)); (%o2) false (%i3) is(equal(r,2)); (%o3) false (%i4) is(equal(r,0)); (%o4) unknown  Comment By: Barton Willis (willisbl) Date: 20070405 23:56 Message: Logged In: YES user_id=895922 Originator: NO Appending (simplifya e nil) might not be the right thing to do, but it does eliminate this bug: (defun equalfactssimp (e) (let ((f (margs ($facts)))) (dolist (fi f (simplifya e nil)) (if (opequalp fi '$equal) (setq e ($ratsubst (nth 2 fi) (nth 1 fi) e))))))  Comment By: Barton Willis (willisbl) Date: 20070405 23:39 Message: Logged In: YES user_id=895922 Originator: NO What's the story: (%i1) assume(r<1); (%o1) [r<1] (%i2) :lisp(trace meqp csign); (MEQP CSIGN) (%i2) is(equal(x,1)),prederror : false; 1> (MEQP $X 1) 2> (CSIGN ((MPLUS RATSIMP) $X 1)) < the argument to csign looks specious ? <2 (CSIGN $PNZ) < Yikes! <1 (MEQP (($EQUAL) $X 1)) (%o2) unknown (%i8) ?csign(r1); 1> (CSIGN ((MPLUS SIMP) 1 $R)) <1 (CSIGN $NEG) (%o8) neg < OK  Comment By: Stavros Macrakis (macrakis) Date: 20070105 15:19 Message: Logged In: YES user_id=588346 Originator: YES assume(r<1)$ is(equal(r,1)) => unknown (???) is(equal(r,2)) => unknown (???) On the other hand, assume(s<t)$ is(equal(s,t)) => false (OK) is(equal(s,t+1)) => unknown (oops, but probably not the same bug) assume(equal(q,1))$ is(q<1) => false (OK) is(q<=1) => true (OK) Maxima 5.11.0 GCL 2.6.8 Windows 2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1629043&group_id=4933 
From: SourceForge.net <noreply@so...>  20071230 02:00:09

Bugs item #1860289, was opened at 20071228 21:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860289&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: 7 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Vadim V. Zhytnikov (vvzhy) Summary: XMaxima 5.14.0 Error in startup script Initial Comment: Upon clicking the shortcut icon or any launch icon of XMaxima an "Error in startup script" message box appears. It states "couldn't open "C:/PROGRA~1/MAXIMA~1.0/share/maxima/514~1.0/xmaxima/intro~1.HTM": no such directory while executing." However, there is a C:\Program Files\Maxima5.14.0\doc\html\intromax.html\. The O/S that I am using is Vista Home Premium. Yours truly, cmoorez@...  >Comment By: Robert Dodier (robert_dodier) Date: 20071229 19:00 Message: Logged In: YES user_id=501686 Originator: NO After installing Maxima from maxima5.14.0a.exe, I get the same error for XMaxima. I have verified that the file mentioned "C:/PROGRA~1/MAXIMA~1.0/share/maxima/514~1.0/xmaxima/intro~1.HTM" (which is the MSDOS name of intro.html, not intromax.html) does exist, and it can be accessed by exactly that name by the "type" command. WxMaxima and commandline Maxima work OK, except that plotting with plot_format=openmath triggers two warning messages in popup windows about something that cannot be found (but the plot seems to be displayed OK after that).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860289&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 22:19:24

Bugs item #1724592, was opened at 20070523 23:43 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1724592&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  Assume Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Stavros Macrakis (macrakis) Summary: sign(2.0*x) evaluates x too many times Initial Comment: aaa:'bbb$ bbb:'ccc$ ccc:23.5$ sign(aaa) => PNZ OK sign(bbb) => PNZ OK sign(2*aaa) => PNZ OK sign(1.0*aaa) => POS !!! sign(1.0*bbb) => POS !!! This is yet another case of EV being misused in the middle of code that has no business doing an evaluation, in this case in compar.lisp, function numer. Adding the noeval flag does not fix the problem  though sign(1.0*aaa) is now PNZ, sign(1.0*bbb) is still POS. $float is better, though a fix is needed to $float for the 2^%pi case.  >Comment By: Dan Gildea (dgildea) Date: 20071229 17:19 Message: Logged In: YES user_id=1797506 Originator: NO Seems to have been fixed in compar.lisp rev 1.27. (%i2) aaa:'bbb$ (%i3) bbb:'ccc$ (%i4) ccc:23.5$ (%i5) sign(aaa); (%o5) pnz (%i6) sign(bbb); (%o6) pnz (%i7) sign(2*aaa); (%o7) pnz (%i8) sign(1.0*aaa); (%o8) pnz (%i9) sign(1.0*bbb); (%o9) pnz  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1724592&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 19:21:09

Bugs item #1854391, was opened at 20071219 13:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1854391&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: "if" doesn't give errors for nonbooleans Initial Comment: The following cases should give errors: if 3 then x$ if %pi then x$ if "hello" then x$ if [1] then x$ if matrix(...) then x$ if {1,2,3} then x$ (other cases?) because the constants or containers cannot evaluate to booleans regardless of the lexical environment. Perhaps the same should be true of expressions whose top level is an arithmetic operator, e.g. if x+1 then ... if 1/x then ... but I suppose the arithmetic operators could be overloaded (using pattern matching) to return boolean results in some cases. I ran into this problem when I mistakenly assumed that Maxima followed the Lisp convention that nonfalse was true: if assoc(x,'[["+",""],["*","//"]]) then ... when x was "+". Instead of getting an error message, I got an unevaluated conditional if "" then ... which made no sense at all. Maxima 5.12.0 GCL Windows  >Comment By: Robert Dodier (robert_dodier) Date: 20071229 12:21 Message: Logged In: YES user_id=501686 Originator: NO >From what I can tell, the parser indeed looks to see if the first argument of "if" is a Boolean expression, but the test is weak  it only detects nonBoolean expressions for operators which are declared nonBoolean via the POS property. The parser's test appear to pass patently nonBoolean expressions such as numbers. e.g. prefix ("@@", 100, expr, expr); if @@ 1 then a else b; => Incorrect syntax: Found algebraic expression where logical expression expected Same result with other operators which have POS = $EXPR e.g.: + . ^ ^^ Maybe changing NUDCALL in src/nparse.lisp is enough. Here is the current version: (defun nudcall (op) (let ((tem (and (symbolp op) (getl op '(nud)))) res) (setq res (if (null tem) (if (operatorp op) (mreadsynerr "~A is not a prefix operator" (mopstrip op)) (cons '$any op)) (funcall (cadr tem) op))) res)) Here is a version which causes if 1234 then a else b; to trigger an error: (defun nudcall (op) (let ((tem (and (symbolp op) (getl op '(nud)))) res) (setq res (if (null tem) (if (operatorp op) (mreadsynerr "~A is not a prefix operator" (mopstrip op)) (if ($numberp op) (cons '$expr op) (cons '$any op))) ;; changed this line (funcall (cadr tem) op))) res)) Probably ($NUMBERP OP) should be something more complicated. We want to rule out numbers, strings, what else? Maybe objects such as matrices, lists, and sets?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1854391&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 18:37:49

Bugs item #1850726, was opened at 20071214 05:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1850726&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: quadpack fcns need abs err argument, was: quad_qag error Initial Comment: Hi, The command quad_qag(legendre_p(2,x),x,0,1,3) reports an abnormal return, although the integral is very simple. The result is right. Regards, M.A.  >Comment By: Robert Dodier (robert_dodier) Date: 20071229 11:37 Message: Logged In: YES user_id=501686 Originator: NO Agreed w/ Ray T on both counts: current behavior is correct, and quad_qag and friends should accept an absolute error argument. Since the original Fortran QUADPACK functions accept an absolute error argument, all that Maxima quadpack need to do is to pass the argument. Changing title of this report accordingly.  Comment By: Raymond Toy (rtoy) Date: 20071217 07:58 Message: Logged In: YES user_id=28849 Originator: NO Maxima says integrate(legendre_p(2,x),x,0,1) is 0. quad_qag says [2.0e17, 4.28e15, 31, 2]. That is, the integral is 2e17. The abnormal return code is 2, which is excessive roundoff. I think this is correct because the default relative error is 1e8 but the absolute error is 0. I think quad_qag (and friends) probably should allow another arg to let the user specify the desired absolute error. And quad_qag probably shouldn't set the absolute error to 0; perhaps something more like doublefloatepsilon (about 1e16) should be used instead.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1850726&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 17:43:04

Bugs item #1860487, was opened at 20071229 10:43 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=1860487&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: MONSTERTRIG endless recursion Initial Comment: MONSTERTRIG tries to reduce some trig expressions and start over. However I've encountered an expression for which the attempted reduction has no effect, so it loops endlessly. e.g. trace (integrate, ?monstertrig); integrate (x*(cos(2*x) + sin(x)), x); => 1 Enter integrate [x*(cos(2*x)+sin(x)),x] 1 Enter ?monstertrig [x*(cos(2*x)+sin(x)),x,x] 1 Exit ?monstertrig false 1 Enter ?monstertrig [x*(cos(2*x)+sin(x)),x,2*x] 2 Enter integrate [?new\var\15974*(cos(?new\var\15974) +sin(?new\var\15974/2)) /2,?new\var\15974] 2 Enter ?monstertrig [?new\var\15974*(cos(?new\var\15974) +sin(?new\var\15974/2)),?new\var\15974, ?new\var\15974/2] 3 Enter integrate [2*?new\var\15975 *(cos(2*?new\var\15975)+sin(?new\var\15975)), ?new\var\15975] 3 Enter ?monstertrig [?new\var\15975*(cos(2*?new\var\15975) +sin(?new\var\15975)),?new\var\15975, ?new\var\15975] 3 Exit ?monstertrig false ... etc etc. Here's the relevant code from MONSTERTRIG (src/sin.lisp). ;; We have trig(c*x+b). Use the substitution y=c*x+b to ;; try to compute the integral. Why? Because x*sin(n*x) ;; takes longer and longer as n gets larger and larger. ;; This is caused by the Risch integrator. This is a ;; workaround for this issue. (let ((c (cdras 'c arg)) (b (cdras 'b arg)) (newvar (gensym "NEWVAR"))) (let ((newint (div ($integrate (maximasubstitute (div (sub newvar b) c) var exp) newvar) c))) (returnfrom monstertrig (maximasubstitute *trigarg* newvar newint))))) risch has no trouble with the example shown above, although the comments in MONSTERTRIG suggest risch has trouble in some cases.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860487&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 17:25:25

Bugs item #1858797, was opened at 20071226 22:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1858797&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Do not use the option a for cp(1) in extract_categories.sh Initial Comment: Dear Developers of Maxima, Today, I built maxima5.14.0cvs from its CVS source over the base Lisp system gcl2.6.7withmymodification. I am using Macintosh iBook G4 running MaxOS 10.5.1(Leopard). I found a single problem in a shell script maxima/doc/info/extract_categories.sh The "make instlal" stage failed finally and I traced its origin in the log file of the command. The error came from a line in the above shell script. I changed the script as follows:  *** extract_categories.sh.org Thu Dec 6 02:36:05 2007  extract_categories.sh Thu Dec 27 14:11:40 2007 *************** *** 9,15 **** TARGET_TEXI=$TARGET.texi WORKING_DIRECTORY=`mktemp d /tmp/maximatexinfocategoriesXXXXXX` ! cp a *.texi figures $WORKING_DIRECTORY d=`pwd` cd $WORKING_DIRECTORY  9,15  TARGET_TEXI=$TARGET.texi WORKING_DIRECTORY=`mktemp d /tmp/maximatexinfocategoriesXXXXXX` ! cp pR *.texi figures $WORKING_DIRECTORY d=`pwd` cd $WORKING_DIRECTORY  This is because cp(1) on MacOSX does not have the option "a". To inspect the meaning of the option "a" for cp(1), I read man page for cp(1) on a Linux box. It is written as a, archive same as dpR The options "p" and "R" for cp(1) are commmon on MacOSX and the flavor (linux ?) of UNIX that the developers of Maxima are using. However, the option "d" does not exist on MacOSX. The option "d" for cp(1) is described on Linux as d, nodereference never follow symbolic links The option "d" for cp(1) on Linux corresponds to the option "P" for cp(1) on MacOSX. I suspect that the option "d" on Linux or "P" on MacOSX is unnecessary in the current case. I accordingly changed the shell script extract_categories.sh as the above diff file describes. If the option "d" is necessary in actual, please write by yourself an appropriate code in the shell script extract_categories.sh without using the option "a" for cp(1). If this problem is fixed, Maxima users on MacOSX become more happier. So, please fix this problem. Thank you. Sincerely yours, Satoshi Adachi P.S. I have confirmed that the two bugs which I reproted several weeks ago, 1845370 "Division by 0 in solve()" and 1845375 "factcomb() in 5.13.0 gives wrong result", are now fiexed in the CVS version of Maxima. Thank you for your fixes.  >Comment By: Robert Dodier (robert_dodier) Date: 20071229 10:25 Message: Logged In: YES user_id=501686 Originator: NO Thanks for this report. I have changed "cp a" to "cp R" in r1.6 doc/info/extract_categories.sh. Closing this report as fixed. I am a curious, however, as to why extract_categories.sh was run. The maximannn.tar.gz distribution contains all of the generated html files, does it not? So I don't think make install should try to run extract_categories.sh. Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1858797&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 16:02:13

Bugs item #1860435, was opened at 20071229 10:02 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=1860435&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Beta function not symmetric Initial Comment: Not a bug, but Maxima doesn't know that the beta function is symmetric: (%i58) beta(aa,bb)beta(bb,aa); (%o58) beta(aa,bb)beta(bb,aa)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860435&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 15:09:18

Bugs item #1860420, was opened at 20071229 09: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=1860420&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: 3 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: beta_args_sum_to_integer doc Initial Comment: The option variable beta_args_sum_to_integer is undocumented. Actually, we should consider getting rid of this option variable.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860420&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 12:34:20

Bugs item #1860250, was opened at 20071228 18:58 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860250&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: erf(inf) Initial Comment: OK (%i3) erf(inf); (%o3) 1 Not OK (%i4) erf(inf); (%o4) erf(inf) (%i5) ev(%); (%o5) 1 Also (%i1) tellsimpafter(erf(z), 42/100); (%o1) [erfrule1,simperf] Not OK (%i2) erf(z); (%o2) erf(z) (%i3) ev(%); (%o3) 21/50  >Comment By: Barton Willis (willisbl) Date: 20071229 06:34 Message: Logged In: YES user_id=895922 Originator: YES Proposed fix (untested): (defmfun simperf (x vestigial z &aux y) (declare (ignore vestigial)) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((zerop1 y) y) ((or (floatp y) (and $numer (integerp y))) (erf (float y))) ((eq y '$inf) 1) ((eq y '$minf) 1) ;;((and $trigsign (mminusp* y)) (neg (list '(%erf simp) (neg y)))) ((and $trigsign (great (neg y) y)) (neg (take '(%erf) (neg y)))) (t (eqtest (list '(%erf) y) x)))) The user documentation doesn't say that trigsign == false prevents erf from doing a reflection simplification.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860250&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 04:17:46

Bugs item #1860289, was opened at 20071228 20: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=1860289&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XMaxima 5.14.0 Error in startup script Initial Comment: Upon clicking the shortcut icon or any launch icon of XMaxima an "Error in startup script" message box appears. It states "couldn't open "C:/PROGRA~1/MAXIMA~1.0/share/maxima/514~1.0/xmaxima/intro~1.HTM": no such directory while executing." However, there is a C:\Program Files\Maxima5.14.0\doc\html\intromax.html\. The O/S that I am using is Vista Home Premium. Yours truly, cmoorez@...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860289&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 01:08:06

Bugs item #1860211, was opened at 20071228 16:40 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860211&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nullspace Initial Comment: the code rendered below produces an error that looks like this: `quotient' by `zero'#0: column_reduce(m=matrix([b*g1+d1+a1*(1d1),D1a1*D1,0,0,0,0,b*(1D1),0,(1d1)*D1,0,g1*(1D1)],[0,(a2*(1d1)b*g2)*(...,i=9,x=?g35312)(linearalgebra.mac line 228)#1: ptriangularize_with_proviso(m=matrix([b*g1+d1+a1*(1d1),D1a1*D1,0,0,0,0,b*(1D1),0,(1d1)*D1,0,g1*(1D1)],[a2*(1d1)b*g2,a2*D1...,v=?g35312)(linearalgebra.mac line 196)#2: nullspace(m=matrix([b*g1+d1+a1*(1d1),D1a1*D1,0,0,0,0,b*(1D1),0,(1d1)*D1,0,g1*(1D1)],[a2*(1d1)b*g2,a2*D1...)(linearalgebra.mac line 70)  an error. To debug this try debugmode(true); here is the code: assume(D1>0 and D1<1); assume(d1>0 and d1<1); assume(D2>0 and D2<1); assume(d2>0 and d2<1); assume(D3>0 and D3<1); assume(d3>0 and d3<1); assume(a1>0 and a1<1); assume(a2>0 and a2<1); assume(b>0 and b<1); assume(g1>0 and g1<1); assume(g2>0 and g2<1); assume((1g1g2)>0 and (1g1g2)<1); assume((1a1a2)>0 and (1a1a2)<1); /* [parameters] */ /* [matrices group 1] */ m11:matrix([D1],[(1D1)]); m12:matrix([d1,0],[(1d1),0],[0,b],[0,(1b)]); m13:matrix([1,0,0,0],[0,a1,0,0],[0,a2,0,0],[0,(1a1a2),0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f1:matrix([1,1,0,0,1,0,0,0],[0,0,1,0,0,1,0,0],[0,0,0,1,0,0,1,0],[0,0,0,0,0,0,0,1]); mA:f1.m13.m12.m11; /* [input 1 end ] */ /* [matrices group 2] */ m21:matrix([D2],[(1D2)]); m22:matrix([d2,0],[(1d2),0],[0,b],[0,(1b)]); m23:matrix([1,0,0,0],[0,a1,0,0],[0,a2,0,0],[0,(1a1a2),0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f2:matrix([0,1,0,0,1,0,0,0],[1,0,1,0,0,1,0,0],[0,0,0,1,0,0,1,0],[0,0,0,0,0,0,0,1]); mB:f2.m23.m22.m21; /* [input 2 end ] */ /* [matrices group 3] */ m31:matrix([D3],[(1D3)]); m32:matrix([d3,0],[(1d3),0],[0,b],[0,(1b)]); m33:matrix([1,0,0,0],[0,a1,0,0],[0,a2,0,0],[0,(1a1a2),0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f3:matrix([0,1,0,0,1,0,0,0],[0,0,1,0,0,1,0,0],[0,0,0,1,0,0,1,0],[0,0,0,0,0,0,0,1]); mC:f3.m33.m32.m31; /* [input 3 end ] */ /* [matrices group 4] */ m41:matrix([0],[1]); m42:matrix([0,0],[0,0],[0,b],[0,(1b)]); m43:matrix([0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f4:matrix([0,0,0,0,1,0,0,0],[0,0,0,0,0,1,0,0],[0,0,0,0,0,0,1,0],[0,0,0,0,0,0,0,1]); mD:f4.m43.m42.m41; /* mAll:([mA],[mB],[mC],[mD]) */ y1:makelist(mA[i,1],i,1,4); y2:makelist(mB[i,1],i,1,4); y3:makelist(mC[i,1],i,1,4); y4:makelist(mD[i,1],i,1,4); /* mAll:append(makelist(mA[j,1],j,1,4),makelist(mB[j,1],j,1,4),makelist(mC[j,1],j,1,4),makelist(mD[j,1],j,1,4)); */ mAll:append(y1,y2,y3,y4); pars:[D1,d1,D2,d2,D3,d3,g1,g2,a1,a2,b]; /* mAll:expand(mAll); */ /* jacobian */ jac1:jacobian(mAll,pars); /* jac:expand(jac1); */ /* rank */ rjac:rank(jac1); print(rjac); /* nullspace ends in error!*/ njac:nullspace(jac1); print(njac);  >Comment By: Barton Willis (willisbl) Date: 20071228 19:08 Message: Logged In: YES user_id=895922 Originator: NO Try setting ratmx : true before you do any calculation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860211&group_id=4933 
From: SourceForge.net <noreply@so...>  20071229 00:58:03

Bugs item #1860250, was opened at 20071228 18:58 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=1860250&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: erf(inf) Initial Comment: OK (%i3) erf(inf); (%o3) 1 Not OK (%i4) erf(inf); (%o4) erf(inf) (%i5) ev(%); (%o5) 1 Also (%i1) tellsimpafter(erf(z), 42/100); (%o1) [erfrule1,simperf] Not OK (%i2) erf(z); (%o2) erf(z) (%i3) ev(%); (%o3) 21/50  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860250&group_id=4933 
From: SourceForge.net <noreply@so...>  20071228 22:40:23

Bugs item #1860211, was opened at 20071228 14:40 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=1860211&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nullspace Initial Comment: the code rendered below produces an error that looks like this: `quotient' by `zero'#0: column_reduce(m=matrix([b*g1+d1+a1*(1d1),D1a1*D1,0,0,0,0,b*(1D1),0,(1d1)*D1,0,g1*(1D1)],[0,(a2*(1d1)b*g2)*(...,i=9,x=?g35312)(linearalgebra.mac line 228)#1: ptriangularize_with_proviso(m=matrix([b*g1+d1+a1*(1d1),D1a1*D1,0,0,0,0,b*(1D1),0,(1d1)*D1,0,g1*(1D1)],[a2*(1d1)b*g2,a2*D1...,v=?g35312)(linearalgebra.mac line 196)#2: nullspace(m=matrix([b*g1+d1+a1*(1d1),D1a1*D1,0,0,0,0,b*(1D1),0,(1d1)*D1,0,g1*(1D1)],[a2*(1d1)b*g2,a2*D1...)(linearalgebra.mac line 70)  an error. To debug this try debugmode(true); here is the code: assume(D1>0 and D1<1); assume(d1>0 and d1<1); assume(D2>0 and D2<1); assume(d2>0 and d2<1); assume(D3>0 and D3<1); assume(d3>0 and d3<1); assume(a1>0 and a1<1); assume(a2>0 and a2<1); assume(b>0 and b<1); assume(g1>0 and g1<1); assume(g2>0 and g2<1); assume((1g1g2)>0 and (1g1g2)<1); assume((1a1a2)>0 and (1a1a2)<1); /* [parameters] */ /* [matrices group 1] */ m11:matrix([D1],[(1D1)]); m12:matrix([d1,0],[(1d1),0],[0,b],[0,(1b)]); m13:matrix([1,0,0,0],[0,a1,0,0],[0,a2,0,0],[0,(1a1a2),0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f1:matrix([1,1,0,0,1,0,0,0],[0,0,1,0,0,1,0,0],[0,0,0,1,0,0,1,0],[0,0,0,0,0,0,0,1]); mA:f1.m13.m12.m11; /* [input 1 end ] */ /* [matrices group 2] */ m21:matrix([D2],[(1D2)]); m22:matrix([d2,0],[(1d2),0],[0,b],[0,(1b)]); m23:matrix([1,0,0,0],[0,a1,0,0],[0,a2,0,0],[0,(1a1a2),0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f2:matrix([0,1,0,0,1,0,0,0],[1,0,1,0,0,1,0,0],[0,0,0,1,0,0,1,0],[0,0,0,0,0,0,0,1]); mB:f2.m23.m22.m21; /* [input 2 end ] */ /* [matrices group 3] */ m31:matrix([D3],[(1D3)]); m32:matrix([d3,0],[(1d3),0],[0,b],[0,(1b)]); m33:matrix([1,0,0,0],[0,a1,0,0],[0,a2,0,0],[0,(1a1a2),0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f3:matrix([0,1,0,0,1,0,0,0],[0,0,1,0,0,1,0,0],[0,0,0,1,0,0,1,0],[0,0,0,0,0,0,0,1]); mC:f3.m33.m32.m31; /* [input 3 end ] */ /* [matrices group 4] */ m41:matrix([0],[1]); m42:matrix([0,0],[0,0],[0,b],[0,(1b)]); m43:matrix([0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,g1,0],[0,0,g2,0],[0,0,(1g1g2),0],[0,0,0,1]); f4:matrix([0,0,0,0,1,0,0,0],[0,0,0,0,0,1,0,0],[0,0,0,0,0,0,1,0],[0,0,0,0,0,0,0,1]); mD:f4.m43.m42.m41; /* mAll:([mA],[mB],[mC],[mD]) */ y1:makelist(mA[i,1],i,1,4); y2:makelist(mB[i,1],i,1,4); y3:makelist(mC[i,1],i,1,4); y4:makelist(mD[i,1],i,1,4); /* mAll:append(makelist(mA[j,1],j,1,4),makelist(mB[j,1],j,1,4),makelist(mC[j,1],j,1,4),makelist(mD[j,1],j,1,4)); */ mAll:append(y1,y2,y3,y4); pars:[D1,d1,D2,d2,D3,d3,g1,g2,a1,a2,b]; /* mAll:expand(mAll); */ /* jacobian */ jac1:jacobian(mAll,pars); /* jac:expand(jac1); */ /* rank */ rjac:rank(jac1); print(rjac); /* nullspace ends in error!*/ njac:nullspace(jac1); print(njac);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1860211&group_id=4933 
From: SourceForge.net <noreply@so...>  20071228 17:15:53

Bugs item #580721, was opened at 20020712 19:38 Message generated for change (Comment added) made by rswarbrick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand bug Initial Comment: Consider this: (C1) display2d:false; (D1) FALSE (C2) tan(%pi/2+x); (D2) COT(x) (C3) tan(%pi/2+%pi*x); (D3) TAN(%PI*x+%PI/2) (C4) %,trigexpand; Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE);) d3 should have been expanded into cot(%pi*x) instead of getting a division by zero error.  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071228 17:15 Message: Logged In: YES user_id=1673565 Originator: NO I think I've posted a patch onto the mailing list that fixes this. I can't work out how to attach files here, so the link is: http://thread.gmane.org/gmane.comp.mathematics.maxima.general/19076  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071227 02:38 Message: Logged In: YES user_id=1673565 Originator: NO So the first thing that's wrong is that %piargstan/cot shouldn't return nonnil for stuff like tan(pi/2) as they aren't defined, let alone simplifiable. Here's an amended and reformatted version with variables renamed and a possible bug due to reuse of variable names eliminated too (I think) (defun %piargstan/cot (x) (displa x) (let ((coeff (linearize (coefficient x '$%pi 1))) (zlrem (coefficient x '$%pi 0)) (sinofcoeffpi) (cosofcoeffpi)) (cond ((and (zerop1 zlrem) (setq sinofcoeffpi (%piargs coeff nil)) (not (zerop1 (setq cosofcoeffpi (%piargs (cons (car coeff) (rplus 1//2 (cdr coeff))) nil))))) ;; sinofcoeffpi and cosofcoeffpi are only nonnil if they ;; are constants that %piargsoffset could compute, and we just ;; checked that cosofcoeffpi was nonzero. Thus we can just ;; return their quotient. (div sinofcoeffpi cosofcoeffpi)) ((not (mevenp (car coeff))) nil) ((integerp (setq x (mmod (cdr coeff) 2))) (consexp '%tan zlrem)) ((or (alike1 1//2 x) (alike1 '((rat) 3 2) x)) (neg (consexp '%cot zlrem))))))  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071227 02:29 Message: Logged In: YES user_id=1673565 Originator: NO Ah. Of course tan(pi/2) = infinity ...  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071226 01:10 Message: Logged In: YES user_id=1673565 Originator: NO Hi, a bit more information: the error's caused by a (div 1 0) which gets returned in %piargstan/cot, called by simp%tan. You can reproduce more simply by just calling tan(%pi/2), trigexpand; I'm trying to work out what the functions are _supposed_ to do. Maybe then I'll be able to fix it!  Comment By: Robert Dodier (robert_dodier) Date: 20060327 00:40 Message: Logged In: YES user_id=501686 For the record, same problem observed in maxima 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&group_id=4933 
From: SourceForge.net <noreply@so...>  20071228 01:35:47

Bugs item #1646525, was opened at 20070128 11:24 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646525&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  Translator Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: no function mdoin Initial Comment: Translation of a 'for i in x while' loop uses use a function mdoin. Apparently, there is no such function: (%i9) try(x) := block([acc : 0], for i in x while i > 5 do acc : acc + i, acc)$ (%i10) try([10,1,5,8]); (%o10) 10 (%i11) translate(try)$ (%i12) try([10,1,5,8]); Maxima encountered a Lisp error: Error in LISP:LAMBDACLOSURE [or a callee]: The function MDOIN is undefined.  >Comment By: Robert Dodier (robert_dodier) Date: 20071227 18:35 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.37 src/transl.lisp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1646525&group_id=4933 
From: SourceForge.net <noreply@so...>  20071228 01:35:05

Bugs item #1728888, was opened at 20070531 05:39 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1728888&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  Translator Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: translator bugs: no mnot mprogn Initial Comment: The missing 'modin' function was reported bug #1646525. The problems with 'mnot' and 'mprogn' being illegal might be unreported bugs: (%i1) f(e,v) := block([vi], for vi in v while not(emptyp(e)) do (print(vi), e : rest(e)))$ (%i2) translate(f)$ (%i3) f([1,2,3],[a,b]); ...The function MDOIN is undefined. (%i4) compile(f)$ ;;; The function (MNOT) is illegal. ;;; The function (MPROGN) is illegal.  >Comment By: Robert Dodier (robert_dodier) Date: 20071227 18:35 Message: Logged In: YES user_id=501686 Originator: NO Resolved by r1.37 src/transl.lisp. The problem was the incorrect translation of "for x in L while ... do", not a problem with mnot or mprogn.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1728888&group_id=4933 
From: SourceForge.net <noreply@so...>  20071227 15:17:45

Bugs item #1858964, was opened at 20071227 09: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=1858964&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([7],[1], x) /> error Initial Comment: Although hgfred([7],[1], x) is undefined, Maxima returns a noun form for this case. (%i1) hgfred([7],[1],x); (%o1) %f[1,1]([7],[1],x) All the logic for detecting this is in place, but it is ignored. In hgfsimpexec there is (not (atom (res))). Should the 'not' be removed and the one reference to 'undef be changed to '$und? (defun hgfsimpexec (argl1 argl2 arg) (let* ((l1 (copytree argl1)) (l2 (copytree argl2)) ($exponentialize nil) (res (hgfsimp l1 l2 arg))) (if (or (numberp res) (atom res)) ;; <change res (fpqform l1 l2 arg)))) This change makes (%i3) hgfred([7],[1],x); (%o3) und Maybe hgfsimp returns other atoms that aren't correct (that need to be caught by (not (atom res)). I don't know.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1858964&group_id=4933 
From: SourceForge.net <noreply@so...>  20071227 14:53:57

Bugs item #1858956, was opened at 20071227 08:53 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=1858956&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: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: no user doc for hgfred Initial Comment: There is no user doc for hgfred: (%i42) describe(hgfred); No exact match found for topic `hgfred'. (%o42) false (%i43) ?? hgfred; (%o43) false  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1858956&group_id=4933 
From: SourceForge.net <noreply@so...>  20071227 14:07:34

Bugs item #1858939, was opened at 20071227 08:07 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=1858939&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: hgfred([1],[2],x) > error Initial Comment: 1F1(1,2,x) = 1 + x/2, but Maxima gives an error for hgfred([1],[2],x) (%i36) hgfred([1],[2],x); gamma(2) is undefined  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1858939&group_id=4933 
From: SourceForge.net <noreply@so...>  20071227 05:54:51

Bugs item #1858797, was opened at 20071227 14:54 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=1858797&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: Do not use the option a for cp(1) in extract_categories.sh Initial Comment: Dear Developers of Maxima, Today, I built maxima5.14.0cvs from its CVS source over the base Lisp system gcl2.6.7withmymodification. I am using Macintosh iBook G4 running MaxOS 10.5.1(Leopard). I found a single problem in a shell script maxima/doc/info/extract_categories.sh The "make instlal" stage failed finally and I traced its origin in the log file of the command. The error came from a line in the above shell script. I changed the script as follows:  *** extract_categories.sh.org Thu Dec 6 02:36:05 2007  extract_categories.sh Thu Dec 27 14:11:40 2007 *************** *** 9,15 **** TARGET_TEXI=$TARGET.texi WORKING_DIRECTORY=`mktemp d /tmp/maximatexinfocategoriesXXXXXX` ! cp a *.texi figures $WORKING_DIRECTORY d=`pwd` cd $WORKING_DIRECTORY  9,15  TARGET_TEXI=$TARGET.texi WORKING_DIRECTORY=`mktemp d /tmp/maximatexinfocategoriesXXXXXX` ! cp pR *.texi figures $WORKING_DIRECTORY d=`pwd` cd $WORKING_DIRECTORY  This is because cp(1) on MacOSX does not have the option "a". To inspect the meaning of the option "a" for cp(1), I read man page for cp(1) on a Linux box. It is written as a, archive same as dpR The options "p" and "R" for cp(1) are commmon on MacOSX and the flavor (linux ?) of UNIX that the developers of Maxima are using. However, the option "d" does not exist on MacOSX. The option "d" for cp(1) is described on Linux as d, nodereference never follow symbolic links The option "d" for cp(1) on Linux corresponds to the option "P" for cp(1) on MacOSX. I suspect that the option "d" on Linux or "P" on MacOSX is unnecessary in the current case. I accordingly changed the shell script extract_categories.sh as the above diff file describes. If the option "d" is necessary in actual, please write by yourself an appropriate code in the shell script extract_categories.sh without using the option "a" for cp(1). If this problem is fixed, Maxima users on MacOSX become more happier. So, please fix this problem. Thank you. Sincerely yours, Satoshi Adachi P.S. I have confirmed that the two bugs which I reproted several weeks ago, 1845370 "Division by 0 in solve()" and 1845375 "factcomb() in 5.13.0 gives wrong result", are now fiexed in the CVS version of Maxima. Thank you for your fixes.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1858797&group_id=4933 
From: SourceForge.net <noreply@so...>  20071227 02:38:45

Bugs item #580721, was opened at 20020712 19:38 Message generated for change (Comment added) made by rswarbrick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand bug Initial Comment: Consider this: (C1) display2d:false; (D1) FALSE (C2) tan(%pi/2+x); (D2) COT(x) (C3) tan(%pi/2+%pi*x); (D3) TAN(%PI*x+%PI/2) (C4) %,trigexpand; Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE);) d3 should have been expanded into cot(%pi*x) instead of getting a division by zero error.  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071227 02:38 Message: Logged In: YES user_id=1673565 Originator: NO So the first thing that's wrong is that %piargstan/cot shouldn't return nonnil for stuff like tan(pi/2) as they aren't defined, let alone simplifiable. Here's an amended and reformatted version with variables renamed and a possible bug due to reuse of variable names eliminated too (I think) (defun %piargstan/cot (x) (displa x) (let ((coeff (linearize (coefficient x '$%pi 1))) (zlrem (coefficient x '$%pi 0)) (sinofcoeffpi) (cosofcoeffpi)) (cond ((and (zerop1 zlrem) (setq sinofcoeffpi (%piargs coeff nil)) (not (zerop1 (setq cosofcoeffpi (%piargs (cons (car coeff) (rplus 1//2 (cdr coeff))) nil))))) ;; sinofcoeffpi and cosofcoeffpi are only nonnil if they ;; are constants that %piargsoffset could compute, and we just ;; checked that cosofcoeffpi was nonzero. Thus we can just ;; return their quotient. (div sinofcoeffpi cosofcoeffpi)) ((not (mevenp (car coeff))) nil) ((integerp (setq x (mmod (cdr coeff) 2))) (consexp '%tan zlrem)) ((or (alike1 1//2 x) (alike1 '((rat) 3 2) x)) (neg (consexp '%cot zlrem))))))  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071227 02:29 Message: Logged In: YES user_id=1673565 Originator: NO Ah. Of course tan(pi/2) = infinity ...  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071226 01:10 Message: Logged In: YES user_id=1673565 Originator: NO Hi, a bit more information: the error's caused by a (div 1 0) which gets returned in %piargstan/cot, called by simp%tan. You can reproduce more simply by just calling tan(%pi/2), trigexpand; I'm trying to work out what the functions are _supposed_ to do. Maybe then I'll be able to fix it!  Comment By: Robert Dodier (robert_dodier) Date: 20060327 00:40 Message: Logged In: YES user_id=501686 For the record, same problem observed in maxima 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&group_id=4933 
From: SourceForge.net <noreply@so...>  20071227 02:29:33

Bugs item #580721, was opened at 20020712 19:38 Message generated for change (Comment added) made by rswarbrick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand bug Initial Comment: Consider this: (C1) display2d:false; (D1) FALSE (C2) tan(%pi/2+x); (D2) COT(x) (C3) tan(%pi/2+%pi*x); (D3) TAN(%PI*x+%PI/2) (C4) %,trigexpand; Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE);) d3 should have been expanded into cot(%pi*x) instead of getting a division by zero error.  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071227 02:29 Message: Logged In: YES user_id=1673565 Originator: NO Ah. Of course tan(pi/2) = infinity ...  Comment By: Rupert Swarbrick (rswarbrick) Date: 20071226 01:10 Message: Logged In: YES user_id=1673565 Originator: NO Hi, a bit more information: the error's caused by a (div 1 0) which gets returned in %piargstan/cot, called by simp%tan. You can reproduce more simply by just calling tan(%pi/2), trigexpand; I'm trying to work out what the functions are _supposed_ to do. Maybe then I'll be able to fix it!  Comment By: Robert Dodier (robert_dodier) Date: 20060327 00:40 Message: Logged In: YES user_id=501686 For the record, same problem observed in maxima 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&group_id=4933 
From: SourceForge.net <noreply@so...>  20071226 21:24:37

Bugs item #1515712, was opened at 20060701 22:05 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515712&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: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: tlimit (x*atan(x)/(x+1),x,inf) => 3 %pi/2, etc Initial Comment: Maxima 5.9.3 & 5.9.3cvs: tlimit(x*atan(x)/(x+1),x,inf) => 3 %pi/2 Should be %pi/2. also tlimit(x*(atan(x)%pi/2),x,inf) => inf Should be 1.  >Comment By: Dan Gildea (dgildea) Date: 20071226 16:24 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in hayat.lisp rev 1.31. (%i9) tlimit(x*atan(x)/(x+1),x,inf); (%o9) %pi/2 (%i10) tlimit(x*(atan(x)%pi/2),x,inf); (%o10) 1 (%i11) tlimit(atan(x^1), x, 0, minus); (%o11) %pi/2 (%i12) tlimit(atan(x^1)/x, x, 0, minus); (%o12) inf (%i13) tlimit((atan(x^1)+%pi/2)/x, x, 0, minus); (%o13) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515712&group_id=4933 
From: SourceForge.net <noreply@so...>  20071226 21:20:06

Bugs item #807275, was opened at 20030916 13:19 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=807275&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Taylor Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Taylor Illegal log kernel: log(cos(th)) @ %pi/2 Initial Comment: taylor(log(cos(th)),th,%pi/2,2) gives the internal error Illegal log kernel but taylor(log(sin(th)),th,0,2), which is equivalent, gives a perfectly reasonable result.  >Comment By: Dan Gildea (dgildea) Date: 20071226 16:20 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in hayat.lisp rev 1.31... (%i7) taylor(log(cos(th)),th,%pi/2,2); (%o7) log((2*th%pi)/2)+log(1)(th%pi/2)^2/6 ... though still not all cases are handled .... (%i8) taylor(log(log(cos(th))),th,%pi/2,2); Maxima encountered a Lisp error: Unhandled kernel in tvarlim  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=807275&group_id=4933 