These "floating-point is weird" discussions tend to be unfair to the virtues of floating point. ;-)
The numbers in computers are NOT the numbers of mathematics. They do not have the same properties, promises, and definitions. So instead of shaking our fists at the computer when we're reminded of the difference, why not accept the difference and use what is provided? Acceptance #1: Floating point values are actually binary integers. While the "floating" aspect means scaling a range of integers over a wide range via a separate exponent, the mantissa part (the fraction) is still a binary integer interpreted as the numerator of a rational number, the denominator being 2^n where n varies of course between 32-bit and 64-bit floating point, with n=52 for the "double precision" 64-bit case. The n here determines the number of values that are expressible perfectly as scaled integers (2^52 of them). In particular, when expressing a floating point value the compiler and computer must find the closest power-of-two fraction to your number: 1.0/2.0 => 2^51 / 2^52, for example and this is an ideal representation. Unfortunately, a value like 1.0/3.0 (or 1.21 == 121/100 in the original question) is impossible to represent a n/d, d=2^k for any k. That is because 2^k is not divisible by 3 and neither is 2^k divisible by 121. We accept this about time. "I'll see you in a 7th of an hour" is a reasonable notion, but it is not expressible in seconds. It is more than 8 seconds, but less than 9 seconds.(t=8.5714285714... seconds) Now if we agree to pretend that this floating point value is the time we mean, it will all work out, unless someone peeks under the hood at the details by asking "why is 7-1/t not equal to zero but instead 3.469446952E-18?" ;-) When they do, it's ok. It just means that we're all observing the measure of the distance between the desired value and the nearest fraction with 2^52 as the denominator. it is all ok. Just remember they're not the numbers of algebra. On Tue, Apr 16, 2019 at 6:40 AM David Riley <fraveyd...@gmail.com> wrote: > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
