2 byte float in MSVC++

[spasmous]

Hi, I'm running out of memory storing a large float array. One
acceptable workaround would be to reduce the float precision by
switching from the default, which is 4 bytes long, to a smaller one -
say, 2 bytes.

I'm using MSVC++ 6.0 and don't see any way to do this. Perhaps MS does
not provide a 2 byte float...? Appreciate your advice. Thanks :)

[The Code Master]

Hi,
Is there anyway I could see the code? MSVC++ 6, is my favoured Editor, I
refuse to give it up.

The Code Master
Th*************@hotmail.com

<sp******@yahoo.com> wrote in message
news:11********************@g47g2000cwa.googlegrou ps.com...

Hi, I'm running out of memory storing a large float array. One
acceptable workaround would be to reduce the float precision by
switching from the default, which is 4 bytes long, to a smaller one -
say, 2 bytes.

I'm using MSVC++ 6.0 and don't see any way to do this. Perhaps MS does
not provide a 2 byte float...? Appreciate your advice. Thanks :)

[Jack Klein]

On 17 Oct 2005 19:58:56 -0700, sp******@yahoo.com wrote in
comp.lang.c++:

Hi, I'm running out of memory storing a large float array. One
acceptable workaround would be to reduce the float precision by
switching from the default, which is 4 bytes long, to a smaller one -
say, 2 bytes.

I'm using MSVC++ 6.0 and don't see any way to do this. Perhaps MS does
not provide a 2 byte float...? Appreciate your advice. Thanks :)

You're not going to find any conforming C++ compiler with a 16-bit
float. It doesn't meet the language requirements. Perhaps you need
to rethink your implementation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[persenaama]

OpenEXR has a fairly good 16-bit floating point type implementation in
C++. You cannot use it as drop-in replacement to 32-bit floating point,
though, for starters the range of values that can be stored is very
small. Works great for normalized or near normalized values (for color
for example this works great).

The implementation is same the Cg, HLSL and GLSL use, but it isn't
standard.. just de-facto standard. :)

[mlimber]

persenaama wrote:

OpenEXR has a fairly good 16-bit floating point type implementation in
C++. You cannot use it as drop-in replacement to 32-bit floating point,
though, for starters the range of values that can be stored is very
small. Works great for normalized or near normalized values (for color
for example this works great).

The implementation is same the Cg, HLSL and GLSL use, but it isn't
standard.. just de-facto standard. :)

Would the OP consider fixed point? If so, s/he could use 16-bit ints
(short ints on many platforms). Without delving into the OpenEXR, I'm
guessing that it would incur a more serious performance hit than fixed
point calculations since it would require emulation software rather
since hardware support for 16-bit floats is generally unavailable. Of
course, performance may not be an issue for the OP.

Cheers! --M

[spasmous]

mlimber wrote:

Would the OP consider fixed point? If so, s/he could use 16-bit ints
(short ints on many platforms). Without delving into the OpenEXR, I'm
guessing that it would incur a more serious performance hit than fixed
point calculations since it would require emulation software rather
since hardware support for 16-bit floats is generally unavailable. Of
course, performance may not be an issue for the OP.

That's an interesting suggestion. The float values I require are
strictly between 0.0 and 1.0. An unsigned short has range 0 to 65536,
so if I were to scale the floats into this range and cast to unsigned
short I would have an effective precision of 1.5e-5. I think that is
probably adequate, I'll try it - thanks for your help :)

[Chris Hulbert]

sp******@yahoo.com wrote:

mlimber wrote:

Would the OP consider fixed point? If so, s/he could use 16-bit ints
(short ints on many platforms). Without delving into the OpenEXR, I'm
guessing that it would incur a more serious performance hit than fixed
point calculations since it would require emulation software rather
since hardware support for 16-bit floats is generally unavailable. Of
course, performance may not be an issue for the OP.

That's an interesting suggestion. The float values I require are
strictly between 0.0 and 1.0. An unsigned short has range 0 to 65536,
so if I were to scale the floats into this range and cast to unsigned
short I would have an effective precision of 1.5e-5. I think that is
probably adequate, I'll try it - thanks for your help :)

It's actually a widely used suggestion especially in scientific data
storage where you typically know the range of data and you have some
fixed significant digits. Take for example an instrument measuring sea
surface temperature to an accuracy of 10^-4 degrees. You can typically
calculate a range of values the temperature can take in a "specific"
body of water. You then use a linear function y = mx + b to scale the
floating point data to some integer type. This is good especially in
storing large data sets where you can cut double or single precision
down to int32 or int16 storage size. When we stored data in HDF files,
we would specify the m and b (slope and intercept) as attributes to
recover the data.