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}
(26) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






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

11

12
(1) 
13
(1) 
14
(5) 
15
(5) 
16

17

18

19
(3) 
20
(1) 
21
(1) 
22
(3) 
23

24
(2) 
25

26

27

28

29
(2) 
30
(1) 
31







From: SourceForge.net <noreply@so...>  20030830 21:31:01

Bugs item #711539, was opened at 20030328 14:58 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711539&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistencies in noun/verb Initial Comment:  nounify(diff) displays as derivative when display2d is true, and diff when display2d is false.  In some cases, the noun form is spelled differently from the verb form. This can be handy, though it is confusing. For example, "IF" has a convenient noun form, COND, so you can write COND(a,b,c) without getting an error ("unable to evaluate predicate"). However, though the noun form of DIFF displays as DERIVATIVE, when Maxima reads in DERIVATIVE, it in fact uses the verb form DIFF. Example: if(1<2,a,b) => a Verb form nounify("IF") => COND (%cond) (nounify("IF"))(a,b) Noun form cond(1<2,a,b) => cond(1<2,a,b) Noun form part(_,0) => cond Noun form diff(x^2,x) => 2*x Verb form nounify('diff) => DERIVATIVE (%derivative) (nounify('diff))(x^2,x) Noun form derivative(x^2,x) => 2*x Verb form part(_,0) => diff Verb form  apply_nouns is documented, but nowhere defined  Noun/verb behavior of operators like "+" and "IF" is messed up:  ev( (' "+")(x,x), nouns) returns +(x,x) instead of 2*x. This is because (' "+")(x,y) gives ((&+) x y). It should give the same thing as (nounify("+"))(x,y), namely ((% mplus simp) x y).  Similarly for "IF".  I haven't tested thoroughly, but there seem to be similar confusions for "DO"/MDO, ":"/SETQ, etc.  >Comment By: Stavros Macrakis (macrakis) Date: 20030830 17:31 Message: Logged In: YES user_id=588346 The semantics of noun/verb are pretty unclear. In the case of trig functions, verbs return floatingpoint results: (verbify('sin))(0) => 0.0; but not for elementary arithmetic: (verbify('"+"))(0,4) => 4. In the case of trig functions, nouns simplify: (nounify('sin))(% pi) => 0; but not for elementary arithmetic: (nounify('"+")) (4,5) => PLUS(4,5).  Comment By: Stavros Macrakis (macrakis) Date: 20030328 17:34 Message: Logged In: YES user_id=588346 I spoke too soon about the "convenience" of COND. verbify(COND) and verbify(nounify(COND)) give %COND rather than MCOND as they should, so COND(a,b,c) doesn't get an error because it has nothing to do with IF/MCOND.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711539&group_id=4933 
From: SourceForge.net <noreply@so...>  20030829 16:43:32

Bugs item #797401, was opened at 20030829 12: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=797401&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: infix should return string, not internal op Initial Comment: infix("X") returns the atom $X (which prints as "X"). The problem with that is that after X is defined as infix, that atom is useless and in fact can't be input into Maxima; "X" means the *string* X, not the *operator* X. Maxima goes to great lengths to make sure that operators can be referred to by their string name. For example, part(1 x 2,0) returns the string &X ("X") even though internally it is $X. Infix("X") should thus be returning the *string* &X ("X").  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=797401&group_id=4933 
From: SourceForge.net <noreply@so...>  20030829 16:39:53

Bugs item #792862, was opened at 20030821 20:17 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792862&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor(r^23*r+3,a^3+1) fatal error Initial Comment: factor(r^23*r+3,a^3+1) Error: Caught fatal error [memory may be damaged] Error signalled by PFACTORALG1. (should be irreducible) This happens regardless of the setting of GCD. Note that various closeby cases work just fine: ..., a^2+3 (factors) ..., a^2+2 (irreducible) ..., a^2+1 (irreducible) ..., a^3+3 (irreducible) ..., a^4+1 (irreducible) ..., a^4+3 (factors) ..., a^6+3 (factors) Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Stavros Macrakis (macrakis) Date: 20030829 12:39 Message: Logged In: YES user_id=588346 Simpler case: factor(q^2+1,a^21); In general, this seems to happen when the second argument isn't irreducible over the integers (which it is supposed to be). This should not cause a fatal error, but an error message.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792862&group_id=4933 
From: SourceForge.net <noreply@so...>  20030824 20:00:15

Bugs item #794296, was opened at 20030824 16:00 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=794296&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(xx^k,k,inf) x=0 wrong Initial Comment: limit(xx^k,k,inf); Is ABS(x)  1 positive, negative, or zero? zero; Is x positive, negative, or zero? pos; => MINF Wrong. If x>0 and abs(x)1=0 then x=1. Since 1 1^k=0, limit(xx^k,k,inf) where x=1 is also 0. With x<0 and abs(x)1=0, limit gives infinity, which is also wrong. Should be UND.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=794296&group_id=4933 
From: SourceForge.net <noreply@so...>  20030824 19:54:21

Bugs item #794294, was opened at 20030824 15: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=794294&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: nusum doesn't understand INF Initial Comment: nusum(x,i,1,inf) gives inf*x That is correct in some sense  but inf should not appear in the answer. Either nusum should given an answer not involving inf, or it should give an error. Although in this case, limit(inf*x) gives the correct answer, I am not sure that is always true.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=794294&group_id=4933 
From: SourceForge.net <noreply@so...>  20030822 05:48:56

Bugs item #792514, was opened at 20030821 10:06 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=792514&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Subscripted literal array doesn't display Initial Comment: matrix([a,b],[c,d])[2,1] is a perfectly legitimate Maxima expression which evaluates to 'c'. And it displays fine with display2d:false: display2d:false$ '( matrix([a,b],[c,d])[2,1] ); => matrix([a,b],[c,d])[2,1] But 2d display causes an error: display2d:true$ '( matrix([a,b],[c,d])[2,1] ) => Error: (DMATRIX RIGHT 2 ...) is not of type CHARACTER. Error signalled by DIMENSIONARRAY. Maxima 5.9.0 gcl 2.5.0 mingw32 Windows2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792514&group_id=4933 
From: SourceForge.net <noreply@so...>  20030822 04:16:07

Bugs item #781657, was opened at 20030801 20:30 Message generated for change (Comment added) made by wjenkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: binomial(x,x) => 1, but binomial(1,1) => 0 Initial Comment: binomial(x,x) simplifies to 1 yet binomial(1,1) simplifies to 0. (C1) binomial(x,x); (D1) 1 (C2) binomial(1,1); (D2) 0 I agree with (d2) because: 1/(1  x) = 1 + x + x^2 + ... = sum(binomial(1,k) (x) ^k,k,0,inf) implies binomial(1,k) = (1)^k, for integers k >= 0. In the recursion relation [Knuth Vol 1, 1.2.6 Eq. (20)] binomial(r,k) = binomial(r1,k) + binomial(r1,k1) set r > 0, k > 0, and use binomial(0,0) = 1 and binomial (1,0) = 1. From this we get binomial(1,1) = 0. Also see, Knuth Vol. 1 (third edition), Section 1.2.6 Exercise 9. There may be other approaches, but I think using the recursion relations and other identities to extend the domain of the binomial function is the best method. In short, I think the simplification binomial(x,x) ==> 1 should happen only for real x with x >= 0. Barton  >Comment By: Wolfgang Jenkner (wjenkner) Date: 20030822 06:16 Message: Logged In: YES user_id=581700 Unless I am mistaken, the (finite) limit of BINOMIAL(x,y) at some latticepoint (a,b) in Z^2 exists if and only if a >= 0. The "if" part is easy: Just write the binomial as GAMMA(x+1)/(GAMMA(y+x+1)*GAMMA(y+1)) and observe that Gamma is certainly continuous in the open right halfplane while 1/Gamma is continuous everywhere. Now assume a <= 1. We have the following identity (for the proof see the Maxima code below) %PI*BINOMIAL(x1,y)*BINOMIAL(x,y)*y = SIN(%PI*y)*SIN(%PI*(xy))/SIN(%PI*x) We have a1 >= 0, so we already know that lim BINOMIAL(x1,y) for (x,y)>(a,b) exists. If lim BINOMIAL(x,y) also existed, lim of the whole left hand side expression of this identity would exist. Now, looking at the right hand side expression we observe that it is Zperiodic with respect to x and y (except for a possible sign change). So lim of it at (a,b) exists if and only if lim of it at (0,0) exists, which is clearly not the case. Note: Strictly speaking, the identity is valid on, say, the complement of the union of the parallels through latticepoints to the first and second axis and to the median of the first quadrant, but this leaves us with enough space :) Nevertheless, of course, it's quite customary to define BINOMIAL(a,b)=a*(a1)* ... *(ab+1)/b! for all a in R and b in Z with b >= 0 (for b=0 the numerator is an empty product), in accordance with the binomial series. This definition happens to coincide with limit(limit(BINOMIAL(x,y),y,b),x,a). matchdeclare([%%u,%%v],true)$ sum_is_1(u,v):=is(u+v = 1)$ let(gamma(%%u)*gamma(%%v),%pi/sin(%pi*%%u),sum_is_1,%%u,%%v); let(%%v/gamma(%%u),1/gamma(%%v),sum_is_1,%%u,%%v); letrat:true; lhs:%pi*y*binomial(x,y)*binomial(x1,y); makegamma(%); letsimp(%); letsimp(%); num(%)/trigexpand(expand(denom(%))); lhs=%;  Comment By: Stavros Macrakis (macrakis) Date: 20030814 18:16 Message: Logged In: YES user_id=588346 I am not sure what you mean by "there may be other approaches". binomial(a,a) should simplify to Q if and only if the double limit exists: limit binomial(x,y) = Q x>a y>a A necessary (but in general not sufficient) condition for this to exist is that the two single limits exist and are equal: limit binomial(a,y) = limit binomial(x,a) = Q y>a x>a If the limit is not welldefined, then binomial(x,x) is not well defined, and it will cause incorrect results in some case or another to arbitrarily set it to some value. I don't know if this limit is or isn't welldefined. I do know that depending on identities with unspecified domains of validity is dangerous....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 
From: SourceForge.net <noreply@so...>  20030822 00:17:04

Bugs item #792862, was opened at 20030821 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=792862&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor(r^23*r+3,a^3+1) fatal error Initial Comment: factor(r^23*r+3,a^3+1) Error: Caught fatal error [memory may be damaged] Error signalled by PFACTORALG1. (should be irreducible) This happens regardless of the setting of GCD. Note that various closeby cases work just fine: ..., a^2+3 (factors) ..., a^2+2 (irreducible) ..., a^2+1 (irreducible) ..., a^3+3 (irreducible) ..., a^4+1 (irreducible) ..., a^4+3 (factors) ..., a^6+3 (factors) Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792862&group_id=4933 
From: SourceForge.net <noreply@so...>  20030821 17:53:48

Bugs item #792114, was opened at 20030820 15:12 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=792114&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: "/" should be the quotient operator /FIX Initial Comment: The name of the quotient operator is currently "//" rather than "/". There is no good reason for this. Currently: part(a/b,0) => "//" (internally &//) "//"(a,b) => a/b Strangely, it also works to say: "/"(a,b) => a/b apply("//",[a,b]) => a/b but apply("/",[a,b]) gives /(a,b), which has nothing to do with division. This is inconsistent, confusing, and unnecessary. I suspect it is accidental, because in some Lisps you needed to write // instead of / (/ was an escape character). Fix: in comm.lisp, change (MNCTIMES &.) (RAT &//) (MQUOTIENT &//) (MNCEXPT &^^) to (MNCTIMES &.) (RAT &/) (MQUOTIENT &/) (MNCEXPT &^^) I suppose you could go through the whole source and change // to /, but since all the other uses are internal, it doesn't matter.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792114&group_id=4933 
From: SourceForge.net <noreply@so...>  20030820 00:57:15

Bugs item #791607, was opened at 20030819 16:46 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=791607&group_id=4933 Category: Xmaxima Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: "Could not open a socket" error Initial Comment: I installed Maxima 5.9 a couple of days ago, and it worked fine, until I installed Borland Turbo C++ 4.5, and now every time Maxima starts, I get a "Could not open a socket" error. I can't do any operation inside the program, because of that. I have already unistalled and reinstalled the program several times, and nothing has changed. Can I do anything to avoid that error?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=791607&group_id=4933 
From: SourceForge.net <noreply@so...>  20030819 20:32:03

Bugs item #771061, was opened at 20030714 12:52 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771061&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: expand dot expr > fatal error/FIX Initial Comment: expand((vt . a^^(1) . u+1)^^(2)) causes a stack overflow (sometimes crashing Maxima entirely) ... infinite recursion in simpncexpt  >Comment By: Stavros Macrakis (macrakis) Date: 20030819 14:22 Message: Logged In: YES user_id=588346 Here is a fix. Note that this does NOT solve the general problem of expanding .expressions. For example, it does not expand a . (a + 1)^^1 to a^^1 + 1. But I wanted to get the fatal error fixed first. Also, it is not clear that Expand gives you enough fine control to do that sort of thing reasonably.  Fix in simpncexpt ;; This does the same thing as above for (A+B)^^(2) ;; and (A.B)^^(2). ((and (or (mplusp factor) (and (not $dotexptsimp) (mnctimesp factor))) (fixnump power) (not (greaterp (minus power) $expon)) (< power 1)) (let (($expop $expon)) (ncpower (ncpower factor ( power)) 1)))  Comment By: Stavros Macrakis (macrakis) Date: 20030715 00:52 Message: Logged In: YES user_id=588346 Simpler case: (a + 1)^^(1) . (a + 1)^^(1), expon:2; The problem is that simpnct and simpncexpt are passing the buck to each other in cases like this. Simpncexpt correctly expands (a+1)^^3 as (a+1).(a+1)^^2, letting simpnct take care of the expansion, which it does. But it also tries to expand (a+1)^^(3) as (a+1)^^1 . (a+1)^^2, but simpnct doesn't recognize that case. Another, less dramatic, bug: expand(a^^1 . (b+c)^^1) does not expand at all. Note that there's no way to combine the parts within the powers without expanding out the powers  same problem with commutative multiplication. That is, how do I simplify a^n * (1+1/a)^n => (a * (1+1/a))^n => (a+1)^n , or to get a little fancier, (1/a+1)^(n+k)*a^(n+m) => a^(mk)*(a+1)^ (n+k). Radcan will do it, but at the cost of losing control over the simplification. Perhaps some variant of multthru is needed, or a new powerscontract.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771061&group_id=4933 
From: SourceForge.net <noreply@so...>  20030819 14:20:12

Bugs item #791234, was opened at 20030819 10:20 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=791234&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor((x^(1/3)+1)^3) fails Initial Comment: factor((x^(1/3)+1)^3) fails, though factor((x^(1/3)+1) ^2) works. The problem is presumably that in the ^2 case, the powers of x are explicitly of the form n/3, whereas in the ^3 case, (x^(1/3))^3 => x, where the (1/3) is not explicit. Similarly for (x^(1/4)+1)^2. Shouldn't factor normalize the exponents (like radcan)?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=791234&group_id=4933 
From: SourceForge.net <noreply@so...>  20030819 02:05:29

Bugs item #789053, was opened at 20030814 23:10 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789053&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rationalize zero divisor error Initial Comment: rat(1.176581703295427e203e36) => Error: Zero divisor. Error signalled by MAXIMARATIONALIZE. Note, by the way, that this number cannot be entered directly in decimal notation  this appears to be a bug in the GCL reader. Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Stavros Macrakis (macrakis) Date: 20030818 22:05 Message: Logged In: YES user_id=588346 Sorry, I can't reproduce this. I must have made some error in reporting it. However, I CAN reproduce the following: 1.176581703295427b203e36; Warning: Float to bigfloat conversion of  2.9999999999999998E36 Error: Zero divisor. Error signalled by MAXIMARATIONALIZE. Ratepsilon is being bound to 1.0e16, and this causes maxima rationalize to fail: rat(3E36),ratepsilon:1.0e16; same error  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789053&group_id=4933 
From: SourceForge.net <noreply@so...>  20030815 04:25:48

Bugs item #711885, was opened at 20030329 13:18 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711885&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Rootscontract with imaginaries fails Initial Comment: q: ((SQRT(3)*%I+1)^(3/2)4*%I)/SQRT(SQRT(3)*%I+1) rootscontract(q) gives the error "SIGN called on an imaginary argument". The error happens within SIMPEXPT, which is not prepared to deal with (1/(SQRT(3)+1))^(1/2) in the form ((MEXPT) ((MEXPT SIMP) ((MPLUS SIMP) 1 ((MEXPT SIMP) 3 ((RAT SIMP) 1 2))) 1) ((RAT) 1 2)) Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: Stavros Macrakis (macrakis) Date: 20030814 23:59 Message: Logged In: YES user_id=588346 cf bug report 789059 The reason I submitted separate bug reports is that in this case, it may be that rootscontract is passing a malformed expression to rootscontract, while in 789059, it is clearly a general simplifier problem.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=711885&group_id=4933 
From: SourceForge.net <noreply@so...>  20030815 04:23:49

Bugs item #789059, was opened at 20030814 23:55 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=789059&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simpexpt problem: sign called on imag arg Initial Comment: The expression ((1)^(1/6))^(1/2) gives the error SIGN called on an imaginary argument This looks a lot like bug report 711885, except that in this case the expression causing the problem was generated directly from valid user input, not by another routine (in that case rootscontract) which created an incorrectly simplified internal result.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789059&group_id=4933 
From: SourceForge.net <noreply@so...>  20030815 04:13:57

Bugs item #789059, was opened at 20030814 23:55 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789059&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simpexpt problem: sign called on imag arg Initial Comment: The expression ((1)^(1/6))^(1/2) gives the error SIGN called on an imaginary argument This looks a lot like bug report 711885, except that in this case the expression causing the problem was generated directly from valid user input, not by another routine (in that case rootscontract) which created an incorrectly simplified internal result.  >Comment By: Stavros Macrakis (macrakis) Date: 20030814 23:59 Message: Logged In: YES user_id=588346 Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789059&group_id=4933 
From: SourceForge.net <noreply@so...>  20030815 03:23:56

Bugs item #789048, was opened at 20030814 23:00 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=789048&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: allroots issues (doc and precision) Initial Comment: The documentation doesn't say to what precision allroots calculates its argument: in fact, it gives full floatingpoint precision (even if the arguments are rats or bfloats). allroots is advertised as "find[ing] all the ...roots of the real polynomial..." In fact it works on real AND complex polynomials, but requires that the coefficients all be explicit numbers (which is not stated). The following get errors: allroots(xsqrt(2)) => ALLROOTS: not a polynomial allroots(x%pi) => ** error while printing ERROR message ** ALLROOTS: polynomial not univariate: ~M Shouldn't allroots simply float its argument? allroots((x  1)^10) gets answers about 20% off because it multiplies out the expression before looking for roots. Shouldn't alreadyfactored expressions be left that way? (I am not sure what the right answer is to that, by the way  perhaps it is more uniform to expand them all as floatingpoint polynomials?) In any case, this should be documented.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789048&group_id=4933 
From: SourceForge.net <noreply@so...>  20030815 03:11:35

Bugs item #789053, was opened at 20030814 23:10 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=789053&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: rationalize zero divisor error Initial Comment: rat(1.176581703295427e203e36) => Error: Zero divisor. Error signalled by MAXIMARATIONALIZE. Note, by the way, that this number cannot be entered directly in decimal notation  this appears to be a bug in the GCL reader. Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789053&group_id=4933 
From: SourceForge.net <noreply@so...>  20030814 23:29:05

Bugs item #788933, was opened at 20030814 16:35 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=788933&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor unhandled multivar datum comparison Initial Comment: taylor(x^y,x,0,1,y,0,1) and taylor(taylor(x^y,y,0,1),x,0,1) => Break: Unhandled multivar datum comparison though taylor(x^y,y,0,1,x,0,1); => 1+(LOG(x)+...)*y+... and TAYLOR(TAYLOR(x^y,x,0,1),y,0,1) => 1+(LOG(x)+...)*y+... and taylor(x^y,[x,y],[0,0],1); = taylor(x^y,[y,x],[0,0],1); => 1+LOG(x)*y+...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788933&group_id=4933 
From: SourceForge.net <noreply@so...>  20030814 19:32:15

Bugs item #788892, was opened at 20030814 15:05 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=788892&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: zeroa handled inconsistently Initial Comment: zeroa (zero+infinitesimal) and zerob (zeroinfinitesimal) are not documented, but they are $symbols, and thus available to the user. They should either be documented, or made into internal symbols. If they are documented, they need to be better supported. Most parts of Maxima don't know about zeroa on input, and as far as I know, no part of Maxima uses zeroa for user output (but see bug 774065), so I would suggest making them internal. The symbols zeroa and zerob (without dollarsign) are currently used only in defint.lisp (askgreateq), and that appears to be a bug.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788892&group_id=4933 
From: SourceForge.net <noreply@so...>  20030814 19:17:13

Bugs item #593350, was opened at 20020809 22:47 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593350&group_id=4933 Category: None Group: None Status: Deleted Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(abs(infinity)) infinite loop Initial Comment: limit(abs(infinity)) appears to get into an infinite loop.  >Comment By: Stavros Macrakis (macrakis) Date: 20030814 15:09 Message: Logged In: YES user_id=588346 Also limit(abs(x),x,infinity)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593350&group_id=4933 
From: SourceForge.net <noreply@so...>  20030814 18:56:16

Bugs item #788882, was opened at 20030814 14:47 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=788882&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factcomb issues Initial Comment: factcomb( 4 * (1)! ) gives Quotient by zero error, though factcomb( (1)! ) gives no error, and for that matter there is no way factcomb can combine 4 and ( 1)!. factcomb((1)! / (2)!) gives a floatingpoint exception (floating point???). The doc for factcomb gives the example of factcomb ((N+1)^B*N!^B). First of all, the documentation (both in the Info file and in Describe) is cut off before the matching Dline, which presumably should have (n+1)! ^b. Secondly, factcomb does not in fact perform that combination. I tried loading in the source for combin.lisp to debug, and many of the above examples now return 1 instead of either the error or the correct answer. minfactorial(( 1)! / (2)!) gives Error: The variable *FACTLIST is unbound. Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788882&group_id=4933 
From: SourceForge.net <noreply@so...>  20030814 16:50:06

Bugs item #781657, was opened at 20030801 14:30 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: binomial(x,x) => 1, but binomial(1,1) => 0 Initial Comment: binomial(x,x) simplifies to 1 yet binomial(1,1) simplifies to 0. (C1) binomial(x,x); (D1) 1 (C2) binomial(1,1); (D2) 0 I agree with (d2) because: 1/(1  x) = 1 + x + x^2 + ... = sum(binomial(1,k) (x) ^k,k,0,inf) implies binomial(1,k) = (1)^k, for integers k >= 0. In the recursion relation [Knuth Vol 1, 1.2.6 Eq. (20)] binomial(r,k) = binomial(r1,k) + binomial(r1,k1) set r > 0, k > 0, and use binomial(0,0) = 1 and binomial (1,0) = 1. From this we get binomial(1,1) = 0. Also see, Knuth Vol. 1 (third edition), Section 1.2.6 Exercise 9. There may be other approaches, but I think using the recursion relations and other identities to extend the domain of the binomial function is the best method. In short, I think the simplification binomial(x,x) ==> 1 should happen only for real x with x >= 0. Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20030814 12:16 Message: Logged In: YES user_id=588346 I am not sure what you mean by "there may be other approaches". binomial(a,a) should simplify to Q if and only if the double limit exists: limit binomial(x,y) = Q x>a y>a A necessary (but in general not sufficient) condition for this to exist is that the two single limits exist and are equal: limit binomial(a,y) = limit binomial(x,a) = Q y>a x>a If the limit is not welldefined, then binomial(x,x) is not well defined, and it will cause incorrect results in some case or another to arbitrarily set it to some value. I don't know if this limit is or isn't welldefined. I do know that depending on identities with unspecified domains of validity is dangerous....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 
From: SourceForge.net <noreply@so...>  20030813 21:53:36

Bugs item #788360, was opened at 20030813 17:25 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=788360&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: algsys a*b=c*d grossly incomplete Initial Comment: algsys([a*b=c*d],[a,b,c,d]) returns [[a = %R2*%R3/%R1,b = %R1,C = %R2,d = %R3]] This is missing some of the solutions where one or both of a and b is zero and one or both of c and d is zero. The complete list of these solutions is: [[a=0,b=%r1,c=0,d=%r2], [a=0,b=%r3,c=%r4,d=0], [a=%r5,b=0,c=0,d=%r6], [a=%r7,b=0,c=%r8,d=0]] The first two are subsumed by the original solution as long as b # 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=788360&group_id=4933 
From: SourceForge.net <noreply@so...>  20030812 16:12:06

Bugs item #783847, was opened at 20030805 20:35 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=783847&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: assignments to %i, inf, ... Initial Comment: Maxima allows assignments to %i, inf, ind, and und. An assignments to %i is especially troublesome (C1) %i : 42; (D1) 42 (C2) %i^2; (D2) 1764 The fix is to give $ind and $und the sysconst property. (The fix is mostly due to Stavros.) Thus change (simp.lisp) (evalwhen (load) (MAPC #'(LAMBDA (X) (MPUTPROP X T '$CONSTANT) (PUTPROP X T 'SYSCONST)) '($%PI $%I $%E $%PHI $INF $MINF $INFINITY %I $%GAMMA))) to (evalwhen (load) (MAPC #'(LAMBDA (X) (MPUTPROP X T '$CONSTANT) (PUTPROP X T 'SYSCONST)) '($%PI $%I $%E $%PHI $INF $MINF $INFINITY %I $%GAMMA $ind $und))) Additionally, I think it would be okay to give $unknown, $pos, $neg, $zero, $pz, $nz, $pn, and $pnz the sysconst property. Now disallow assignments to sysconsts by changing mset to (mlisp.lisp) to (DEFUN MSET (X Y) (declare (object y x)) (PROG NIL (COND ((OR (NULL $SETCHECK) (EQ $SETCHECK '$SETCHECK))) ((AND (OR (ATOM $SETCHECK) (MEMALIKE X (CDR $SETCHECK)) (AND (NOT (ATOM X)) (MEMALIKE (CAAR X) (CDR $SETCHECK)))) (NOT (EQ X Y))) (DISPLA (LIST '(MTEXT) (DISP2 X) ' set to  Y)) (IF $SETCHECKBREAK (LET (($SETVAL Y)) (MERRBREAK T) (SETQ Y $SETVAL))))) (COND ((ATOM X) (WHEN (OR (NOT (SYMBOLP X)) (MEMQ X '(T NIL)) (MGET X '$NUMER) (char= (GETCHARN X 1) #\&) (get x 'sysconst)) ;; prevent assignments to system consts (IF MUNBINDP (RETURN NIL)) (IF (MGET X '$NUMER) (MERROR "~:M improper value assignment to a numerical quantity" X) (MERROR "~:M improper value assignment" X))) (LET ((F (GET X 'ASSIGN))) (IF (AND F (OR (NOT (EQ X Y)) (MEMQ F '(NEVERSET READ ONLYASSIGN)))) (IF (EQ (FUNCALL F X Y) 'MUNBINDP) (RETURN NIL)))) (COND ((AND (NOT (BOUNDP X)) (NOT DSKSETP)) (ADD2LNC X $VALUES)) ((AND (NOT (EQ X Y)) (OPTIONP X)) (IF $OPTIONSET (MTELL "~:M option is being set.~%" X)) (IF (NOT (EQ X '$LINENUM)) (ADD2LNC X $MYOPTIONS)))) (RETURN (SET X Y))) ((MEMQ 'ARRAY (CDAR X)) (RETURN (ARRSTORE X Y))) ((AND $SUBSCRMAP (MEMQ (CAAR X) '(MLIST $MATRIX))) (RETURN (OUTERMAP1 'MSET X Y))) (T (MERROR "Improper value assignment:~% ~M" X))))) After the fixes (C1) load("mset.x86f"); (D2) mset.x86f (C3) und : 13; UND improper value assignment  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C4) inf : 34; INF improper value assignment  an error. Quitting. To debug this try DEBUGMODE (TRUE);) (C5) %i : 1; %I improper value assignment  an error. Quitting. To debug this try DEBUGMODE (TRUE);) Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20030812 11:59 Message: Logged In: YES user_id=588346 I would suggest putting sysconst on T and NIL and getting rid of the separate test (memq x '(t nil)). That is more uniform  TRUE and FALSE are sysconsts like everything else. As for putting sysconst on pz, nz, pn, etc., I am not sure. If they were long and specific names (nonneg, nonpos, nonzero, etc.), I wouldn't have any problem. But twoletter names are just too useful  since subscripts like p[z] have a specific meaning in Maxima, it is common to use pz to mean things like potential sub z or whatever. Moreover, there is no good reason to be evaluating these symbols  tests should be e.g. if sign(x)='pz (though I know many people don't bother to quote). So to be uniform, I argue AGAINST making pz, nz, pz, and pnz (and for uniformity, pos and neg) into sysconsts.  Comment By: Raymond Toy (rtoy) Date: 20030807 11:14 Message: Logged In: YES user_id=28849 Very nice! I'll apply this shortly, with the additional symbols you mentioned.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=783847&group_id=4933 