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}
(79) 
S  M  T  W  T  F  S 






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

10
(3) 
11
(1) 
12
(2) 
13
(11) 
14
(1) 
15
(5) 
16

17

18
(2) 
19
(10) 
20
(2) 
21
(2) 
22
(3) 
23
(2) 
24
(6) 
25
(2) 
26
(6) 
27
(2) 
28
(10) 
29
(1) 
30

31
(3) 






From: SourceForge.net <noreply@so...>  20090521 19:44:39

Bugs item #609464, was opened at 20020915 05:18 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&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  Floating point Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1+%e,numer and %e^%e,numer Initial Comment: %e^%e,numer does not evaluate numerically to 15.15... as it should, it simply returns the simplified expression %e^%e.  >Comment By: Dieter Kaiser (crategus) Date: 20090521 21:44 Message: The flag %enumer has not been cut out as suggested in the last posting, but code has been added to simp.lisp with revision 1.77 to simplify %e in expressions, when $numer is true. The examples 1+%e, %e^%e give the expected numerical values. Furhtermore functions with %e as an argument simplify accordingly. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090514 00:48 Message: We have the flag %enumer which should prevent the evaluation of %e to its numerical value when the flag $numer is true. The evaluation occurs only when $%enumer is true too. But we have the following code in the function $ev: (if (and (cdr l) (null (cddr l)) (eq (car l) '$%e) (eq (cadr l) '$numer)) (setq l (append l '($%enumer)))) This code is responsible for some of the inconsistent behaviors as reported in this bug report: %e is evaluated because of the above special handling: (%i5) %e,numer; (%o5) 2.718281828459045 Partially evaluation with a multiplication: (%i7) %e*(%e+1)^2,numer; (%o7) 2.7182817*(%e+1)^2 All examples are evaluated with %enumer true: (%i10) %e*(%e+1)^2,numer,%enumer; (%o10) 37.581930949508 We can prevent evaluation: (%i4) %e,numer,noeval; (%o4) %e A further complication is the simplifier. If we have an exponent, simplification and not evaluation causes the numerical evaluation. (%i5) %e^1,numer,noeval; (%o5) 2.718281828459045 First I tried to get this all more consistent by removing the hack in $ev which causes evaluation of %e in certain expressions. But because of the simplifier, as shown in the last example, this does not help completely. So, I think it would be most consistent to cut out the special handling of the flag %enumer in the code of meval1. ((and $numer (setq val (safemget form '$numer)) ;(or (not (eq form '$%e)) $%enumer) ) (return (meval1 val))) There are two further pieces of code we can cut out. With this changes %enumer has no longer a function and we would get: (%i8) %e,numer; (%o8) 2.718281828459045 (%i9) %e+1,numer; (%o9) 3.718281828459045 (%i10) sin(%e),numer; (%o10) .4107812905029088 (%i11) (%e+1)^2,numer; (%o11) 13.82561975584874 When we cut out %enumer, the flag %numer would be more consistent with the results of he flag bfloat and the functions float and bfloat, too. The testsuite and the share_testsuite would have no problem. Is there a reason not to cut out the flag %enumer? Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20080127 20:22 Message: Logged In: YES user_id=588346 Originator: YES What is by design is that %e^x,numer does not become 2.718^x (unless %enumer is true). The other cases are because the original coder either didn't care about cases like %e+1 or thought it would be too computationally expensive to handle them differently, since they can't be handled bottomup. After all, all of %e^2, %e^%pi, %e^(2/3) with ,numer *do* evaluate to floats. If we fix %e+1,numer we should also fix sin(%pi+x),numer. Currently, that gives sin(3.14+x); it should give sin(x) (that is, the %pi should not simplify to 3.14; the regular simplifier should take over). There is a special hack so that *at the top level*, %e,numer => 2.718. This is really ugly: %e,numer => 2.7 %e+1,numer => %e+1 [%e],numer => [%e] The correct intuition is this: with numer=true, if simplifying a constant (like %e or %pi or for that matter %i and inf) to a float would cause the expression it is contained in (and not just the constant itself) to become a float/complex float, then do it. Otherwise don't. For the purposes of this definition, consider that a toplevel constant is "contained in" some sort of expression. This design would give numer:true %e^x => %e^x sin(%pi+x) => sin(x) inf => <<IEEE positive infinity>> but of course we don't currently handle that %e^2 => 7.4 2^%e => 6.6 atan(1) => .78 atan(inf) => 1.57 sin(2/3*%pi + x) => sin(x+2.1) %e^%i => .5+.8*%i %i^%i => .27 sin(1+%pi) => 0.84 I don't think we can easily fix all these cases, but we should start. The current behavior is incoherent and not very useful.  Comment By: Robert Dodier (robert_dodier) Date: 20080127 20:01 Message: Logged In: YES user_id=501686 Originator: NO I'm pretty sure we should change the behavior of %e in the presence of numer, whether or not the current behavior is intentional. Reopening this report accordingly. I've been bitten by this inconsistency repeatedly. %e, numer; => 2.718281828459045 %e + 1, numer; => %e + 1 %e^%pi, numer; => 23.14069263277927 %e^%e, numer; => %e^%e Preserving %e in %e^foo, numer when foo is nonnumeric is OK by me. I suppose that's the original intent of %enumer but for whatever reason it is not the sole effect.  Comment By: Dan Gildea (dgildea) Date: 20080127 19:26 Message: Logged In: YES user_id=1797506 Originator: NO This seems to be by design. (%i5) %e^%e,numer,%enumer; (%o5) 15.15426224147926 (%i6) %e^%e,numer; (%o6) %e^%e (%i7) %e+1,numer,%enumer; (%o7) 3.718281828459045 (%i8) %e+1,numer; (%o8) %e+1  Comment By: Robert Dodier (robert_dodier) Date: 20060626 20:17 Message: Logged In: YES user_id=501686 Still present in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20040323 18:48 Message: Logged In: YES user_id=588346 cf. bug 531466 re float(exp(exp(2)))  Comment By: Stavros Macrakis (macrakis) Date: 20020919 05:12 Message: Logged In: YES user_id=588346 1+%e,numer also fails These examples work with bfloat, e.g. 1+%e,bfloat; %e^%e,bfloat;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&group_id=4933 
From: SourceForge.net <noreply@so...>  20090521 19:31:39

Bugs item #2003386, was opened at 20080626 20:49 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2003386&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: Includes proposed fix >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: float(elliptic_kc(1)) causes Lisp error Initial Comment: float(elliptic_kc(1)) signals a Lisp error. I think it should do something else. Perhaps return inf since elliptic_kc(x) > inf as x > 1, so elliptic_kc(1) might return inf instead of a noun form.  >Comment By: Dieter Kaiser (crategus) Date: 20090521 21:31 Message: A check for an argument 1 has been added to simp%elliptic_kc with revision 1.68 of ellipt.lisp. elliptic_kc(1), elliptic_kc(1.0), and elliptic_kc(1.0b0) give a Maxima error. The function is undefined. The suggested further simplifications for some special values are not implemented. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090512 16:31 Message: I think a check for an argument 1 for the function elliptic_kc should be added before we call the numerical routines and a Maxima error should be thrown. A more general result would be infinity. Because Maxima can not handle infinities correctly, we do not return infinities in other cases too. In the following code the handling of infinities as an argument and the handling of the number 1 for elliptic_ec has been added too. Index: ellipt.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/ellipt.lisp,v retrieving revision 1.67 diff u r1.67 ellipt.lisp  ellipt.lisp 29 Mar 2009 06:24:51 0000 1.67 +++ ellipt.lisp 12 May 2009 14:22:49 0000 @@ 1947,13 +1947,23 @@ (declare (ignore yy)) (oneargcheck form) (let ((m (simpcheck (cadr form) z)))  (cond ((floatnumericalevalp m) + (cond ((onep1 m) + (merror + (intl:gettext "elliptic_kc: elliptic_kc(~:M) is undefined.") + m)) + ((floatnumericalevalp m) ;; Numerically evaluate it (elliptick (float m))) ((complexfloatnumericalevalp m) (complexify (bigfloat::bfelliptick (complex ($realpart m) ($imagpart m))))) ((complexbigfloatnumericalevalp m) (to (bigfloat::bfelliptick (bigfloat:to ($bfloat m))))) + ((or (member m '($inf $minf $infinity)) + (member (mul 1 m) '($inf $minf)) + (member (mul '$%i m) '($inf $minf)) + (member (mul 1 '$%i m) '($inf $minf))) + ;; Handle infinities as an argument. + 0) ((zerop1 m) '((mtimes) ((rat) 1 2) $%pi)) ((alike1 m 1//2) @@ 2002,6 +2012,11 @@ ((zerop1 m) '((mtimes) ((rat) 1 2) $%pi)) ;; Some special cases we know about. + ((onep1 m) m) + ((or (eq m '$minf) + (eq (mul 1 m) '$inf)) + '$inf) + ((eq m '$infinity) '$infinity) (t ;; Nothing to do (eqtest (list '(%elliptic_ec) m) form))))) Success, CVS operation completed Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2003386&group_id=4933 