> On Oct 20, 2016, at 10:04, Joe Groff <jgr...@apple.com> wrote: > > >> On Oct 20, 2016, at 9:42 AM, Jordan Rose <jordan_r...@apple.com> wrote: >> >> Some disconnected thoughts: >> >> - “Does not interpret” does not mean “does not preserve”. The very next >> sentence in the standard is "Note, however, that operations on bit >> strings—copy, negate, abs, copySign—specify the sign bit of a NaN result, >> sometimes based upon the sign bit of a NaN operand." >> >> - If we were to claim a class of NaNs, I would pick signalling NaNs rather >> than positive or negative ones. AFAIK most NaN-embedding tricks avoid >> signalling NaNs because they can, well, signal, even though (again AFAIK) >> most modern systems don’t bother. > > Claiming sNaNs would be unfortunate since "signaling" is about the only > semantically distinct bit NaNs normally have, and I think we should minimize > interference with users who are taking advantage of signaling or NaN payloads > for their own means. (OTOH, on some platforms like x87 it's already > practically impossible to preserve the signaling bit, since even loads will > immediately raise the exception and quiet the NaN, and there would be some > nice safety benefits to getting a trap early if a Float? is bitcast to a > Float without being formally checked first.)
Right, that’s sort of my point. If you’re using NaN payloads for non-float-related information, you shouldn’t be using the bit that’s part of the floating-point standard. But I could also see plenty of people saying “we’re not going to waste a whole bit” and not bothering to distinguish it from the rest. At the same time, I can certainly see people saying “hey, an extra bit” about the sign bit. If you’re using NaN payloads, you probably are going to check for that before performing any operations on the NaN, rather than relying on nil-swallowing NaN-propagation doing what your program requires. >> >> - I don’t feel like we have a coherent story here. We know that APIs taking >> “Double” or “Float” can represent any bit pattern. The last plan I heard for >> floating-point comparison treats NaNs as unordered relative to one another, >> even in a total order comparison. (I maintain that this is unsound.) And >> this proposal would treat some or all NaNs as invalid. I feel like we need >> to pick one approach here. > > I'm not saying that they'd be invalid, only that the language doesn't > guarantee to preserve these representations exactly. That seems orthogonal to > the comparison issue—whatever rule we come up with for float ordering, all > NaNs ought to be treated uniformly by that rule. I don’t think I agree with either of those sentences. I’d really like the story to be either “we treat different NaN bit strings as distinct” or “there are no meaningful distinctions between NaNs in Swift (except maybe sNaN vs. qNaN); if you want anything more you need to use Int as your storage type”. Each of those has natural consequences for me concerning both extra inhabitants and total ordering. Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
