Hi, On Sun, Oct 16, 2011 at 6:22 PM, Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Sun, Oct 16, 2011 at 6:13 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Sun, Oct 16, 2011 at 4:29 PM, Charles R Harris >> <charlesr.har...@gmail.com> wrote: >> > On Sun, Oct 16, 2011 at 4:16 PM, Nathaniel Smith <n...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion