Dave Hirschfeld, 13.02.2013 09:16:
> Robert Bradshaw writes:
>> Yes, this is a bug; there is a bad interaction between fused types and
>> special methods.
>>
>> I created http://trac.cython.org/cython_trac/ticket/802
>>
>
> Thanks for following up. My actual use-case was to allow either 1D or 2D
>
Robert Bradshaw writes:
>
> Yes, this is a bug; there is a bad interaction between fused types and
> special methods.
>
> I created http://trac.cython.org/cython_trac/ticket/802
>
Thanks for following up. My actual use-case was to allow either 1D or 2D
MemoryView inputs to a function by simpl
Yes, this is a bug; there is a bad interaction between fused types and
special methods.
I created http://trac.cython.org/cython_trac/ticket/802
On Fri, Feb 8, 2013 at 8:54 AM, Dave Hirschfeld
wrote:
> Is this a bug?
> The following code fails to compile on windows VS2012, 32bit Python2.7 with a
Is this a bug?
The following code fails to compile on windows VS2012, 32bit Python2.7 with a
recent 0.19-pre github cython:
cimport cython
ctypedef fused char_or_float:
cython.char
cython.float
cdef class FusedExample:
def __init__(self, char_or_float x):
pass
#
Resu
On 06/02/2011 11:51 PM, Robert Bradshaw wrote:
On Thu, Jun 2, 2011 at 2:42 PM, mark florisson
wrote:
On 2 June 2011 23:31, Robert Bradshaw wrote:
On Thu, Jun 2, 2011 at 2:18 PM, Dag Sverre Seljebotn
wrote:
On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
In looking at merging fused types,
On Thu, Jun 2, 2011 at 2:42 PM, mark florisson
wrote:
> On 2 June 2011 23:31, Robert Bradshaw wrote:
>> On Thu, Jun 2, 2011 at 2:18 PM, Dag Sverre Seljebotn
>> wrote:
>>> On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
In looking at merging fused types, it's time to nail down the syntax
On 2 June 2011 23:31, Robert Bradshaw wrote:
> On Thu, Jun 2, 2011 at 2:18 PM, Dag Sverre Seljebotn
> wrote:
>> On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
>>>
>>> In looking at merging fused types, it's time to nail down the syntax.
>>> The current implementation is
>>>
>>> ctypedef cytho
On Thu, Jun 2, 2011 at 2:18 PM, Dag Sverre Seljebotn
wrote:
> On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
>>
>> In looking at merging fused types, it's time to nail down the syntax.
>> The current implementation is
>>
>> ctypedef cython.fused_type(list, dict, object) fused_t
>>
>> This requ
On Jun 2, 2011 2:18 PM, "Dag Sverre Seljebotn"
wrote:
> If you only want this allowed in typedefs, then, being puristic, I think
that really a "fused type" is really different from a ctypedef, and that it
would warrant something like a new keyword.
>
> cdef fusedtype [list, dict, object] fused_t
On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
In looking at merging fused types, it's time to nail down the syntax.
The current implementation is
ctypedef cython.fused_type(list, dict, object) fused_t
This requires an addition to the grammer to allow the "call" syntax in
a type declaratio
On Thu, Jun 2, 2011 at 1:07 PM, mark florisson
wrote:
> On 2 June 2011 18:39, Robert Bradshaw wrote:
>> In looking at merging fused types, it's time to nail down the syntax.
>> The current implementation is
>>
>> ctypedef cython.fused_type(list, dict, object) fused_t
>>
>> This requires an add
On 2 June 2011 18:39, Robert Bradshaw wrote:
> In looking at merging fused types, it's time to nail down the syntax.
> The current implementation is
>
> ctypedef cython.fused_type(list, dict, object) fused_t
>
> This requires an addition to the grammer to allow the "call" syntax in
> a type dec
Not that my opinion carriers any weight, but I'm +1 on this.
On Thu, Jun 2, 2011 at 11:39 AM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
> In looking at merging fused types, it's time to nail down the syntax.
> The current implementation is
>
>ctypedef cython.fused_type(list, dic
In looking at merging fused types, it's time to nail down the syntax.
The current implementation is
ctypedef cython.fused_type(list, dict, object) fused_t
This requires an addition to the grammer to allow the "call" syntax in
a type declaration, as well as special casing to make it allowed on
Dag Sverre Seljebotn wrote:
The argument to the above goes that you *should* be out of luck. For
instance, talking about dot products, BLAS itself has float-float and
double-double, but not float-double AFAIK.
Seems to me that's more because generating lots of versions
of a function in C is h
On 05/04/2011 08:13 PM, Robert Bradshaw wrote:
On Wed, May 4, 2011 at 1:47 AM, mark florisson
wrote:
On 4 May 2011 10:24, Dag Sverre Seljebotn wrote:
On 05/04/2011 01:07 AM, Greg Ewing wrote:
mark florisson wrote:
cdef func(floating x, floating y):
...
you get a "float, float" version,
On Wed, May 4, 2011 at 1:47 AM, mark florisson
wrote:
> On 4 May 2011 10:24, Dag Sverre Seljebotn wrote:
>> On 05/04/2011 01:07 AM, Greg Ewing wrote:
>>>
>>> mark florisson wrote:
>>>
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, doubl
On 4 May 2011 10:24, Dag Sverre Seljebotn wrote:
> On 05/04/2011 01:07 AM, Greg Ewing wrote:
>>
>> mark florisson wrote:
>>
>>> cdef func(floating x, floating y):
>>> ...
>>>
>>> you get a "float, float" version, and a "double, double" version, but
>>> not "float, double" or "double, float".
>>
>>
On 05/04/2011 01:07 AM, Greg Ewing wrote:
mark florisson wrote:
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
It's hard to draw conclusions from this example because
it's degenerate. You do
On 4 May 2011 01:07, Greg Ewing wrote:
> mark florisson wrote:
>
>> cdef func(floating x, floating y):
>> ...
>>
>> you get a "float, float" version, and a "double, double" version, but
>> not "float, double" or "double, float".
>
> It's hard to draw conclusions from this example because
> it's
On Tue, May 3, 2011 at 4:40 PM, Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> ctypedef fused_type(float, double) speed_t
>> ctypedef fused_type(float, double) acceleration_t
>>
>> then you get 4 specializations.
>>
>> ctypedef speed_t acceleration_t
>>
>> I guess only 2 specializations.
>>
On Tue, May 3, 2011 at 12:59 PM, Dag Sverre Seljebotn
wrote:
> On 05/03/2011 08:19 PM, Robert Bradshaw wrote:
>
>>> 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 m
Dag Sverre Seljebotn wrote:
ctypedef fused_type(float, double) speed_t
ctypedef fused_type(float, double) acceleration_t
then you get 4 specializations.
ctypedef speed_t acceleration_t
I guess only 2 specializations.
Treating the typedefs in this way is slightly fishy of course.
Indeed. Th
mark florisson wrote:
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
It's hard to draw conclusions from this example because
it's degenerate. You don't really need multiple versions of a
On 05/03/2011 08:19 PM, Robert Bradshaw wrote:
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.
Well, we'll want to avoid compil
On Tue, May 3, 2011 at 10:06 AM, mark florisson
wrote:
> On 3 May 2011 18:00, Robert Bradshaw wrote:
>> floating is implicitly available, we could require making it explicit.
>
> How would we make it explicit.
Require the parameterization, i.e.
floating_p[floating]
would be the as-yet-unsp
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 p
On 3 May 2011 18:00, Robert Bradshaw wrote:
> On Tue, May 3, 2011 at 12:59 AM, mark florisson
> wrote:
>> On 3 May 2011 00:21, Robert Bradshaw wrote:
>>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>>> wrote:
On 2 May 2011 18:24, Robert Bradshaw wrote:
> On Sun, May 1, 2011 at 2:38
On 3 May 2011 16:36, Sturla Molden wrote:
> Den 03.05.2011 16:06, skrev Dag Sverre Seljebotn:
>>
>> Well, if you do something like
>>
>> ctypedef fused_type(float, double) speed_t
>> ctypedef fused_type(float, double) acceleration_t
>>
>> cdef func(speed_t x, acceleration_t y)
>>
>> then you get 4
On Tue, May 3, 2011 at 7:06 AM, Dag Sverre Seljebotn
wrote:
> On 05/03/2011 03:51 PM, Stefan Behnel wrote:
>>
>> mark florisson, 03.05.2011 15:17:
>>>
>>> if you have
>>>
>>> cdef func(floating x, floating y):
>>> ...
>>>
>>> you get a "float, float" version, and a "double, double" version, but
>>
On Tue, May 3, 2011 at 12:59 AM, mark florisson
wrote:
> On 3 May 2011 00:21, Robert Bradshaw wrote:
>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>> wrote:
>>> On 2 May 2011 18:24, Robert Bradshaw wrote:
On Sun, May 1, 2011 at 2:38 AM, mark florisson
wrote:
> A remaining iss
Den 03.05.2011 16:06, skrev Dag Sverre Seljebotn:
Well, if you do something like
ctypedef fused_type(float, double) speed_t
ctypedef fused_type(float, double) acceleration_t
cdef func(speed_t x, acceleration_t y)
then you get 4 specializations. Each new typedef gives a new
polymorphic type.
On 05/03/2011 03:51 PM, Stefan Behnel wrote:
mark florisson, 03.05.2011 15:17:
if you have
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
So, what would you have to do in order to get a "flo
mark florisson, 03.05.2011 15:17:
if you have
cdef func(floating x, floating y):
...
you get a "float, float" version, and a "double, double" version, but
not "float, double" or "double, float".
So, what would you have to do in order to get a "float, double" and
"double, float" version
On 3 May 2011 15:17, mark florisson wrote:
> On 3 May 2011 07:47, Greg Ewing wrote:
>> I'm a bit confused about how fused types combine to
>> create further fused types. If you have something
>> like
>>
>> ctypedef struct Vector:
>> floating x
>> floating y
>> floating z
>>
>> then is i
On 3 May 2011 07:47, Greg Ewing wrote:
> I'm a bit confused about how fused types combine to
> create further fused types. If you have something
> like
>
> ctypedef struct Vector:
> floating x
> floating y
> floating z
>
> then is it going to generate code for all possible
> combinations
I'm a bit confused about how fused types combine to
create further fused types. If you have something
like
ctypedef struct Vector:
floating x
floating y
floating z
then is it going to generate code for all possible
combinations of types for x, y and z?
That's probably not what the
On 3 May 2011 10:57, Dag Sverre Seljebotn wrote:
> On 05/03/2011 10:49 AM, mark florisson wrote:
>>
>> On 3 May 2011 10:44, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn
wrote:
>
> On 05/03/20
On 05/03/2011 10:49 AM, mark florisson wrote:
On 3 May 2011 10:44, Dag Sverre Seljebotn wrote:
On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn
wrote:
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw
wrote:
On
On 3 May 2011 10:44, Dag Sverre Seljebotn wrote:
> On 05/03/2011 10:42 AM, mark florisson wrote:
>>
>> On 3 May 2011 10:07, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw
wrote:
>
> On Mon, May 2, 2
On 05/03/2011 10:42 AM, mark florisson wrote:
On 3 May 2011 10:07, Dag Sverre Seljebotn wrote:
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshawwrote:
On Mon, May 2, 2011 at 1:56 PM, mark florisson
wrote:
On 2 May 2011 18:24, Robert Bradshaw
wrot
On 3 May 2011 10:07, Dag Sverre Seljebotn wrote:
> On 05/03/2011 09:59 AM, mark florisson wrote:
>>
>> On 3 May 2011 00:21, Robert Bradshaw wrote:
>>>
>>> On Mon, May 2, 2011 at 1:56 PM, mark florisson
>>> wrote:
On 2 May 2011 18:24, Robert Bradshaw
wrote:
>
> On Sun, Ma
On 05/03/2011 09:59 AM, mark florisson wrote:
On 3 May 2011 00:21, Robert Bradshaw wrote:
On Mon, May 2, 2011 at 1:56 PM, mark florisson
wrote:
On 2 May 2011 18:24, Robert Bradshaw wrote:
On Sun, May 1, 2011 at 2:38 AM, mark florisson
wrote:
A remaining issue which I'm not quite certain
On 3 May 2011 00:21, Robert Bradshaw wrote:
> On Mon, May 2, 2011 at 1:56 PM, mark florisson
> wrote:
>> On 2 May 2011 18:24, Robert Bradshaw wrote:
>>> On Sun, May 1, 2011 at 2:38 AM, mark florisson
>>> wrote:
A remaining issue which I'm not quite certain about is the
specialization
On Mon, May 2, 2011 at 1:56 PM, mark florisson
wrote:
> On 2 May 2011 18:24, Robert Bradshaw wrote:
>> On Sun, May 1, 2011 at 2:38 AM, mark florisson
>> wrote:
>>> A remaining issue which I'm not quite certain about is the
>>> specialization through subscripts, e.g. func[double]. How should this
On 2 May 2011 18:24, Robert Bradshaw wrote:
> On Sun, May 1, 2011 at 2:38 AM, mark florisson
> wrote:
>> On 30 April 2011 09:51, Dag Sverre Seljebotn
>> wrote:
>>> On 04/30/2011 08:39 AM, Robert Bradshaw wrote:
On Fri, Apr 29, 2011 at 3:53 AM, mark florisson
wrote:
>
>
On Sun, May 1, 2011 at 2:38 AM, mark florisson
wrote:
> On 30 April 2011 09:51, Dag Sverre Seljebotn
> wrote:
>> On 04/30/2011 08:39 AM, Robert Bradshaw wrote:
>>>
>>> On Fri, Apr 29, 2011 at 3:53 AM, mark florisson
>>> wrote:
On 29 April 2011 12:28, Pauli Virtanen wrote:
>
On 05/02/2011 03:00 PM, Sturla Molden wrote:
Den 02.05.2011 11:15, skrev Dag Sverre Seljebotn:
I.e., your question is very vague.
Ok, what I wanted to ask was "why have one syntax for interfacing C++
templates and another for generics?" It seems like syntax bloat to me.
You're welcome to d
On 05/02/2011 03:00 PM, Sturla Molden wrote:
Den 02.05.2011 11:15, skrev Dag Sverre Seljebotn:
I.e., your question is very vague.
Ok, what I wanted to ask was "why have one syntax for interfacing C++
templates and another for generics?" It seems like syntax bloat to me.
But we do that. The
Den 02.05.2011 11:15, skrev Dag Sverre Seljebotn:
I.e., your question is very vague.
Ok, what I wanted to ask was "why have one syntax for interfacing C++
templates and another for generics?" It seems like syntax bloat to me.
You're welcome to draft your own proposal for full-blown templat
On 2 May 2011 12:32, Stefan Behnel wrote:
> mark florisson, 02.05.2011 11:22:
>>
>> On 2 May 2011 11:08, Stefan Behnel wrote:
>>>
>>> Robert Bradshaw, 30.04.2011 08:16:
On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
>
> With the type matching it matches on exactly 'if src_type i
mark florisson, 02.05.2011 11:22:
On 2 May 2011 11:08, Stefan Behnel wrote:
Robert Bradshaw, 30.04.2011 08:16:
On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
With the type matching it matches on exactly 'if src_type is
dst_type:' so you can't use 'and' and such... perhaps I should turn
thes
On 2 May 2011 11:08, Stefan Behnel wrote:
> Robert Bradshaw, 30.04.2011 08:16:
>>
>> On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
>>>
>>> With the type matching it matches on exactly 'if src_type is
>>> dst_type:' so you can't use 'and' and such... perhaps I should turn
>>> these expression int
On 05/01/2011 06:25 PM, Sturla Molden wrote:
Den 01.05.2011 16:36, skrev Stefan Behnel:
Not everyone uses C++. And the C++ compiler cannot adapt the code to
specific Python object types.
Ok, that makes sence.
Second question: Why not stay with the current square-bracket syntax?
Does Cython
n
Robert Bradshaw, 30.04.2011 08:16:
On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
With the type matching it matches on exactly 'if src_type is
dst_type:' so you can't use 'and' and such... perhaps I should turn
these expression into a node with the constant value first and then
see if the resul
Sturla Molden, 01.05.2011 18:25:
I'd also think duck types could be specialised from run-time information?
(Cf. profile-guided optimisation.)
Interesting. That could even be much simpler than WPA. Basically, the
profiler would dump the argument types it sees, and then generate a .pxd
file wit
Den 01.05.2011 16:36, skrev Stefan Behnel:
Not everyone uses C++. And the C++ compiler cannot adapt the code to
specific Python object types.
Ok, that makes sence.
Second question: Why not stay with the current square-bracket syntax?
Does Cython
need a fused-type in addition?
I'd also thi
Sturla Molden, 01.05.2011 15:29:
Den 01.05.2011 02:24, skrev Greg Ewing:
Stefan Behnel wrote:
Meaning, we'd find a new type during type analysis or inference, split
off a new version of the function and then analyse it.
I'm not sure that this degree of smartness would really
be a good idea. I
Den 01.05.2011 02:24, skrev Greg Ewing:
Stefan Behnel wrote:
Meaning, we'd find a new type during type analysis or inference,
split off a new version of the function and then analyse it.
I'm not sure that this degree of smartness would really
be a good idea. I'd worry that if I made a type err
On 30 April 2011 09:51, Dag Sverre Seljebotn wrote:
> On 04/30/2011 08:39 AM, Robert Bradshaw wrote:
>>
>> On Fri, Apr 29, 2011 at 3:53 AM, mark florisson
>> wrote:
>>>
>>> On 29 April 2011 12:28, Pauli Virtanen wrote:
No, just that real_t is specialized to float whenever struct_t is
Stefan Behnel wrote:
Meaning, we'd find a new type during type analysis
or inference, split off a new version of the function and then analyse
it.
I'm not sure that this degree of smartness would really
be a good idea. I'd worry that if I made a type error
somewhere, the compiler would go off
On Sat, Apr 30, 2011 at 7:24 AM, Stefan Behnel wrote:
> Robert Bradshaw, 29.04.2011 06:32:
>>
>> On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel
>> wrote:
>>>
>>> mark florisson, 28.04.2011 23:29:
On 28 April 2011 22:31, mark florisson wrote:
>
> On 28 April 2011 22:12, Robert Br
On Sat, Apr 30, 2011 at 12:51 AM, Dag Sverre Seljebotn
wrote:
> On 04/30/2011 08:39 AM, Robert Bradshaw wrote:
>>
>> On Fri, Apr 29, 2011 at 3:53 AM, mark florisson
>> wrote:
>>>
>>> On 29 April 2011 12:28, Pauli Virtanen wrote:
No, just that real_t is specialized to float whenever st
Robert Bradshaw, 29.04.2011 06:32:
On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel wrote:
mark florisson, 28.04.2011 23:29:
On 28 April 2011 22:31, mark florisson wrote:
On 28 April 2011 22:12, Robert Bradshaw wrote:
On Thu, Apr 28, 2011 at 12:48 PM, mark florisson wrote:
So I fixed all
On 04/30/2011 08:39 AM, Robert Bradshaw wrote:
On Fri, Apr 29, 2011 at 3:53 AM, mark florisson
wrote:
On 29 April 2011 12:28, Pauli Virtanen wrote:
No, just that real_t is specialized to float whenever struct_t is specialized
to A and to double when B. Or a more realistic example,
c
On Fri, Apr 29, 2011 at 3:53 AM, mark florisson
wrote:
> On 29 April 2011 12:28, Pauli Virtanen wrote:
>> Fri, 29 Apr 2011 11:30:19 +0200, mark florisson wrote:
>>> On 29 April 2011 11:03, Pauli Virtanen wrote:
>> [clip]
Are you planning to special-case the "real_t complex" syntax? Shooting
On Fri, Apr 29, 2011 at 8:04 AM, mark florisson
wrote:
> On 29 April 2011 06:32, Robert Bradshaw wrote:
>> On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel wrote:
>>> mark florisson, 28.04.2011 23:29:
On 28 April 2011 22:31, mark florisson wrote:
>
> On 28 April 2011 22:12, Rober
Fri, 29 Apr 2011 16:59:22 +0200, mark florisson wrote:
[clip]
> Hmm, indeed, it's pretty weird. I'm fine with the pairing also, although
> I'm still not sure how common this case is, and if we really want to
> support it. Wouldn't good old C promotion work for this? e.g. if the
> type is either flo
On 29 April 2011 06:32, Robert Bradshaw wrote:
> On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel wrote:
>> mark florisson, 28.04.2011 23:29:
>>>
>>> On 28 April 2011 22:31, mark florisson wrote:
On 28 April 2011 22:12, Robert Bradshaw wrote:
>
> On Thu, Apr 28, 2011 at 12:48 PM,
On 29 April 2011 13:37, Pauli Virtanen wrote:
> Fri, 29 Apr 2011 12:53:06 +0200, mark florisson wrote:
> [clip]
>> But if we just allow that for fused types, then couldn't we simply do
>>
>> ctypedef cython.fused_type(float, double) real_t
>>
>> cdef real_plus_one(real_t complex a):
>> real_t
Fri, 29 Apr 2011 12:53:06 +0200, mark florisson wrote:
[clip]
> But if we just allow that for fused types, then couldn't we simply do
>
> ctypedef cython.fused_type(float, double) real_t
>
> cdef real_plus_one(real_t complex a):
> real_t b = a.real
> return b + 1
>
> ? Then you don't nee
On 04/29/2011 12:53 PM, mark florisson wrote:
On 29 April 2011 12:28, Pauli Virtanen wrote:
Fri, 29 Apr 2011 11:30:19 +0200, mark florisson wrote:
On 29 April 2011 11:03, Pauli Virtanen wrote:
[clip]
Are you planning to special-case the "real_t complex" syntax? Shooting
from the sidelines,
On 29 April 2011 12:28, Pauli Virtanen wrote:
> Fri, 29 Apr 2011 11:30:19 +0200, mark florisson wrote:
>> On 29 April 2011 11:03, Pauli Virtanen wrote:
> [clip]
>>> Are you planning to special-case the "real_t complex" syntax? Shooting
>>> from the sidelines, one more generic solution might be, e
Fri, 29 Apr 2011 11:30:19 +0200, mark florisson wrote:
> On 29 April 2011 11:03, Pauli Virtanen wrote:
[clip]
>> Are you planning to special-case the "real_t complex" syntax? Shooting
>> from the sidelines, one more generic solution might be, e.g.,
>
> I'm sorry, I'm not sure what syntax you are
On 29 April 2011 11:03, Pauli Virtanen wrote:
> Fri, 29 Apr 2011 10:23:55 +0200, mark florisson wrote:
> [clip]
>> Ok, branching on the type sounds fine to me. It brings one problem
>> though: because you cannot declare the variables of your variable type
>> (the type of say, mystruct.attrib), you
Fri, 29 Apr 2011 10:23:55 +0200, mark florisson wrote:
[clip]
> Ok, branching on the type sounds fine to me. It brings one problem
> though: because you cannot declare the variables of your variable type
> (the type of say, mystruct.attrib), you will need to do multiple
> declarations outside of yo
On 29 April 2011 06:32, Robert Bradshaw wrote:
> On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel wrote:
>> mark florisson, 28.04.2011 23:29:
>>>
>>> On 28 April 2011 22:31, mark florisson wrote:
On 28 April 2011 22:12, Robert Bradshaw wrote:
>
> On Thu, Apr 28, 2011 at 12:48 PM,
On 28 April 2011 23:59, Robert Bradshaw wrote:
> On Thu, Apr 28, 2011 at 2:29 PM, mark florisson
> wrote:
>> On 28 April 2011 22:31, mark florisson wrote:
>>> On 28 April 2011 22:12, Robert Bradshaw
>>> wrote:
On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
wrote:
> So I f
On 28 April 2011 23:30, Robert Bradshaw wrote:
> On Thu, Apr 28, 2011 at 1:31 PM, mark florisson
> wrote:
>> On 28 April 2011 22:12, Robert Bradshaw wrote:
>>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
>>> wrote:
>>>
So I fixed all that, but I'm currently wondering about the propose
On Thu, Apr 28, 2011 at 7:09 PM, Stefan Behnel wrote:
> mark florisson, 28.04.2011 23:29:
>>
>> On 28 April 2011 22:31, mark florisson wrote:
>>>
>>> On 28 April 2011 22:12, Robert Bradshaw wrote:
On Thu, Apr 28, 2011 at 12:48 PM, mark florisson wrote:
> So I fixed all that, but
mark florisson, 28.04.2011 23:29:
On 28 April 2011 22:31, mark florisson wrote:
On 28 April 2011 22:12, Robert Bradshaw wrote:
On Thu, Apr 28, 2011 at 12:48 PM, mark florisson wrote:
So I fixed all that, but I'm currently wondering about the proposed
cython.typeof(). I believe it currently re
On Thu, Apr 28, 2011 at 2:29 PM, mark florisson
wrote:
> On 28 April 2011 22:31, mark florisson wrote:
>> On 28 April 2011 22:12, Robert Bradshaw wrote:
>>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
>>> wrote:
>>>
So I fixed all that, but I'm currently wondering about the proposed
>
On Thu, Apr 28, 2011 at 1:31 PM, mark florisson
wrote:
> On 28 April 2011 22:12, Robert Bradshaw wrote:
>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
>> wrote:
>>
>>> So I fixed all that, but I'm currently wondering about the proposed
>>> cython.typeof(). I believe it currently returns a s
On 28 April 2011 22:31, mark florisson wrote:
> On 28 April 2011 22:12, Robert Bradshaw wrote:
>> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
>> wrote:
>>
>>> So I fixed all that, but I'm currently wondering about the proposed
>>> cython.typeof(). I believe it currently returns a string wit
On 28 April 2011 22:12, Robert Bradshaw wrote:
> On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
> wrote:
>
>> So I fixed all that, but I'm currently wondering about the proposed
>> cython.typeof(). I believe it currently returns a string with the type
>> name, and not the type itself.
>
> Yes.
On Thu, Apr 28, 2011 at 12:48 PM, mark florisson
wrote:
> So I fixed all that, but I'm currently wondering about the proposed
> cython.typeof(). I believe it currently returns a string with the type
> name, and not the type itself.
Yes. This is just because there's not really anything better to
On 28 April 2011 22:10, mark florisson wrote:
> On 28 April 2011 21:58, Stefan Behnel wrote:
>> mark florisson, 28.04.2011 21:48:
>>>
>>> I'm currently wondering about the proposed
>>> cython.typeof(). I believe it currently returns a string with the type
>>> name, and not the type itself. So I t
On 28 April 2011 21:58, Stefan Behnel wrote:
> mark florisson, 28.04.2011 21:48:
>>
>> I'm currently wondering about the proposed
>> cython.typeof(). I believe it currently returns a string with the type
>> name, and not the type itself. So I think it would be inconsistent to
>> suddenly start all
mark florisson, 28.04.2011 21:48:
I'm currently wondering about the proposed
cython.typeof(). I believe it currently returns a string with the type
name, and not the type itself. So I think it would be inconsistent to
suddenly start allowing comparison with 'is' and 'isinstance' and
such.
I'm al
On 26 April 2011 20:05, Robert Bradshaw wrote:
> On Tue, Apr 26, 2011 at 8:18 AM, mark florisson
> wrote:
>> On 26 April 2011 16:43, Stefan Behnel wrote:
>>> mark florisson, 26.04.2011 16:23:
I've been working a bit on fused types
(http://wiki.cython.org/enhancements/fusedtypes),
mark florisson, 26.04.2011 17:18:
On 26 April 2011 16:43, Stefan Behnel wrote:
mark florisson, 26.04.2011 16:23:
I've been working a bit on fused types
(http://wiki.cython.org/enhancements/fusedtypes), and I've got it to
generate code for every permutation of specific types. Currently it
only
On Tue, Apr 26, 2011 at 8:18 AM, mark florisson
wrote:
> On 26 April 2011 16:43, Stefan Behnel wrote:
>> mark florisson, 26.04.2011 16:23:
>>>
>>> I've been working a bit on fused types
>>> (http://wiki.cython.org/enhancements/fusedtypes), and I've got it to
>>> generate code for every permutatio
On 26 April 2011 16:43, Stefan Behnel wrote:
> mark florisson, 26.04.2011 16:23:
>>
>> I've been working a bit on fused types
>> (http://wiki.cython.org/enhancements/fusedtypes), and I've got it to
>> generate code for every permutation of specific types. Currently it
>> only works for cdef functi
mark florisson, 26.04.2011 16:23:
I've been working a bit on fused types
(http://wiki.cython.org/enhancements/fusedtypes), and I've got it to
generate code for every permutation of specific types. Currently it
only works for cdef functions. Now in SimpleCallNode I'm trying to use
PyrexTypes.best_
Hey,
I've been working a bit on fused types
(http://wiki.cython.org/enhancements/fusedtypes), and I've got it to
generate code for every permutation of specific types. Currently it
only works for cdef functions. Now in SimpleCallNode I'm trying to use
PyrexTypes.best_match() to find the function w
95 matches
Mail list logo
