# Arbitrary precision computations: BigFloat and ArbNumerics.jl
**URL:** https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645
**Category:** Numerics
**Tags:** numerics
**Created:** [November 23, 2020, 6:46pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645 "2020-11-23T18:46:49Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@lrnv](https://discourse.julialang.org/u/lrnv)
#### Post date: [November 23, 2020, 6:46pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/1 "2020-11-23T18:46:49Z")
Hey,
I have troubles to understand why arbitrary precision in Julia has to go through C code, like biglofats (that uses the mpfr library), and ArbNumerics (that uses the Arb library).
Although these are stunning packages and the underlying code is awesome, wouldnt an implementation of native julia bigfloat be better ? If no, why ? if yes, would it be very very hard to do ?
---
### Author:  [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)
#### Post date: [November 23, 2020, 7:21pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/2 "2020-11-23T19:21:57Z")
I think the “why” is it’s a lot of work. I’m sure people would be very thankful if you wrote a Julia-native `BigFloat`
---
### Author:  [@lrnv](https://discourse.julialang.org/u/lrnv)
#### Post date: [November 23, 2020, 10:54pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/3 "2020-11-23T22:54:40Z")
Yeah I would be thankful if someone wrote one too ! The question is rather would it be awfully slower than mpfr for reasons that I dont understand or is it still worth the shot
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [November 23, 2020, 11:24pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/4 "2020-11-23T23:24:13Z")
I think that most people suspect that a native julia `BigFloat` would not be appreciably slower, but also likely wouldn’t be appreciably faster than existing implementations. However, there would be other potential advantages than speed, like better composability and introspectability.
I think it’s a worthy project, just not one that someone has tackled yet (as far as I’m aware). There are MANY projects worthy of tackling in julia right now.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [November 23, 2020, 11:29pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/5 "2020-11-23T23:29:10Z")
One place where native `BigFloat` would be faster is that the compiler would probably do a better job of re-using memory. That could lead to decent performance improvements.
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [November 23, 2020, 11:40pm UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/6 "2020-11-23T23:40:05Z")
Yeah, that’s very true. But we do have ways around that like MutableArithmetic.jl. Arguably, it’s be easier to make this package more general and more effortless to use than to reinvent BigFloat.
But I still think that one day a Julia user will reinvent BigFloat and it’ll be great.
---
### Author:  [@dpsanders](https://discourse.julialang.org/u/dpsanders)
#### Post date: [November 24, 2020, 6:44am UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/7 "2020-11-24T06:44:45Z")
It would be nice, and presumably “not too hard”, to “just” rewrite [Arb](http://arblib.org/) in Julia.
It may be possible (or not) to get permission to do so with an MIT license.
However, as far as I understand / recall, Arb uses GMP or MPIR under the hood. Rewriting those seems like an even bigger undertaking.
---
### Author:  [@lrnv](https://discourse.julialang.org/u/lrnv)
#### Post date: [November 24, 2020, 9:03am UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/8 "2020-11-24T09:03:48Z")
> [@dpsanders](#):
>
> However, as far as I understand / recall, Arb uses GMP or MPIR under the hood. Rewriting those seems like an even bigger undertaking.
And if I understood correctly, the mutability problem come straight from gmp/mpir/mpfr code ?
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [November 24, 2020, 9:41am UTC](https://discourse.julialang.org/t/arbitrary-precision-computations-bigfloat-and-arbnumerics-jl/50645/9 "2020-11-24T09:41:35Z")
Yeah, kind of - GMP does a lot of things internally with memory and caching.
I’ve tried to reimplement BigInt in native julia about a year ago, but I couldn’t even get multiplication to work 😅 It’s certainly nontrivial and very hard to debug, since you can’t really visualize the big numbers it fails for properly… It did lead to a working property based testing framework with basic shrinking though, so it’s not a total loss.
That said, if it did work, I think it would be an amazing addition to the overall ecosystem 🙂