On 3 May 2011 10:07, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> wrote:
> On 05/03/2011 09:59 AM, mark florisson wrote:
>>
>> On 3 May 2011 00:21, Robert Bradshaw<rober...@math.washington.edu> wrote:
>>>
>>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>>> <markflorisso...@gmail.com> wrote:
>>>>
>>>> On 2 May 2011 18:24, Robert Bradshaw<rober...@math.washington.edu>
>>>> wrote:
>>>>>
>>>>> On Sun, May 1, 2011 at 2:38 AM, mark florisson
>>>>> <markflorisso...@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@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.
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
