[Cython] Fused Types

[Dag Sverre Seljebotn]

On 05/03/2011 10:49 AM, mark florisson wrote:
> On 3 May 2011 10:44, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>  wrote:
>> On 05/03/2011 10:42 AM, mark florisson wrote:
>>>
>>> On 3 May 2011 10:07, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>
>>>   wrote:
>>>>
>>>> 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
>>>> _______________________________________________
>>>> cython-devel mailing list
>>>> cython-devel at python.org
>>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>>
>>>
>>> Ok, if those typedefs should be disallowed then specialization through
>>> indexing should then definitely get the types listed in the fused_type
>>> typedef.
>>
>> I'm not sure what you mean here. What is disallowed exactly?
>
> ctypedef cython.fused_type(float, double) floating
> ctypedef floating *floating_p
>
> That is what you meant right? Because prohibiting that makes it easier
> to see where a type is variable (as the entire type always is, and not
> some base type of it).


No. I meant that the above is automatically transformed into

ctypedef cython.fused_type(float, double) floating
ctypedef cython.fused_type(float*, double*) floating_p


DS