From: Dan C. <dan...@co...> - 2005-11-12 17:35:11
|
SBCL currently uses read-time evaluation (#.) forms to textually represent infinite values. We needed to be able to print/read these values without *read-eval* enabled. Lispworks uses a simple, extended number syntax to encode IEEE 754 values (e.g., 1e++0 for INF) that we like and would like to see more broadly adopted. Modified SBCL 0.9.6 functions that provide this extended-syntax support for INF, -INF, and NaN can be found at: http://dancorkill.home.comcast.net/sbcl-inf.lisp (Sorry, I don't have these as patches to the development sources.) I'd like to see this "extended" number syntax more widely adopted (allowing infinite values to be portably exchanged among CL implementations that support 754). [No IEEE 754 debates, please!] -- Dan Corkill |
From: James Y K. <fo...@fu...> - 2005-11-12 21:52:52
|
On Nov 12, 2005, at 12:34 PM, Dan Corkill wrote: > SBCL currently uses read-time evaluation (#.) forms to textually > represent > infinite values. We needed to be able to print/read these values > without > *read-eval* enabled. Lispworks uses a simple, extended number > syntax to encode IEEE 754 values (e.g., 1e++0 for INF) that we like > and > would like to see more broadly adopted. Modified SBCL 0.9.6 > functions that provide this extended-syntax support for INF, -INF, > and NaN can be found at: > http://dancorkill.home.comcast.net/sbcl-inf.lisp > (Sorry, I don't have these as patches to the development sources.) 1e++0 and -1e++0 seem like really bad representations for +-inf, as they are completely meaningless to most anyone who might see one. That 1e+-0 is the representation for NaN doesn't make things any better. And what's with only outputting the trapping-ness of the NaN in a comment? That's kinda weird. Following the examples of the above, surely a trapping NaN should be -1e+-0. Ugh. Of course, outputting a comment after every NaN does help with the "what the hell is this" problem. James |
From: Dan C. <dan...@co...> - 2005-11-12 22:18:09
|
> 1e++0 and -1e++0 seem like really bad representations for +-inf, as > they are completely meaningless to most anyone who might see one. The 1e++0 representation has the advantage of being compact, adding little overhead to the reader, and unlikely to collide with anyone's symbol names. I was thinking along the lines of 1e+inf and -1e+inf until I learned of the Lispworks scheme. Since my goal is to facilitate portable exchange of infinity values, I went with the Lispworks scheme in my modifications rather than introducing another one. > That 1e+-0 is the representation for NaN doesn't make things any > better. And what's with only outputting the trapping-ness of the NaN > in a comment? That's kinda weird. Following the examples of the > above, surely a trapping NaN should be -1e+-0. Ugh. Of course, > outputting a comment after every NaN does help with the "what the > hell is this" problem. Lispworks doesn't distinguish trapping/non-trapping NaNs, so again I stayed compatible. I think that 1e--0 is more noticable than 1e+-0 (and is still read in as NAN), but again I didn't change from what Lispworks uses. Using -e+-0 for trapping NaN is read compatible with Lispworks, but Lispworks would treat it as equivalent to e+-0. My goal is to have a *some* solution that is better than incompatible #.(form) representations. |
From: Christophe R. <cs...@ca...> - 2005-11-12 22:27:42
|
James Y Knight <fo...@fu...> writes: > On Nov 12, 2005, at 12:34 PM, Dan Corkill wrote: >> SBCL currently uses read-time evaluation (#.) forms to textually >> represent >> infinite values. We needed to be able to print/read these values >> without >> *read-eval* enabled. Lispworks uses a simple, extended number >> syntax to encode IEEE 754 values (e.g., 1e++0 for INF) that we like >> and >> would like to see more broadly adopted. Modified SBCL 0.9.6 >> functions that provide this extended-syntax support for INF, -INF, >> and NaN can be found at: >> http://dancorkill.home.comcast.net/sbcl-inf.lisp >> (Sorry, I don't have these as patches to the development sources.) > > 1e++0 and -1e++0 seem like really bad representations for +-inf, as=20=20 > they are completely meaningless to most anyone who might see one.=20=20 I'm glad it's not just me who had this reaction. They're non-mnemonic and also dangerously close in a Levenstein sense: your 1e+0 is one small typo away from +Inf.0...=20=20 > That 1e+-0 is the representation for NaN doesn't make things any=20=20 > better. And what's with only outputting the trapping-ness of the NaN=20=20 > in a comment? That's kinda weird. Following the examples of the=20=20 > above, surely a trapping NaN should be -1e+-0. Ugh. Of course,=20=20 > outputting a comment after every NaN does help with the "what the=20=20 > hell is this" problem. The bonus that I get in replying to you rather than to Dan is that I'm allowed to introduce a little bit of IEEE754 debate :-) So, IEEE754 specifies only two distinct NaNs: quiet and signalling/trapping. However, in the standard 32-bit and 64-bit encodings of IEEE754, there is great redundancy in NaN-space, and implementations and applications are encouraged to use that redundancy to communicate information. Should these redundant bits be part of the output format, so that they can be reconstructed at the other end? People on this list might not be terribly aware of the fact that the IEEE754 standard is undergoing revision; interested parties may want to read <http://754r.ucbtest.org/drafts/754r.pdf> (the other versions have mangled mathematical symbols) to see the current state of thinking. At least some of the 200+ pages are devoted to talking about interchange formats; if they can't agree on anything (and my superficial reading is that they can't) I'm not sure that we can either. Then, of course, we're constrained by CL's "potential number" restrictions. For the implementation to have the latitude to treat something as a number [where I've interpreted for the purpose of this dicussion in square brackets]: * The token consists entirely of digits, signs, ratio markers, decimal points (.), extension characters (^ or _), and [nonadjacent letters]; * The token contains at least one [decimal digit]; * The token begins with a digit, sign, decimal point, or extension character; * The token does not end with a sign. These are actually pretty onerous requirements, so given that it's not terribly surprising that the 1e++0 abomination appears to make sense. (obviously, "+=E2=88=9E" would be too simple). +I.0 and -I.0 are at least passable for +Inf.0 and -Inf.0; maybe +1.0/0.0 and -1.0/0.0 would likewise be good, but what about encoding NaNs? I suppose following the second of the above ideas 0.0/0.0 is a workable general NaN, but that doesn't solve the problem of preserving the extra information. Cheers, Christophe |