Let user specify Integer ->Float conversion type

[jeremiahpslewis]

Based on these related issues: FluxML/Flux.jl#2305, FluxML/Zygote.jl#1445, JuliaGPU/GPUArrays.jl#484

it seems like it might be useful to have a bit more control over whether Int projections are mapped to Float64 or another AbstractFloat subtype. While this might be possible via overloading, it would be nice to know that one hasn't broken any ChanRulesCore.jl functionality by overloading the method. Especially for working with GPUs, greedy type conversion to Float64 seems to be problematic.

This PR introduces a local user preference int2float via which a Float type can be specified. I have also adjusted the tests so that they can be run with different preference settings.

The problem which this PR solves, in a nutshell:

using ChainRulesCore

# Second test fails
ProjectTo(1.0f0)(2) === 2.0f0
ProjectTo(1)(2.0f0) === 2.0f0

# Both tests pass (after restart)
ChainRulesCore.set_int2float!("Float32")
ProjectTo(1.0f0)(2) === 2.0f0
ProjectTo(1)(2.0f0) === 2.0f0

Disclaimer I'm new to this package and imagine that this may be the wrong way to fix the problem, so please don't hesitate to close this PR if I've missed something.

[devmotion]

Maybe you know already, but one can set preferences before loading a package by specifying the package via its UUID.

[jeremiahpslewis]

Thanks, I've used this in running the tests, anywhere else where this would be helpful?

[oxinabox]

this scares me. So do most uses of preferences to be fair.
I can't see how this can be safely used.
If one package assumes one behavour and another another then it will error.

Julia provides a function, float, to get the reference floating point type.

Though in most cases it is the chainrules conception to refuse to deal with integers.
because they represent discrete quantities.
And we treat types as having semantic meaning, not merely for computation convieience.
(See also how we treat structurally sparse array types. We don't let their derivatives have nonzeros in the wrong places)
I would have expected

ProjectTo(1)(2.0f0) === NoTangent()

[jeremiahpslewis]

@oxinabox Agree, the more I work on this PR, the less I like it. I've opened a new one with only the added tests, so at least the behavior is documented...

[jeremiahpslewis]

Superseded by #629