Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Problems with multiplications of doubles and/or floats

Reply
Thread Tools

Problems with multiplications of doubles and/or floats

 
 
John Harrison
Guest
Posts: n/a
 
      04-15-2004

"J.K. Becker" <(E-Mail Removed)> wrote in message
news:c5lhod$umn$(E-Mail Removed)-mainz.de...
> I can't take the program apart, that would be more work than
> reprograming the part that is not working. There is a reason for me not
> to post the progam here, you know, believe me, if I could I would. I can
> post the function here, but that is not going to help.
> If you insist I will.
>


I'm not insisting on anything, just explaining how this group works. The
regulars here contribute a lot of their time for no recompense. I don't
think any have the time to take on the sort of in depth study that it sounds
like your problem needs.

You might have got lucky with you post and someone have recognised the
problem but you didn't so I guess there is no alternative but some hard work
on your part.

Post the function if you like, you never know it might help. One of the
things I've learned from this group is that posters are often convinced that
a problem is in some piece of code which they post (even though they don't
know what the problem is) but when after much resistence that are persuaded
to post more code, the problem turns out to have been in some part of the
code they were holding back.

John

BTW top posting is frowned on in this group.


 
Reply With Quote
 
 
 
 
J.K. Becker
Guest
Posts: n/a
 
      04-15-2004
John Harrison wrote:
> "J.K. Becker" <(E-Mail Removed)> wrote in message
> news:c5lhod$umn$(E-Mail Removed)-mainz.de...
>
>>I can't take the program apart, that would be more work than
>>reprograming the part that is not working. There is a reason for me not
>>to post the progam here, you know, believe me, if I could I would. I can
>>post the function here, but that is not going to help.
>>If you insist I will.
>>

>
>
> I'm not insisting on anything, just explaining how this group works. The
> regulars here contribute a lot of their time for no recompense. I don't
> think any have the time to take on the sort of in depth study that it sounds
> like your problem needs.
>
> You might have got lucky with you post and someone have recognised the
> problem but you didn't so I guess there is no alternative but some hard work
> on your part.
>
> Post the function if you like, you never know it might help. One of the
> things I've learned from this group is that posters are often convinced that
> a problem is in some piece of code which they post (even though they don't
> know what the problem is) but when after much resistence that are persuaded
> to post more code, the problem turns out to have been in some part of the
> code they were holding back.
>
> John
>
> BTW top posting is frowned on in this group.
>
>


I know that it is not a simple error (well, it might be but I have no
idea where). The program consits of, I don't know, 10000 lines or more,
something like 100 and more seperate files. And to make it more fun, it
has grown over the years so some files are c++ (OO), some are c++ (not
OO), some c and some fortran. And it has been written by people in the
US, Australia, UK, Germany (that's me) and France. So no way to strip
that down to something everybody can understand quickly.
But since we all are running out of ideas on what and where to look, I
thought I'd try here.

Jens

 
Reply With Quote
 
 
 
 
Bruce Clement
Guest
Posts: n/a
 
      04-15-2004
J.K. Becker wrote:
> [...]
>
> J.K. Becker wrote:
> [...]
>> double=float*double; (or every possible combination of it). An example:
>>
>> 0.3 * 0.7 would result in 1.7 (with lots more digits). Anyone any
>> idea? If I change the types of the variables I think the result stays
>> the same (but I am not 100% sure)...
>>
>> Jens
>>

>


If I'm understanding the problem correctly, this isn't a C++ problem, but an
implementation artifact.

Let's say that in your implementation, float has 6 digits of precision & double
has 12, so 0.3 is 0.300000, and 0.7 is 0.700000000000. These aren't integers
though, they are finite precision representations of real numbers, so 0.3 is
actually any number between 0.299999500000 and 0.300000499999. When the
generated code, or, more likely, the computer's Floating Point Hardware (FPU),
converts the 0.3 from float to double, it is perfectly entitled to convert it to
anything within its valid range.

Most people thing in base ten, so we intuitively expect that the 0.300000 will
be seamlessly converted into 0.300000000000. The FPU is probably constructed as
a binary device, and so it will still zero fill, but in binary. When converted
back to decimal, this gives some value that is close to, but not, exactly
0.300000000000. The value it gives is still correct though.

You can see how your compiler / FPU handle these conversions by single stepping
through this fragment.

float x = 0.3;

int main( int, char ** )
{
some_external_fn( &x ); // stop the optimizer making assumptions about x
double y = x;
std::cout << y << std::eol;
return 0;
}

Regards

Bruce

 
Reply With Quote
 
J.K. Becker
Guest
Posts: n/a
 
      04-15-2004
This is the function where the error occurs. As you can see there are a
lot of calculations in it, they all work fine except the one mentioned
(which seems to be the easiest one).

Fx = un.x * dEdp;
Fy = un.y * dEdp;

This always gives the wrong results... Everything before it works and
everything after it works too (except that everything is calculated with
the wrong values for Fx and Fy).


But I guess it is too complex for a quick fix...


Thanks anyway

Jens


int GBE_MoveNode( int index, Coords * movedir )
{
int i, l, k, moveflag = 0;
double E1, E2, E3, E4, vangle[3],lenL[3] , lenK[3];
double truetimestep = 3.1536e10;
float Fx,Fy;
double lenP, lenV, lenF, mobility1, mobility2, mobility3 , switchd;
Coords p1, p2, gvector, un, sigma1, sigma2, sigma3, L[3], F;
Coords newxy, xynb, xy, prev, V;
float dEdp;
int nb[3];
char cc[255];

mobility1 = 1e-12;
mobility2 = 1e-12;
mobility3 = 1e-12;

switchd = ElleSwitchdistance() / 10;
//Get position of first node
ElleNodePosition( index, & p1 );
ElleNodePrevPosition( index, & prev );

//this is the first energy we need: E((x+dx),y)
p2.x = p1.x + switchd;
p2.y = p1.y;
ElleSetPosition( index, & p2 );
GetNodeEnergy( index, & p2, & E1 );

//this is the second energy we need:E((x-dx),y)
p2.x = p1.x - switchd;
p2.y = p1.y;
ElleSetPosition( index, & p2 );
GetNodeEnergy( index, & p2, & E2 );

//this is the third energy we need: E(x,(y+dy))
p2.x = p1.x;
p2.y = p1.y + switchd;
ElleSetPosition( index, & p2 );
GetNodeEnergy( index, & p2, & E3 );

//this is the fourth energy we need: E(x,(y-dy))
p2.x = p1.x;
p2.y = p1.y - switchd;
ElleSetPosition( index, & p2 );
GetNodeEnergy( index, & p2, & E4 );

//Reset node position to starting values
ElleSetPosition( index, & p1 );
ElleSetPrevPosition( index, & prev );

//So now we can calculate the gradient vector (P)
gvector.x = ( E1 - E2 ) / ( 2 * switchd );
gvector.y = ( E3 - E4 ) / ( 2 * switchd );
if ( gvector.x == 0.0 && gvector.y == 0.0 )
{
movedir->x = 0.0;
movedir->y = 0.0;
return ( 0 );
}
else
{
//reverse gradient
gvector.x *= -1;
gvector.y *= -1;
//length of gradient
lenP = sqrt( ( gvector.x * gvector.x ) + ( gvector.y * gvector.y ) );
//unit vector
un.x = gvector.x / lenP;
un.y = gvector.y / lenP;
dEdp = ( ( gvector.x / gvector.y ) + ( gvector.y / gvector.x ) ) /
lenP;

////////
//////// wrong results in this calculation
////////
Fx = un.x * dEdp;
Fy = un.y * dEdp;
////////
////////
////////

lenF = sqrt( ( Fx * Fx ) + ( Fy * Fy ) );
ElleNeighbourNodes( index, nb );
for ( i = 0, k = 0; i < 3; i++ )
{
if ( nb[i] != NO_NB && ElleNodeIsActive( index ) )
{
ElleNodePosition( nb[i], & xynb );
L[k].x = p1.x - xynb.x;
L[k].y = p1.y - xynb.y;
lenL[k] = sqrt( ( L[k].x * L[k].x ) + ( L[k].y * L[k].y ) );
vangle[k] = fabs(90- ( acos( ( Fx * L[k].x + Fy * L[k].y ) / (
lenL[k] * lenF ) ) ));
lenK[k] = lenL[k] * fabs( sin( vangle[k] * ( 180 / 3.1415926535
) ) );
k++;
}
}
sigma1.x = Fx / ( lenK[0] + ( mobility1 / mobility2 ) * lenK[1] );
sigma1.y = Fy / ( lenK[0] + ( mobility1 / mobility2 ) * lenK[1] );
V.x = sigma1.x * (mobility1/switchd/switchd);
V.y = sigma1.y * (mobility1/switchd/switchd);
lenV = sqrt( ( V.x * V.x ) + ( V.y * V.y ) );
movedir->x = p1.x - V.x;
movedir->y = p1.y - V.y;
moveflag = 1;
return ( moveflag );
}
}

 
Reply With Quote
 
J.K. Becker
Guest
Posts: n/a
 
      04-15-2004
Bruce Clement wrote:

> If I'm understanding the problem correctly, this isn't a C++ problem,
> but an implementation artifact.
>
> Let's say that in your implementation, float has 6 digits of precision &
> double has 12, so 0.3 is 0.300000, and 0.7 is 0.700000000000. These
> aren't integers though, they are finite precision representations of
> real numbers, so 0.3 is actually any number between 0.299999500000 and
> 0.300000499999. When the generated code, or, more likely, the computer's
> Floating Point Hardware (FPU), converts the 0.3 from float to double, it
> is perfectly entitled to convert it to anything within its valid range.
>
> Most people thing in base ten, so we intuitively expect that the
> 0.300000 will be seamlessly converted into 0.300000000000. The FPU is
> probably constructed as a binary device, and so it will still zero fill,
> but in binary. When converted back to decimal, this gives some value
> that is close to, but not, exactly 0.300000000000. The value it gives is
> still correct though.
>
> You can see how your compiler / FPU handle these conversions by single
> stepping through this fragment.
>
> float x = 0.3;
>
> int main( int, char ** )
> {
> some_external_fn( &x ); // stop the optimizer making assumptions
> about x
> double y = x;
> std::cout << y << std::eol;
> return 0;
> }
>
> Regards
>
> Bruce
>


I thought about that too, but the error is to big to be a rounding
problem (well I think). 0.3 *0.7 can give something 0.210001238389741291
(just an example) which would be fine with me, but not 1.72094230948.
The error is just too big. It is interesting to note though that it
always calculates the same so it does not multiply arbitrary numbers
that it gets from memory somewhere, but always the same numbers....

Jens

 
Reply With Quote
 
J.K. Becker
Guest
Posts: n/a
 
      04-15-2004
Is there the slightest chance that the debugger shows wrong values but
the calculation acutally uses the right ones? (gdb/ddd)

See how desperate I am?!

Jens

 
Reply With Quote
 
Bruce Clement
Guest
Posts: n/a
 
      04-15-2004
J.K. Becker wrote:

[...]

>
> I thought about that too, but the error is to big to be a rounding
> problem (well I think). 0.3 *0.7 can give something 0.210001238389741291
> (just an example) which would be fine with me, but not 1.72094230948.
> The error is just too big. It is interesting to note though that it
> always calculates the same so it does not multiply arbitrary numbers
> that it gets from memory somewhere, but always the same numbers....
>


OK,

Jens, please don't take what follows as dismissive or demeaning. I've been
making my living from developing code for over 25 years, and when I don't
understand the problem I find it makes sense to go back to basics & attempt to
double check that I've eliminated all the obvious problems.

So let's look at it in context.

////////
//////// wrong results in this calculation
////////
Fx = un.x * dEdp;
Fy = un.y * dEdp;
////////
////////
////////

Presumably this means that when un.x = 0.3 and dEdp = 0.7 that Fx becomes
1.7209423...

If that's the case, there's only a very few possibilities:
1. The prerequisites are not met (either un.x != 0.3 or dEdp != 0.7)
2. The result isn't what you think it is (Fx does = 0.21) and something else is
wrong
3. The debugger is confused (I've seen this happen with optimised code)
4. The compiler is generating bad code
5. You've uncovered a hardware bug in the FPU.
...

1 & 2 can be eliminated by breaking the program at this step & examining
variables before & after the assignments

If 3 is a possibility, try switching into machine code & tracing the statement
through at the instruction level. You may find that the variables being loadedd
/ stored aren't what you expected.

4 & 5 Are very unlikely, but can be eliminated as possibilities by debugging at
machine instruction level as per 3.


Good Luck

Bruce

 
Reply With Quote
 
Bruce Clement
Guest
Posts: n/a
 
      04-15-2004
J.K. Becker wrote:
> Is there the slightest chance that the debugger shows wrong values but
> the calculation acutally uses the right ones? (gdb/ddd)
>
> See how desperate I am?!
>
> Jens
>

Yes,

I've seen this in debuggers especially when dealing with optimised code. The
windows VC6 compiler was especially bad (thought 'this' was in a different
register to the one it was actually in).

You need to make sure you've compiled up for debugging.

I've also seen it in GDB when the compile failed (I'd missed that it had a
compile error )

B.

 
Reply With Quote
 
J.K. Becker
Guest
Posts: n/a
 
      04-15-2004
Bruce Clement wrote:

[snip]
>
> Presumably this means that when un.x = 0.3 and dEdp = 0.7 that Fx
> becomes 1.7209423...
>
> If that's the case, there's only a very few possibilities:
> 1. The prerequisites are not met (either un.x != 0.3 or dEdp != 0.7)
> 2. The result isn't what you think it is (Fx does = 0.21) and
> something else is wrong
> 3. The debugger is confused (I've seen this happen with optimised code)
> 4. The compiler is generating bad code
> 5. You've uncovered a hardware bug in the FPU.
> ...
>
> 1 & 2 can be eliminated by breaking the program at this step & examining
> variables before & after the assignments
>
> If 3 is a possibility, try switching into machine code & tracing the
> statement through at the instruction level. You may find that the
> variables being loadedd / stored aren't what you expected.
>
> 4 & 5 Are very unlikely, but can be eliminated as possibilities by
> debugging at machine instruction level as per 3.
>
>
> Good Luck
>
> Bruce
>

Ah, don't worry, these are the kind of tips I was looking for! I had a
look with a debugger and I am using makeg, so I guess #1 is unlikely. I
agree that I have not found a hardware error (oh how I wish that would
be the case: "See, it is not my fault, there is nothing I can do, it is
IBM and AMD's fault...." ).
I will try to debug the whole thing with machine code, although I really
have no idea yet if that is going to help me (my assembler-skills are,
well, rudimentary would be a compliment). But I think that is the best
way to go for now

If you can think of anything else....

Thanks

Jens

 
Reply With Quote
 
J.K. Becker
Guest
Posts: n/a
 
      04-15-2004
John Harrison wrote:
> "J.K. Becker" <(E-Mail Removed)> wrote in message
> news:c5lkcb$uqc$(E-Mail Removed)-mainz.de...
>
>>Is there the slightest chance that the debugger shows wrong values but
>>the calculation acutally uses the right ones? (gdb/ddd)
>>

>
>
> That's entirely possible. Have you tried dumping the values out to a file?
>
> john
>
>


I did a printf in the function, and it showed the same vaules as the
debugger does so I guess it is not that....

Jens

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how do you convert and array of doubles into floats? SpreadTooThin Python 7 09-16-2006 01:14 AM
++ / -- operators with floats and doubles my.correo.basura@gmail.com C Programming 14 05-26-2005 12:59 PM
Re: Floats, doubles C and MSVC Andrew Reilly C Programming 2 10-14-2004 02:50 PM
floats doubles long doubles dan C++ 1 11-26-2003 05:12 AM
Comparing two floats or doubles to a precision {AGUT2} {H}-IWIK C++ 4 09-12-2003 02:51 PM



Advertisments