3 ms·
> That Go uses arbitrary-precision for constant expressions seems dangerous to me. I'm somewhat baffled by this statement. If a Go program compared a constant
by Cyphus 3y ago
> That Go uses arbitrary-precision for constant expressions seems dangerous to me.
I'm somewhat baffled by this statement. If a Go program compared a constant expression float against a runtime computed float, it could have unexpected results, but comparing floats in general is dangerous. I don't see how this language quirk increases that danger in a meaningful way.
- zamadatix 3y agoIt's not an issue an issue about whether or not efficient float formats are dangerous to work with rather one of whether they are consistent to work with in a language. It's simple enough to remember when reading about it but will you and everyone else know this from the start and remember it every time it comes up without fail? That said, for the negatives it comes with it does come with positives as well and I think that makes it worth it.
- LeifCarrotson 3y agoIt's one thing if a language outputs one, two, or zero for this expression. Two and zero are mathematically wrong, but at least they're predictable. It's another thing if a language sometimes outputs two and sometimes outputs one depending on the syntax of the request. This is reasonable where that syntax change is not an explicit cast to double precision or single precision, but dangerous if it uses a behind-the-scenes default of arbitrary precision in compiled literals and a default of FP32 in implicitly typed literal assignments.
- ridiculous_fish 3y agoOne unexpected consequence is the behavior around negative zero. For example: var d = -0.0 is different than var d = 0.0 d = -d This IMO crosses the line into "outright bug" territory. https://play.golang.com/p/X-JR9NdiCIC https://play.golang.com/p/X-JR9NdiCIC