aside:
would it help others to find this to have a new thread that links here
with the subject:
why does checking that a promote_rule exists work in the REPL and not
inside a module?
On Tuesday, March 22, 2016 at 6:39:51 PM UTC-4, Jeffrey Sarnoff wrote:
>
> 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.
>>>
>>
