Are you saying with all this that cdef object CHAR_MAX = <char>((<unsigned char>-1)>>1)
will not give me in CHAR_MAX a (Python) integer with the maximum value representable in a C char? On Thu, Mar 19, 2009 at 12:55 PM, Stefan Behnel <[email protected]> wrote: > Dag Sverre Seljebotn wrote: >> Stefan Behnel wrote: >>> Dag Sverre Seljebotn wrote: >>> >>>> Is it impossible for constant folding to happen before type annotation? >>>> After all, the type should be hard-coded in the class for constants? >>> >>> Not sure. At least, it needs scope and target type information in its >>> current way of working, as it does type coercions. It might be possible >>> to >>> remove that completely, and to determine the widest target type of two >>> operands instead. Want to have fun giving it a try? :) >>> >> Unfortunately email activity == procrastination != real opportunity for >> Cython activity; at least for the rest of this week. (And unfortunately >> procrastination doesn't work the way that one can simply "bottle it up" >> and use it for real coding :-) ). >> >> (I think that when I get a peaceful Cython moment, I'll focus on e.g. >> getting more nodes over to new temps; the constant folding has a >> learning curve and I should focus on the 0.12 stuff which doesn't >> involve a learning curve first; more effective use of manpower that way.) > > Sure, good idea. > > >>> BTW, I'm not sure how type casts should be handled. What about something >>> like this: >>> >>> cdef int x = 3 + <long><char>(2**10) >>> >> This is asking for a wraparound if you ask me. I'd say 2**10 folds, then >> leave it to runtime, because we cannot know the type sizes (at least of >> long). >>> ? Whereas >>> >>> cdef int x = 3 + <int>(2**10) >>> >>> would simplify just fine... >>> >> However, >> cdef long x = 3 + <long>(2**34) >> >> would simplify fine on non-Windows 64-bit but not otherwise. I'd be >> reluctant to simplify casts at all because the only intention I can find >> in code like that is to do a "& MAX_VALUE_OF_TYPE", and that stuff is >> much better left to the compiler. > > Yep. I also think that it's rather unlikely that users will put a type > cast before constants in places where compile time values are actually > interesting (such as loop ranges/steps). > > Stefan > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
