strconv: FormatFloat returns value out of IEEE float64 range #18409
Comments
|
/cc @griesemer |
|
It's a denormalized number. It does lose precision eventually: https://play.golang.org/p/xqfMMXrXWc Working as expected. |
|
@tejasmanohar Please use the usual channels (not the issue tracker) for general Go questions in the future. Thanks. Regarding the -1 precision, the documentation is clear: "The special precision -1 uses the smallest number of digits necessary such that ParseFloat will return f exactly." ( https://golang.org/pkg/strconv/#FormatFloat ). And as you already cited Wikipedia, it says right there that the range allows even smaller values up to approx. 5 × 10^-324. The number you're using can still be represented because it's mantissa (2.33125) is apparently short enough to still fit. In short, the value is not out of float64 range. |
|
This makes sense. Sorry about that! I think Redshift's string parsing has a bug where it doesn't happen denormalized numbers (unless that's how it's suppoesd to work... we'll see). This is not a Go problem, sorry :) |
|
Came to this btw https://play.golang.org/p/NOOG49ag-E |
Please answer these questions before submitting your issue. Thanks!
https://play.golang.org/p/BsjbwEDp84
What version of Go are you using (
go version)?go version go1.7.4 darwin/amd64
(but this doesn't seem to be a new thing)
What operating system and processor architecture are you using (
go env)?GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
but can replicate in play.golang.org
What did you do?
https://play.golang.org/p/BsjbwEDp84
What did you expect to see?
I expected 2.33125e-315 to lose precision when stored as float64 by Go or at least when converted to string because it's more precise / closer to 0 than
1e-308.What did you see instead?
Go handled this number fine even though it was out of range.
I believe Go is using the "subnormal representation" mentioned here. If that's the case, is there a reliable way to convert to float64 string as precise as the standard representation can handle? I think using
-1as the precision measure is throwing Go off since it can handle more precise numbers than the IEEE standard (but I may totally be wrong-- I'm not that familiar/strong here).PS: If you're wondering how I came to this, I'm working on some ETL software, and the provided number
2.33125e-315does not work for Redshift's float8/double (8 bytes, 64 bits) type.The text was updated successfully, but these errors were encountered: