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}
(22) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

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

9
(2) 
10
(5) 
11
(2) 
12

13
(1) 
14

15
(1) 
16

17

18
(19) 
19
(1) 
20
(22) 
21
(6) 
22
(4) 
23
(2) 
24
(1) 
25
(1) 
26

27
(3) 
28

29
(5) 
30
(7) 
31
(2) 




From: SourceForge.net <noreply@so...>  20100802 22:49:42

Bugs item #1993208, was opened at 20080613 19:38 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1993208&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: Oliver Kullmann (xgateruq9) Assigned to: Nobody/Anonymous (nobody) Summary: cartesian_product incorrect on empyt argument list Initial Comment: In version 5.15 we have cartesian_product(); {} while the correct result is {[]} This is obvious in many ways:  an empty product is 1 (not 0)  a product of a family (X_i)_{i in I} of sets is the set of all choice functions; if I is empty, then there is exactly one such choice function, namely the empty map, and this corresponds to the empty list. The corrected version is: corr_cartesian_product([S]) := if emptyp(S) then {[]} else apply(cartesian_product,S)$  >Comment By: Dieter Kaiser (crategus) Date: 20100803 00:49 Message: The suggested correction has been implemented with revision 1.36 of nset.lisp. Closing this bug report as fixed. Dieter Kaiser  Comment By: Alexey Beshenov (beshenov) Date: 20080614 02:40 Message: Logged In: YES user_id=1498309 Originator: NO > cartesian_product(); > {} > > while the correct result is > > {[]} > > This is obvious in many ways: >  an empty product is 1 (not 0) More precisely, the empty product of numbers is the multiplicative identity 1. It isn't related to the empty Cartesian product. >  a product of a family (X_i)_{i in I} > of sets is the set of all choice functions; > if I is empty, then there is exactly one such > choice function, namely the empty map, and > this corresponds to the empty list. Well, it's not "obvious in many ways"One may found natural to treat empty Cartesian product in a different manner, i.e. as some other singleton. The output of cartesian_product() may be corrected, but it's a minor issue.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1993208&group_id=4933 
From: SourceForge.net <noreply@so...>  20100802 22:49:26

Bugs item #1990099, was opened at 20080610 21:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1990099&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: Oliver Kullmann (xgateruq9) Assigned to: Nobody/Anonymous (nobody) Summary: wrong integer_partitions(0) Initial Comment: (%i2) integer_partitions(0); (%o2) {} is wrong: it must be {[]}. The documentation of integer_partitions correctly states "A list [a_1, ..., a_m] is a partition of a nonnegative integer n when (1) each a_i is a nonzero integer, and (2) a_1 + ... + a_m = n." Unfortunately, then follows: "Thus 0 has no partitions." while obviously from the definition it follows that [] is the unique partition of 0. The partition function p(n), which counts the number of partitions of n, is accordingly defined as p(0) = 1. See any book on number theory, or e.g. http://en.wikipedia.org/wiki/Partition_(number_theory). Or see http://www.research.att.com/~njas/sequences/A000041. (For example, S_0 is the trivial group, the same as S_1, and thus p(0) = p(1) = 1.) Another bug: The documentation states that n is an integer. However: (%i4) integer_partitions(1); (%o4) int_partitions(1) The value is {} for negative n. The corrected integer_partition is corrected_integer_partitions(n) := if n < 0 then {} elseif n = 0 then {[]} else integer_partitions(n)$  >Comment By: Dieter Kaiser (crategus) Date: 20100803 00:49 Message: The suggested correction has been implemented with revision 1.36 of nset.lisp. Closing this bug report as fixed. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20080701 13:10 Message: Logged In: YES user_id=895922 Originator: NO fixed typo: int_partitions > integer_partitions (CVS revision 1.26)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1990099&group_id=4933 
From: SourceForge.net <noreply@so...>  20100802 21:11:05

Bugs item #1954693, was opened at 20080430 07:26 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&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: Satoshi Adachi (satoshi_adachi) Assigned to: Nobody/Anonymous (nobody) Summary: 2D display of long denominator of nested fractional Initial Comment: Dear Developers of Maxima, I think that I met a bug of Maxima to display nested fractionals in the 2D style. If the denominator of a nested fractional is long, it is not displayed correctly. The display width controll based on the variable LINEL seems to be not effective in the denominator. Compared to this, the numerator of a nested fractional causes no such problem to be displayed even when the numerator is long. Here, I have prepared a program for demonstration:  /* * denominator_of_nested_fractional_is_not_displayed_correctly.maxima: * * The line length, which is usually controlled by the variable LINEL, * is not recognized in the denominator of a nested fractional, if the * nested fractional has a long denominator. * * S.Adachi 2008/04/29 */ /* Do not use ``display2d:false;'', since this is a problem in displaying a mathematical expression in the 2D style. */ X:product(f(i+1/2),i,0,20); Y:product(g(i+1/2),i,0,20); Z:X/Y; /* A nested fractional; its denominator is not displayed correctly. */ /* END */  This is a problem in displaying mathematical expressions in the 2D style. Accordingly, I cannot attach here the log list that is obtained by running the above program. (If I include in a bug report the mathematical expressions that are displayed in the 2D style by Maxima, the posted bug report becomes a disordered gabage in appearance.) So, please execute the above program by the command maxima b denominator_of_nested_fractional_is_not_displayed_correctly.maxima to see the phenomenon that I am reporting in this letter. I am using a console terminal with line width 80 to run the above program. It is essential for Maxima to display any mathematical expression in a correct mannar. If it is not, we cannot read the output from Maxima. So, please fix this bug. Sincerely yours, Satoshi Adachi  >Comment By: Dieter Kaiser (crategus) Date: 20100802 23:11 Message: Again I had a look at the problem. I have found the reason in a change of the function dimnary in revision 1.37. When I revert the changes of this function I get the expected breakup of long lines. This is the routine (defun dimnary (form result lop op rop w) ; (declare (ignore op)) (if (and (consp form) ; (member (safeget (caar form) 'dimension) '(dimensioninfix dimensionnary)) (eq (caar form) op) ) (dimensionparen form result) (dimension form result lop rop w right))) We get the following for the example of the last posting: (%i1) num:a1+a2+a3+a4+a5+a6+a7+a8+a9$ (%i2) denom:b1+b2+b3+b4+b5+b6+b7+b8+b9$ (%i3) linel:10$ (%i4) num/(x*denom); (%o4) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /((b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) x) The change has been introduced to get a more correct display for expressions like a * b . c > a (b . c) I have not analyzed the problem further and I have no solution to get a correct breakup of long lines. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100203 01:04 Message: I had again a look at this problem. The example I have given in the bug report ID:635708 is a more simple example for the reported problem in this bug report. But there are two problems and this bug report is not related to the first one. The problem of this bug report is present until Maxima 5.15. In Maxima 5.14 the display of this example is correct. The example I have given in the report ID:635708 is correct in Maxima 5.14 too, but not since Maxima 5.15. This is again the more simple example: We take a long numerator and a long denominator. (%i1) num:a1+a2+a3+a4+a5+a6+a7+a8+a9; (%o1) a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1 (%i2) denom:b1+b2+b3+b4+b5+b6+b7+b8+b9; (%o2) b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 We set linel to a small value 10. (%i4) linel:10; (%o4) 10 We display num/denom. This is a correct display. (%i5) num/denom; (%o5) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /(b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) We get the error when we multiply the denominator with a further constant. The last line is no longer broken up correctly: (%i6) num/(x*denom); (%o6) (a9 + a8 + a7 + a6 + a5 + a4 + a3 + a2 + a1) /((b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1) x) Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100202 17:40 Message: I think this bug report is related to the following bug report: ID 635708  Bad 2ddisplay of a long denominator. A 2ddisplay with a small value of linel shows that the long denominator is not broken up correctly. This seems to be a general problem. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20080622 23:55 Message: Logged In: YES user_id=501686 Originator: NO Assign category = lisp core.  Comment By: Robert Dodier (robert_dodier) Date: 20080504 07:55 Message: Logged In: YES user_id=501686 Originator: NO Observed in Maxima 5.15.0cvs. NOT observed in 5.9.0  so I guess the display code was modified incorrectly at some point. I can try some different versions, but it will be a while. The line width doesn't appear to be important  I get incorrect output when linel:65, or linel:70, or linel:80.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1954693&group_id=4933 
From: SourceForge.net <noreply@so...>  20100802 20:07:21

Bugs item #3038467, was opened at 20100802 20:07 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3038467&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: fpprec bug or bad command use? Initial Comment: Why when in wxMaxima (v. 5.21.1) i set for example fpprec : 1000, the result of 250! is printed as 323285626090910773232081455202[433 digits]000000000000000000000000000000 and not with all digits? Using command line "version" the result is correctly printed with all digits.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3038467&group_id=4933 
From: SourceForge.net <noreply@so...>  20100802 18:39:59

Bugs item #820770, was opened at 20031009 19:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820770&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: plog(x^2) => 2*log(x) Initial Comment: Plog is advertised as the principal branch of the complexvalued natural logarithm with %PI < CARG(X) <= +%PI This sounds very useful, and presumes that the regular 'log' function represents something other than the principal branch  perhaps all branches as a multivalued function? But plog(x^2) simplifies to 2*log(x) (after asking whether x is nonzero). This simplification is incorrect for x=1. The main meaning of plog appears to be that it will *carry out* the logarithm when the imagpart is a multiple of %pi/4. makelist([log(x),plog(x)],x,[1,%i,1+%i,%i*2,2+%i]) => [[0,0], [LOG(%I), %I*%PI/2 ], [LOG(%I+1), LOG(2)/2+%I*%PI/4 ], [LOG(2*%I), LOG(2)+%I*%PI/2 ], [LOG(%I+2), PLOG(%I+2) ] ] And the only use of plog within Maxima is by defint. I am not even sure that defint actually needs plog (as opposed to plain log)  maybe it is some sort of vestige?  >Comment By: Dieter Kaiser (crategus) Date: 20100802 20:39 Message: With revision 1.113 of simp.lisp the implementation of the Log function has changed. Simplifications like log(x^2) > 2*log(x) are no longer done by default. Because of this we now get: (%i1) plog(x^2); Is x zero or nonzero? n; (%o1) log(x^2) It simplifies when the sign of x is known to be positive: (%i2) assume(x>0)$ (%i3) plog(x^2); (%o3) 2*log(x) (%i4) plog(x^2); (%o4) 2*log(x)+%i*%pi But not if the sign is known to be negative: (%i5) assume(y<0)$ (%i6) plog(y^2); (%o6) log(y^2) Closing this bug report as fixed. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060711 06:38 Message: Logged In: YES user_id=501686 Same behavior in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=820770&group_id=4933 