[Cython] Fused Types

[Robert Bradshaw]

On Tue, May 3, 2011 at 12:59 PM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 05/03/2011 08:19 PM, Robert Bradshaw wrote:
>
>>> Btw we shouldn't count on pruning for the design of this, I think this
>>> will
>>> for a large part be used with def functions. And if you use a cdef
>>> function
>>> from another module through a pxd, you also need all versions.
>>
>> Well, we'll want to avoid compiler warnings. E.g. floating might
>> include long double, but only float and double may be used. In pxd and
>> def functions, however, we will make all versions available.
>
> Which is a reminder to hash out exactly how the dispatch will be resolved
> when coming from Python space (we do want to support "f(x, y)", without
> []-qualifier, when calling from Python, right?)
>
> Fused types mostly make sense when used through PEP 3118 memory views (using
> the planned syntax for brevity):
>
> def f(floating[:] x, floating y): ...
>
> I'm thinking that in this kind of situation we let the array override how y
> is interpreted (y will always be a double here, but if x is passed as a
> float32 then use float32 for y as well and coerce y).
>
> Does this make sense as a general rule -- if there's a conflict between
> array arguments and scalar arguments (array base type is narrower than the
> scalar type), the array argument wins? It makes sense because we can easily
> convert a scalar while we can't convert an array; and there's no "3.4f"
> notation in Python.

I hadn't thought of that... it''s a bit odd, but we do have object ->
float but no float[:] -> double[:], so the notion of something being
the only match, even if it involves truncation, would be OK here. I'd
like the rules to be clear. Perhaps we allow object -> float (e.g. in
the auto-dispatching mode) but not double -> float.

> This makes less sense
>
> def f(floating x): ...
>
> as it can only ever resolve to double; although I guess we should allow it
> for consistency with usecases that do make sense, such as "real_or_complex"
> and "int_or_float"
>
> The final and most difficult problem is what Python ints resolve to in this
> context. The widest integer type available in the fused type? Always
> Py_ssize_t? -1 on making the dispatch depend on the actual run-time value.

-1 to run-time cutoffs. I'd choose the widest integral type.

- Robert