On dimanche 12 septembre 2021 17 h 08 min 56 s EDT Martin Storsj� wrote: > With your implementation, this prints: > > 0x0.8p-1022 > 0x1p-1022 > > However with glibc, this prints: > > 0x0.8p-1022 > 0x0p-1022 > > This looks wrong to me though, and I'd say your version is correct. > Surprisingly though, UCRT also prints the same here. As those probably > don't share the implementation, it would imply that there's some reason > for it (that I don't see).
Looks like a bug in glibc to me. I think I narrowed it down to where and what in their code but I don't know why it's coded that way. I don't think it's well tested, I don't think anybody ever use that particular case in real software. > On macOS, this case prints > > 0x1p-1023 > 0x1p-1023 > > which is another correct way of handling it (although different from how > glibc handles denormals). > > // Martin Looks like it's being normalized first. It is better, it lose less precision. I think glibc's implementation could be improved. It's rather messy, the file can't even maintain proper indentation. After looking at glibc's implementation, I also noticed that the rounding is affected by the rounding mode. Right now in mingw, it's only rounding to nearest. I don't know how it is on other platforms. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
