On Apr 16, 2019, at 2:29 AM, Miki Tebeka <miki.teb...@gmail.com> wrote: >> >> On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote: >> On Apr 15, 2019, at 12:47 PM, Miki Tebeka <miki....@gmail.com> wrote: >> > >> > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: >> > >> > 1.1*1.1 and 1.21 are untyped constants and have much higher precision at >> > which they are not equal. >> > Does that mean that the Go compiler is using floats with more precision >> > than the runtime? >> >> Yes, but it's also worth remembering that in general, in computing, it's not >> a great idea to compare floats for absolute equality except for specific >> constants (e.g. +/- zero, +/- infinity, NaN). >> >> Is there an in-built intrinsic in Go for comparing floats within an epsilon, >> or does that have to be done manually? > > I came across this when teaching about floats not being exact, was surprised > to see the "true" :)
Yup! My personal perspective is that it's best to treat floating point numbers as "noisy", because you lose or add little bits to them with most operations in ways that are hard to control (this is one of the reasons IEEE floating point numbers have tightly-defined characteristics, because then at least the flaws are well-defined and you don't get e.g. diverging results in physics simulations on different machines because they round differently). Treat a floating point number as a noisy signal, always compare within ranges (often enough, even when comparing against zero, especially considering that there is also a *negative* zero in floats) and you won't go wrong. Well, not *very* wrong. Better yet, avoid use of floating point arithmetic where at all possible (but here I'm showing my personal biases). - Dave -- 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.
