That is not supposed to be how it works!
As I recall there was a meetup where JeffB explains that promote_rule
always never cares about the order of its arguments and internals generate
lookups for both orderings.
On Tuesday, March 22, 2016 at 6:26:51 PM UTC-4, Bill Hart wrote:
>
> 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.
>>
>
