OK I solved (5). Apparently promote_rule needs to be defined for both
orderings of its arguments if one wants it to work with arguments in either
order.
I can't think of any reason why one wouldn't expect a promote_rule to come
up with a common type to which both can be promoted, regardless of the
order of its arguments. But maybe such an application exists. So maybe this
is actually reasonable behaviour.
Bill.
On Tuesday, 22 March 2016 22:58:29 UTC+1, Bill Hart wrote:
>
> Another problem:
>
> 5) We have been using promote_type to find out the type returned by a
> promote_rule we defined, which has mostly worked fine, oddly enough. But
> now that I realise that's not what promote_type is for, I switched to using
> promote_rule instead, since it just returns Union{} if there is no
> promote_rule for the supplied types. But this doesn't work in Nemo.
>
> Even though we have an explicit promote rule (not generated at runtime)
>
> Base.promote_rule{T <: Integer}(::Type{fmpz_poly}, ::Type{T}) = fmpz_poly
>
> a call to Base.promote_rule(fmpz_poly, Int) inside Nemo returns Union{}.
>
> However, such a call from the REPL results in Nemo.fmpz_poly.
>
> There's clearly something broken here. I need to be able to explicitly
> tell if the promote_rules that I create actually exist or not. At present I
> only seem to be able to do that from the REPL, not inside my actual module.
>
> Bill.
>
