I'm really showing my ignorance now, I think; so, the old-style "fmt % (tuple)" must use a different mechanism, and perhaps that's why np.savetxt never choked on a float32 for me before (yes, I am on a 64-bit system).
In [8]: type(tmp.lat) Out[8]: numpy.float32 In [9]: '%6s %8i %11.6f' % (tmp.sta, tmp.ondate, tmp.lat) Out[9]: ' XYZZ 2001123 -23.820000' Thanks again for your patience. On Jun 6, 2013, at 2:26 PM, Robert Kern wrote: > > np.float64 works because it inherits from the Python float type > (Python floats are 64-bit floats). np.float32 doesn't inherit from the > Python float type because it can't; they don't represent the same kind > of data, so their memory layouts at the C level cannot coincide. Since > you are on a 64-bit platform, np.int64 represents the same kind of > integer as the Python int type, so it can subclass, but an np.int32 > couldn't. > > It's not necessarily intuitive, but it's the best we can do under the > constraints. The only thing more intuitive would be to disallow > subclassing from the Python builtin types entirely, but that's > *really* annoying. > > -- > Robert Kern > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
