[Numpy-discussion] np.longlong casts to int
Thu Feb 23 12:55:08 CST 2012
On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe <firstname.lastname@example.org> wrote:
> On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett <email@example.com>
>> On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
>> <firstname.lastname@example.org> wrote:
>> > Le 23/02/2012 17:28, Charles R Harris a écrit :
>> >> That's correct. They are both extended precision (80 bits), but
>> >> aligned on 32bit/64bit boundaries respectively. Sun provides a true
>> >> quad precision, also called float128, while on PPC long double is an
>> >> odd combination of two doubles.
>> > This is insane ! ;-)
>> I don't know if it's insane, but it is certainly very confusing, as
>> this thread the previous one show.
>> The question is, what would be less confusing?
> One approach would be to never alias longdouble as float###. Especially
> float128 seems to imply that it's the IEEE standard binary128 float, which
> it is on some platforms, but not on most.
It's virtually never IEEE binary128. Yarik Halchenko found a real one
on an s/360 running Debian. Some docs seem to suggest there are Sun
machines out there with binary128, as Chuck said. So the vast
majority of numpy users with float128 have Intel 80-bit, and some have
Do we all agree then that 'float128' is a bad name?
In the last thread, I had the feeling there was some consensus on
renaming Intel 80s to:
float128 -> float80_128
float96 -> float80_96
For those platforms implementing it, maybe
float128 -> float128_ieee
Maybe for PPC:
float128 -> float_pair_128
and, personally, I still think it would be preferable, and less
confusing, to encourage use of 'longdouble' instead of the various
platform specific aliases.
What do you think?
More information about the NumPy-Discussion