ENH: float 4 IBM format support as part of the basic types (such as 'f4')

I’m aware that there are some ufunctions which convert float4ibm to ieee float and inverse. The point of this enhancement request that there are many file formats (mostly in Earth Science) dealing with float4ibm and doing something like:

#assuming that 'w4' is format for float4ibm
mytype=numpy.dtype([('integer','>i4'),('float4ibm','>w4'),('string','S5')])
...
a=numpy.fromfile(fd,dtype=mytype,count=100)
...
a.tofile('updated.data',dtype=mytype)

looks much cleaner (and possibly closer to the user) than

#implement ufunc or cython or python version of **float4ieee** and **float4ibm**
mytype=numpy.dtype([('integer','>i4'),('float4ibm','i4'),('string','S5')])
...
a=numpy.fromfile(fd,dtype=mytype,count=100)
b=float4ieee(a['float4ibm'][:])
...
a['float4ibm'][:]=float4ibm(b)
a.tofile('chnaged.data',dtype=mytype)

My point is that ibm float is the same thing as ieee 4 byte and having one implemented and not another is unfair.

[mhvk]

@thoth291 - I don’t think I was trying to diminish the importance, but really just argue where things belong. Surely, if one runs large jobs on supercomputers, one has standard seismic python packages that one uses (with hopefully numpy under the hood). Separation of concerns suggests those should those take care of the conversion.

And yes, astronomy is also a large user of supercompuers, and at least on my blue gene jobs here in Toronto, I combine packages I wrote myself with astropy + numpy. If an equivalent to astropy does not exist for seismic studies, perhaps it should be made to?

Anyway, since I will neither be writing the code nor deciding the fate of any pull request to implement it, I’ll shut up now.

[rkern]

It’s certainly fair to only implement IEEE floats since none of the CPU architectures that we support implement native IBM float arithmetic.

You will always have to convert to a native float somewhere along the line. The conversions could be made more convenient, certainly, and it might be useful to implement these conversion functions in numpy (@njsmith, yes these are quite common in the geosciences. The standards date from the 70s when VAXes ruled the Earth). One could imagine a function that takes a structured array and converts specified fields in-place and returns a view on the converted data with the native dtypes and another to go the other way.

It might also be reasonable to implement an arithmetic-less dtype for this purpose, so you just need to use .astype(). However, that approach encourages (requires) memory-copying while the explicit conversions above can be written to avoid that, which is often desirable since you only need to do these conversions upon I/O.