Hi, On Sun, Oct 16, 2011 at 6:22 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Oct 16, 2011 at 6:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Sun, Oct 16, 2011 at 4:29 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sun, Oct 16, 2011 at 4:16 PM, Nathaniel Smith <njs@pobox.com> wrote:
I understand the argument that you don't want to call it "float80" because not all machines support a float80 type. But I don't understand why we would solve that problem by making up two *more* names (float96, float128) that describe types that *no* machines actually support... this is incredibly confusing.
Well, float128 and float96 aren't interchangeable across architectures because of the different alignments, C long double isn't portable either, and float80 doesn't seem to be available anywhere. What concerns me is the difference between extended and quad precision, both of which can occupy 128 bits. I've complained about that for several years now, but as to extended precision, just don't use it. It will never be portable.
I think part of the confusion here is about when a type is named like 'float<N>', does 'N' refer to the size of the data or to the minimum alignment? I have a strong intuition that it should be the former, and I assume Matthew does too. If we have a data structure like struct { uint8_t flags; void * data; }
We need both in theory, in practice floats and doubles are pretty well defined these days, but long doubles depend on architecture and compiler for alignment, and even for representation in the case of PPC. I don't regard these facts as obscure if one is familiar with floating point, but most folks aren't and I agree that it can be misleading if one assumes that types and storage space are strongly coupled. This also ties in to the problem with ints and longs, which may both be int32 despite having different C names.
then 'flags' will actually get 32 or 64 bits of space... but we would never, ever refer to it as a uint32 or a uint64! I know these extended precision types are even weirder because the compiler will insert that padding unconditionally, but the intuition still stands, and obviously some proportion of the userbase will share it.
If our API makes smart people like Matthew spend a week going around in circles, then our API is dangerously broken!
I think "dangerously" is a bit overly dramatic.
The solution is just to call it 'longdouble', which clearly communicates 'this does some quirky thing that depends on your C compiler and architecture'.
Well, I don't know. If someone is unfamiliar with floats I would expect they would post a complaint about bugs if a file of longdouble type written on a 32 bit system couldn't be read on a 64 bit system. It might be better to somehow combine both the ieee type and the storage alignment.
David was pointing out that e.g. np.float128 could be a different thing on SPARC, PPC and Intel, so it seems to me that the float128 is a false friend if we think it at all likely that people will use platforms other than Intel. Personally, if I saw 'longdouble' as a datatype, it would not surprise me if it wasn't portable across platforms, including 32 and 64 bit. float80_96 and float80_128 seem fine to me, but it would also be good to suggest longdouble as the default name to use for the platform-specific higher-precision datatype to make code portable across platforms. See you, Matthew