On Thu, Feb 23, 2012 at 5:23 AM, Francesc Alted <[email protected]>wrote:
> On Feb 23, 2012, at 6:06 AM, Francesc Alted wrote: > > On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote: > > > >> On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted <[email protected]> > wrote: > >>> Exactly. I'd update this to read: > >>> > >>> float96 96 bits. Only available on 32-bit (i386) platforms. > >>> float128 128 bits. Only available on 64-bit (AMD64) platforms. > >> > >> Except float96 is actually 80 bits. (Usually?) Plus some padding… > > > > Good point. The thing is that they actually use 96 bit for storage > purposes (this is due to alignment requirements). > > > > Another quirk related with this is that MSVC automatically maps long > double to 64-bit doubles: > > > > http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx > > > > Not sure on why they did that (portability issues?). > > Hmm, yet another quirk (this time in NumPy itself). On 32-bit platforms: > > In [16]: np.longdouble > Out[16]: numpy.float96 > > In [17]: np.finfo(np.longdouble).eps > Out[17]: 1.084202172485504434e-19 > > while on 64-bit ones: > > In [8]: np.longdouble > Out[8]: numpy.float128 > > In [9]: np.finfo(np.longdouble).eps > Out[9]: 1.084202172485504434e-19 > > i.e. NumPy is saying that the eps (machine epsilon) is the same on both > platforms, despite the fact that one uses 80-bit precision and the other > 128-bit precision. For the 80-bit, the eps should be (): > > 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. Chuck > In [5]: 1 / 2**63. >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
