It is not crazy in any way to use the special NaN payload--it was designed just for you. Dr. Kahan and others provided the broad set of NaNs in '754 for just this purpose, for example, to encode missing data values and N/A data values separately for statistical processing, or to allow great freedom to encode provenance or intent in the lower bits.
One reservation is that FP operations with quiet NaNs and signalling NaNs are not inherently full speed, so benchmark to make sure you are satisfied about performance in your specific context. On Mon, Apr 10, 2017 at 7:27 AM, <brian.bra...@robustperception.io> wrote: > 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? > 2) It is safe to presume FPUs won't change the bit representation of a NaN? > 3) If 1) and not 2), is there a way control/know when a float64 could have > ended up in a FPU? At the level where it matters, we're almost entirely > doing bit manipulation rather than floating point operations. > > As this is a mildly crazy idea, I've unfortunately not been able to find > any documentation indicating one way or other. > > Thanks, > Brian > > -- > 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. > -- Michael T. Jones michael.jo...@gmail.com -- 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.
