[Haskell-cafe] 16 bit floating point data in Haskell?

[Casey Hawthorne]

On Mon, 28 Sep 2009 12:06:47 +1300, you wrote:

>
>On Sep 28, 2009, at 9:40 AM, Olex P wrote:
>
>> Hi,
>>
>> Yes, I mean "sizeOf 2". It's useful not only on GPUs but also in  
>> "normal" software. Think of huge data sets in computer graphics  
>> (particle clouds, volumetric data, images etc.) Some data (normals,  
>> density, temperature and so on) can be easily represented as float  
>> 16 making files 200 GB instead of 300 GB. Good benefits.
>
> From the OpenEXR technical introduction:
>
>	half numbers have 1 sign bit, 5 exponent bits,
>	and 10 mantissa bits.  The interpretation of
>	the sign, exponent and mantissa is analogous
>	to IEEE-754 floating-point numbers.  half
>	supports normalized and denormalized numbers,
>	infinities and NANs (Not A Number).  The range
>	of representable numbers is roughly 6.0E-8 to 6.5E4;
>	numbers smaller than 6.1E-5 are denormalized.
>
>Single-precision floats are already dangerously short for
>many computations.  (Oh the dear old B6700 with 39 bits of
>precision in single-precision floats...)  Half-precision
>floats actually have less than half the precision of singles
>(11 bits instead of 23).  It's probably best to think of
>binary 16 as a form of compression for Float, and to write
>stuff that will read half-precision from a binary stream as
>single-precision, and conversely stuff that will accept
>single-precision values and write them to a binary stream in
>half-precision form.
>

I agree with the above.

I hadn't realized how dangerously short for many computations
single-precision is.

So, as he says, for computing, you do want to convert half-precision
to single-precision, if not double-precision.

If you want to save storage space, then some sort of compression
scheme might be better on secondary storage.

As for the video card, some sort of fast decompression scheme would be
necessary for the half-precision numbers coming in.

You are probably in the realm of DSP.

--
Regards,
Casey