[Cython] Fused Types
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Tue May 3 10:07:42 CEST 2011
On 05/03/2011 09:59 AM, mark florisson wrote:
> On 3 May 2011 00:21, Robert Bradshaw<robertwb at math.washington.edu> wrote:
>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>> <markflorisson88 at gmail.com> wrote:
>>> On 2 May 2011 18:24, Robert Bradshaw<robertwb at math.washington.edu> wrote:
>>>> On Sun, May 1, 2011 at 2:38 AM, mark florisson
>>>> <markflorisson88 at gmail.com> wrote:
>>>>> A remaining issue which I'm not quite certain about is the
>>>>> specialization through subscripts, e.g. func[double]. How should this
>>>>> work from Python space (assuming cpdef functions)? Would we want to
>>>>> pass in cython.double etc? Because it would only work for builtin
>>>>> types, so what about types that aren't exposed to Python but can still
>>>>> be coerced to and from Python? Perhaps it would be better to pass in
>>>>> strings instead. I also think e.g. "int *" reads better than
>>>>> cython.pointer(cython.int).
>>>>
>>>> That's whey we offer cython.p_int. On that note, we should support
>>>> cython.astype("int *") or something like that. Generally, I don't like
>>>> encoding semantic information in strings.
>>>>
>>>> OTHO, since it'll be a mapping of some sort, there's no reason we
>>>> can't support both. Most of the time it should dispatch (at runtime or
>>>> compile time) based on the type of the arguments.
>>>
>>> If we have an argument type that is composed of a fused type, would be
>>> want the indexing to specify the composed type or the fused type? e.g.
>>>
>>> ctypedef floating *floating_p
>>
>> How should we support this? It's clear in this case, but only because
>> you chose good names. Another option would be to require
>> parameterization floating_p, with floating_p[floating] the
>> "as-yet-unparameterized" version. Explicit but redundant. (The same
>> applies to struct as classes as well as typedefs.) On the other had,
>> the above is very succinct and clear in context, so I'm leaning
>> towards it. Thoughts?
>
> Well, it is already supported. floating is fused, so any composition
> of floating is also fused.
>
>>> cdef func(floating_p x):
>>> ...
>>>
>>> Then do we want
>>>
>>> func[double](10.0)
>>>
>>> or
>>>
>>> func[double_p](10.0)
>>>
>>> to specialize func?
>>
>> The latter.
>
> I'm really leaning towards the former. What if you write
>
> cdef func(floating_p x, floating_p *y):
> ...
>
> Then specializing floating_p using double_p sounds slightly
> nonsensical, as you're also specializing floating_p *.
I made myself agree with both of you in turn, but in the end I think I'm
with Robert here.
Robert's approach sounds perhaps slightly simpler if you think of it
this way:
ctypedef fused_type(float, double) floating
ctypedef floating* floating_p
is really a short-hand for
ctypedef fused_type(float*, double*) floating_p
I.e., when using a fused_type in a typedef you simply get a new
fused_type. This sounds in a sense simpler without extra complexity
getting in the way ("which was my fused base type again...").
Dag SVerre
More information about the cython-devel
mailing list