u/precalcin r/haskell • Recommends
Exact Real Arithmetic in Haskell - Mitchell Riley - BFPG 2015-05
0:00 / 0:00
#exactrealarithmetic#realnumbers#functionalprogramming
Exact Real Arithmetic in Haskell - Mitchell Riley - BFPG 2015-05
Brisbane Functional Programming Group
710 subscribers • 6 videos on Hallway
- Recommended by 1 person: 1 in engineering communities.
- Presented by Mitchell Riley
Advanced. Deep dive for people who know the field.
6.3K views11 years ago1 recommendation
Programming languagesComputer scienceHaskellMath for programmers
Mitchell Riley explores two methods for performing exact real arithmetic in Haskell along with their tradeoffs.
Mitchell talks about two methods of doing exact real arithmetic, their tradeoffs and how to use them in haskell.Why it's here
1 person recommends thisu/Roboguy2in r/ProgrammingLanguages • Mentions
On “Managing Irrational Numbers Without Floats”
You might be interested in the talk "Exact Real Arithmetic in Haskell". It describes two exact representations for (computable) real numbers: one based on Cauchy sequences and one based on continued fractions.
You can use this to, for example, have an exact representation of pi, e or sqrt(2).
It is slower than an arbitrary precision rational representation but, of course, rational representations cannot exactly represent irrational numbers (unlike the techniques in the video).
At the end of the video, he gives links to an implementation of each of those two representations.
He also starts the video with a very nice example of floating point arithmetic going horribly wrong.
## A bit of…
u/Roboguy2in r/ProgrammingLanguages • Mentions
On “Alternative names for float and double?”
The issue I have with this is that, to me, the names in the OP suggest that whatever representation that is being used doesn’t have IEEE floating point’s weird quirks (addition & multiplication aren’t associative, the “equality” isn’t even an equivalence relation since it has something that isn’t “equal” to itself, etc).
Based on some of the names in the OP, I would guess it’s either a system of *exact* real arithmetic (that you can extract arbitrary precision approximations from) based on [Cauchy sequence-based representation or a continued fraction-based representation], a ratio-based representation or a fixed point representation. Admittedly, part of the reason might be that I’ve only ev…
u/haskellgr8in r/haskell • Mentions
On “What's the current state of Haskell for numerical computing?”
One potentially great reason for using Haskell for numerical computing is a mind-blowing feature of Haskell that I asked about a while back:
For those of you familiar with lots of languages other than Haskell: Do you know of any other language that treats things like 2, 3, pi as general numbers (Num or Floating in Haskell) that can in the end act as any number type?
Whatever I do, I try not to litter my codebase with `Double`s. It's a very dangerous practice IMO. (To learn why, watch the first *2 minutes and 30 seconds* of this talk.) If you find that in your language of choice writing more generic code is hard, maybe it's not the greatest language for this purpose.
u/ForTheFunctionGodin r/haskell • Mentions
On “What I found inconvenient in Haskell”
> Lastly, floating point numbers still suck. No amount of typeclass twiddling will change that :(
This talk might interest you (might be a repost). The guy shows two really very clever schemes for doing arithmetic with unbounded precision.