Thread overview | ||||||
---|---|---|---|---|---|---|
|
October 01, 2016 Anyone relying on signaling NaNs? | ||||
---|---|---|---|---|
| ||||
Just tried to fix the float/double initialization w/ signaling NaNs [¹], but it seems we can't reliably do that for all backends/architectures. Any additional move of float might convert SNaNs to QNaNs (quiet NaNs). This has also been the finding of other people [²][³]. The biggest problem w/ the current situation is that float fields of a struct sometimes are initialized to QNaNs and fail `s.field is float.init`. We thought about giving up on SNaNs as default float init values. Is anyone relying on them? -Martin [¹]: [fix Issue 15316 - different NaN value in struct initializer](https://github.com/dlang/dmd/pull/6163#issuecomment-250929498) [²]: [Issue 9813 – Signalling NaN initialization does not always work correctly on x86](https://issues.dlang.org/show_bug.cgi?id=9813) [³]: [Coding Castles: NaNs, Uninitialized Variables, and C++](http://codingcastles.blogspot.de/2008/12/nans-in-c.html) |
October 01, 2016 Re: Anyone relying on signaling NaNs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Saturday, 1 October 2016 at 19:10:47 UTC, Martin Nowak wrote:
> Just tried to fix the float/double initialization w/ signaling NaNs [¹], but it seems we can't reliably do that for all backends/architectures. Any additional move of float might convert SNaNs to QNaNs (quiet NaNs). This has also been the finding of other people [²][³].
>
> [...]
Not Mir. Furthermore, default zero initialisation is better.
|
October 02, 2016 Re: Anyone relying on signaling NaNs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ilya Yaroshenko | On Saturday, 1 October 2016 at 19:35:54 UTC, Ilya Yaroshenko wrote:
> Not Mir. Furthermore, default zero initialisation is better.
Yes, initializing floats to a value that is useless, requiring additional setting before usage is a weird design, but such a big change is out of scope and you can provide the init value.
|
July 26, 2017 Re: Anyone relying on signaling NaNs? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Saturday, 1 October 2016 at 19:10:47 UTC, Martin Nowak wrote: > Just tried to fix the float/double initialization w/ signaling NaNs [¹], but it seems we can't reliably do that for all backends/architectures. Any additional move of float might convert SNaNs to QNaNs (quiet NaNs). This has also been the finding of other people [²][³]. > > The biggest problem w/ the current situation is that float fields of a struct sometimes are initialized to QNaNs and fail `s.field is float.init`. > > We thought about giving up on SNaNs as default float init values. Is anyone relying on them? I just had the same 'fun' with LDC. Both LDC 1.3 and DMD 2.074.0 produce special quiet NaNs for float.init and double.init on Win64 (both most significant mantissa bits set). I also tried to fix it, but it seems impossible when the x87 FPU (and not SSE) is used. This leads to a Win64 LDC build using signalling inits when cross-compiling via `-m32`, while the native Win32 LDC compiler uses quiet ones etc. So I'm all in for consistent special quiet NaNs as init values for all 3 floating-point types (already implemented, https://github.com/ldc-developers/ldc/pull/2207). If someone relies on signalling NaNs and missed the original post, here's your chance to speak up. |
Copyright © 1999-2021 by the D Language Foundation