floating-point-bytes->real and real->floating-point-bytes are not inverses for all inputs

[tonyg]

What version of Racket are you using?
v8.5.0.2 [cs]

What program did you run?

(define input (bytes #x7f #x80 #x01 #x01))
(equal? input (real->floating-point-bytes (floating-point-bytes->real input #t 0 4) 4 #t))

What should have happened?
It should have answered #t, but it answered #f, because real->floating-point-bytes yielded (bytes #x7f #xc0 #x01 #x01).

Please include any other relevant details
x86_64 Debian linux.

[tonyg]

Surprisingly, the analogous case for 64-bit floats doesn't cause a problem:

(define input (bytes #x7f #xf0 #x00 #x00 #x00 #x00 #x01 #x01))
(equal? input (real->floating-point-bytes (floating-point-bytes->real input #t 0 8) 8 #t))

[mflatt]

I imagine that converting a 32-bit NaN to a 64-bit NaN and back is where things are changing in the original example. Offhand, I have no ideas what guarantees to expect there.

[tonyg]

The payload bits are being preserved; it's just the signalling/quiet bit that isn't. I could be mistaken but I suspect it can and should be preserved too.

[mflatt]

From what I can find so far, forcing to quiet appears to be common at machine and language levels:

https://stackoverflow.com/questions/71774007/nan-conversion-from-float-to-double-changes-its-underlying-data

golang/go#36399

WebAssembly/wabt#1925

[tonyg]

OK! Floats are weird :-) I'll try to work around the issue in my own code. (I am attempting to write a codec that preserves all detail of single and double precision floats.) Is there anything useful we could add to the documentation here? Maybe a generic "watch out for NaNs, we can't guarantee that all detail of NaNs are preserved for every word size for every architecture"?

[tonyg]

For reference, here's what I'm doing to preserve the necessary bits: https://gitlab.com/preserves/preserves/-/blob/351feba8d25e6c09a77118aea0a0ab0c68e7be98/implementations/racket/preserves/preserves/float-bytes.rkt

[gus-massa]

I thought that in Racket all the NaNs were collapsed to a single value (or to be more precise two nan.f and nan.s), but IIUC I'm wrong. Luckily, it's one assumption I ignored in my code and also in the optimizations I wrote for Racket.

@mflatt: What happens if you use the ffi to create a strange-nan? Does Racket normalize it when it enters Racket? Does it make Racket crash or get a weird result? (for example (nan? strange-nan) or (rational? strange-nan)) Is it preserved in calculation? If you calculate (+ strange-nan 0.0) or (+ strange-nan 1.0) the result is strange-nan or just nan?

I think it would be a good idea to add a warning in the docs of floating-point-bytes->real.

[mflatt]

The nan? procedure at the Chez Scheme level recognizes all NaN patterns. Arithmetic and conversions generally let through whatever the processor does. When a 64-bit double comes from a foreign library, it will keep its bit pattern, because that's what machine-level loads and stores do. When a 32-bit float comes from a foreign library, the conversion to a flonum will (as I've learned from this thread) change from a signalling to a quiet NaN.