Author pitrou
Recipients casevh, josh.r, lemburg, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, vstinner, yselivanov, zbyrne
Date 2016-02-04.14:06:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <56B35AF7.7030500@free.fr>
In-reply-to <1454594095.73.0.393687709596.issue21955@psf.upfronthosting.co.za>
Content
Le 04/02/2016 14:54, Yury Selivanov a écrit :
> 
> 30% faster floats (sic!) is a serious improvement, that shouldn't
> just be discarded. Many applications have floating point calculations one way
> or another, but don't use numpy because it's an overkill.

Can you give any example of such an application and how they would
actually benefit from "faster floats"? I'm curious why anyone who wants
fast FP calculations would use pure Python with CPython...

Discarding Numpy because it's "overkill" sounds misguided to me.
That's like discarding asyncio because it's "less overkill" to write
your own select() loop. It's often far more productive to use the
established, robust, optimized library rather than tweak your own
low-level code.

(and Numpy is easier to learn than asyncio ;-))

I'm not violently opposing the patch, but I think maintenance effort
devoted to such micro-optimizations is a bit wasted. And once you add
such a micro-optimization, trying to remove it often faces a barrage of
FUD about making Python slower, even if the micro-optimization is
practically worthless.

> Python 2 is much faster than Python 3 on any kind of numeric
> calculations.

Actually, it shouldn't really be faster on FP calculations, since the
float object hasn't changed (as opposed to int/long). So I'm skeptical
of FP-heavy code that would have been made slower by Python 3 (unless
there's also integer handling in that, e.g. indexing).
History
Date User Action Args
2016-02-04 14:06:51pitrousetrecipients: + pitrou, lemburg, rhettinger, mark.dickinson, vstinner, casevh, serhiy.storchaka, yselivanov, josh.r, zbyrne
2016-02-04 14:06:50pitroulinkissue21955 messages
2016-02-04 14:06:50pitroucreate