Param does not play nicely with Unitful quantities

[bgroenks96]

Math operations with Param/AbstractNumber do not work with Unitful quantities.

Param(1.0)*1.0u"m"
ERROR: MethodError: *(::Param{Float64, NamedTuple{(:val,), Tuple{Float64}}}, ::Quantity{Float64, 𝐋, Unitful.FreeUnits{(m,), 𝐋, nothing}}) is ambiguous. Candidates:
  *(y::Number, x::Unitful.AbstractQuantity) in Unitful at /home/bgroenke/.julia/packages/Unitful/SUQzL/src/quantities.jl:32
  *(a::AbstractNumbers.AbstractNumber, b::Number) in AbstractNumbers at /home/bgroenke/.julia/packages/AbstractNumbers/jJpxf/src/overloads.jl:586
Possible fix, define
  *(::AbstractNumbers.AbstractNumber, ::Unitful.AbstractQuantity)
Stacktrace:
 [1] top-level scope
   @ REPL[13]:1

I suppose this is really more of an issue with AbstractNumbers, but what is the quickest workaround here?

[rafaqz]

stripparams

Or define the method yourself maybe?

I'm not even sure what AbstractNumbers.jl could do, but I would review and merge a PR that doesn't include a Unitful.jl dependency ;)

Maybe it should dispatch on both Real and AbstractNumber instead of Number, so other number types can handle things?

[bgroenks96]

Yes, I agree that we wouldn't want a Unitful dependency. Seems like the real solution, actually, would be for Unitful to subtype AbstractNumber. Not sure what the chances of that happening are though.

[bgroenks96]

I don't really agree that stripparams is the solution.... so long as Param is supposed to act like a number (and the interface currently defined this way), it should do so correctly and not cause dispatch errors like this when used with other numeric types.

[rafaqz]

I mean, that is the dream. But in practice things like this seem to happen somewhere or other.

There are essentially no active maintainers of AbstractNumbers.jl, and the maintainers are only me and Simon Danisch anyway, so very unlikely there will ever be time to improve it given our other packages.

I imagine the chances of unitful subtyping AbstractNumber would be approaching zero.

[bgroenks96]

I asked anyway. There needs to be some unification here because this points to an underlying issue that will also occur when mixing other custom numeric types.

[rafaqz]

We need a function like parent for numbers in Base that is called as a fallback. That would solve this completely.

[rafaqz]

The solution is to actually treat Number like an interface in Base.

But probably good to push the point. Although be aware you are essentially volunteering to maintain AbstractNumbers.jl, as the defacto maintainer I have no time to work on any problems that come up with this idea.