The use of Rational here is interesting, but I think more expensive than it needs to be. It looks like we really only need to generalize the _round_to_even function to accept any number (such as y.i * powt) instead of only a power of 10.

Well, I suppose since we are using widemul anyway, it could make sense to use the wider rational type.

I ended up switching to the Rational to fix a precision problem. I'll verify that this is necessary as I may have just been running into this issue at the time: JuliaLang/julia#19779

Right, this should be precise where the original floating point isn't. However, see my PR #9 which achieves the same result but with no possibility of intermediate overflow.

Could you explain this change? It seems to me that x * powt is susceptible to overflow, and the original code was better at avoiding that.

I changed since some FixedDecimal numbers with large values of f may not be able to represent the den. The x * powt seems to be safe from silently overflowing as Rationals will either raise an OverflowError or promote correctly:

julia> (typemax(Int) // 1) * 2
ERROR: OverflowError()
 in *(::Rational{Int64}, ::Rational{Int64}) at ./rational.jl:208
 in *(::Rational{Int64}, ::Int64) at ./promotion.jl:191

julia> (typemax(Int) // 1) * BigInt(2)
18446744073709551614//1

Can we keep the old code for now, replacing / FD{T, f}(den) with / den which avoids the issue with representation of den? It won't silently overflow, but this new code looks nevertheless susceptible to OverflowError in more cases than before. We should revisit it later.

Actually, I see the difference now: the old code handled inexact conversions, whereas this one will throw InexactError. I'm OK with the change to throw InexactError as it does match what happens if you convert a fixed-decimal with higher precision to one with lower precision; we should preserve the old code as a round method.

This allocates memory, which we should avoid. There are better way to compute this without overflow.

However I would rather, personally, ensure that 1 is representable in every FD type. That means requiring typemax(IntType) >= 10^f for every constructible FD{IntType, f} type, which would not require excessive overflow checks which I would like to avoid in Currencies. Is there a use case for FixedDecimal types that cannot represent 1? (Note that this change almost makes all operations on those types InexactErrors anyway, so I lean toward simply disallowing their construction.)

I agree that making sure 1 can always be represented in every FD type is reasonable. I personally, don't have a use case for this but I my original thought was that FixedDecimals purpose is for representing decimal numbers without losing precision so it made sense to support a decimal at any arbitrary precision. Your proposal also implies that we should not allow any value of f < 0.

As for "excessive overflow checks" we're still going to need to make use of widemul in quite a few places as we can still run into overflow with large integers:

julia> T = Int; powt = T(10)^2
100

julia> typemax(T) * powt
-100

widemul should generally (except in the BigInt case) be much cheaper than the overflow checks for exponentiation as implemented here, so I'm OK with that.

Ok, I'll switch the coefficient function to just be T(10)^f and add the appropriate restrictions when constructing a FixedDecimal instance.

We can do a branch here so that

if !applicable(typemax, T)
    return typemax(Int)
end

which would be a little nicer than the current approach in that it will handle arbitrary-precision integers that are not BigInt properly (e.g. if someone had their own custom implementation).

I think I would rather do:

if !applicable(typemax, T)
    throw(DomainError())
end

or alternatively

if !applicable(typemax, T)
    return -1
end

Returning a large exponent which is guaranteed to overflow doesn't seem like the right answer.

But typemax(Int) won't "overflow" for BigInt or other types that don't define typemax. It would just simplify the implementation of the constructor so as not to require special-casing BigInt.

What I mean is that T(10)^x where T is BigInt and x = typemax(Int) does actually overflow:

julia> BigInt(10)^typemax(Int)
gmp: overflow in mpz type

signal (6): Abort trap: 6
while loading no file, in expression starting on line 0
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 3959986 (Pool: 3958822; Big: 1164); GC: 25
Abort trap: 6

I agree with your point that the FixedDecimal constructor shouldn't have the BigInt special case so I'll try to generalize the code in a different way.