widen and promote_rule on Float64 to BigFloat, and how to handle adding new types into widen/promote

95 views
Skip to first unread message

Scott Jones

unread,
Jun 30, 2016, 11:46:17 AM6/30/16
to julia-dev
I've been working on fixing a number of issues with BigFloat (which many people have already said should be moved out to a package anyway), such as thread-safety, handling potential GC issues, excessive memory usage, and ability to stack allocate.

In doing so, I came across a couple of problems that affect any package that tries to replace BigFloat.
There doesn't seem to be any way (without warnings), to change the definitions in Base of widen / promote_rule.
It would be very useful to be able somehow to suppress those sorts of warnings.

Another issue is that it doesn't seem to me to be correct to "widen" or promote from a fixed precision float to an arbitrary precision float, where it might be possible
for the precision of BigFloat to be set to be *lower* than the largest fixed precision float.
While that is not so much of an issue now, since it is probably not common for anybody to change the precision for BigFloat to be < 53, it still could happen,
and when there are fixed size floating point types that are larger (such as in my package or in Jeffrey Sarnoff's Arb package), it doesn't make sense to have a promotion from a
1024 bit float down to an arbitrary precision fp type.

(This isn't an issue for BigInts, because those are really variable size, not an arbitrary fixed precision).

Any ideas about either issue?

Thanks,
Scott

Reply all
Reply to author
Forward
0 new messages