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}
(8) 
_{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...>  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 