From: Marco A. <ma...@cs...> - 2005-11-14 15:16:38
|
As bad as the ++ and +- stuff looks, I usually write code for=20 CMUCL/SBCL and LW (and other ones) Having this extra bit of compatibility with LW would help. Cheers Marco On Nov 14, 2005, at 9:57 AM, Raymond Toy wrote: >>>>>> "Christophe" =3D=3D Christophe Rhodes <cs...@ca...> writes: > > Christophe> * +I.0 and -I.0 for the infinities > > Christophe> * +=B0.0 and -=B0.0 for the infinities > > Christophe> * 1.0/0.0, -1.0/0.0 and 0.0/0.0 for +inf, -inf and=20 > NaN. (To answer > Christophe> Raymond's question which I've cut, if I were=20 > implementing this I > Christophe> would implement the relevant float infinities as > Christophe> <any non-zero float>/<any zero float> with the right=20= > contagion and > Christophe> sign, to minimize confusion, but I would print as=20 > one over zero). > > I think 1.0/0.0 and -1.0/0.0 are nice ways to denote infinities. > Adding an extra sign to the exponent is very hard to see and is easily > overlooked. > > Christophe> I agree with Raymond that it would be nice to be able > Christophe> to print all of the information in a NaN. > > Perhaps +N.<digits in the NaN> would be sufficient. > > Ray > > > -- Marco Antoniotti = http://bioinformatics.nyu.edu/~marcoxa NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Dan C. <dan...@co...> - 2005-11-14 17:09:32
|
> Dan> A small advantage of ++, +- (other than current support in LW) is that > Dan> it adds only a tiny change to the reader: an additional sign check > Dan> after the exponent sign has been parsed. Christophe's 1.0/0.0 > Dan> suggestion is clearly readable by humans, but it could cause problems > Dan> for someone using an infix extension, and it becomes a bit less clear > Dan> specifying single, double, ... floats explicitly. (1d+inf, -1s+inf > >Raymond> Wouldn't they be written 1d0/0d0, 1f0/0f0, and so on? Or maybe even >Raymond> 1d0/0, 1f0/0. > > Would 1d0/0s0 be illegal or have some coersion rules? 1d0/0 seems better to me (looks less like two distinct numbers). |
From: Raymond T. <ray...@er...> - 2005-11-14 17:15:27
|
>>>>> "Dan" == Dan Corkill <dan...@co...> writes: Dan> A small advantage of ++, +- (other than current support in LW) is that Dan> it adds only a tiny change to the reader: an additional sign check Dan> after the exponent sign has been parsed. Christophe's 1.0/0.0 Dan> suggestion is clearly readable by humans, but it could cause problems Dan> for someone using an infix extension, and it becomes a bit less clear Dan> specifying single, double, ... floats explicitly. (1d+inf, -1s+inf >> Raymond> Wouldn't they be written 1d0/0d0, 1f0/0f0, and so on? Or maybe even Raymond> 1d0/0, 1f0/0. >> >> Dan> Would 1d0/0s0 be illegal or have some coersion rules? 1d0/0 seems Dan> better to me (looks less like two distinct numbers). I would assume normal contagion rules would be applied. Christophe mentions that in one of his messages. Ray |
From: Dan C. <dan...@co...> - 2005-11-14 19:05:10
|
> >> Seems to me that if you're playing with float infinities, you'd have > >> overflow disabled, and, most-likely, divide-by-zero too. > > James> Not necessarily -- it's perfectly natural to have traps enabled, yet > James> still want to introduce an explicit infinity into your data. The > James> trapping rules allow this to occur sensibly -- most manipulation of > James> the introduced infinity doesn't cause additional traps. A > >I think I understand what you're saying, but what does "most >manipulation" mean here? Just loading/storing? I was assuming you'd >use infinity as you would any other FP number and either it signals >overflow when you do basic operations with it, or you mask the >exception and continue to produce infinities (or underflows.) > > (+ Inf 1), (* Inf 10), (- Inf 100), and (+ Inf Inf) all return Inf without additional traps. (+ Inf -Inf) => NaN trap >But this doesn't have much to do with the original question of >representing infinity in a readable fashion.... > > Yes. Let's not open up the IEEE754 can of worms... -- Dan |
From: Raymond T. <ray...@er...> - 2005-11-14 19:13:19
|
>>>>> "Dan" == Dan Corkill <dan...@co...> writes: Dan> (+ Inf 1), (* Inf 10), (- Inf 100), and (+ Inf Inf) all return Inf Dan> without additional traps. Dan> (+ Inf -Inf) => NaN trap Oops. My fault. You're right. Ray |
From: Marco A. <ma...@cs...> - 2005-11-15 15:14:55
|
On Nov 14, 2005, at 9:18 PM, Mike McDonald wrote: > >> To: CMUCL Mailing List <cmu...@co...> >> Date: Mon, 14 Nov 2005 13:39:55 -0500 >> From: Marco Antoniotti > >> Point taken. But that has very little to do with syntax. I just >> think >> the 1.0/0.0 syntax has more problems than the somewhat clumsy 1e++0 >> one. > > Does the INFIX package "just" support the ++ +- syntax or would it > have to be updated? Good point. It doesn't. So I guess I was wrong. Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Mike M. <mi...@mi...> - 2005-11-15 16:01:55
|
>To: SBCL Devel List <sbc...@li...> >Date: Tue, 15 Nov 2005 14:24:28 +0200 (EET) >From: Nikodemus Siivola >I feel provisionally attracted to the styles such as > > +I^f0 > -I^d0 > >as they clearly differentiate the object from a regular number. Does infinity have a precision? Does it really make any sense to distinguish between single, float, and double infinite? Just curious. Mike McDonald mi...@mi... |
From: Dan C. <dan...@co...> - 2005-11-15 16:08:34
|
Mike McDonald wrote: > Does infinity have a precision? Does it really make any sense to >distinguish between single, float, and double infinite? > > Yes, there are individual precisions in IEEE 754 for infinitives and NaNs. |
From: Mario S. M. <mm...@co...> - 2005-11-16 13:14:35
|
Nikodemus Siivola <nik...@ra...> writes: > I'm following this, and share the sentiment of portability and potential > issues with reader-extensions while also finding the LW syntax rather > obscure at the first glance. > > I feel provisionally attracted to the styles such as > > +I^f0 > -I^d0 I like the +I.0f+0 etc. style proposed by Christophe a little bit better. For NaNs one could use something like N.0d+<char>, where <char> is a one-char abbrev. of whatever additional attribute is appropriate. Regards, Mario. |
From: Raymond T. <ray...@er...> - 2005-11-16 19:29:54
|
>>>>> "Mario" == Mario S Mommer <mm...@co...> writes: Mario> I like the +I.0f+0 etc. style proposed by Christophe a little bit Mario> better. For NaNs one could use something like N.0d+<char>, where Mario> <char> is a one-char abbrev. of whatever additional attribute is Mario> appropriate. The entire mantissa of the NaN could contain information. So a one-char abbreviation isn't enough. You need all the bits. However, I'm not aware of any processor that actually tells you what it encodes in the bits, if anything. Ray |
From: Rob M. <ra...@ri...> - 2005-11-16 22:21:43
|
> > The entire mantissa of the NaN could contain information. So a > one-char abbreviation isn't enough. You need all the bits. > > However, I'm not aware of any processor that actually tells you what > it encodes in the bits, if anything. > I thought the idea was not really that the processor would generate NaN's with interesting bits in them, but you could do so if you wanted to create distinghishable uninitialized values for your datastructures. However I suspect very few people are even aware of this feature, let alone exploit it. Rob |
From: Nikodemus S. <nik...@ra...> - 2005-11-17 12:42:17
|
A further possibility that has not yet been mentioned is using a dispatch-macro: CLHS implicitly allows implementations to provide non-standard dispatch macros -- only !, ?, [, ], {, and } are explicitly reserved for users. Eg. #@single-float-infinity #@(nan ...) This has the benefit of being easy to port in user-space: if implementation X doesn't support reading this syntax out of the box writing the dispatch macros to deal with it is easier then hacking into the reader to deal with the syntax for potential numbers. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Michael H. <mw...@py...> - 2005-11-16 22:11:56
|
Raymond Toy <ray...@er...> writes: >>>>>> "Mario" == Mario S Mommer <mm...@co...> writes: > > Mario> I like the +I.0f+0 etc. style proposed by Christophe a little bit > Mario> better. For NaNs one could use something like N.0d+<char>, where > Mario> <char> is a one-char abbrev. of whatever additional attribute is > Mario> appropriate. > > The entire mantissa of the NaN could contain information. So a > one-char abbreviation isn't enough. You need all the bits. In some sense :) > However, I'm not aware of any processor that actually tells you what > it encodes in the bits, if anything. I didn't think the intent was so much for processors to use these bits as libraries -- I think the bits get carried through computations in a defined way, so you could potentially tell which routine produced the NaN. I don't think people actually do this, either, mind, though on Windows there are at least two printed representations for NaN... Oh, and most processor documentation will tell you the difference between a SNaN and a QNaN. Cheers, mwh -- The Oxford Bottled Beer Database heartily disapproves of the excessive consumption of alcohol. No, really. -- http://www.bottledbeer.co.uk/beergames.html (now sadly gone to the big 404 in the sky) |
From: Dan C. <dan...@co...> - 2005-11-14 16:25:22
|
Marco wrote: > As bad as the ++ and +- stuff looks, I usually write code for > CMUCL/SBCL and LW (and other ones) > Having this extra bit of compatibility with LW would help. Compatability among CLs is important, but if there is strong support for another representation scheme, perhaps we can get LW to support it as well. I generated the ++, +- mods for SBCL, CMUCL, and OpenMCL, and I've also floated the idea with Franz. A small advantage of ++, +- (other than current support in LW) is that it adds only a tiny change to the reader: an additional sign check after the exponent sign has been parsed. Christophe's 1.0/0.0 suggestion is clearly readable by humans, but it could cause problems for someone using an infix extension, and it becomes a bit less clear specifying single, double, ... floats explicitly. (1d+inf, -1s+inf might be clearer in this regard.) I also agree that it would be nice to represent all the information in a NaN (even if it is mostly ignored by another CL when reading the representation). Using a somewhat different scheme for NaNs than for infinities might make sense. My need is to address the (currently) bad situation of portably and readably expressing infinite values and (to a lesser extent) NaNs. My hope is that there can be enough agreement to get something reasonable in place. I felt the LW approach was a good place to start, so that's what I did... -- Dan |
From: Raymond T. <ray...@er...> - 2005-11-14 16:39:35
|
>>>>> "Dan" == Dan Corkill <dan...@co...> writes: Dan> Marco wrote: >> As bad as the ++ and +- stuff looks, I usually write code for >> CMUCL/SBCL and LW (and other ones) >> Having this extra bit of compatibility with LW would help. Dan> A small advantage of ++, +- (other than current support in LW) is that Dan> it adds only a tiny change to the reader: an additional sign check Dan> after the exponent sign has been parsed. Christophe's 1.0/0.0 Dan> suggestion is clearly readable by humans, but it could cause problems Dan> for someone using an infix extension, and it becomes a bit less clear Dan> specifying single, double, ... floats explicitly. (1d+inf, -1s+inf Wouldn't they be written 1d0/0d0, 1f0/0f0, and so on? Or maybe even 1d0/0, 1f0/0. I think users will have to speak up and say what they want. Ray |
From: Marco A. <ma...@cs...> - 2005-11-14 16:48:38
|
On Nov 14, 2005, at 11:39 AM, Raymond Toy wrote: >>>>>> "Dan" == Dan Corkill <dan...@co...> writes: > > Dan> Marco wrote: > >>> As bad as the ++ and +- stuff looks, I usually write code for >>> CMUCL/SBCL and LW (and other ones) >>> Having this extra bit of compatibility with LW would help. > > Dan> A small advantage of ++, +- (other than current support in > LW) is that > Dan> it adds only a tiny change to the reader: an additional sign > check > Dan> after the exponent sign has been parsed. Christophe's 1.0/0.0 > Dan> suggestion is clearly readable by humans, but it could cause > problems > Dan> for someone using an infix extension, and it becomes a bit > less clear > Dan> specifying single, double, ... floats explicitly. (1d+inf, > -1s+inf > > Wouldn't they be written 1d0/0d0, 1f0/0f0, and so on? Or maybe even > 1d0/0, 1f0/0. > > I think users will have to speak up and say what they want. The more I think about it the more I see the rationale of the LW solution. I use the INFIX package all the time. While I have not had to deal with NaN and Infinities in conjunction with it (actually I had to, and I had to kludge my way around it, with and without the INFIX package), I can see the problems lurking in cl-prompt> #I(1.0/0.0) ; ==> (/ 1.0 0.0) #<infinity> The "infinity sign" is the obvious candidate, but the "infinity sign" opens up the Unicode can of worms. What is the status of Unicode support among CLs? Meaning: what are the common interfaces supported? Barring that, the ++ thingy looks ok to me. Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Raymond T. <ray...@er...> - 2005-11-14 16:58:48
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: Marco> I use the INFIX package all the time. While I have not had to deal Marco> with NaN and Infinities in conjunction with it (actually I had to, and Marco> I had to kludge my way around it, with and without the INFIX package), Marco> I can see the problems lurking in cl-prompt> #I(1.0/0.0) ; ==> (/ 1.0 0.0) Marco> #<infinity> What is the issue here? What's wrong with #<infinity> here? Or is that something that the infix package produced? Marco> The "infinity sign" is the obvious candidate, but the "infinity sign" Marco> opens up the Unicode can of worms. What is the status of Unicode Marco> support among CLs? Meaning: what are the common interfaces supported? CMUCL doesn't currently support unicode. Ray |
From: Marco A. <ma...@cs...> - 2005-11-14 17:19:00
|
On Nov 14, 2005, at 11:58 AM, Raymond Toy wrote: >>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: > > Marco> I use the INFIX package all the time. While I have not had > to deal > Marco> with NaN and Infinities in conjunction with it (actually I > had to, and > Marco> I had to kludge my way around it, with and without the > INFIX package), > Marco> I can see the problems lurking in > > cl-prompt> #I(1.0/0.0) ; ==> (/ 1.0 0.0) > Marco> #<infinity> > > What is the issue here? What's wrong with #<infinity> here? Or is > that something that the infix package produced? What I meant is that #I(1.0/0.0) expands to (/ 1.0 0.0) which should signal an error. I missed a question mark before and I wasn't clear. Sorry. The #<infinity> bit is not referring to any implementation in particular. > > Marco> The "infinity sign" is the obvious candidate, but the > "infinity sign" > Marco> opens up the Unicode can of worms. What is the status of > Unicode > Marco> support among CLs? Meaning: what are the common interfaces > supported? > > CMUCL doesn't currently support unicode. Exactly my point. And even if it did, portability concerns would be lurking as well, probably even more. Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: Raymond T. <ray...@er...> - 2005-11-14 18:10:06
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: Marco> On Nov 14, 2005, at 11:58 AM, Raymond Toy wrote: >> What is the issue here? What's wrong with #<infinity> here? Or is >> that something that the infix package produced? Marco> What I meant is that #I(1.0/0.0) expands to (/ 1.0 0.0) which should Marco> signal an error. I missed a question mark before and I wasn't clear. Marco> Sorry. The #<infinity> bit is not referring to any implementation in Marco> particular. Seems to me that if you're playing with float infinities, you'd have overflow disabled, and, most-likely, divide-by-zero too. Ray |
From: Marco A. <ma...@cs...> - 2005-11-14 18:40:03
|
On Nov 14, 2005, at 1:09 PM, Raymond Toy wrote: >>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: > > Marco> On Nov 14, 2005, at 11:58 AM, Raymond Toy wrote: > >>> What is the issue here? What's wrong with #<infinity> here? Or is >>> that something that the infix package produced? > > Marco> What I meant is that #I(1.0/0.0) expands to (/ 1.0 0.0) > which should > Marco> signal an error. I missed a question mark before and I > wasn't clear. > Marco> Sorry. The #<infinity> bit is not referring to any > implementation in > Marco> particular. > > Seems to me that if you're playing with float infinities, you'd have > overflow disabled, and, most-likely, divide-by-zero too. Point taken. But that has very little to do with syntax. I just think the 1.0/0.0 syntax has more problems than the somewhat clumsy 1e++0 one. Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |
From: James Y K. <fo...@fu...> - 2005-11-14 18:41:01
|
On Nov 14, 2005, at 1:09 PM, Raymond Toy wrote: > Seems to me that if you're playing with float infinities, you'd have > overflow disabled, and, most-likely, divide-by-zero too. Not necessarily -- it's perfectly natural to have traps enabled, yet still want to introduce an explicit infinity into your data. The trapping rules allow this to occur sensibly -- most manipulation of the introduced infinity doesn't cause additional traps. A representation for infinity that requires fp traps to be off is not workable. (I don't think anyone has proposed one of those yet). James |
From: Raymond T. <ray...@er...> - 2005-11-14 18:54:23
|
>>>>> "James" == James Y Knight <James> writes: James> On Nov 14, 2005, at 1:09 PM, Raymond Toy wrote: >> Seems to me that if you're playing with float infinities, you'd have >> overflow disabled, and, most-likely, divide-by-zero too. James> Not necessarily -- it's perfectly natural to have traps enabled, yet James> still want to introduce an explicit infinity into your data. The James> trapping rules allow this to occur sensibly -- most manipulation of James> the introduced infinity doesn't cause additional traps. A I think I understand what you're saying, but what does "most manipulation" mean here? Just loading/storing? I was assuming you'd use infinity as you would any other FP number and either it signals overflow when you do basic operations with it, or you mask the exception and continue to produce infinities (or underflows.) But this doesn't have much to do with the original question of representing infinity in a readable fashion.... Ray |
From: Nikodemus S. <nik...@ra...> - 2005-11-15 15:11:40
|
I'm following this, and share the sentiment of portability and potential issues with reader-extensions while also finding the LW syntax rather obscure at the first glance. I feel provisionally attracted to the styles such as +I^f0 -I^d0 as they clearly differentiate the object from a regular number. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Arthur L. <ale...@xs...> - 2005-11-15 16:10:37
|
Nikodemus Siivola wrote: > I'm following this, and share the sentiment of portability and potential > issues with reader-extensions while also finding the LW syntax rather > obscure at the first glance. > > I feel provisionally attracted to the styles such as > > +I^f0 > -I^d0 > > as they clearly differentiate the object from a regular number. I don't remember hearing any real objections against the LW syntax other than that it's 'ugly' or 'obscure'. If that's the only objection, I think the advantages of portability are more important than the disadvantage of the perceived uglyness. In my non-specialist view, NaNs are ugly no matter how you write them anyway ;-) As far as the current version of the INFIX library is concerned, I think that 1.0/0.0 would be parsed as (/ 1.0 0.0), +I^f0 would be parsed as (LOGXOR I F0) and 1e++0 would be parsed as (+ |1E| 0). So INFIX would have to be changed no matter which notation you choose. "When in doubt, follow either Lispworks or Franz" sounds like a reasonable rule of thumb to me... |
From: Nikodemus S. <nik...@ra...> - 2005-11-15 17:01:24
|
On Tue, 15 Nov 2005, Arthur Lemmens wrote: > "When in doubt, follow either Lispworks or Franz" sounds like a reasonable > rule of thumb to me... I see where the sentiment comes from, but I really don't agree with it. If there are no issues with an interface used by either, then it is as sounds as the more general "copy well-designed interfaces". However, unfortunately neither Franz nor Lispworks possess magic 8-ball that enables them to get it right every time, and blindly copying the interface you're not sure of is a good way to get hit by each and every near-miss. This is not to say that NIH is the way to go for its own sake, just a reminder on the importance of looking at interfaces critically even if it leads to temporary loss of portability. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |