CustomFloat

[Bill Baxter]

On Fri, Oct 17, 2008 at 1:56 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Fri, Oct 17, 2008 at 1:30 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>> I found myself in need for smaller and specialized floating point types,
>>> where I configure the exact configuration (sign, mantissa, exponent,
>>> bias).
>>> See http://en.wikipedia.org/wiki/Half_precision for a half precision
>>> number
>>> slated for inclusion in IEEE 754r.
>>>
>>> Would it be interesting to add a CustomFloat template to phobos? I'm
>>> thinking along the lines of:
>>>
>>> template CustomFloat!(bool sign, uint mantissa,
>>>       uint exponent, uint bias)
>>> {
>>>   ...
>>> }
>>>
>>> So half-precision numbers are:
>>>
>>> alias CustomFloat!(true, 5, 10, 15) HalfFloat;
>>>
>>> There are quite a few details to kink out but this is definitely doable.
>>> Numbers like 24-bit floating point and even 8-bit floating point would be
>>> easy to support too. For now CustomFloat would be intended exclusively as
>>> a
>>> compact storage mechanism; only conversion to the standard floating
>>> points
>>> would be implemented. Later, maybe we can get to implement some
>>> operations
>>> natively at least on machines that support them in hardware. I wanted to
>>> gauge interest in the topic.
>>>
>>
>>
>> In theory it would be great to have this in Phobos.  I say in theory
>> because I haven't actually been in need of such a thing recently, but
>> it is definitely handy to have if you're working with high dynamic
>> range images (like from openEXR), or doing other GPU-related things.
>> Is that the kind of thing you need them for too?  I've heard of using
>> anything beyond 16-bit and 24-bit floats in the GPU/HDR world, though.
>>  A full generic solution is probably overkill for that.
>
> Yah, graphics is a big target for such types (and a big pusher for
> standardizing them). I need such numbers for different purposes, i.e.
> storing large arrays of probability distribution. In that case the range is
> [0, 1] and I need to cram those numbers in as little space as possible. I
> could definitely use a customized floating point layout.
>
> Note that a fully generic implementation is not overkill; if there are two
> layouts to support, you might as well support any.

Yeh, mostly thinking about ASM tweaks to make them fast.

That and handling of denormal numbers.  Not sure how regular denormals
are across different precisions of floating point numbers.   Been a
while since I looked at how denormals are defined, though.  Maybe it's
easy.

But writing optimized ASM for math ops is probably not as easy to do
in a generic way.  Don's probably going to prove me wrong though.  :-)

--bb