std.bigint.BigInt: allow casting to floating point numbers

[n8sh]

Limitation: casting to & comparison with quadruple precision floating point numbers are not supported. The path for 80 bit (EDIT: and greater) extended floats use std.math.scalbn which currently is impure and non-CTFE-able.

[dlang-bot]

Thanks for your pull request, @n8sh!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20146	enhancement	Allow casting from std.bigint.BigInt to built-in floating point types

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#7151"

[Biotronic]

Is scalbn a better solution than r * 2.0L^^N? At the very least, that solution should be a good enough stopgap for CTFE.

[n8sh]

@Biotronic: let's use that to make scalbn CTFE-able in general (#7153).

[n8sh]

Added path for arbitrarily high precision floating point numbers. Locally tested that it works for 80 bit reals.

[n8sh]

I may have to rethink the rounding used in opCast. When unsigned magnitude equals or exceeds 2^^64 casting to floating point truncates (rounds towards zero) because that makes it easy to use opCast in the implementation of opCmp. But when magnitude is less than 2^^64 rounding is performed as if converting a ulong to floating point.

[n8sh]

I've changed opCast to specify the rounding mode. Now the default rounding is roundToNearest but opCmp calls it with roundToZero.

[n8sh]

Since this seemingly isn't the default rounding mode on the Win32 & FreeBSD_32 test machines, my inclination is to abandon this rounding mode and round ties away from zero for float/double.

[ghost]

Is this still WIP?

[n8sh]

@berni44 the WIP tag is because the rounding behavior might astonish someone who used it without reading the documentation.

// BigInts that fall exactly between two non-infinite floats/doubles
// are rounded away from zero when cast to float/double. (Note that
// in most environments this is NOT the same rounding rule rule used
// when casting int/long to float/double.)

Any way of handling rounding had disadvantages. I'm not convinced that this choice is the best.

[n8sh]

Also, this isn't great:

When cast to float or double or 64-bit real the rounding is strictly defined. When cast to extended-precision real the rounding rules vary by environment.

[ghost]

@berni44 the WIP tag is because the rounding behavior might astonish someone who used it without reading the documentation.

I had exactly the same problems with the functions that print floating point numbers in std.format. But there is a slight difference: Printing is IMHO mainly done for humans and there is IMHO "ties away from zero" the expected choice. Here, the numbers might be used to do some more calculating and as far as I know "ties to even" works better for that, because it can straighten out the accumulating errors.

What I currently do in std.format is to read out the rounding mode of the processor and use this mode (round down, round up, round to zero, round to nearest with ties to even). That's what printf does and the reason why printing floats isn't pure.