added support for an arbitrary number of fraction bits

[bjarthur]

i need to add four Image{Gray{UFixed16}} together without overflowing. could convert to Float32, but thought a UFixed{UInt32,16} would be more graceful. so before realizing that the snazzy new @generated was taboo, i refactored ufixed.jl to support arbitrary fractional bit depths. anything goes, like UFixed{UInt64,3}, as an additional example.

all of the tests pass in julia 0.5-rc2.

so why are generated functions to be avoided?

[vchuravy]

A lot of the generated functions are unnecessary and I think we could rework most of the eval-for loops by using methods like @pure mask{T, f}(::Type{UFixed{T,f}}) = convert(T, 1<<(f-1)). LLVM constant-folds this calculation and we won't need to resort to the inlining trick.

Will put up an PR for that momentarily. Thank you for your help.

[bjarthur]

doh! it should've occurred to me that generated functions whose body only contains the returned expression could be rewritten as normal functions. thanks!

i've added more tests, updated the docs, and included a commit, which could be a separate PR if preferred, which fixes the type returned by round and ceil.

any ideas for benchmarks?

[vchuravy]

This will be costly on v0.4. On v0.5 we can constant fold this, but only if we outline the 2^nbitsfrac(T) into a pure function Base.@pure one_pattern(f)=(2^f-1), but this won't work on v0.4.

One solution would be for now to use the current way on v0.4 with your method as a fallback, and on v0.5 and higher use pure functions on the type-parameter to get the same effect.

[bjarthur]

good catch. thanks. it was 4x slower. fixed for 0.4 and 0.5 with a generated function. that seems a simpler solution to me than having to switch on the version.

[vchuravy]

Thank you for tackling this. The added generality will be valuable, but we have to make sure that this comes at no extra cost, because FixedPointNumbers is used in performance sensitive places.

Would you mind also adding a few benchmarks with BenchmarkTools?

[bjarthur]

thanks for pointing out BenchmarkTools to me. i used it to fix a few things you pointed out. is it customary to commit benchmarks? if so, where?

[vchuravy]

Any reason for these to be removed?

[bjarthur]

this is part of the second commit. removing them fixes the bug that round(UFixed) returns an Int, not a UFixed.

[timholy]

This looks quite good to me. I do not personally have a problem with the generated functions. Some could become @pure on Julia 0.5, of course.

[bjarthur]

show now omits FixedPointNumbers for brevity, as requested.

anything else?

[vchuravy]

Why is this a @generated function? I would think it is unnecessary here ;)

[timholy]

Right, this should not be @generated, it's not performance-critical and in any case being @generated won't help here.

[vchuravy]

Looks good to me.

[bjarthur]

is this what you had in mind instead of a generated function?

[timholy]

UFixed{UInt16,12} is a type, not a value.

[timholy]

Sorry to keep pestering you with review comments. I was about to hit merge and thought I should give it another once-over. I must be less tired this time.

[bjarthur]

dang. good catches. two less evil generated functions now. 0.4 behaves the same.

[timholy]

Thanks!

BTW, to answer your question above about why they are evil:

• They are much slower to JIT compile, so add to latency-to-first-result when using them
• They prevent static compilation (see http://juliacomputing.com/blog/2016/02/09/static-julia.html)
• Jameson hates them 😄

All of these actually come down to the same thing: the compiler can't easily reason about what a generated function will do, because they can do arbitrary things.

So really they're only partly evil, but it's fair to say they are to be avoided unless there is no really good alternative.