You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(4) 
3
(2) 
4
(1) 
5

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100313 22:22:21

Bugs item #932095, was opened at 20040409 01:28 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932095&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ode2 redundant asksign Initial Comment: ode2('diff(y,x,2)=x^a,y,x) asks whether a+1 is zero or nonzero. Answer zero. It then asks whether a+2 is zero or nonzero! What is happening: Ode2 calls integrate twice. Integrate calls asksign each time, and apparently integrate resets the asksign database each time.  >Comment By: Dieter Kaiser (crategus) Date: 20100313 23:22 Message: Fixed in compar.lisp revision 1.68. asksign writes the answers from the user in the global context '$initial and not in a local context which might be created during the evaluation phase. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932095&group_id=4933 
From: SourceForge.net <noreply@so...>  20100313 19:34:31

Bugs item #1995531, was opened at 20080616 23:49 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&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: zeta errors near 0.0 / 0.0b0 Initial Comment: zeta(0.0) => division by zero zeta(1.0e20) => division by zero zeta(0.0b0) => division by zero And the values aren't accurate near 0.0b0: fpprec:20% zeta(1.0b7) => 1.05b3 (WAY WAY OFF!!) zeta(1.0b20) => 4.919b1 (WAY OFF!) zeta(10.0b13) < 1/2 (WAY OFF!)  >Comment By: Dieter Kaiser (crategus) Date: 20100313 20:34 Message: We have a new implementation of the numerical algorithm for the zeta function. But still we have problems near the value zero. We get a Lisp error for a small floating point argument: (%i1) zeta(1.0e20); Maxima encountered a Lisp error: arithmetic error DIVISIONBYZERO signalled Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. The accurarcy is bad for bigfloat values near zero: (%i2) fpprec:20$ (%i4) zeta(1.0b20); (%o4) 5.1145234580810622639b1 (%i5) zeta(10.0b13); (%o5) 5.0000000078891903798b1 I think the best is to implement the following approximation near a zero argument: zeta(s) = 1/2  1/2*log(2*%pi)*s + O(s^2) This is the code which does it: (defun floatzeta (s) (let ((s (bigfloat:to s))) (cond ((bigfloat:< (bigfloat:* s s) (bigfloat:epsilon s)) ;; s^2 < epsilon, use the expansion zeta(s) = 1/21/2*log(2*%pi)*s (bigfloat:+ (bigfloat:/ 1 2) (bigfloat:* (bigfloat:/ 1 2) (bigfloat:log (bigfloat:* 2 (bigfloat:%pi s))) s))) ... With this approximation we get correct results for a small argument near the value zero: (%i7) zeta(1.0e20); (%o7) 0.5 (%i8) zeta(1.0b20); (%o8) 4.9999999999999999999b1 (%i9) zeta(10.0b13); (%o9) 4.9999999999908106147b1 Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080622 12:42 Message: Logged In: YES user_id=895922 Originator: NO Also try makelist(bfloat(bfzeta(1.0b7,20 + 10 * k)),k,1,40). The bug doesn't seem to be just a case of subtractive cancellation.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1995531&group_id=4933 
From: SourceForge.net <noreply@so...>  20100313 18:58:18

Bugs item #781657, was opened at 20030801 20:30 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&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 (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: Dieter Kaiser (crategus) Date: 20100313 19:58 Message: The following is an implementation of simpbinocoef which does not simplify binomial(x,x) to the number 1, if the sign of the argument x can be negative. ;; Binomial has Mirror symmetry (defprop %binomial t commuteswithconjugate) (defun simpbinocoef (x vestigial z) (declare (ignore vestigial)) (twoargcheck x) (let ((u (simpcheck (cadr x) z)) (v (simpcheck (caddr x) z)) (y)) (cond ((integerp v) (cond ((minusp v) (if (and (integerp u) (minusp u) (< v u)) (bincomp u ( u v)) 0)) ((or (zerop v) (equal u v)) 1) ((and (integerp u) (not (minusp u))) (bincomp u (min v ( u v)))) (t (bincomp u v)))) ((integerp (setq y (sub u v))) (cond ((zerop1 y) (if (member ($csign u) '($pnz $pn $neg $nz)) (eqtest (list '(%binomial) u v) x) (bincomp u y))) (t (bincomp u y)))) ((complexfloatnumericalevalp u v) (let (($numer t) ($float t)) ($rectform ($float ($makegamma (list '(%binomial) ($float u) ($float v))))))) ((complexbigfloatnumericalevalp u v) ($rectform ($bfloat ($makegamma (list '(%binomial) ($bfloat u) ($bfloat v)))))) (t (eqtest (list '(%binomial) u v) x))))) We get the results (%i1) binomial(x,x); (%o1) binomial(x,x) (%i2) assume(x>0)$ (%i3) binomial(x,x); (%o3) 1 In addition the above code implements the numercial evaluation for floating point arguments more consistent and in addition for complex float and float and complex bigfloat values: (%i4) binomial(0.5,1/2); (%o4) 1.0 (%i5) binomial(0.5,1/2+%i); (%o5) 2.6238968513421611.279746064016377*%i (%i6) binomial(0.5b0,1/2+%i); (%o6) 2.62389685134216b01.279746064016376b0*%i Furthermore, the property mirror symmetry is added: (%i7) conjugate(binomial(1+%i,1%i)); (%o7) binomial(1%i,%i+1) The testsuite has one changed result, because binomial(t,t) does not simplify to the number 1. t has to be declared to be positive. The share_testsuite has no problems. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060708 19:23 Message: Logged In: YES user_id=501686 If, and from the comments it appears it is not certain, we want to make special cases for binomial, we might get the desired effect by using an unevaluated conditional. E.g. stuff like binomial(x, x) > if x = 1 then 0 elseif realp(x) and x > 0 then 1 else 'binomial(x, x). Just a thought.  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...>  20100313 15:37:49

Bugs item #710307, was opened at 20030326 21:38 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=710307&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: orderlessp of bfloat, %e, and inf Initial Comment: sort([1,2,3,1.0,2.0,3.0,1.0b0,2.0b0,3.0b0,3/2,5/2]) => [1,1.0,3/2,2,2.0,5/2,3,3.0,1.0B0,2.0B0,3.0B0] that is, bfloats sort after all other numbers (integers, floats, and rats) regardless of their magnitude. I realize that orderlessp does not and cannot in general sort by magnitude, and I also realize that sort takes a predicate as a second argument (e.g. "<"), but in the case of explicit numbers, I think it would be better (principle of least surprise) if it sorted strictly by magnitude. Symbolic constants like %E and INF are a harder case. Currently, they sort after numbers and before variables and alphabetically among themselves: sort([1,5,%e,%pi,%phi,%gamma,inf,minf]) => [1,5,%E,%GAMMA,%PHI,%PI,INF,MINF] We could sort them by magnitude, giving [MINF,%GAMMA,1,%PHI,%E,%PI,5,INF] But the user can always change the value of a *user defined* "constant", if not a systemdefined constant. This might lead to anomalies. My suggested solution: sort systemdefined constants by magnitude (not %i of course), but not userdefined constants (by the time a user understands userdefined constants, he/she is no longer a beginner, and can deal with the surprise above). The basic problem here is that "constant" means two different things: 1) a pseudovariable such that diff(v)=0; 2) a mathematical constant defined for all time.  >Comment By: Dieter Kaiser (crategus) Date: 20100313 16:37 Message: The following function sorts all constant expressions, e.g. numbers, symbolic constants, or expressions which evaluate to a constant by magnitude. ;; Test function to order a and b by magnitude. If it is not possible to ;; order a and b by magnitude they are ordered by great. (defun $order_by_magnitude (a b) (let (sgn) (cond ((and (or (constp a) (member a '($inf $minf))) (or (constp b) (member b '($inf $minf))) (member (setq sgn ($csign (sub b a))) '($pos $neg $zero))) (cond ((eq sgn '$pos) t) ((eq sgn '$zero) (great b a)) (t nil))) ((or (constp a) (member a '($inf $minf))) t) ((or (constp b) (member b '($inf $minf))) nil) (t (great b a))))) With this function we get the desired order by magnitude: (%i10) sort([1,2,3,1.0,2.0,3.0,1.0b0,2.0b0,3.0b0,3/2,5/2],order_by_magnitude); (%o10) [1,1.0,1.0b0,3/2,2,2.0,2.0b0,5/2,3,3.0,3.0b0] (%i12) sort([1,5,%e,%pi,%phi,%gamma,inf,minf],order_by_magnitude); (%o12) [minf,%gamma,1,%phi,%e,%pi,5,inf] Constant expressions are ordered by magnitude too: (%i14) sort([0,1,2,3,10,sin(1),%e^2],order_by_magnitude); (%o14) [0,sin(1),1,2,3,%e^2,10] Expression which are not constant follow in the order of great: (%i17) sort([3,10,sin(1),%e^2,x,y,2*x],order_by_magnitude); (%o17) [sin(1),3,%e^2,10,x,2*x,y] With this small test function the desired order by magnitude is not the default, but is possible for the user to get it. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=710307&group_id=4933 
From: SourceForge.net <noreply@so...>  20100313 15:05:13

Bugs item #2968174, was opened at 20100310 20:29 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968174&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Richard Hennessy (richardhennessy) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of hypergeometric bug Initial Comment: Try, kill(all); display2d:false; false integrate(bessel_j(4,x),x); hypergeometric([5/2],[7/2,5],x^2/4)*x^5/1920 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^6/11520 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^7/80640 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^8/645120 integrate(%,x); hypergeometric([5/2],[7/2,5],1/4)*x^9/5806080 Only the first entry is right. Richard Hennessy  >Comment By: Dieter Kaiser (crategus) Date: 20100313 16:05 Message: Fixed in sin.lisp revision 1.57. Now we get a correct noun when we integrate again: (%i1) integrate(bessel_j(4,x),x); (%o1) hypergeometric([5/2],[7/2,5],x^2/4)*x^5/1920 (%i2) integrate(%,x); (%o2) ('integrate(hypergeometric([5/2],[7/2,5],x^2/4)*x^5,x))/1920 Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100312 21:59 Message: I think this is a general bug of the integrator. In general the integrator can not handle functions with more than one argument correctly, when one of the arguments is an expression or a list. Another example is: First a correct result. The first argument is an atom: (%i10) integrate(gamma_incomplete(a,x^2)*x^2,x); (%o10) 'integrate(gamma_incomplete(a,x^2)*x^2,x) Now the first argument is an expression. We get a wrong result: (%i11) integrate(gamma_incomplete(2*a,x^2)*x^2,x); (%o11) gamma_incomplete(2*a,1)*x^3/3 The reason is that the functions powerlist and rat10 do not handle this type of functions correctly. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2968174&group_id=4933 