On Mar 2, 2012 10:48 AM, "Paweł Biernat" <pwl_b@wp.pl> wrote:
The portability is broken for numpy.float128 anyway (as I understand, it behaves in different ways on different architectures), so adding a new type (call it, say, quad128) that properly supports binary128 shouldn't be a drawback. Later on, when the hardware support for binary128 shows up, the quad128 will be already there.
There's already been movement to deprecate using float128 as the name for machine-specific long doubles. This just gives even more reason. If/when someone adds __float128 support to numpy we should really just call it float128, not quad128. (This would even be backwards compatible, since float128 currently gives no guarantees on precision or representation.) - n