A good option for arbitrary floating-point precision is MPFR (
http://www.mpfr.org/ ). This library is LGPL and, according to the FAQ,
"The precision of a MPFR variable is the *exact* number of bits used for
its mantissa (...) this implies that the MPFR results do not depend on the
number of bits (16, 32, 64 or more) of the underlying architecture."
2013/6/18 Steve Strobel <[email protected]>
> On 06/12/2013 01:00 PM, Bruce Perens wrote:
> > I didn't immediately find a full-featured half float library in OpenEXR,
> > but there seems to be one at http://half.sourceforge.net/
>
> On Wed, Jun 12, 2013 at 3:09 PM, Bruce Perens <[email protected]> wrote:
>
>> Under the hood, this is implemented with single-precision float. I would
>> expect functions for OpenEXR to be done the same. I'd expect it to offer
>> more consistency for testing, but it might still have some issues.
>>
>
> Good find at Sourceforge. I haven't dug into either of them deeply enough
> to compare the internals (I did compile the OpenEXR version as a library
> for Blackfin). But judging by the description of OpenEXR, I think it is
> truly 16-bit internally. http://www.openexr.com/about.html says, "ILM
> decided to develop a new HDR file format with 16-bit floating-point color
> component values. Since the IEEE-754 floating-point specification does not
> define a 16-bit format, ILM created the "half" format. Half values have 1
> sign bit, 5 exponent bits, and 10 mantissa bits...The half format supports
> denormalized numbers, positive and negative infinities, and NaNs. It is
> identical to the half data type in NVIDIA's Cg graphics language, allowing
> a developer to process values from an OpenEXR image directly on current
> NVIDIA GPUs such as the GeForce FX family."
>
> I think the half class is part of IlmBase which can be downloaded here:
> http://www.openexr.com/downloads.html. Bruce, I will email you the rest
> of my notes about it; they are are kind of large to attach here. If
> anyone else is interested in them, just email me directly.
>
> Note that I wasn't suggesting that a 16-bit float library would
> necessarily be the right tool to use for verifying codec2; I was thinking
> that a very high precision software float library would probably be most
> appropriate for that, as it would tend to give the same output even if the
> order of operations (and any resulting rounding/truncation) changed. I
> haven't looked for such a high-precision library.
>
> Steve
>
>
> --
> Steve Strobel
> Link Communications, Inc.
> 1035 Cerise Rd
> Billings, MT 59101-7378
> (406) 245-5002 ext 102
> (406) 245-4889 (fax)
> WWW: http://www.link-comm.com
> MailTo:[email protected]
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
