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
(6) 
2
(2) 
3

4

5

6

7
(6) 
8
(2) 
9

10
(1) 
11
(1) 
12
(3) 
13
(1) 
14
(8) 
15
(3) 
16
(5) 
17
(1) 
18

19

20
(2) 
21
(6) 
22
(3) 
23
(1) 
24
(1) 
25
(5) 
26
(5) 
27

28
(3) 
29

30

31
(2) 

From: SourceForge.net <noreply@so...>  20090725 22:12:26

Bugs item #660948, was opened at 20030102 05:23 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&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  Complex Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of exp(%i*...) Initial Comment: There are some weirdnesses and inconsistencies in the simplification of exp(%i*...). First, let's look at the case exp(%i*%pi*q). If q is (m/n) with n in {1,2,3,4,6}, it returns a solution in rationals and radicals, e.g. for q=11/3, we get 1/2SQRT (3)*%I/2. For other n's, it reduces q to the range (1,+1]. If q is a float which is exactly m/n as above, it rationalizes it: exp(%i*%pi*.25) => SQRT(2)*%I/2+SQRT(2)/2 I am not comfortable with this, because a floating point number is supposed to be an approximation, and we're getting an exact result here. It does the same thing for x^1.0 and (x^3)^float(1/3), though not for x^0.5 or x^2.0 or (x^3)^float(5/3). However, it does a weird thing if q is very near m/n: exp(%i*%pi*.166666666) => (%I/2+SQRT(3)/2)*%E^(6.666666663157628E10*%I*% PI) Of course this is accurate, but it seems pointless and bizarre. It is also inconsistent in its handling of purely floating exponents: exp(%i*%pi*.333) => %E^(0.333*%I*%PI) (OK) but exp(%i*%pi*5.333) => %E^(667*%I*%PI/1000) (why rationalized here?) Now let's look at the case exp(%i*q). If q = 1.0 exactly, it acts as though q=1: exp(%i*1.0) => %e^%i. This follows the (in my opinion anomalous) case x^1.0 => x, as above. I don't know why this should be; after all, 2^1.0 => 2.0, not 2. And for other floats, it does no reduction at all to (pi,pi]: exp(%i*ev(%pi,numer)) => %E^(3.141592653589793*%I) exp(%i*ev(%pi*100,numer)) => %E^(314.1592653589793*%I) exp(%i*300.0) => exp(%i*300.0) All this needs to be made consistent and clear. In my opinion, floats should NEVER be coerced to exact numbers, unless the user asks for it (e.g. by converting to Rat form).  >Comment By: Dieter Kaiser (crategus) Date: 20090726 00:12 Message: I think the problems of this bug report are no longer present. These are the results for the given examples: No rationalizing of float numbers: (%i2) exp(%i*%pi*0.25); (%o2) %e^(0.25*%i*%pi) No simplification to an exact result: (%i3) x^1.0; (%o3) x^1.0 (%i4) (x^3)^float(1/3); (%o4) x^1.0 More examples for float numbers: (%i5) exp(%i*%pi*0.166666666); (%o5) %e^(0.166666666*%i*%pi) (%i6) exp(%i*%pi*5.333); (%o6) %e^(5.333*%i*%pi) The exp function with a complex float argument evaluate numerically: (%i7) exp(%i*1.0); (%o7) .8414709848078965*%i+.5403023058681398 (%i8) exp(%i*ev(%pi,numer)); (%o8) 1.224500708041116E16*%i1.0 (%i9) exp(%i*ev(%pi*100,numer)); (%o9) 1.961926030129856E15*%i+1.0 (%i10) exp(%i*300.0); (%o10) .9997558399011495*%i.02209661927868395 Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 20:07:34

Bugs item #2825092, was opened at 20090722 00:45 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825092&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: %pi^2.0b0 does not evaluate numerically Initial Comment: Maxima evaluates numeric constants numerically, if the exponent is a floating point number or $numer is T: (%i3) %pi^2.0; (%o3) 9.869604401089358 (%i4) %gamma^2.0; (%o4) .3331779238077187 (%i5) %pi^2,numer; (%o5) 9.869604401089358 (%i6) %gamma^2,numer; (%o6) .3331779238077187 But it does not work if the exponent is a bigfloat number (only %e works): (%i9) %pi^2.0b0; (%o9) %pi^2.0b0 (%i10) %gamma^2.0b0; (%o10) %gamma^2.0b0 This is a piece of code in simpexpt, which will change this: (t (let ((y (mget gr '$numer))) ;; Check for a numeric constant. (and y (floatp y) (or (floatp pot) ;; The exponent is a bigfloat. Convert base to bigfloat. (and ($bfloatp pot) (member gr *builtinnumericconstants*) (setq y ($bfloat gr))) (and $numer (integerp pot))) ;; The evaluation is done in exprtl. (return (exptrl y pot)))))) (%i12) %pi^2.0b0; (%o12) 9.869604401089359b0 (%i13) %gamma^2.0b0; (%o13) 3.331779238077187b1 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20090725 22:07 Message: With revision 1.87 of simp.lisp all numeric constants are evaluated numerically, if the exponent is a bigfloat number. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825092&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 20:05:01

Bugs item #2825082, was opened at 20090722 00:20 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825082&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: %pi^1.0b0 > floating point value Initial Comment: The exponent is a bigfloat number, but a floating point number is returned: (%i16) %pi^1.0b0; (%o16) 3.141592653589793 (%i17) %gamma^1.0b0; (%o17) .5772156649015329 The only case which is handled correctly is %e: (%i18) %e^1.0b0; (%o18) 2.718281828459045b0 That is the piece of code in simpexpt, which can handle the other numeric constants too: ((onep1 pot) ;; Exponent is One. (let ((y (mget gr '$numer))) (if (and y (floatp y) (or $numer (not (equal pot 1)))) ;; Base is a numeric constant with a floating point value or ;; $numer is TRUE and the Exponent is not the integer One. (return (if (and (member gr *builtinnumericconstants*) (equal pot bigfloatone)) ;; Convert numeric constant to bigfloat value. ($bfloat gr) ;; Can we reach this point? y)) ;; Handle other cases in exptrl. (return (exptrl gr pot))))) We get: (%i16) %pi^1.0b0; (%o16) 3.141592653589793b0 (%i17) %gamma^1.0b0; (%o17) 5.772156649015329b1 (%i18) %phi^1.0b0; (%o18) 1.618033988749895b0 Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20090725 22:05 Message: With revision 1.87 of simp.lisp all numeric constants return a bigfloat number, if the exponent is bigfloat one. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2825082&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 15:32:54

Bugs item #2824928, was opened at 20090721 14:17 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824928&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: limit(sqrt(z)/b^z,z,inf) Initial Comment: The following limit is not correct for b>1 and b<=0; (%i1) limit(sqrt(z)/b^z,z,inf); (%o1) inf Maxima knows the correct answer for b>1: (%i10) assume(b>1)$ (%i11) limit(sqrt(z)/b^z,z,inf); (%o11) 0 Dieter Kaiser  >Comment By: Dan Gildea (dgildea) Date: 20090725 11:32 Message: Fixed in limit.lisp rev 1.73 decided to return noun form rather than asking user questions.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824928&group_id=4933 
From: SourceForge.net <noreply@so...>  20090725 14:29:51

Bugs item #2824909, was opened at 20090721 19:19 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: exp(%i*%pi/4) not simplified Initial Comment: The following expression is not fully simplified: (%i3) exp(%i*%pi/4); (%o3) %i/sqrt(2)+sqrt(2)/2 We have to do an extra simplification: (%i4) expand(%,0,0); (%o4) %i/sqrt(2)+1/sqrt(2) The reason is, that the routine spang1 in csimp.lisp returns the value of the global special variable sqrt2//2. The value is not correctly simplified by hand: (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) We have the same problem with the variable sqrt2//2 (%i5) :lisp sqrt2//2 ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) 2 ((RAT SIMP) 1 2))) There are two solutions: 1. Correct the value of the global variables. 2. Do not use the global variables, but use code which simplifies accordingly, e.g. sqrt2//2 > (div 1 ($sqrt 2)) The global variables sqrt2//2, sqrt//2, sqrt3//2, sqrt3//2 are definied in trigi.lisp. All variables are used only one time in csimp.lisp. I think it is the best to cut out these four variables and to insert the code directly in the routine spang1. Dieter Kaiser  >Comment By: Dieter Kaiser (crategus) Date: 20090725 16:29 Message: The suggested change (2) has been committed with revision 1.19 of csimp.lisp. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2824909&group_id=4933 