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}
(23) 
_{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...>  20030802 14:27:30

Bugs item #771301, was opened at 20030714 19:50 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771301&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(1)) internal error /FIX Initial Comment: trigrat(sin(1)) => Error: $%I is not of type LIST. Fix: in $listofei (trigrat.lisp), replace (cond ((and (CONSP VAR) (CONSP (CAR VAR)) (equal (caar var) 'mexpt) (equal (cadr var) '$%e) (equal (caaaddr var) 'mtimes) (equal (cadaddr var) '$%i)) (setq $lexp (cons var $lexp)) ... with (cond ((and (mexptp var) (equal (cadr var) '$%e) (mtimesp (caddr var)) (eq (cadr (caddr var)) '$%i)) (setq $lexp (cons var $lexp)) ...  >Comment By: Stavros Macrakis (macrakis) Date: 20030802 10:27 Message: Logged In: YES user_id=588346 Trigrat does some ugly things. I am not sure what it is *supposed* to return for sin(1)  perhaps sin(1)?  but at least (1) what it does return is correct and (2) it doesn't give an error.  Comment By: Raymond Toy (rtoy) Date: 20030802 10:19 Message: Logged In: YES user_id=28849 If I do this, trigrat(sin(1)) returns (%I*(SIN(1)*SIN(2)+COS(1)*COS(2)COS(1)) COS(1)*SIN(2)+SIN(1)*COS(2)SIN(1)) /(2*SIN(1)^2+2*COS(1)^2) Is that really right? (The numerical value is right.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771301&group_id=4933 
From: SourceForge.net <noreply@so...>  20030802 14:19:41

Bugs item #771301, was opened at 20030714 19:50 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771301&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(1)) internal error /FIX Initial Comment: trigrat(sin(1)) => Error: $%I is not of type LIST. Fix: in $listofei (trigrat.lisp), replace (cond ((and (CONSP VAR) (CONSP (CAR VAR)) (equal (caar var) 'mexpt) (equal (cadr var) '$%e) (equal (caaaddr var) 'mtimes) (equal (cadaddr var) '$%i)) (setq $lexp (cons var $lexp)) ... with (cond ((and (mexptp var) (equal (cadr var) '$%e) (mtimesp (caddr var)) (eq (cadr (caddr var)) '$%i)) (setq $lexp (cons var $lexp)) ...  >Comment By: Raymond Toy (rtoy) Date: 20030802 10:19 Message: Logged In: YES user_id=28849 If I do this, trigrat(sin(1)) returns (%I*(SIN(1)*SIN(2)+COS(1)*COS(2)COS(1)) COS(1)*SIN(2)+SIN(1)*COS(2)SIN(1)) /(2*SIN(1)^2+2*COS(1)^2) Is that really right? (The numerical value is right.)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771301&group_id=4933 
From: SourceForge.net <noreply@so...>  20030802 14:07:48

Bugs item #781753, was opened at 20030801 17:13 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Raymond Toy (rtoy) Summary: bfloat>float fails for very large and very small Initial Comment: sm: 2.0b0^1024.00001b0 => 5.5626...B309 (OK) float(sm) => 0.0 NO! true for all smaller sm's but floats can represent numbers down to 4.94e324 float(8.989b307) => nonnumber but floats can represent numbers up to 1.797693134862316E+308 A much more minor problem: though 2.8e324 correctly reads in as 4.94e324 (rounded), 2.7e324 reads in as 0.0. This is a GCL problem. These may be fixed in more recent GCLs, but should still be checked in Maxima. Maxima 5.9.0 GCL 2.5.0 mingw Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20030802 10:07 Message: Logged In: YES user_id=28849 Fixed.  Comment By: Raymond Toy (rtoy) Date: 20030801 21:20 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  Comment By: Raymond Toy (rtoy) Date: 20030801 21:20 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  Comment By: Raymond Toy (rtoy) Date: 20030801 18:30 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 
From: SourceForge.net <noreply@so...>  20030802 01:20:45

Bugs item #781753, was opened at 20030801 17:13 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Raymond Toy (rtoy) Summary: bfloat>float fails for very large and very small Initial Comment: sm: 2.0b0^1024.00001b0 => 5.5626...B309 (OK) float(sm) => 0.0 NO! true for all smaller sm's but floats can represent numbers down to 4.94e324 float(8.989b307) => nonnumber but floats can represent numbers up to 1.797693134862316E+308 A much more minor problem: though 2.8e324 correctly reads in as 4.94e324 (rounded), 2.7e324 reads in as 0.0. This is a GCL problem. These may be fixed in more recent GCLs, but should still be checked in Maxima. Maxima 5.9.0 GCL 2.5.0 mingw Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20030801 21:20 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  Comment By: Raymond Toy (rtoy) Date: 20030801 21:20 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  Comment By: Raymond Toy (rtoy) Date: 20030801 18:30 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 
From: SourceForge.net <noreply@so...>  20030802 01:20:36

Bugs item #781753, was opened at 20030801 17:13 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Raymond Toy (rtoy) Summary: bfloat>float fails for very large and very small Initial Comment: sm: 2.0b0^1024.00001b0 => 5.5626...B309 (OK) float(sm) => 0.0 NO! true for all smaller sm's but floats can represent numbers down to 4.94e324 float(8.989b307) => nonnumber but floats can represent numbers up to 1.797693134862316E+308 A much more minor problem: though 2.8e324 correctly reads in as 4.94e324 (rounded), 2.7e324 reads in as 0.0. This is a GCL problem. These may be fixed in more recent GCLs, but should still be checked in Maxima. Maxima 5.9.0 GCL 2.5.0 mingw Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20030801 21:20 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  Comment By: Raymond Toy (rtoy) Date: 20030801 18:30 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 23:33:58

Bugs item #771133, was opened at 20030714 13:26 Message generated for change (Comment added) made by willisb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771133&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: double overflow => 0.0e0 Initial Comment: (C1) ?most\positive\double\float; (D1) 1.7976931348623157e+308 (C2) 1.7976931348623157e+308; (D2) 1.7976931348623157e+308 (C3) 1.7976931348623158e+308; (D3) 1.7976931348623157e+308 No problem sofar; but a problem here (C4) 1.7976931348623159e+308; (D4) 0.e+0 (C17) build_info(); Maxima version: 5.9.0rc3 Maxima build date: 15:25 5/11/2003 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18d (D17) Barton  >Comment By: Barton Willis (willisb) Date: 20030801 18:33 Message: Logged In: YES user_id=570592 From a cmucl prompt, I get a overflow error. So this has something to do with Maxima. From Maxima, look what readfromstring does (C1) :lisp(trace makenumber readlist readfromstring); (MAKENUMBER READLIST READFROMSTRING) (C1) 1.7976931348623159e+308; 0: (MAKENUMBER ((#\3 #\0 #\8) (#\+) (#\E) (#\7 #\9 #\7 #\6 #\9 ...) (#\.) ...)) 1: (READLIST (#\1 #\. #\7 #\9 #\7 ...)) 2: (READFROMSTRING "1.7976931348623159E+308" NIL NIL :START ...) Debug: Both still valid #.(SYSTEM:INTSAP #x3FFFE79C) #. (SYSTEM:INTSAP #x282D1FED) #.(SYSTEM:INTSAP #x3FFFE6B4) #.(SYSTEM:INTSAP #x08053383) 2: READFROMSTRING returned 0.0 23 Debug: Both still valid #.(SYSTEM:INTSAP #x3FFFE79C) #. (SYSTEM:INTSAP #x282D1FED) #.(SYSTEM:INTSAP #x3FFFE6B4) #.(SYSTEM:INTSAP #x08053383) 1: READLIST returned 0.0 23 Debug: Both still valid #.(SYSTEM:INTSAP #x3FFFE79C) #. (SYSTEM:INTSAP #x282D1FED) #.(SYSTEM:INTSAP #x3FFFE6B4) #.(SYSTEM:INTSAP #x08053383) 0: MAKENUMBER returned 0.0 23 (D1) 0.e+0 Compare with (C2) 1.7976931348623158e+308; 0: (MAKENUMBER ((#\3 #\0 #\8) (#\+) (#\E) (#\7 #\9 #\7 #\6 #\9 ...) (#\.) ...)) 1: (READLIST (#\1 #\. #\7 #\9 #\7 ...)) 2: (READFROMSTRING "1.7976931348623158E+308" NIL NIL :START ...) Debug: Both still valid #.(SYSTEM:INTSAP #x3FFFE79C) #. (SYSTEM:INTSAP #x282D1FED) #.(SYSTEM:INTSAP #x3FFFE6B4) #.(SYSTEM:INTSAP #x08053383) 2: READFROMSTRING returned 1.7976931348623157e+308 23 Debug: Both still valid #.(SYSTEM:INTSAP #x3FFFE79C) #. (SYSTEM:INTSAP #x282D1FED) #.(SYSTEM:INTSAP #x3FFFE6B4) #.(SYSTEM:INTSAP #x08053383) 1: READLIST returned 1.7976931348623157e+308 23 Debug: Both still valid #.(SYSTEM:INTSAP #x3FFFE79C) #. (SYSTEM:INTSAP #x282D1FED) #.(SYSTEM:INTSAP #x3FFFE6B4) #.(SYSTEM:INTSAP #x08053383) 0: MAKENUMBER returned 1.7976931348623157e+308 23 (D2) 1.7976931348623e+308 (C3) build_info(); Maxima version: 5.9.0rc3 Maxima build date: 15:25 5/11/2003 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18d Barton  Comment By: Stavros Macrakis (macrakis) Date: 20030801 16:00 Message: Logged In: YES user_id=588346 GCL 2.5.0 does not have this problem.  Comment By: Raymond Toy (rtoy) Date: 20030729 10:08 Message: Logged In: YES user_id=28849 Interesting. Can you try with 18e or a recent snapshot? A snapshot of CMUCL running on a sparc gets a floatingpointoverflow Lisp error, as expected.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771133&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 22:30:02

Bugs item #781753, was opened at 20030801 17:13 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) >Assigned to: Raymond Toy (rtoy) Summary: bfloat>float fails for very large and very small Initial Comment: sm: 2.0b0^1024.00001b0 => 5.5626...B309 (OK) float(sm) => 0.0 NO! true for all smaller sm's but floats can represent numbers down to 4.94e324 float(8.989b307) => nonnumber but floats can represent numbers up to 1.797693134862316E+308 A much more minor problem: though 2.8e324 correctly reads in as 4.94e324 (rounded), 2.7e324 reads in as 0.0. This is a GCL problem. These may be fixed in more recent GCLs, but should still be checked in Maxima. Maxima 5.9.0 GCL 2.5.0 mingw Windows 2000 Athlon  >Comment By: Raymond Toy (rtoy) Date: 20030801 18:30 Message: Logged In: YES user_id=28849 The float(sm) issue appears to be a GCL problem. CMUCL doesn't do that. (Perhaps GCL defaults to truncatetozero?) The overflow issue is caused by trying to compute 0.5 * 2^1024, and 2^1024 doesn't fit in a doublefloat. A fix using scalefloat instead solves this problem. CMUCL doesn't have problems with 2.7e324 becoming 0.0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 22:16:18

Bugs item #781788, was opened at 20030801 18:16 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=781788&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: scalar/matrix addition inconsistent Initial Comment: I claim that componentwise addition of scalars to matrices is wrong. By default, doallmxops=true. Define m:matrix([a,b],[c,d]). Calculate ratsimp(m.m^^1+m). This yields matrix ([a+1,b],[c,d+1]). Good. Now calculate subst(m,n,n.n^^1+n). This yields matrix ([a+1,b+1],[c+1,d+1]). I believe this is wrong. Note that this happens even when dotident is not equal to 1. Only if dotexptsimp=false (which is a pretty radical restriction) does the subst case match the nonsubst case. As far as I can tell, the only sensible thing for scalar+matrix to mean is scalar*identitymatrix + matrix. I do not believe that componentwise addition of scalar to matrix is ever useful; if it is, you can always write it as scalar*allonesmatrix + matrix. Note that scalar/matrix *multiplication* is a completely different matter  componentwise is perfectly meaningful and useful there. Maxima 5.9.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781788&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 21:13:46

Bugs item #781753, was opened at 20030801 17:13 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=781753&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: bfloat>float fails for very large and very small Initial Comment: sm: 2.0b0^1024.00001b0 => 5.5626...B309 (OK) float(sm) => 0.0 NO! true for all smaller sm's but floats can represent numbers down to 4.94e324 float(8.989b307) => nonnumber but floats can represent numbers up to 1.797693134862316E+308 A much more minor problem: though 2.8e324 correctly reads in as 4.94e324 (rounded), 2.7e324 reads in as 0.0. This is a GCL problem. These may be fixed in more recent GCLs, but should still be checked in Maxima. Maxima 5.9.0 GCL 2.5.0 mingw Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781753&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 21:00:45

Bugs item #771133, was opened at 20030714 14:26 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771133&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: double overflow => 0.0e0 Initial Comment: (C1) ?most\positive\double\float; (D1) 1.7976931348623157e+308 (C2) 1.7976931348623157e+308; (D2) 1.7976931348623157e+308 (C3) 1.7976931348623158e+308; (D3) 1.7976931348623157e+308 No problem sofar; but a problem here (C4) 1.7976931348623159e+308; (D4) 0.e+0 (C17) build_info(); Maxima version: 5.9.0rc3 Maxima build date: 15:25 5/11/2003 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18d (D17) Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20030801 17:00 Message: Logged In: YES user_id=588346 GCL 2.5.0 does not have this problem.  Comment By: Raymond Toy (rtoy) Date: 20030729 11:08 Message: Logged In: YES user_id=28849 Interesting. Can you try with 18e or a recent snapshot? A snapshot of CMUCL running on a sparc gets a floatingpointoverflow Lisp error, as expected.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=771133&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 20:45:17

Bugs item #781726, was opened at 20030801 16:45 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=781726&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with IEEEfloat NaN and INF Initial Comment: flinf: 2.0^1024$ flinf => Error: Can't print a nonnumber (lisp break) Should print something special, e.g. INFe0 flnan: flinfflinf$ flnan => Bind stack overflow (lisp break) Should print something special, e.g. NaNe0 is(flnan=flnan) => TRUE NO! NaN is not equal to itself; cf ?=(flnan,flnan). is(flnan>0) => TRUE NO! is(flnan<0) => TRUE NO! flnan*0 => 0 NO! flinf*0 => 0 NO! GCL also can't print flnan/flinf. Maxima 5.9.0 gcl 2.5.0 mingw Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781726&group_id=4933 
From: SourceForge.net <noreply@so...>  20030801 18:30:21

Bugs item #781657, was opened at 20030801 13:30 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=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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=781657&group_id=4933 