Re: automatic NaN propogation detection?
On Saturday, 25 September 2021 at 08:18:49 UTC, Elronnd wrote: (Not saying @live isn't useless, just that this doesn't indicate that.) Must we continue hurting Walter's feelings :(
Re: automatic NaN propogation detection?
On Saturday, 25 September 2021 at 07:53:11 UTC, Chris Katko wrote: Is that some sort of "NP complete" can't-fix issue or something? The general case is obviously unsolvable. Trivial proof: float x = nan; if (undecidable) use x. I'm sure your imagination can supply more realistic cases (but I promise they really do come up!) However that doesn't mean we can't do flow analysis conservatively. Similar caveats apply to @live, but that does not mean it is useless. (Not saying @live isn't useless, just that this doesn't indicate that.) The bigger problem is that it really is hard to tell if you 'meant' to use a nan somewhere or not. And if you tried to apply such a semantic analysis pass to existing code, you would find it riddled with false positives, where a float was default-initialized to nan and the compiler was unable to convince itself the variable was overridden before being used in all paths.
automatic NaN propogation detection?
Is there any automatic compiler-based or library methods for detecting NaNs? I mean, if the compiler is outputting code that it knows is going to be set in memory to NaN, why isn't it giving me at least a compiler warning? Is that some sort of "NP complete" can't-fix issue or something? I mean, I can pass NaN to std.math.round() and it doesn't fire off an exception or anything. It compiles fine even though it's impossible-as-compiled to be correct. (Unless my absurd intention was to find the rounded value of NaN.) Instead, I'm stuck finding out where the NaN started, from a trail of destruction of values destroyed by NaN propogation. Why not stop it at its source? Even dscanner won't flag this code! ```d import std.stdio; import std.math; int main() { float x; writeln(x); writeln(round(x)); return 0; } ```