bug in BigFloat trunc / floor / ceil / round

[getzdan]

The following error should not occur, as trunc(255.5) is 255 which is a legal UInt8:

julia> trunc(UInt8,BigFloat(255.5))
ERROR: InexactError: trunc(UInt8, 2.555000000000000000000000000000000000000000000000000000000000000000000000000000e+02)
Stacktrace:
 [1] trunc(::Type{UInt8}, ::BigFloat) at ./mpfr.jl:209

The same logic applies to the other casting functions.

A proper solution should be to perform the round/trunc/floor/ceil in the source type, i.e. BigFloat and then cast to the target type and error if it doesn't fit correctly.

The relevant code is:

julia/base/mpfr.jl

Lines 207 to 223 in c6899ec

	function trunc(::Type{T}, x::BigFloat) where T<:Union{Signed,Unsigned}
	(typemin(T) <= x <= typemax(T)) || throw(InexactError(:trunc, T, x))
	unsafe_cast(T, x, RoundToZero)
	end
	function floor(::Type{T}, x::BigFloat) where T<:Union{Signed,Unsigned}
	(typemin(T) <= x <= typemax(T)) || throw(InexactError(:floor, T, x))
	unsafe_cast(T, x, RoundDown)
	end
	function ceil(::Type{T}, x::BigFloat) where T<:Union{Signed,Unsigned}
	(typemin(T) <= x <= typemax(T)) || throw(InexactError(:ceil, T, x))
	unsafe_cast(T, x, RoundUp)
	end
	function round(::Type{T}, x::BigFloat) where T<:Union{Signed,Unsigned}
	(typemin(T) <= x <= typemax(T)) || throw(InexactError(:round, T, x))
	unsafe_cast(T, x, ROUNDING_MODE[])
	end

[StefanKarpinski]

A proper solution should be to perform the round/trunc/floor/ceil in the source type, i.e. BigFloat and then cast to the target type and error if it doesn't fit correctly.

Yes, I do think that would work. The assumption required is that you can correctly do the round/trunc/floor/ceil operation in the original type. That seems like a reasonable requirement. Once the value is correct in the source type, the value can simply be converted and rely on domain checking of convert, so the implementation is quite simple:

$op(::Type{T}, x::Number) = convert(T, $op(x))

[drpn]

I would like to suggest a solution. Can't we convert BigFloat to AbstractFloat first and then, go for trunc?
Thats even working fine. Thus I want to know its performance too.

[StefanKarpinski]

Can't we convert BigFloat to AbstractFloat first and then, go for trunc?

BigFloat is an implementation of AbstractFloat, so that conversion would do nothing.

[drpn]

Ok, can you just tell me how can I test if I edit the code which I have cloned in my desktop? I want to try both the suggested one and mine.

[mbauman]

In simple cases like this you can just re-define the method at the REPL:

julia> @eval Base.MPFR function trunc(::Type{T}, x::BigFloat) where T<:Union{Signed,Unsigned}
            (typemin(T) <= x <= typemax(T)) || throw(InexactError(:trunc, T, x))
            println("NEW IMPLEMENTATION!")
            unsafe_cast(T, x, RoundToZero)
        end
WARNING: Method definition trunc(Type{T<:Union{Signed, Unsigned}}, Base.MPFR.BigFloat) in module MPFR at REPL[13]:2 overwritten at REPL[14]:2.
trunc (generic function with 66 methods)

julia> trunc(Int, big(2.4))
NEW IMPLEMENTATION!
2

[laborg]

This has apparently been handled in #29157

julia> trunc(UInt8,BigFloat(255.5))
0xff