Avoidable overflow errors in division

[kimikage]

If the output uses FixedPoint, as shown below, there is some rationale for the overflow error.

julia> Gray{N0f8}(1) / Gray{N0f8}(1)
Gray{N0f8}(1.0)

julia> Gray{N0f8}(1) / Gray{N0f8}(0.6)
ERROR: ArgumentError: N0f8 is an 8-bit type representing 256 values from 0.0 to 1.0; cannot represent 1.6666666

On the other hand, if the output uses AbstractFloat, the error should be avoided.

julia> Gray(1.0) / Gray{N0f8}(0.6)
Gray{Float64}(1.6666666666666667)

julia> Gray(1.0) / 0.6N0f8
ERROR: ArgumentError: N0f8 is an 8-bit type representing 256 values from 0.0 to 1.0; cannot represent 1.6666666

Originally posted by @kimikage in #148 (comment)

This is a bug in the optimization technique using reciprocals. E.g.:

ColorVectorSpace.jl/src/ColorVectorSpace.jl

Line 253 in 85b8759

(/)(c::AbstractGray, f::Real) = (one(f)/f)*c

By properly promoting the type before calculating the reciprocal, this problem should be avoided. E.g.:

(/)(c::AbstractGray, f::Real) = (oneunit(divtype(eltype(c), typeof(f)))/f)*c

That said, division is fast enough on modern CPUs, so we might verify how effective the technique of using reciprocals is in the first place.

[kimikage]

The following differs from the Normed case in that an error occurs before the reciprocal calculation.

julia> Gray(0.25Q0f7) / 0.5Q0f7
ERROR: ArgumentError: Q0f7 is an 8-bit type representing 256 values from -1.0 to 0.992; cannot represent 1

[kimikage]

julia> Gray{Q2f5}(0.25) / 0.5Q2f5 # OK
Gray{Q2f5}(0.5Q2f5)

julia> Gray{Q1f6}(0.25) / 0.5Q1f6 # silently overflowed
Gray{Q1f6}(-0.5Q1f6)

[kimikage]

BTW, there is an issue introduced in v0.9.0, although it is essentially a known issue with ColorTypes.

julia> julia> 1 / Gray(1)
1.0f0                # v0.8
Gray{Float32}(1.0f0) # v0.9

julia> 1+0im / Gray(1)
1.0f0 + 0.0f0im            # v0.8
ERROR: StackOverflowError: # v0.9

I don't have a clear answer on how to handle non-Real types, but for now I will try to avoid the stack overflow.