Il giorno lunedì 10 aprile 2017 16:53:31 UTC+2, brian....@robustperception.io ha scritto: > > Hi, > > I'm working on a feature for the Prometheus monitoring system that > requires adding special entries in our database. > Our values are float64, and I plan on taking advantage of the fact that > there's 2^52-1 valid bit representations for NaN. > So I'll choose one of those representations for an actual NaN (as we > support that), and others for the special entries I need. > > What I'd like to do is change the few bits of code that need to know about > the special values, and continue to use float64 types as-is elsewhere. > > I worry though that with the complexity of modern systems that depending > on the bit representation of a NaN not to change as a float64 is passed > around may not be wise. > Not having to change everything to [8]byte throughout the stack would be > handy, but I am willing to switch all the relevant code if needed. > > What I'm wondering is: > 1) Is it safe to presume Go itself won't change the bit representation of > a NaN? >
The representation of NaN is not decided by Go, but by the IEEE 754 standard. You can see some details in https://golang.org/src/math/bits.go https://en.wikipedia.org/wiki/NaN#Encoding Currently the NaN value as returned by math.NaN function is encoded as 0x7FF8000000000001. But you can use any other values, and compare them using the Float64bits function. 2) It is safe to presume FPUs won't change the bit representation of a NaN? > What do you plan to do with these "placeholder" values? If you just store them in memory and compare them, then, AFAIK, they will not be modified. > [...] Manlio -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
