I was wrong. We need
cdef f(floating x, floating_p y)
...to get 2 specializations, not 4. And the rest follows from there. So I'm
with Robert's real stance :-)
I don't think we want flexibility, we want simplicity over all. You can always
use a templating language.
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.
DS
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
mark florisson <markflorisso...@gmail.com> wrote:
On 3 May 2011 18:00, Robert Bradshaw <rober...@math.washington.edu> wrote: > On
Tue, May 3, 2011 at 12:59 AM, mark florisson > <markflorisso...@gmail.com>
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 type
defs.)
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. > > Ugh. I totally changed the meaning of that when I refactored my
email. > I'm in agreement with you: func[double]. I see, however Dag just
agreed on double_p :) So it depends, as Dag said, we can view ctypedef floating
*floating_p as a fused type with variable part double * and float *. But you
can also view the variable part as double and float. Either way makes sense,
but the former allows you to differentiate floating from floating_p. So I
suppose that if we want func[double] to specialize 'cdef func(floating_p x, fl
oating
y)', then it would specialize both floating_p and floating. However, if we
settle on Dag's proposal, we can differentiate 'floating' from 'floating_p' and
we could make 'speed_t' and 'acceleration_t' a ctypedef of floating. So I guess
Dag's proposal makes sense, because if you want a single specialization, you'd
write 'cdef func(floating *x, floating y)'. So overall you get more
flexibility. >> 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 *. >> >>>> FYI, the type
checking works like 'double_p is >>>> floating_p' and not 'double is
floating_p'. But for functions this is >>>> a little different. On the one hand
specifying the full types >>>> (double_p) makes sense as you're kind of
specifying a signature, but >>>> on the other hand you're specializing fused
types and you don't care >>>> how they are composed -- especially if they
occur
multiple times with >>>> different composition. So I'm thinking we want
'func[double]'. >>> >>> That's what I'm thinking too. The type you're branching
on is >>> floating, and withing that block you can declare variables as >>>
floating*, ndarray[dtype=floating], etc. >> >> What I actually meant there was
"I think we want func[double] for the >> func(floating_p x) signature". >> >>
Right, people can already say 'cdef func(floating *p): ...' and then >> use
'floating'. However, if you do 'cdef floating_p x): ...', then >> 'floating' is
not available, only 'floating_p'. It would be rather >> trivial to also support
'floating' in the latter case, which I think >> we should, > > floating is
implicitly available, we could require making it explicit. How would we make it
explicit. >> unless you are adamant about prohibiting regular typedefs >> of
fused types. > > No, I'm nto adamant against it, just wanted to get some
discussion going. > > - Robert
>_____________________________________________
> 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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
