2 byte float in MSVC++

Re: 2 byte float in MSVC++

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

The Code Master
The_Code_Master @hotmail.com

<spasmous@yahoo .com> wrote in message
news:1129604336 .060430.6380@g4 7g2000cwa.googl egroups.com...[color=blue]
> 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 :)
>[/color]

Re: 2 byte float in MSVC++

On 17 Oct 2005 19:58:56 -0700, spasmous@yahoo. com wrote in
comp.lang.c++:
[color=blue]
> 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 :)[/color]

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.l earn.c-c++

Re: 2 byte float in MSVC++

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. :)

Re: 2 byte float in MSVC++

persenaama wrote:[color=blue]
> 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. :)[/color]

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

Re: 2 byte float in MSVC++

mlimber wrote:[color=blue]
>
> 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.
>[/color]


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 :)

Re: 2 byte float in MSVC++


spasmous@yahoo. com wrote:[color=blue]
> mlimber wrote:[color=green]
> >
> > 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.
> >[/color]
>
>
> 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 :)[/color]

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.