HN is more and more like first semester coding class where the professor always tells the "fun facts" but we have to be in the same class every year
just let the lucky thousand of today have their fun!
0.1 and 0.2 Returns 0.30000000000000004 (2018)
91–100 of 161 posts
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#92Golly. Surprised by floating point arithmetic? 1.99999999.... == 2.0 There are limits to computer representation of floating point numbers. Computers are finite state, floating point numbers are not. sigh
> Computers are finite state, floating point numbers are not. No, floating point numbers are finite state. That’s the whole point behind this discussion. There are only so many possible floating point numbers representable in so many bits. I never understand this confusion - you have finite memory - with this you can only represent a finite set of real numbers. So of course all the real numbers can’t be mapped direct…
I understand the confusion. It occurs when people haven't fully grokked that floating point numbers generally use binary representation, and that the set of numbers that can be represented with a finite number of decimal digits is distinct from the set of numbers that can be represented with a finite number of binary digits. People generally know that they can't write down the decimal value of 1÷3 exactly - they just haven't considered that for the same reason you can't write down the binary value of 1÷10 exactly either.
This confusion is also helped along by the fact that the input and output of such numbers is generally still done in decimal, often rounded, that both decimal and binary can exactly represent the integers with a finite number of digits, and that the set of numbers exactly representable with in a finite decimal expansion is a superset of those exactly representable in a finite binary expansion (since 2 is a factor of 10).
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#93I use this as one of my interview questions (in a piece of code where it would run correctly if 0.1 + 0.2 = 0.3). Maybe 1/3 of interviewees recognize the cause, and maybe half of those can actually explain why and how to mitigate it. I work in scientific computing so it's absolutely relevant to my work
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#94One of the many reasons I think we all would've been better off, had Brendan Eich decided he'd been able to simply use Scheme within the crazy time constraint he'd been given, rather than create JavaScript, :) is that Scheme comes with a distinction between exact and inexact numbers, in its numerical tower:
https://en.wikipedia.org/wiki/Numerical_tower
One change I'd consider making to Scheme, and to most high-level general-purpose languages (that aren't specialized for number-crunching or systems programming), is to have the reader default to reading numeric literals as exact.
For example, the current behavior in Racket and Guile:
Welcome to Racket v7.3.
> (+ 0.1 0.2)
0.30000000000000004
> (+ #e0.1 #e0.2)
3/10
> (exact->inexact (+ #e0.1 #e0.2))
0.3
By default, that would give the programmer in this high-level language the expected behavior.
And systems programmers, people writing number-crunching code, would be able to add annotations when they want an imprecise float or an overflowable int.
(I'd also default to displaying exact fractional rational numbers using familiar decimal point conventions, not the fractional form in the example above.)
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#95Earlier quoted context omitted.
I think one of the problems today is that floating point remains the default even for scripting languages like python. I'd wager that the huge majority of users of floating point arithmetic in their programs actually want correct math rather than efficient operations. This feels a bit like Random vs SecureRandom. So many people use the default and then accidentally shoot themselves in the foot. IMO, for scripting lan…
This is not a trivial decision because rational numbers can have an unbounded denominator and it can cause a serious performance problem. Python explicitly ruled rational numbers out due to this issue [1]. There are multiple possible answers: - Keep rational numbers; you also have an unbounded integer so that's to be expected. (Well, unbounded integers are visible, while unbounded denominators are mostly invisble. Fo…
Sure, every solution has problems. If there was an obvious alternative with little downside I think we'd have adopted it decades ago.
I just suspect that alternatives bite people less frequently than floating point does.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#96One of the many reasons I think we all would've been better off, had Brendan Eich decided he'd been able to simply use Scheme within the crazy time constraint he'd been given, rather than create JavaScript, :) is that Scheme comes with a distinction between exact and inexact numbers, in its numerical tower: https://en.wikipedia.org/wiki/Numerical_tower One change I'd consider making to Scheme, and to most high-level…
Many languages make a distinction between floating-point numbers and fixed-point numbers. Fixed-point numbers (e.g.: "Decimal" / "BigDecimal" in Java) do not suffer from this problem.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#97If you think that is crazy, check out Muller's Recurrence: https://scipython.com/blog/mullers-recurrence/
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#98One of the many reasons I think we all would've been better off, had Brendan Eich decided he'd been able to simply use Scheme within the crazy time constraint he'd been given, rather than create JavaScript, :) is that Scheme comes with a distinction between exact and inexact numbers, in its numerical tower: https://en.wikipedia.org/wiki/Numerical_tower One change I'd consider making to Scheme, and to most high-level…
This would make particular sense in a language like python, which no one (should?) be using for systems programming.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#99Earlier quoted context omitted.
> Correct FP calculation requires error analysis No, it does not. Please, don't make it seem harder than it needs to. 99% applications, if you don't do anything stupid you are completely fine. If you care for precision so much the last digit make difference for you you are probably one of very few cases. I remember somebody giving an example circumference of solar system showing uncertainty of the value of Pi availab…
> 99% applications, if you don't do anything stupid you are completely fine. This is a common misconception. Or "anything stupid" is quite broader than you think. The main issue with FP arithmetic is that effectively every calculation incurs an error. You seem to aware of catastrophic cancellation, but it is problematic not because of the cancellation but because the error is proportional to the input, which can wild…
I work on financial risk calculations during day and embedded control devices after my official work hours.
My controller running moving horizon estimator to simulate thermal system of the espresso machine and Kalman filters to correct model parameters against measurements runs 50 times a second and works fine for days, thank you, using floats on STM32.
I have written huge amount of embedded software over past 20 years and I am yet to do any error analysis with focus on actual floating point inaccuracy. Never saw any reduced performance of any of my devices due to FP inaccuracy. That's because I know what kind of things can cause those artifacts and I just don't do that stupid shit.
What you describe are just no-noes you should not be doing in software.
There exists huge amount of software that works for years at a time, heavy in FP math, and it works completely fine.
If drones were not limited in flight time they would also work fine because what you describe is just stupid errors and not a necessity when using FP math.
Game simulations don't use FP mostly because it is expensive. Fixed point is still faster and you can approximate results of most calculations or use look up tables to get the result that is just fine.
Some games (notably Quake 1 on the source code which I worked after it became available) do require that the simulation results between client and server are in lockstep but this is in no way necessity. Requiring lockstep between client and server causes lag.
What newer games do, they allow client and server run simulations independently even when they don't agree exactly, and then reconcile the results from time to time.
If you ever saw your game partner "stutter" in flight, that was exactly what happened -- the client and the server coming to an agreement on what is actual reality and moving stuff into its right place.
In that light, there is absolutely no problem if after couple of frames the object differs from official position by 1 tenth of a pixel, it is going to get corrected soon.
Go do your "error analysis" if you feel so compelled, but don't be telling people this is necessary or the software isn't going to work. Because that's just stupid. Maybe NASA does this. You don't need to.
Re: 0.1 and 0.2 Returns 0.30000000000000004 (2018)
#100One of the many reasons I think we all would've been better off, had Brendan Eich decided he'd been able to simply use Scheme within the crazy time constraint he'd been given, rather than create JavaScript, :) is that Scheme comes with a distinction between exact and inexact numbers, in its numerical tower: https://en.wikipedia.org/wiki/Numerical_tower One change I'd consider making to Scheme, and to most high-level…
A Scheme system that implemented exact reals as unnormalized floating decimal (IEEE 754-2008), coupled with a directive that said `numbers with a decimal point should/should not be read as exact' would be wonderful, not just for financial things, but also for teaching students.