Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 302 303 304 305 306 307 308 309 310 311 312 .. 5022
— 502,152 events total
2020-09-29 18:36:50 <zincy_> I thought not but now I am reading stuff which questions this
2020-09-29 18:37:09 → geekosaur joins (42d52102@66.213.33.2)
2020-09-29 18:37:13 → mu_ joins (~mu@unaffiliated/mu)
2020-09-29 18:38:06 <koz_> zincy_: As someone having to deal with the fallout of this: no, you should never, under any circumstances, ever.
2020-09-29 18:38:22 <zincy_> haha
2020-09-29 18:38:30 <monochrom> "should" is ambiguous. For example, more socially acceptable? Technically better? More moral?
2020-09-29 18:38:31 <zincy_> I am trying to question my understanding of this ... so here goes
2020-09-29 18:38:44 <koz_> You have _no idea_ what kind of absurd contortions I have been putting codebases through for several months to get around this _horrific_ decision.
2020-09-29 18:38:53 <monochrom> For example, to be more socially acceptable among bankers, use fixed point, it's what they do.
2020-09-29 18:38:59 <koz_> (made a long time by someone who isn't me)
2020-09-29 18:39:05 <monochrom> in fact use decimal fixed point.
2020-09-29 18:39:40 × murphy_ quits (~murphy_@2604:2000:1281:8a9e:14d4:9618:a1b2:ef6b) (Remote host closed the connection)
2020-09-29 18:39:40 <monochrom> But binary is technically better than decimal in terms of minimizing errors, as shown by Knuth.
2020-09-29 18:39:49 <zincy_> You cannot use floating point to accurately store monetary values because expansions of rational numbers that are recurring cannot be stored within a finite amount of memory
2020-09-29 18:39:57 → murphy_ joins (~murphy_@2604:2000:1281:8a9e:d2e4:da3f:de8a:c9c9)
2020-09-29 18:40:11 <zincy_> Is that right?
2020-09-29 18:40:43 <koz_> zincy_: That isn't even the _tenth_ reason.
2020-09-29 18:40:46 <zincy_> monochrom: What does better mean in terms of error distribution?
2020-09-29 18:40:54 <monochrom> Yes, rational numbers is even better than binary floating point, technically.
2020-09-29 18:40:57 <koz_> Firstly, there are some integer values that cannot be represented as floats as such.
2020-09-29 18:41:12 <monochrom> smaller errors if you have to round
2020-09-29 18:41:20 <koz_> Secondly, you cannot guarantee (for example) associativity of addition where floats are involved.
2020-09-29 18:41:40 <monochrom> As for distribution, round to even is better than "round up when half". As shown by Knuth, same paper.
2020-09-29 18:42:01 <koz_> (I'm not even mentioning the fact that some _non_-integer values cannot be represented)
2020-09-29 18:42:15 <koz_> The fact that you truncate recurring decimals is a drop in the goddamned ocean.
2020-09-29 18:42:16 <monochrom> However, rational number is even less socially acceptable than binary floating point.
2020-09-29 18:42:22 → shatriff joins (~vitaliish@176.52.219.10)
2020-09-29 18:42:42 <zincy_> Yes rational numbers are seen as idealistic
2020-09-29 18:43:14 <zincy_> Im not comfortable with how changing the base results in less errors
2020-09-29 18:43:31 <monochrom> Bankers have made the decision of decimal fixed point, and have built very anal rounding rules around it. If you use rational numbers, you stand to be more correct than them, but that also means from their POV you're wrong.
2020-09-29 18:43:34 <zincy_> What are examples of values that cannot be represented
2020-09-29 18:43:41 <tomsmeding> zincy_: 1/10
2020-09-29 18:43:52 <monochrom> This is the very reason Intel floating point has BCD.
2020-09-29 18:43:59 <tomsmeding> > sum (replicate 10 0.1)
2020-09-29 18:44:01 × elliott_ quits (~elliott_@pool-100-36-54-163.washdc.fios.verizon.net) (Ping timeout: 264 seconds)
2020-09-29 18:44:02 <lambdabot> 0.9999999999999999
2020-09-29 18:44:09 <monochrom> Note: BCD is still floating point, just decimal.
2020-09-29 18:44:18 <dolio> I mean, that's the real reason. If you want your program to be used for anything, you need to comply with all the rules.
2020-09-29 18:44:26 <dolio> And you, some random tech dude, aren't going to change the rules.
2020-09-29 18:44:46 → elliott_ joins (~elliott_@pool-100-36-54-163.washdc.fios.verizon.net)
2020-09-29 18:44:47 <monochrom> Hell, Knuth is not random, and still can't change the rules.
2020-09-29 18:45:13 <zincy_> Why can't you just represent 1/10 as 10^-1 ?
2020-09-29 18:45:21 <zincy_> Isnt floating point essentially scientific notation
2020-09-29 18:45:23 <tomsmeding> zincy_: then you're using base 10 :)
2020-09-29 18:45:42 <monochrom> 1/3 can be represented in floating point if base 3.
2020-09-29 18:45:43 <zincy_> So is floating point generally base 2
2020-09-29 18:45:54 <tomsmeding> IEEE floating points use base 2, which means all numbers are represented as <integer> * 2^<integer>
2020-09-29 18:45:55 <geekosaur> yes
2020-09-29 18:46:07 <tomsmeding> not just generally; most programmers will answer you "always"
2020-09-29 18:46:20 <tomsmeding> for the normal definition of the term "floating point", which is IEEE floating points
2020-09-29 18:46:21 <dolio> You can define floating point for any base, but the ones implemented in hardware are base 2.
2020-09-29 18:46:32 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-09-29 18:46:33 <monochrom> OK you need to read this: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
2020-09-29 18:46:39 × mu_ quits (~mu@unaffiliated/mu) (Read error: Connection reset by peer)
2020-09-29 18:46:47 <tomsmeding> long though
2020-09-29 18:47:09 → mu_ joins (~mu@unaffiliated/mu)
2020-09-29 18:47:17 <monochrom> long compared to what? compared to replicating the same length in #haskell?
2020-09-29 18:47:21 <tomsmeding> :D
2020-09-29 18:47:22 × whiteline_ quits (~whiteline@unaffiliated/whiteline) (Remote host closed the connection)
2020-09-29 18:47:47 → whiteline_ joins (~whiteline@unaffiliated/whiteline)
2020-09-29 18:47:51 <zincy_> Understanding the limitations of floating point actually goes quite deep
2020-09-29 18:48:03 <monochrom> Seriously by the time one asks "why is 1/10 not representable" it's time to actually learn it.
2020-09-29 18:48:32 <monochrom> Or else, finish the 2nd year "computer organization" course in the standard CS curriculum.
2020-09-29 18:48:59 <zincy_> Yeah i Have done zero architecture or low level stuff
2020-09-29 18:49:34 <Noughtmare[m]> It is also very important for geometric algorithms and numeric analysis.
2020-09-29 18:50:01 <zincy_> I guess I should do that computer organization course
2020-09-29 18:50:03 <geekosaur> you have reached the point here you need to know it and its limitations and how to work around them
2020-09-29 18:50:09 <geekosaur> *where you
2020-09-29 18:50:19 <zincy_> Yeah
2020-09-29 18:50:42 <zincy_> I am past the point where I can just memorise the answer without understanding why
2020-09-29 18:51:08 <zincy_> That is get away with it rather than *should*
2020-09-29 18:51:11 <ski> @where floating-point
2020-09-29 18:51:11 <lambdabot> "What Every Programmer Should Know About Floating-Point Arithmetic" at <http://floating-point-gui.de/> and "What Every Computer Scientist Should Know About Floating-Point Arithmetic" by David
2020-09-29 18:51:11 <lambdabot> Goldberg in 1991 at <http://docs.sun.com/source/806-3568/ncg_goldberg.html> and <http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.244>
2020-09-29 18:51:38 × knupfer quits (~Thunderbi@200116b82c08f6003db34c53b593aaa2.dip.versatel-1u1.de) (Quit: knupfer)
2020-09-29 18:52:56 <zincy_> Thanks I have some reading to do :)
2020-09-29 18:53:06 → Ariakenom__ joins (~Ariakenom@h-178-174-193-185.NA.cust.bahnhof.se)
2020-09-29 18:54:07 → hiroaki joins (~hiroaki@2a02:908:4b18:e20::a362)
2020-09-29 18:55:39 → thir joins (~thir@p200300f27f0fc60094e773283d7bf825.dip0.t-ipconnect.de)
2020-09-29 18:55:51 × voyons_osti quits (~dan@107-190-41-58.cpe.teksavvy.com) (Read error: Connection reset by peer)
2020-09-29 18:56:29 → Ariakenom joins (~Ariakenom@h-82-196-111-138.NA.cust.bahnhof.se)
2020-09-29 18:56:36 → voyons_osti joins (~dan@107-190-41-58.cpe.teksavvy.com)
2020-09-29 18:56:37 × mu_ quits (~mu@unaffiliated/mu) (Read error: Connection reset by peer)
2020-09-29 18:56:52 × Ariakenom_ quits (~Ariakenom@h-98-128-229-8.NA.cust.bahnhof.se) (Ping timeout: 256 seconds)
2020-09-29 18:57:07 → mu_ joins (~mu@unaffiliated/mu)
2020-09-29 18:59:14 <dolio> I guess one thing to consider is that the market capitalization of Apple is (as far as bankers might be concerned) a number requiring almost 53 bits of precision, just on its own. So Double just gets by, and it's immediately going to be rounding stuff according to the non-banker specification.
2020-09-29 18:59:21 × Ariakenom__ quits (~Ariakenom@h-178-174-193-185.NA.cust.bahnhof.se) (Ping timeout: 256 seconds)
2020-09-29 19:00:45 <dolio> 53 might actually not be enough, even.
2020-09-29 19:00:47 × thir quits (~thir@p200300f27f0fc60094e773283d7bf825.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2020-09-29 19:01:44 <Noughtmare[m]> There was also this blog post: https://cs-syd.eu/posts/2020-07-28-how-to-deal-with-money-in-software
2020-09-29 19:02:12 <Noughtmare[m]> Might be an easier read and more related to Haskell and money.
2020-09-29 19:02:25 × nbloomf quits (~nbloomf@2600:1700:83e0:1f40:209d:e921:7304:6018) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-09-29 19:04:27 → mmohammadi9812 joins (~mmohammad@5.238.179.190)
2020-09-29 19:05:41 × machinedgod quits (~machinedg@45.78.189.122) (Read error: Connection reset by peer)
2020-09-29 19:05:51 × benl23 quits (sid284234@gateway/web/irccloud.com/x-uphxfqxgzdhiwrls) (Ping timeout: 260 seconds)
2020-09-29 19:05:51 × affinespaces quits (sid327561@gateway/web/irccloud.com/x-qpsgoegqtleeqjei) (Ping timeout: 260 seconds)
2020-09-29 19:05:59 → nbloomf joins (~nbloomf@2600:1700:83e0:1f40:b8df:2d55:a789:4c6e)
2020-09-29 19:05:59 × adius quits (sid321344@gateway/web/irccloud.com/x-quuxqbuikynbakrx) (Ping timeout: 246 seconds)
2020-09-29 19:05:59 × sethetter__ quits (sid17895@gateway/web/irccloud.com/x-wdliizmlfolakmwm) (Ping timeout: 246 seconds)
2020-09-29 19:06:23 × zacts quits (~zacts@dragora/developer/zacts) (Ping timeout: 260 seconds)
←Prev  Next→
Page 1 .. 302 303 304 305 306 307 308 309 310 311 312 .. 5022

All times are in UTC.