On Wed, Jun 6, 2012 at 8:49 PM, John Cowan <[email protected]> wrote:
> Emmanuel Medernach scripsit: > > > Here is a WG2 proposal for a "NaN dissecting" library: > > http://trac.sacrideo.us/wg/wiki/NanMedernach > > Thanks for working on this. > > Thanks for your comments and for doing so much work ! About your comments: > I think the payload should be constrained to be an exact > non-negative integer interpreted as a sequence of bits. In IEEE > formats, the sign bit is part of the payload, and should be > extractable separately from the payload using nan-negative? or some > such predicate. In addition, the sense of the signaling/quiet bit is > implementation-dependent (it is always the highest-order bit of the > mantissa, but whether 1 is signaling or quiet depends on the > hardware), and so nan-signaling? should also be added. IMHO this is restrictive, having payload to be an exact non-negative integer (or a sequence of bits) precludes using it to store symbols if one (future) implementation wish to do so. > In addition, the requirement that read invoke nan seems pointless to > me. If read returns any old NaN, that should be good enough. Yes, one implementation may decide to always return the same old NaN. My point is that (nan) and +nan.0 should have the same behaviour: if an implementation decides that (nan) returns a new NaN at each invocation then also should +nan.0. Providing that, I agree to remove the requirement that the reader have to invoke (nan). Best, -- Emmanuel
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
