Home > Archive > VC Language > November 2005 > Will the following code assert:
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Will the following code assert:
|
|
| Alan Carre 2005-11-22, 7:04 pm |
| // headers...
int main ()
{
double d = 0;
ASSERT (d == 0);
}
?
Or is it machine/[HW/SW]floating-point processing dependent? Might 1.0E-1024
be a convenient way to store zero on some machines? Is there any certainty
with doubles of floats or do we 100% of the time have to call fabs with some
precision spec?
Thanks in advance,
- Alan
| |
| Alan Carre 2005-11-22, 7:04 pm |
| Err, more precisely does it always have to be:
ASSERT (fabs (d - 0) < fprecision).
ie. can we ever use "==" with doubles/floats? Or is it completely
meaningless to ask if two doubles are "equal".
- Alan
"Alan Carre" <alan@twilightgames.com> wrote in message
news:ebQAKK47FHA.252@TK2MSFTNGP15.phx.gbl...
> // headers...
>
> int main ()
> {
> double d = 0;
> ASSERT (d == 0);
> }
>
> ?
>
> Or is it machine/[HW/SW]floating-point processing dependent? Might
> 1.0E-1024 be a convenient way to store zero on some machines? Is there any
> certainty with doubles of floats or do we 100% of the time have to call
> fabs with some precision spec?
>
>
> Thanks in advance,
> - Alan
>
>
| |
| Victor Bazarov 2005-11-22, 7:04 pm |
| Alan Carre wrote:
> // headers...
>
> int main ()
> {
> double d = 0;
> ASSERT (d == 0);
> }
>
> ?
>
> Or is it machine/[HW/SW]floating-point processing dependent? Might 1.0E-1024
> be a convenient way to store zero on some machines? Is there any certainty
> with doubles of floats or do we 100% of the time have to call fabs with some
> precision spec?
double a = 42;
double b = 3.14159;
a = b;
if (a == b) // should be just like if (true)
Two floating point values shall always compare equal with '==' if they are
(a) of the same FP type and (b) one was assigned from the other. If the
conditions are different, then '==' may not be the right choice.
There is always a possibility of a bug in the compiler, of course. Slim,
but not necessarily altogether absent.
V
| |
| James Curran 2005-11-22, 7:04 pm |
| I cannot imagine a properly functioning compiler translating "0" into
one binary image on one line, and a different binary image on the next.
Hence we can feel confident that the following will run (without an abort):
int main ()
{
double d = 0;
double e = 0;
ASSERT (memcmp(d,e,sizeof(double)) == 0);
}
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
"Alan Carre" <alan@twilightgames.com> wrote in message
news:ebQAKK47FHA.252@TK2MSFTNGP15.phx.gbl...
> // headers...
>
> int main ()
> {
> double d = 0;
> ASSERT (d == 0);
> }
>
> ?
>
> Or is it machine/[HW/SW]floating-point processing dependent? Might
1.0E-1024
> be a convenient way to store zero on some machines? Is there any certainty
> with doubles of floats or do we 100% of the time have to call fabs with
some
> precision spec?
>
>
> Thanks in advance,
> - Alan
>
>
| |
| Joe Butler 2005-11-22, 7:04 pm |
| IEEE standard floats have a defined bit pattern. Zero is _defined_ as all
bits off, so your assert would pass without an assertion. This is a +0,
btw. There is also a -0 where the bit pattern is not all zero.
This may or may not be true on platforms that use other floating point
representations.
What _is_ dangerous is to assume that a series of calculations that
mathematically yield a result of zero will be stored as zero in your float.
Your assert will probably fail in these cases.
I'm not sure it testing -0 against 0.0 with an equality test would produce
equality or not....
"Alan Carre" <alan@twilightgames.com> wrote in message
news:ebQAKK47FHA.252@TK2MSFTNGP15.phx.gbl...
> // headers...
>
> int main ()
> {
> double d = 0;
> ASSERT (d == 0);
> }
>
> ?
>
> Or is it machine/[HW/SW]floating-point processing dependent? Might
1.0E-1024
> be a convenient way to store zero on some machines? Is there any certainty
> with doubles of floats or do we 100% of the time have to call fabs with
some
> precision spec?
>
>
> Thanks in advance,
> - Alan
>
>
| |
| Igor Tandetnik 2005-11-22, 9:59 pm |
| "Joe Butler" <ffffh.no.spam@hotmail-spammers-paradise.com> wrote in
message news:ubQsyV87FHA.1000@tk2msftngp13.phx.gbl
> I'm not sure it testing -0 against 0.0 with an equality test would
> produce equality or not....
If a platform follows IEEE standard, then +0 and -0 must be considered
equal.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Alan Carre 2005-11-24, 7:01 pm |
| Thanks all for your answers. I will assume assignment to zero will result in
"== 0" being true.
- Alan
"Alan Carre" <alan@twilightgames.com> wrote in message
news:ebQAKK47FHA.252@TK2MSFTNGP15.phx.gbl...
> // headers...
>
> int main ()
> {
> double d = 0;
> ASSERT (d == 0);
> }
>
> ?
>
> Or is it machine/[HW/SW]floating-point processing dependent? Might
> 1.0E-1024 be a convenient way to store zero on some machines? Is there any
> certainty with doubles of floats or do we 100% of the time have to call
> fabs with some precision spec?
>
>
> Thanks in advance,
> - Alan
>
>
| |
| Barry Schwarz 2005-11-24, 7:01 pm |
| Assigning from a constant 0 should work since most floating point
schemes can represent 0 exactly. However, assigning from an
expression that you believe evaluates to 0, such as
d = 2 - sqrt(2)*sqrt(2);
can produce non-zero values.
On Thu, 24 Nov 2005 22:52:52 +0700, "Alan Carre"
<alan@twilightgames.com> wrote:
>Thanks all for your answers. I will assume assignment to zero will result in
>"== 0" being true.
>
>- Alan
>
>"Alan Carre" <alan@twilightgames.com> wrote in message
>news:ebQAKK47FHA.252@TK2MSFTNGP15.phx.gbl...
>
<<Remove the del for email>>
| |
| Alan Carre 2005-11-25, 7:02 pm |
| Sure of course. I meant only assignment to 0 itself.
- Alan
"Barry Schwarz" <schwarzb@deloz.net> wrote in message
news:jl4co1pftupfrq985ektuua28ekdrk6jjm@
4ax.com...
> Assigning from a constant 0 should work since most floating point
> schemes can represent 0 exactly. However, assigning from an
> expression that you believe evaluates to 0, such as
> d = 2 - sqrt(2)*sqrt(2);
> can produce non-zero values.
>
> On Thu, 24 Nov 2005 22:52:52 +0700, "Alan Carre"
> <alan@twilightgames.com> wrote:
>
>
>
> <<Remove the del for email>>
| |
| Alan Carre 2005-11-25, 7:02 pm |
| Err... what do you mean by *most* floating point schemes? If it's not all,
then I must throw away my assumption and use 'fabs' and '>'.
ie.
if (fabs (xvelocity) > 0.00001)
{
//do lots of work.
}
else
{
//do nothing.
}
What's a good number to choose? 0.00001 seems pretty good assuming it's
"pixels per second". What about a more general case? How low can you go that
is, and still be relatively 'safe'???
- A
"Barry Schwarz" <schwarzb@deloz.net> wrote in message
news:jl4co1pftupfrq985ektuua28ekdrk6jjm@
4ax.com...
> Assigning from a constant 0 should work since most floating point
> schemes can represent 0 exactly. However, assigning from an
> expression that you believe evaluates to 0, such as
> d = 2 - sqrt(2)*sqrt(2);
> can produce non-zero values.
>
> On Thu, 24 Nov 2005 22:52:52 +0700, "Alan Carre"
> <alan@twilightgames.com> wrote:
>
>
>
> <<Remove the del for email>>
| |
| Alan Carre 2005-11-25, 7:02 pm |
| If anyone cares... experimentation reveals these limits:
float f = 0;
ASSERT (f == 0);
f = 0. 0000000000000000000000000000000000000000
000008;
ASSERT (f != 0);
f = 0. 0000000000000000000000000000000000000000
000007;
ASSERT (f == 0);
Code does not assert. It seems the 'smallest positive float' is
1.40130e-045, anything smaller seems to zero-fill the buffer (which appears
to have the effect of dropping the exponent).
- Alan
"Barry Schwarz" <schwarzb@deloz.net> wrote in message
news:jl4co1pftupfrq985ektuua28ekdrk6jjm@
4ax.com...
> Assigning from a constant 0 should work since most floating point
> schemes can represent 0 exactly. However, assigning from an
> expression that you believe evaluates to 0, such as
> d = 2 - sqrt(2)*sqrt(2);
> can produce non-zero values.
>
> On Thu, 24 Nov 2005 22:52:52 +0700, "Alan Carre"
> <alan@twilightgames.com> wrote:
>
>
>
> <<Remove the del for email>>
| |
| Joe Butler 2005-11-25, 9:57 pm |
| Check out FLT_EPSILON, FLT_MIN, etc. in <float.h>
"Alan Carre" <alan@twilightgames.com> wrote in message
news:%235X2OLi8FHA.3804@TK2MSFTNGP14.phx.gbl...
> If anyone cares... experimentation reveals these limits:
>
> float f = 0;
> ASSERT (f == 0);
>
> f = 0. 0000000000000000000000000000000000000000
000008;
> ASSERT (f != 0);
>
> f = 0. 0000000000000000000000000000000000000000
000007;
> ASSERT (f == 0);
>
> Code does not assert. It seems the 'smallest positive float' is
> 1.40130e-045, anything smaller seems to zero-fill the buffer (which
appears
> to have the effect of dropping the exponent).
>
> - Alan
>
> "Barry Schwarz" <schwarzb@deloz.net> wrote in message
> news:jl4co1pftupfrq985ektuua28ekdrk6jjm@
4ax.com...
result[color=darkred]
call[color=darkred]
>
>
| |
| Barry Schwarz 2005-11-26, 3:59 am |
| On Sat, 26 Nov 2005 06:55:06 +0700, "Alan Carre"
<alan@twilightgames.com> wrote:
>Err... what do you mean by *most* floating point schemes? If it's not all,
>then I must throw away my assumption and use 'fabs' and '>'.
I mean that there are lots of systems that I have not used and it
would be presumptuous of me to assume they behave like the ones I am
familiar with. I learned a long time ago that others do not suffer
the same limits of imagination that I do and my limits don't seem to
be related to the real world.
>
>ie.
>
>if (fabs (xvelocity) > 0.00001)
> {
> //do lots of work.
> }
>else
> {
> //do nothing.
> }
>
>What's a good number to choose? 0.00001 seems pretty good assuming it's
>"pixels per second". What about a more general case? How low can you go that
>is, and still be relatively 'safe'???
>
>- A
>
>"Barry Schwarz" <schwarzb@deloz.net> wrote in message
> news:jl4co1pftupfrq985ektuua28ekdrk6jjm@
4ax.com...
>
<<Remove the del for email>>
|
|
|
|
|