Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Floating Point Math

0.30000000000000004.com

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Floating Point Math

#21

Post by shultays »

lokedhs wrote: post #17
toxicFork wrote: post #6

Why don't we store fractions as fractions rather than floating point?

Common Lisp does by default. Calling (/ 1 3) gives 1/3 which is a rational. The individual components of a rational number are bignums, so the size of the fraction is only limited to available RAM. However, this is not enough in many cases. For example, how would you store pi? In the case of Lisp, pi is stored as a floating point number, and the conversion rules say that a mathematical operation between a rational an…

  how would you store pi?
same way we do now I guess? Approximate it. My vote is on 22 / 7

Re: Floating Point Math

#22

Post by nraynaud »

Do you have a good blog post on choosing tolerances and ranges? I just started at a company where it’s probably about now that we should get smart with that. We do geometry so the problem gets even worse.

Re: Floating Point Math

#23

Post by Kevcmk »

codebje wrote: post #20
svat wrote: post #15

A couple of thoughts I've always had about floating-point arithmetic: 1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, program…

> IMO it's unfortunate that most languages default to floating-point. Most beginning programmers would be better served … Most languages, most of the time, are not used by beginners.

Agree. But experts/intermediates often gloss over language semantics in pursuit if getting something done. For me, floating point by-default is more often a nuisance

Re: Floating Point Math

#24

Post by vardump »

lokedhs wrote: post #17
toxicFork wrote: post #6

Why don't we store fractions as fractions rather than floating point?

Common Lisp does by default. Calling (/ 1 3) gives 1/3 which is a rational. The individual components of a rational number are bignums, so the size of the fraction is only limited to available RAM. However, this is not enough in many cases. For example, how would you store pi? In the case of Lisp, pi is stored as a floating point number, and the conversion rules say that a mathematical operation between a rational an…

You could store pi as a symbol.

Of course, ultimately this is going to be a compromise and I understand the choice of not storing common constants that way. In the end you'd end up just replicating common mathematical notation and computing with that is not going to be fast.

Re: Floating Point Math

#25

Post by dx034 »

Such a shame that decimals don't get more attention. I program in Go a lot and they don't even have a fixed point number type built into the language. Floating point numbers always seems to be the default. And while there is support via third party packages, it makes everything harder to use, from communicating with databases to (de-)serializing data.

However, in reality most numbers I deal with can reasonably be assumed to have a maximum number of decimals and can be stored easily this way. I know way fewer examples where I'd need floating point precision than where I need a fixed number of decimals. But with poorer support I always fall back to using float.

Re: Floating Point Math

#26

Post by thethirdone »

codebje wrote: post #20
svat wrote: post #15

A couple of thoughts I've always had about floating-point arithmetic: 1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, program…

> IMO it's unfortunate that most languages default to floating-point. Most beginning programmers would be better served … Most languages, most of the time, are not used by beginners.

If you are using "beginner" to refer to the time spent, this is true.

However, if you use "beginner" to the knowledge gained, it might not be. If you only ever make webpages, even if you have made 100s you could still be a novice programmer because you never branched out enough to learn new programming concepts.

If a programming language makes it easy to do something moderately, but it is hard to do it well. Programmers who only know that language are likely to have a gap in their stills. Floating point (in most languages) is easy to gets the basics working, but are hard to do well and very hard to do perfectly. This leads to a lot of programmers not learning floating point well.

Re: Floating Point Math

#27

Post by kwhitefoot »

trinovantes wrote: post #18
svat wrote: post #15

A couple of thoughts I've always had about floating-point arithmetic: 1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, program…

If nothing else, I think compilers/linters should warn when trying to use equality/comparison operators between floats since most of the time it's mathematically wrong. All of my projects are filled with isApproxEquals(float1, float2)

That really depends on where the floats come from and how they have been manipulated. I have written quite a lot of code where comparing floats was perfectly sensible. I had to repeatedly revert changes by colleagues who didn't understand the code and had replaced A == B with something like isApproxEquals(A, B). This was in electrical design software where every millisecond counted.

Re: Floating Point Math

#28

Post by svat »

codebje wrote: post #20
svat wrote: post #15

A couple of thoughts I've always had about floating-point arithmetic: 1. IMO it's unfortunate that most languages default to floating-point. Most programmers, most of the time, would be better served by slightly slower but less confusing alternatives (it's nice that Raku uses rational numbers by default: similarly for integers, it's great that Python uses arbitrary-precision integers by default). At any rate, program…

> IMO it's unfortunate that most languages default to floating-point. Most beginning programmers would be better served … Most languages, most of the time, are not used by beginners.

Whether or not that's true, you can remove "beginning" from my statement as it's not necessary (done, just edited, thanks): most programmers, most of the time, don't need the speed of floating-point everywhere (compared to fixed-point/scaled integers, or rationals, or interval arithmetic, or whatever), and when they do, the language could let them easily opt into it with a declaration like "use float" or whatever.

Re: Floating Point Math

#29

Post by carnitine »

shultays wrote: post #21
lokedhs wrote: post #17

Earlier quoted context omitted.

Common Lisp does by default. Calling (/ 1 3) gives 1/3 which is a rational. The individual components of a rational number are bignums, so the size of the fraction is only limited to available RAM. However, this is not enough in many cases. For example, how would you store pi? In the case of Lisp, pi is stored as a floating point number, and the conversion rules say that a mathematical operation between a rational an…

how would you store pi? same way we do now I guess? Approximate it. My vote is on 22 / 7

That’a a terrible approximation. Also requires memorising about the same amount of information as just memorising the digits.

Re: Floating Point Math

#30

Post by adhesive_wombat »

kwhitefoot wrote: post #27
trinovantes wrote: post #18

Earlier quoted context omitted.

If nothing else, I think compilers/linters should warn when trying to use equality/comparison operators between floats since most of the time it's mathematically wrong. All of my projects are filled with isApproxEquals(float1, float2)

That really depends on where the floats come from and how they have been manipulated. I have written quite a lot of code where comparing floats was perfectly sensible. I had to repeatedly revert changes by colleagues who didn't understand the code and had replaced A == B with something like isApproxEquals(A, B). This was in electrical design software where every millisecond counted.

To be fair, float point equality is often a red flag and often deserves a double-take (even if the result is, yes, it's correct).

A comment like "exact equality is deliberate here and valid because XYX and important for meeting performance requirements ABC" would help, unless it's a major part of the system, in which case the colleague should know that already.

And on their part, a check in with you for "hey, I don't understand why this equality is valid" would be better than assuming it's wrong and changing it.

Post reply on HN