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

0.30000000000000004

0.30000000000000004.com

Post reply on HN
Print view View original

21–30 of 422 posts

Re: 0.30000000000000004

#21

Post by miketuritzin »

_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

Reminds me of this Inigo Quilez article on experimenting with rendering using rational numbers: https://iquilezles.org/www/articles/floatingbar/floatingbar....

Re: 0.30000000000000004

#22

Post by knome »

goosehonk wrote: post #9

When did RFC1035 get thrown under the bus? According to it, with respect to domain name labels, "They must start with a letter" (2.3.1).

The same document defines `in-addr.arpa` domains that have numeric labels.

The mandate of a starting letter was for backwards compatibility, and mentions it in light of keeping names compatible with email servers and HOSTS files it was replacing.

Taking a numeric label risks incompatibility with antiquated systems, but I doubt it will effect any modern browser.

Re: 0.30000000000000004

#23

Post by gus_massa »

mc3 wrote: post #2

This is a good thing to be aware of. Also the "field" of floating point numbers is not commutative†, (can run on JS console:) x=0;for (let i=0; i --> 1.000000000000001 x=1;for (let i=0; i --> 1 Although most of the time a+b===b+a can be relied on. And for most of the stuff we do on the web it's fine!†† † edit: Please s/commutative/associative/, thanks for the comments below. †† edit: that's wrong! Replace with (a+b)+…

Note that the addition is commutative [1], i.e. a+b==b+a always.

What is failing is associativity, i.e. (a+b)+c==a+(b+c)

For example

(.0000000000000001 + .0000000000000001 ) + 1.0

--> 1.0000000000000002

.0000000000000001 + (.0000000000000001 + 1.0)

--> 1.0

In your example, you are mixing both properties,

(.0000000000000001 + .0000000000000001) + 1.0

--> 1.0000000000000002

(1.0 + .0000000000000001) + .0000000000000001

--> 1.0

but the difference is caused by the lack of associativity, not by the lack of commutativity.

[1] Perhaps you must exclude -0.0. I think it is commutative even with -0.0, but I'm never 100% sure.

Re: 0.30000000000000004

#24

Post by gowld »

_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

"Why don't we just" because it's harder than one thinks.

https://en.m.wikipedia.org/wiki/Arbitrary-precision_arithmet...

and gets harder when you want exact irrationals too https://www.google.com/search?q=exact+real+arithmetic

Re: 0.30000000000000004

#25

Post by maxdamantus »

Ididntdothis wrote: post #6

I still remember when I encountered this and nobody else in the office knew about it either. We speculated about broken CPUs and compilers until somebody found a newsgroup post that explained everything. Makes me wonder why we haven't switched to a better floating point model in the last decades. It will probably be slower but a lot of problems could be avoided.

Unless you have a floating point model that supports arbitrary bases, you're always going to have the issue. Binary floats are unable to represent 1/10 just as decimal floats are unable to represent 1/3.

And in case anyone's wondering about handling it by representing the repeating digits instead, here's the decimal representation of 1/12345 using repeating digits:

  0.0[0008100445524503847711624139327663021466180639935196435803969218307006885378
  69582827055488051842851356824625354394491697043337383556095585257189145402997164
  84406642365330093155123531794248683677602268124746861077359254759011745646010530
  57918185500202511138112596192790603483191575536654515998379910895099230457675172
  13446739570676387201296071283920615633859862292426083434588902389631429728635074
  92912110166059133252328878088294856217091940056703118671526933981368975293641150
  26326447954637505062778452814904819765087079789388416362899959497772377480761441
  87930336168489266909680032401782098015390846496557310652085864722559740785743215
  87687322802754151478331308221952207371405427298501417577966788173349534224382341
  02875658161198865937626569461320372620494127176994734710409072498987444309437019
  03604698258404212231672742]

Re: 0.30000000000000004

#26

Post by teraflop »

mc3 wrote: post #2

This is a good thing to be aware of. Also the "field" of floating point numbers is not commutative†, (can run on JS console:) x=0;for (let i=0; i --> 1.000000000000001 x=1;for (let i=0; i --> 1 Although most of the time a+b===b+a can be relied on. And for most of the stuff we do on the web it's fine!†† † edit: Please s/commutative/associative/, thanks for the comments below. †† edit: that's wrong! Replace with (a+b)+…

Your example shows that floating-point addition isn't associative, not that it isn't commutative.

Re: 0.30000000000000004

#27

Post by acqq »

Ididntdothis wrote: post #6

I still remember when I encountered this and nobody else in the office knew about it either. We speculated about broken CPUs and compilers until somebody found a newsgroup post that explained everything. Makes me wonder why we haven't switched to a better floating point model in the last decades. It will probably be slower but a lot of problems could be avoided.

Decimal floating point is standardized since 2008:

https://en.wikipedia.org/wiki/Decimal_floating_point#IEEE_75...

But it's still not much used. E.g. for C++ it was proposed in 2012 for the first time

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n340...

then revised in 2014:

http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.ht...

...and... silence?

https://www.reddit.com/r/cpp/comments/8d59mr/any_update_on_t...

Re: 0.30000000000000004

#28

Post by kstrauser »

thaumasiotes wrote: post #13
kstrauser wrote: post #5

Earlier quoted context omitted.

Yep. The TL;DR of a numerical analysis class I took is that if you're going to sum a list of floats, sort it by increasing numeric value first so that the tiny values aren't rounded to zero every time.

Really? It wasn't to use Kahan summation? https://en.wikipedia.org/wiki/Kahan_summation_algorithm

Hah! Well, yeah, that too. But if there's a gun to your head, sorting the list before adding will get you most of the way there with the least amount of work.

Re: 0.30000000000000004

#30

Post by amelius »

gowld wrote: post #24
_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

"Why don't we just" because it's harder than one thinks. https://en.m.wikipedia.org/wiki/Arbitrary-precision_arithmet... and gets harder when you want exact irrationals too https://www.google.com/search?q=exact+real+arithmetic

Also, it's a lot less efficient, so it should only be used if absolutely necessary.
Post reply on HN