> On Oct 20, 2016, at 2:59 PM, Joe Groff via swift-dev <swift-dev@swift.org> > wrote: >> >> copysign( ) is a reason to not pick the first option. I’m not very worried >> about it, but it is a reason. I see no problem with the second option. > > As we discussed in person this morning, de-canonicalizing b11 might be a > better compromise to minimize the potential impact of layout optimizations. > That would leave the implementation with 2^51 NaN representations (50 > significand bits, plus the sign bit) in Double to play with, which ought to > be enough for anyone™. I liked the idea of using the sign bit originally > since testing for NaNs and sign bits is something that can be easily done > using common FPU instructions without crossing domains, but as you noted, it > sounds like comparison and branching operations tend to do that anyway, so > masking and branching using integer operations shouldn't be too much of a > burden. Jordan's question of to what degree we consider different NaN > encodings to be distinct semantic values is still an interesting one, but if > we take only the b11 NaN payloads away, that should minimize the degree to > which the implementation needs to be considered as a constraint in having > that discussion.
To your original email, I agree this is an important problem to tackle, and that we should handle the inhabitant masking when the FP value is converted to optional. That said, I don’t understand the above. With the “b11” representation, what how is a "Double?" tested for “.None"? One advantage of using the signbit is that “is negative” comparisons are very cheap on risc systems, because you don’t have to materialize a large/weird immediate. -Chris
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
