In some cases of reduction operations, it may be useful to use special intermediate representations for speed and accuracy. A typical example is computing the sum of fixed-point numbers within the form of an integer accumulation.
We can customize Base.reduce_empty / Base.reduce_first. However, they also affect the final result type, and there seems not to be something like Base.reduce_result / Base.reduce_final.
Of course it’s possible to overload sum, reduce, etc, but I think that’s much more problematic than overloading Base.reduce_empty etc.
Any thoughts?
Just convert the final result type to whatever you need?
That’s right. However I expect the customizations in packages, e.g. FixedPointNumbers.jl.
One could imagine a framework for reduce(op, itr) where all these (first and empty element transformations, widening to an intermediate representation than narrownig, etc) would be customizable, but generally those methods would need to dispatch on op and eltype(itr), at which point one may just name the operation (eg op === + as sum) and implement custom methods for that.
That said, a package could be a good place to experiment with this.
1 Like