Robert Bradshaw wrote: > On Oct 9, 2009, at 1:58 AM, Dag Sverre Seljebotn wrote: > >> Robert Bradshaw wrote: >> I think I figured out a nice way to fix this issue in general >> though...optimize >> >> some_int = int(some_float) >> >> Nice and Pythonic and one doesn't have to bother with casts, types >> etc. >> >> http://trac.cython.org/cython_trac/ticket/400 > > Very good point! I see people do int(...) and float(...) all the > time, and sometimes it's the only Python calls in their inner loops > (and makes everything else into a Python call as well. Would int(...) > return a long if it's going to be used in a C context? One issue is > that I use int(...) when I want an actual Python object, though I'm > sure we could figure something out.
Yes, I'd never support something that disturbs the actual semantics, I was only thinking about optimizations (more advanced than what we do now -- would perhaps need to have a stack of "preferred result types" go inwards in during type analysis...) So an overflow check must always be generated (in case of int(1e200)). And this cannot be optimized: some_int = int(some_float) + 1 ...in case the +1 makes it overflow integer. (Or, well, that's a seperate optimization calling for overflow-checking arithmetic which can be turned off with a compiler directive.) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
