Thread: [GD-General] ieee754 -0.0f?
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Andras B. <and...@gm...> - 2006-02-01 16:50:12
|
I know that -0.0f == +0.0f is true, but the floating point representation of the two numbers should be different, no? Shouldn't the negative zero have the sign bit set? Well, on my machine -0.0 and 0.0 are bitwise equal!! What's going on here? thx, Andras -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Peter <pe...@to...> - 2006-02-01 17:34:10
|
what is the context here? If you're interpreting 0x80000000 (32 bit int) as a 32-bit IEEE float it's -0.0f and 0x00000000 is 0.0f. Where are you seeing the -0.0f? In a debugger? I think you must be seeing some idiosyncrasy of your development environment or toolchain. Andras Balogh wrote: > I know that -0.0f == +0.0f is true, but the floating point > representation of the two numbers should be different, no? Shouldn't > the negative zero have the sign bit set? Well, on my machine -0.0 and > 0.0 are bitwise equal!! What's going on here? > > thx, > > > Andras > |
|
From: Andras B. <and...@gm...> - 2006-02-01 17:51:09
|
I run this code:
float f = -0.0f;
void* p = *(reinterpret_cast<void**>(&f));
::printf("%f = %p\n", f, p);
And it prints all zeroes. For any other number I see the correct
hexadecimal representation of the float number.
Thanks,
Andras
On Wed, 01 Feb 2006 10:32:28 -0700, Peter <pe...@to...> wrote:
> what is the context here? If you're interpreting 0x80000000 (32 bit
> int) as a 32-bit IEEE float it's -0.0f and 0x00000000 is 0.0f.
> Where are you seeing the -0.0f? In a debugger? I think you must be
> seeing some idiosyncrasy of your development environment or toolchain.
>
> Andras Balogh wrote:
>
>> I know that -0.0f == +0.0f is true, but the floating point
>> representation of the two numbers should be different, no? Shouldn't
>> the negative zero have the sign bit set? Well, on my machine -0.0 and
>> 0.0 are bitwise equal!! What's going on here?
>>
>> thx,
>>
>>
>> Andras
|
|
From: Peter <pe...@to...> - 2006-02-01 18:49:14
|
then it's your compiler. When it translates the string/token "-0.0f"
apparently it's smart enough to generate a 'real' zero. I don't know of
any requirement that a compiler supports explicit generation of -0 in
any form; only that its underlying math behaves correctly.
So if you try this:
union { unsigned int asUInt; float asFloat; } val; val.asUInt =
0x80000000; printf("%f",val.asFloat);
you -may- see -0.0f depending on whether your printf implementation
cares to show the difference! Personally I've frequently been bitten by
quirks in the way a debugger's windows accept input or display output -
you need to look at a hex or binary display of memory and registers, and
use an assembly (rather than source-level) debug, to be sure of what's
really happening.
Peter
Andras Balogh wrote:
> I run this code:
>
> float f = -0.0f;
> void* p = *(reinterpret_cast<void**>(&f));
> ::printf("%f = %p\n", f, p);
>
> And it prints all zeroes. For any other number I see the correct
> hexadecimal representation of the float number.
>
>
> Thanks,
>
> Andras
>
>
>
> On Wed, 01 Feb 2006 10:32:28 -0700, Peter <pe...@to...> wrote:
>
>> what is the context here? If you're interpreting 0x80000000 (32 bit
>> int) as a 32-bit IEEE float it's -0.0f and 0x00000000 is 0.0f.
>> Where are you seeing the -0.0f? In a debugger? I think you must be
>> seeing some idiosyncrasy of your development environment or toolchain.
>>
>> Andras Balogh wrote:
>>
>>> I know that -0.0f == +0.0f is true, but the floating point
>>> representation of the two numbers should be different, no?
>>> Shouldn't the negative zero have the sign bit set? Well, on my
>>> machine -0.0 and 0.0 are bitwise equal!! What's going on here?
>>>
>>> thx,
>>>
>>>
>>> Andras
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
|
|
From: Brian H. <ho...@bo...> - 2006-02-01 17:49:15
|
On Wed, 01 Feb 2006 09:50:00 -0700, Andras Balogh wrote: > I know that -0.0f =3D=3D +0.0f is true, but the floating point > representation of the two numbers should be different, no? They are different, on an IEEE compliant system. IEEE-754 has the high bit reserved for sign, such that on a 32-bit system you would have: -0.0 =3D 0xbf800000 +0.0 =3D 0x3f800000 > Shouldn't the negative zero have the sign bit set? Well, on my > machine -0.0 and 0.0 are bitwise equal!! What's going on here? You didn't mention the language or how you're generating those values. Using VC6 on a Pentium-M by setting global floats I get the correct and expected values. Brian |
|
From: Andras B. <and...@gm...> - 2006-02-01 17:58:55
|
> They are different, on an IEEE compliant system. Yeah, I know, that's why I'm surprised! :) > -0.0 = 0xbf800000 > +0.0 = 0x3f800000 These are -1.0f and +1.0f, but yeah, I've got the point. > You didn't mention the language or how you're generating those values. > Using VC6 on a Pentium-M by setting global floats I get the correct > and expected values. VS7.1 running on Athlon64, see source in previous post. thanks, Andras |
|
From: Ash H. <hen...@gm...> - 2006-02-01 18:15:58
|
Hi Andras, I suspect you've got "Fast" floating point model selected in VS project options (check in C++->Code Generation I think). Running your code here with Strict or Precise gives: -0.000000 =3D 80000000 but it falls down how you describe (00000000), with Fast selected. (Turion 64 MSVC8 here). Cheers. -- Ash. On 2/1/06, Andras Balogh <and...@gm...> wrote: > > > They are different, on an IEEE compliant system. > > Yeah, I know, that's why I'm surprised! :) > > > -0.0 =3D 0xbf800000 > > +0.0 =3D 0x3f800000 > > These are -1.0f and +1.0f, but yeah, I've got the point. > > > You didn't mention the language or how you're generating those values. > > Using VC6 on a Pentium-M by setting global floats I get the correct > > and expected values. > > VS7.1 running on Athlon64, see source in previous post. > > > thanks, > > > > Andras > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 > |
|
From: Andras B. <and...@gm...> - 2006-02-01 18:26:21
|
Well, I've thought about that too, I'm running in debug mode, no optimizations and using improved floating point consistency (/Op). Still, -0.0f gives me 0x00000000.. On Wed, 01 Feb 2006 11:15:54 -0700, Ash Henstock <hen...@gm...> wrote: > Hi Andras, > > I suspect you've got "Fast" floating point model selected in VS project > options (check in C++->Code Generation I think). > Running your code here with Strict or Precise gives: > -0.000000 = 80000000 > but it falls down how you describe (00000000), with Fast selected. > > (Turion 64 MSVC8 here). > > Cheers. > > -- Ash. > > On 2/1/06, Andras Balogh <and...@gm...> wrote: >> >> > They are different, on an IEEE compliant system. >> >> Yeah, I know, that's why I'm surprised! :) >> >> > -0.0 = 0xbf800000 >> > +0.0 = 0x3f800000 >> >> These are -1.0f and +1.0f, but yeah, I've got the point. >> >> > You didn't mention the language or how you're generating those values. >> > Using VC6 on a Pentium-M by setting global floats I get the correct >> > and expected values. >> >> VS7.1 running on Athlon64, see source in previous post. >> >> >> thanks, >> >> >> >> Andras |
|
From: Jim T. <jim...@gm...> - 2006-02-01 18:50:49
|
Andreas, Seems like the visual compiler tries to be smart when you say "float b =3D = - 0.0f;", the outputed assembly looks like this: mov DWORD PTR _b$[ebp], 0 Notice in my previous post that I did "float b =3D 0.0f/-1.0f" ? That force= s the compiler to output: mov DWORD PTR _b$[ebp], -2147483648 ; 80000000H /j On 2/1/06, Andras Balogh <and...@gm...> wrote: > > Well, I've thought about that too, I'm running in debug mode, no > optimizations and using improved floating point consistency (/Op). Still, > -0.0f gives me 0x00000000.. > > On Wed, 01 Feb 2006 11:15:54 -0700, Ash Henstock <hen...@gm...> > wrote: > > > Hi Andras, > > > > I suspect you've got "Fast" floating point model selected in VS project > > options (check in C++->Code Generation I think). > > Running your code here with Strict or Precise gives: > > -0.000000 =3D 80000000 > > but it falls down how you describe (00000000), with Fast selected. > > > > (Turion 64 MSVC8 here). > > > > Cheers. > > > > -- Ash. > > > > On 2/1/06, Andras Balogh <and...@gm...> wrote: > >> > >> > They are different, on an IEEE compliant system. > >> > >> Yeah, I know, that's why I'm surprised! :) > >> > >> > -0.0 =3D 0xbf800000 > >> > +0.0 =3D 0x3f800000 > >> > >> These are -1.0f and +1.0f, but yeah, I've got the point. > >> > >> > You didn't mention the language or how you're generating those > values. > >> > Using VC6 on a Pentium-M by setting global floats I get the correct > >> > and expected values. > >> > >> VS7.1 running on Athlon64, see source in previous post. > >> > >> > >> thanks, > >> > >> > >> > >> Andras > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 > |
|
From: Andras B. <and...@gm...> - 2006-02-01 19:37:04
|
> Notice in my previous post that I did "float b = 0.0f/-1.0f" ? Yep, I did, and already answered that, it's just that the turnaround of this mailing list is somewhat slow, so we are always one post behind :) andras |
|
From: Ash H. <hen...@gm...> - 2006-02-01 20:18:32
|
Peter's earlier message with the union reminded me of some old, (horribly
non portable) code I had lying around. Marginally useful for fiddling with
float values, but mostly just a peculiarity. Scary :)
union __float
{
struct
{
unsigned m_mantissa : 24;
unsigned m_exponent : 7;
unsigned m_sign : 1;
};
int m_int;
unsigned int m_uint;
float m_float;
// -- a few implicit conversions
__float(float _f) { m_float =3D _f; }
__float(int _i) { m_int =3D _i; }
__float(unsigned int _i) { m_uint =3D _i; }
};
#ifdef _DEBUG
#define float __float
#endif
int _tmain(int argc, _TCHAR* argv[])
{
float f =3D 0;
/* -- can set in VC debugger; the one I have here you can at least
f.m_sign =3D 1;
f.m_exponent =3D 0;
f.m_mantissa =3D 0;
*/
void* p =3D *(reinterpret_cast<void**>(&f));
::printf("%.16e =3D %p\n", f.m_float, p);
return 0;
};
-- Ash.
On 2/1/06, Andras Balogh <and...@gm...> wrote:
>
> > Notice in my previous post that I did "float b =3D 0.0f/-1.0f" ?
>
> Yep, I did, and already answered that, it's just that the turnaround of
> this mailing list is somewhat slow, so we are always one post behind :)
>
>
>
> andras
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>
|
|
From: Jim T. <jim...@gm...> - 2006-02-01 18:19:55
|
Brian,
Hmmm, are you sure about those values? It thought the following was true:
Zeroes are special in IEEE574 since there is an implicit leading 1 in the
mantissa for 754 (which makes it impossible to get zero regardless of which
exponent we choose). So there are special values for zeroes in 754,
similarily to how Inf and NaN are specially represented. Conviniently ,
positive zero is all zeroes and negative zero just have the high bit set.
+0.0f =3D 0x00000000
-0.0f =3D 0x80000000
I don't have VC6 here, but for VC7 on a regular P4 box the following
produces the expected results:
#include <cstdio>
void main()
{
float a =3D 0.0f;
float b =3D 0.0f/-1.0f;
printf( "%f =3D 0x%8.8x\n", a, *(int*)&a );
printf( "%f =3D 0x%8.8x\n", b, *(int*)&b );
}
/j
On 2/1/06, Brian Hook <ho...@bo...> wrote:
>
> On Wed, 01 Feb 2006 09:50:00 -0700, Andras Balogh wrote:
> > I know that -0.0f =3D=3D +0.0f is true, but the floating point
> > representation of the two numbers should be different, no?
>
> They are different, on an IEEE compliant system. IEEE-754 has the
> high bit reserved for sign, such that on a 32-bit system you would
> have:
>
> -0.0 =3D 0xbf800000
> +0.0 =3D 0x3f800000
>
> > Shouldn't the negative zero have the sign bit set? Well, on my
> > machine -0.0 and 0.0 are bitwise equal!! What's going on here?
>
> You didn't mention the language or how you're generating those values.
> Using VC6 on a Pentium-M by setting global floats I get the correct
> and expected values.
>
> Brian
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>
|
|
From: Brian H. <ho...@bo...> - 2006-02-01 18:38:45
|
> Hmmm, are you sure about those values? It thought the following was > true: No, I'm a dumbass. In my curry to cut and paste I used -1 and +1. Sorry for any confusion =3D/ On VC6 it does report 0x00000000 for both -0 and +0. Brian |
|
From: Andras B. <and...@gm...> - 2006-02-01 19:04:44
|
Hah, there's the problem! Your program gives me the expected result, but
if I replace "0.0f/-1.0f" to simply "-0.0f", then I get the wrong result!
andras
On Wed, 01 Feb 2006 11:19:40 -0700, Jim Tilander <jim...@gm...>
wrote:
> I don't have VC6 here, but for VC7 on a regular P4 box the following
> produces the expected results:
>
> #include <cstdio>
>
> void main()
> {
> float a = 0.0f;
> float b = 0.0f/-1.0f;
>
> printf( "%f = 0x%8.8x\n", a, *(int*)&a );
> printf( "%f = 0x%8.8x\n", b, *(int*)&b );
> }
>
>
> /j
>
|
|
From: Jon W. <hp...@mi...> - 2006-02-02 17:52:33
|
> struct
> {
> unsigned m_mantissa : 24;
> unsigned m_exponent : 7;
> unsigned m_sign : 1;
> };
I believe the mantissa is only 23 bits, with a leading "implicit" one
for all exponents that aren't denormal. There are also 8 exponent bits.
Cheers,
/ h+
--
-- The early bird gets the worm, but the second mouse gets the cheese.
|
|
From: Ash H. <hen...@gm...> - 2006-02-02 18:03:51
|
Indeed you are right. I'll be off hanging my head somewhere...
;)
Regardless, it's pretty horrible thing to be doing. I think I originally
wrote it to generate homework answers when I was doing my degree... hand
converting numerical representations in the exam room was perhaps one of th=
e
most boring tasks I've faced. And clearly it didn't help me remember
anything :)
On 2/2/06, Jon Watte <hp...@mi...> wrote:
>
>
> > struct
> > {
> > unsigned m_mantissa : 24;
> > unsigned m_exponent : 7;
> > unsigned m_sign : 1;
> > };
>
>
> I believe the mantissa is only 23 bits, with a leading "implicit" one
> for all exponents that aren't denormal. There are also 8 exponent bits.
>
> Cheers,
>
> / h+
>
>
> --
> -- The early bird gets the worm, but the second mouse gets the cheese.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X