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

41–50 of 67 posts

Re: Floating Point Math

#41

Post by [deleted] »

ketzu wrote: post #38
codebje wrote: post #36

Earlier quoted context omitted.

Every option here has tradeoffs and drawbacks: fixed point arithmetic suffers from a very limited precision range, rationals aren't even the same number set, cauchy sequences are precise but comparatively very slow… there's no one size fits all solution that's right in every circumstance. Except, of course, at lower levels of abstraction - where IEEE floats are what the hardware implements. Lower level languages use…

> rationals aren't even the same number set In what way are rationals not the same number set? In the strictest sense basically none of the proposed versions have the same number set, but in a broad sense, they all represent a useful subset of rationals, right?

[deleted]

Re: Floating Point Math

#42

Post by codebje »

ketzu wrote: post #38
codebje wrote: post #36

Earlier quoted context omitted.

Every option here has tradeoffs and drawbacks: fixed point arithmetic suffers from a very limited precision range, rationals aren't even the same number set, cauchy sequences are precise but comparatively very slow… there's no one size fits all solution that's right in every circumstance. Except, of course, at lower levels of abstraction - where IEEE floats are what the hardware implements. Lower level languages use…

> rationals aren't even the same number set In what way are rationals not the same number set? In the strictest sense basically none of the proposed versions have the same number set, but in a broad sense, they all represent a useful subset of rationals, right?

In a broad sense, sure.

Re: Floating Point Math

#43

Post by codebje »

thethirdone wrote: post #26
codebje wrote: post #20

Earlier quoted context omitted.

> 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. Programm…

General purpose programming languages are complex tools.

In this specific case representing non-integer numbers effectively on a binary device is complex. If you use a different representation than IEEE floats you just give a different set of corner cases and unexpected outcomes.

Don't let a novice build software you need to be correct without supervision, and if you are a novice expect to make mistakes, just like if I were to build a website I wouldn't expect my style choices to render appropriately on a wide range of devices... that's complex too!

Re: Floating Point Math

#44

Post by ketzu »

codebje wrote: post #42
ketzu wrote: post #38

Earlier quoted context omitted.

> rationals aren't even the same number set In what way are rationals not the same number set? In the strictest sense basically none of the proposed versions have the same number set, but in a broad sense, they all represent a useful subset of rationals, right?

In a broad sense, sure.

Could you elaborate what your intended meaning was? It felt to me like you were singeling out 'rationals' as not being the same number set. Maybe we also think of something different when talking about 'rationals'?

Maybe I also missed something obvious, so I'd like to satisfy my curiosity!

Re: Floating Point Math

#45

Post by lizmat »

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…

Thank you for your mention of the Raku Programming Language.

If you want to force usage of floating point arithmetic, you will have to indicate that in literal values. E.g. `0.1` would be a [Rat](https://docs.raku.org/type/Rat) (Rational number), and `0.1e0` would be a [Num](https://docs.raku.org/type/Num) (aka a floating point".

In Raku, to get the nearest representation, use the [.narrow](https://docs.raku.org/routine/narrow) method. So `42e0.narrow`, `42.0.narrow` and `42+0i.narrow` would all be an `Int`. Yes, Raku has complex numbers built in as well :-)

Re: Floating Point Math

#46

Post by codebje »

ketzu wrote: post #44
codebje wrote: post #42

Earlier quoted context omitted.

In a broad sense, sure.

Could you elaborate what your intended meaning was? It felt to me like you were singeling out 'rationals' as not being the same number set. Maybe we also think of something different when talking about 'rationals'? Maybe I also missed something obvious, so I'd like to satisfy my curiosity!

I meant that rationals are a subset of the reals, and while floats are also a subset of exact reals a "typical" fixed bitwidth implementation will have a significantly greater range in floats than rationals.

I don't know that it's necessarily as significant a difference as I'd first considered it to be, though.

Re: Floating Point Math

#47

Post by franga2000 »

> Your language isn’t broken, it’s doing floating point math.

Hard disagree right from the start - if your language is doing floating point math by default (as in, if numeric literals and basic operators use floating point in the absence of explicit type annotations or tags), your language is broken. Maybe if it's hyper-targeted towards graphics or ML or some other field where floating point errors don't matter and performance is king, then I'd call it fine, but users of such languages probably aren't reading this page.

Now, I get what the author is saying - there isn't a bug in your interpreter, it's how it's designed. But that means it's broken by design.

Re: Floating Point Math

#48

Post by 7x11x13 »

Someone wrote: post #33
7x11x13 wrote: post #8

Earlier quoted context omitted.

> it can only express fractions that use a prime factor of the base. IMO it could do better to explain why this is the case rather than state it as a fact, as it’s not immediately obviously true (at least to me). A terminating decimal is equivalent to a fraction with a denominator that is a power of 10. Any fraction with a denominator that is a product of prime factors of 10 can be turned into a fraction with a denom…

That’s not a very good explanation. That second sentence > Any fraction with a denominator that is a product of prime factors of 10 can be turned into a fraction with a denominator that is a power of 10. isn’t sufficient. You also have to argue that any fraction with a denominator that is not a product of the prime factors of 10 cannot be written as a finite decimal. If you do that you end up with a tautology. A bett…

You're right, my explanation was invalid.

Re: Floating Point Math

#49

Post by franga2000 »

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.

That doesn't really matter. Even if you had 20 years of experience in C++ or whatever, you could confidently write JavaScript code with floating point bugs in it, because "the type is called Number, obviously that isn't floating point". Beginner programmers might actually realise this sooner, since veterans aren't going to be writing console.log(0.3+0.2) as part of learning the language.

Re: Floating Point Math

#50

Post by dx034 »

xigoi wrote: post #32
dx034 wrote: post #25

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 ass…

In what context couldn't you just use an integer?

You can multiply and use integers but it's a bit ugly. Especially if you work across systems, you'll always need to store notations on the multiplier used. Having a decimal as a built in type with that information stored would be much easier.

But in the end I tend to use that for most numbers, especially as compression in time series also often better works on integers than floats if you have gradual changes in the numbers.

Post reply on HN