BigFloats parametrised by precision


#1

I vaguely remember that there have been several discussions about parametrising BigFloats according to their precision, and I think I recall that someone already has a package that does this.

Could someone please point me to it?


#2

I’d been working on doing that just before JuliaCon 2016, but haven’t had the time to finish it.
I was trying to accomplish a few things.
Allow Julia to access in a clean fashion references to BigFloats (very useful for performance if you want to
do something like sum a bunch of things and not have a huge amount of allocations.
Make BigFloats much smaller and truly immutable (perform calculations by filling in cached big float reference types, calling MPFR, and then constructing an immutable to return, instead of using a type that points into C allocated memory,
requiring 16 bytes extra per object for finalizer pointers). This improved performance a lot in my tests.
Add parameterized BigFloats (using the same scheme as above).
Add a few specific sizes of parameterized big floats.


#3

I think my last version was this: https://gist.github.com/ScottPJones/37aef2198eb2bc37c5241887cb7117a2 (you had even starred my version from just before JuliaCon :wink: )


#4

Seems like there are several useful changes mixed up here. Maybe it would be useful to separate them out into different commits to be able to evaluate each separately?


#5

As soon as I finish revamping the stuff I’m doing for LaTeX, Emoji, Unicode, and HTML entities wrapped up (I’m just finishing debugging the hardest one of the set, Unicode) I can revisit that code.
Do you have any particular way you think it would be best to organize this?
The “FloatRef” is kind of the lowest level, that is really the basis for the rest, and might be separable into another package, and then building the others on top of that framework.


#6

By the way, I think I’ve found a different solution for having a Float128 type (I didn’t want to call a 128-bit MPFR based type “Float128”, because the other Float types are all based on IEEE, but BigFloats are not), which is wrapping another C library that implements 16, 32, 64, 80, and 128 bit IEEE binary floats.


#7

Personally, it seems to me that it would be best to start with just parametrising the code that currently exists in base/mpfr.jl, with no other changes. Then each subsequent substantial change can be a separate commit on top of that.