On 3 May 2011 10:57, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> wrote:
> On 05/03/2011 10:49 AM, mark florisson wrote:
>>
>> On 3 May 2011 10:44, Dag Sverre Seljebotn<d.s.seljeb...@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.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.
>>>
>>> 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
I see, so you want to allow it but you consider the entire thing
variable. Ok sure, in a way it makes as much sense as the other. So
then 'floating *' would get specialized using 'double', and
'floating_p' would get specialized using 'double_p'.
>
> DS
> _______________________________________________
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
