On 10 April 2017 at 17:38, Michael Jones <michael.jo...@gmail.com> wrote:

> 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.
>

Great, thanks for the information.


>
> 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.
>

At the level we care about it's all bit twiddling (e.g. XOR-based
compression), so this shouldn't affect us. It'll all be benchmarked anyway.

Yours,
Brian


>
> 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
>



-- 
Brian Brazil
www.robustperception.io

-- 
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.

Reply via email to