Hi there,
I am trying to multiply doubles with floats (actually I tried every
possible combination by now) and it never works (well, it does something
but it is always wrong). I have no idea what it is and where to look for
help, maybe some of you know?
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 43 2120
Sorry, I forgot:
Linux (Debian) and gcc3.3
Jens
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
I don't get the same answer:
TH009MA@th009ma-shl2-01 /cygdrive/d/temp
$ cat junk.c
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
const double three_tenths = 0.3;
const double seven_tenths = 0.7;
const float f_three_tenths = 0.3;
const float f_seven_tenths = 0.7;
printf("direct multiplication: 0.3 * 0.7 = %f\n", 0.3 * 0.7);
printf("double * double: %f\n", three_tenths * seven_tenths);
printf("float * float: %f\n", f_three_tenths * f_seven_tenths);
printf("double * float: %f\n", three_tenths * f_seven_tenths);
printf("float * double: %f\n", f_three_tenths * seven_tenths);
return EXIT_SUCCESS;
}
TH009MA@th009ma-shl2-01 /cygdrive/d/temp
$ gcc --version
gcc (GCC) 3.3.1 (cygming special)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
TH009MA@th009ma-shl2-01 /cygdrive/d/temp
$ ./junk
direct multiplication: 0.3 * 0.7 = 0.210000
double * double: 0.210000
float * float: 0.210000
double * float: 0.210000
float * double: 0.210000
************************************************
TH009MA@th009ma-shl2-01 /cygdrive/d/temp
$ bcc32 junk.c
Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
junk.c:
Turbo Incremental Link 5.60 Copyright (c) 1997-2002 Borland
TH009MA@th009ma-shl2-01 /cygdrive/d/temp
$ ./junk
direct multiplication: 0.3 * 0.7 = 0.210000
double * double: 0.210000
float * float: 0.210000
double * float: 0.210000
float * double: 0.210000
--
Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq: http://www.raos.demon.uk/acllc-c++/faq.html
Other sites: http://www.josuttis.com -- C++ STL Library book
"J.K. Becker" wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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?
Yes. Post the program. You have a bug in it.
--
Karl Heinz Buchegger kb******@gascad.at
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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)...
Works here:
#include <iostream>
int main()
{
float a = 0.3;
double b = 0.7;
std::cout << a << " * " << b << " = " << a * b << '\n';
}
Output:
0.3 * 0.7 = 0.21
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-mainz.de... Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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?
No that is impossible, you have a bug somewhere else in your program. Since
you didn't post the program its impossible to help. Post the code.
What else did you expect, did you think someone would say 'oh yes that's the
well known 0.7 * 0.3 bug, it's been fixed in the new compiler version'?
Compilers do not make basic arithmetic errors. If you want help with a buggy
program you have to post the program code, there is no other way.
See the FAQ http://www.parashift.com/c++-faq-lit...t.html#faq-5.8
john
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
The problem is in your print statement or output statement.
man fprintf.
Oh well, you got it all wrong! This stupid calculation was just an
example, it does not matter what the numbers are, the result is always
wrong. When I asked for help I was looking for something in the line of
"you could have a memory leak" (of course I checked that already) or
"this always happens on sunny days with gcc3.3, try gcc0.1prealpha" or
something.
The program is far to long to post here, if you really want to look at
it have a look at the working parts first here https://sourceforge.net/projects/elle/
or a description with links to all kinds of stuff there: http://www.microstructure.uni-tuebin...enix/index.php
And now that you know that I am not completely new to c++, no more rtfm,
or man printf, I think I am past that by now...
Jens
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-mainz.de... Oh well, you got it all wrong! This stupid calculation was just an example, it does not matter what the numbers are, the result is always wrong. When I asked for help I was looking for something in the line of "you could have a memory leak" (of course I checked that already) or "this always happens on sunny days with gcc3.3, try gcc0.1prealpha" or something. The program is far to long to post here, if you really want to look at it have a look at the working parts first here
https://sourceforge.net/projects/elle/
or a description with links to all kinds of stuff there:
http://www.microstructure.uni-tuebin...enix/index.php
And now that you know that I am not completely new to c++, no more rtfm, or man printf, I think I am past that by now...
Well how was anyone supposed to know that? We get lots of clueless newbies
posting here. One reason for posting source code is that it makes it easy
for people to assess your level of expertise.
The answer is still to post source code. Take your large program and cut out
the irrelevant parts. When doing this one of two things will happen. You may
remove some code you don't think is relevant and the problem goes away, this
is a good clue as to where the bug is. The other thing that might happen is
that you get down to a smallish program that still exhibits the behaviour
you don't understand, then you can post that code here and someone will fix
it.
This is all explained in the FAQ http://www.parashift.com/c++-faq-lit...t.html#faq-5.8
Take the trouble, and you'll get your problem fixed.
john
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.
John Harrison wrote: "J.K. Becker" <jk******@becker.de> wrote in message news:c5**********@news1.zdv.uni-mainz.de...
Oh well, you got it all wrong! This stupid calculation was just an example, it does not matter what the numbers are, the result is always wrong. When I asked for help I was looking for something in the line of "you could have a memory leak" (of course I checked that already) or "this always happens on sunny days with gcc3.3, try gcc0.1prealpha" or something. The program is far to long to post here, if you really want to look at it have a look at the working parts first here
https://sourceforge.net/projects/elle/
or a description with links to all kinds of stuff there:
http://www.microstructure.uni-tuebin...enix/index.php
And now that you know that I am not completely new to c++, no more rtfm, or man printf, I think I am past that by now...
Well how was anyone supposed to know that? We get lots of clueless newbies posting here. One reason for posting source code is that it makes it easy for people to assess your level of expertise.
The answer is still to post source code. Take your large program and cut out the irrelevant parts. When doing this one of two things will happen. You may remove some code you don't think is relevant and the problem goes away, this is a good clue as to where the bug is. The other thing that might happen is that you get down to a smallish program that still exhibits the behaviour you don't understand, then you can post that code here and someone will fix it.
This is all explained in the FAQ
http://www.parashift.com/c++-faq-lit...t.html#faq-5.8
Take the trouble, and you'll get your problem fixed.
john
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-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.
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
John Harrison wrote: "J.K. Becker" <jk******@becker.de> wrote in message news:c5**********@news1.zdv.uni-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
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 );
}
}
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
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
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
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.
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
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-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
John Harrison wrote: "J.K. Becker" <jk******@becker.de> wrote in message news:c5**********@news1.zdv.uni-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
Bruce Clement wrote:
In principle you are right.
But the number the OP has posted are far to much off, that the
error can be attributed to some floating point problem.
He has a bug somewhere else.
--
Karl Heinz Buchegger kb******@gascad.at
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-mainz.de... 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...
Maybe the function is too complex for the compiler's optimiser. Compiler
optimiser bugs aren't totally unheard of.
Have you tried changing the optimisation settings (i.e. disabling it
entirely) or spliting the function into smaller pieces.
john
J.K. Becker wrote: I did a printf in the function, and it showed the same vaules as the debugger does so I guess it is not that....
What printf did you do?
[ Fx = un.x * dEdp; ]
[ Fy = un.y * dEdp; ]
If you only checked the value of the result, I suggest you check the
value of un.x and of dEdp as well, using printf rather than the
debugger. (If it were me I'd be using "std::cerr << un.x" etc..)
--
Regards,
Buster.
Buster wrote: J.K. Becker wrote:
I did a printf in the function, and it showed the same vaules as the debugger does so I guess it is not that....
What printf did you do?
[ Fx = un.x * dEdp; ] [ Fy = un.y * dEdp; ]
If you only checked the value of the result, I suggest you check the value of un.x and of dEdp as well, using printf rather than the debugger. (If it were me I'd be using "std::cerr << un.x" etc..)
I printf'ed (nice word!) them all, all the same..
John Harrison wrote: Maybe the function is too complex for the compiler's optimiser. Compiler optimiser bugs aren't totally unheard of.
Have you tried changing the optimisation settings (i.e. disabling it entirely) or spliting the function into smaller pieces.
john
This part of the code is not optimized at all, but it uses libraries
(that we wrote) which have been compiled with -O .
Can that make a difference? If I have to recompile all those without
optimization, I would have to change a lot of Makefiles...
Jens
I just found out some really strange behaviour..
If I debug the whole thing now (that I use -ggdb), the debugger does not
go through the code one line to the next, but keeps jumping back and
forth a few times (hard to explain, but I hope you know what I mean).
And each time it jumps around, the value of dEdp changes. If the
debugger is past the point of the calculation, dEdp does not change
anymore, but shows the (I think) correct value (which it didn't when the
program actually calculated the stuff). Where does that come from?
Although I have not found any flags for optimization in the Makefile,
can it be that?
Does that ring any bells?
Jens
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-mainz.de... John Harrison wrote: Maybe the function is too complex for the compiler's optimiser. Compiler optimiser bugs aren't totally unheard of.
Have you tried changing the optimisation settings (i.e. disabling it entirely) or spliting the function into smaller pieces.
john
This part of the code is not optimized at all, but it uses libraries (that we wrote) which have been compiled with -O . Can that make a difference?
I don't see how it could, but its not something I know a great deal about.
Optimisation is normally done on a per function basis as far as I am aware.
john
Ok, after a make clean -- makeg (again) this is what happens:
dEdp gets a value in line 1, if the program continues to line 2 dEdp
changes. So the calculation is done correctly, but the value changes for
some reason. And most of the time it changes back to the right value
after line 3...
I have put the function into an older version of the program, it does
more or less the same but dEdp does not change back to the original
value after completing with line 3....
I have no idea, but I wish I would get a Euro for every time I did make,
I would be stinking rich by now!
1- dEdp = ( ( gvector.x / gvector.y ) + ( gvector.y / gvector.x ) ) / lenP;
2- Fx = un.x * dEdp;
3- Fy = un.y * dEdp;
Jens
J.K. Becker wrote: I just found out some really strange behaviour.. If I debug the whole thing now (that I use -ggdb), the debugger does not go through the code one line to the next, but keeps jumping back and forth a few times (hard to explain, but I hope you know what I mean).
[...] Although I have not found any flags for optimization in the Makefile, can it be that?
Have you tried "-ggdb -O0" (no optimization)?
(That's "Minus Oh Zero" ;)
--
Regards,
Buster.
Buster wrote: J.K. Becker wrote:
I just found out some really strange behaviour.. If I debug the whole thing now (that I use -ggdb), the debugger does not go through the code one line to the next, but keeps jumping back and forth a few times (hard to explain, but I hope you know what I mean).
[...]
Although I have not found any flags for optimization in the Makefile, can it be that?
Have you tried "-ggdb -O0" (no optimization)?
(That's "Minus Oh Zero" ;)
No, I haven't, but if I give dEdp a value (e.g. dEdp=0.01;) everything
works fine...
I think I am going to go and get a piece of paper and a pen and dump the
stupid computer-simulation...... ;0)
Jens
J.K. Becker wrote: //////// //////// wrong results in this calculation //////// Fx = un.x * dEdp; Fy = un.y * dEdp; //////// //////// ////////
Print the values of all the parts of the expressions and the results and
see if they really are what you think they are.
Bill Seurer wrote: J.K. Becker wrote:
//////// //////// wrong results in this calculation //////// Fx = un.x * dEdp; Fy = un.y * dEdp; //////// //////// ////////
Print the values of all the parts of the expressions and the results and see if they really are what you think they are.
I (we) have realized that the error is because dEdp changes its value..
I still have no idea why, but it seems that I am getting somewhere..
Jens
"J.K. Becker" <jk******@becker.de> wrote in message
news:c5**********@news1.zdv.uni-mainz.de... Ok, after a make clean -- makeg (again) this is what happens: dEdp gets a value in line 1, if the program continues to line 2 dEdp changes. So the calculation is done correctly, but the value changes for some reason. And most of the time it changes back to the right value after line 3...
I have put the function into an older version of the program, it does more or less the same but dEdp does not change back to the original value after completing with line 3....
I have no idea, but I wish I would get a Euro for every time I did make, I would be stinking rich by now!
1- dEdp = ( ( gvector.x / gvector.y ) + ( gvector.y / gvector.x ) ) /
lenP; 2- Fx = un.x * dEdp; 3- Fy = un.y * dEdp;
Jens
I wonder if you are running into compiler problems because of the complexity
of the function. I'd try breaking the function into two pieces. Just a
hunch. Of course even you did this and it worked it wouldn't prove anything.
john
J.K. Becker wrote: Ok, after a make clean -- makeg (again) this is what happens: dEdp gets a value in line 1, if the program continues to line 2 dEdp changes. So the calculation is done correctly, but the value changes for some reason. And most of the time it changes back to the right value after line 3...
I have put the function into an older version of the program, it does more or less the same but dEdp does not change back to the original value after completing with line 3....
I have no idea, but I wish I would get a Euro for every time I did make, I would be stinking rich by now!
1- dEdp = ( ( gvector.x / gvector.y ) + ( gvector.y / gvector.x ) ) / lenP; 2- Fx = un.x * dEdp; 3- Fy = un.y * dEdp;
Jens
Try declaring "dedp" as either static or volatile.
These two modifiers will help prevent variables being optimized-out.
I've seen my debugger change values of two variables when only one
has been changed (the compiler uses the same register later on..).
Also, have you considered rewriting the arithmetic to:
1. Removed fixed calculations & variables out of loops?
2. Changing multiplication to repetitive addition?
I highly suggest you use print to a debug file, with statements
like:
fprintf(debug_file, "At Line %d: dEdp == %f, un.x == %f\n",
__LINE__, dEdp, un.x);
Insert this kind of print statement after each line of calculation.
This will slow down the program, but you will get a detailed
analysis in the debug file.
--
Thomas Matthews
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq: http://www.raos.demon.uk/acllc-c++/faq.html
Other sites: http://www.josuttis.com -- C++ STL Library book
John Harrison wrote: I wonder if you are running into compiler problems because of the complexity of the function. I'd try breaking the function into two pieces. Just a hunch. Of course even you did this and it worked it wouldn't prove anything.
john
Since you suggest it, it obviously is a possibility, but I wonder why? I
mean in the end it is just standart vector-calculation (the compiler of
course has never heard of that), but is this complex already? And if so,
wouldn't you expect the error somewhere in the for-loop for example, in
the middle of the calculations, instead of at the beginning where
everything is still simple? This is all new stuff to me, so far
everything worked fine or were stupid mistakes I made somewhere (e.g. my
alltime favorite->type collisions with double x; x=1; and such)..
Jens
J.K. Becker wrote: Ok, after a make clean -- makeg (again) this is what happens: dEdp gets a value in line 1, if the program continues to line 2 dEdp changes. So the calculation is done correctly, but the value changes for some reason. And most of the time it changes back to the right value after line 3...
I have put the function into an older version of the program, it does more or less the same but dEdp does not change back to the original value after completing with line 3....
I have no idea, but I wish I would get a Euro for every time I did make, I would be stinking rich by now!
1- dEdp = ( ( gvector.x / gvector.y ) + ( gvector.y / gvector.x ) ) / lenP; 2- Fx = un.x * dEdp; 3- Fy = un.y * dEdp;
Try putting "volatile" on the declarations of all the things used in the
above expressions like this:
volatile float dEdp;
And see what happens.
Also, change all your "floats" to "doubles" and see what happens.
Bill Seurer wrote: J.K. Becker wrote:
Ok, after a make clean -- makeg (again) this is what happens: dEdp gets a value in line 1, if the program continues to line 2 dEdp changes. So the calculation is done correctly, but the value changes for some reason. And most of the time it changes back to the right value after line 3...
I have put the function into an older version of the program, it does more or less the same but dEdp does not change back to the original value after completing with line 3....
I have no idea, but I wish I would get a Euro for every time I did make, I would be stinking rich by now!
1- dEdp = ( ( gvector.x / gvector.y ) + ( gvector.y / gvector.x ) ) / lenP; 2- Fx = un.x * dEdp; 3- Fy = un.y * dEdp;
Try putting "volatile" on the declarations of all the things used in the above expressions like this: volatile float dEdp; And see what happens.
Also, change all your "floats" to "doubles" and see what happens.
Hmmm.....
Volatile seems to save my day! I must admit I have never heard of that
before and it does not make sense to me that it seems to work since I am
not optimizing anything (no -O in the Makefile) but what do I care. Now
I just have to make sure that it really works....
Thanks a lot!
Jens
Does gcc "secretly" optimize something if I do not explicitly say -O0?
No idea, never thought about that...
Jens
J.K. Becker wrote: Does gcc "secretly" optimize something if I do not explicitly say -O0? No idea, never thought about that...
No, my mistake. -O0 is the default. (From the "Options That Control
Optimization" page of gcc's Texinfo manual.)
--
Regards,
Buster.
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
Show us the format string for the print statement that prints the
incorrect value.
"J.K. Becker" <jk******@becker.de> wrote in message news:<c5**********@news1.zdv.uni-mainz.de>... Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
Well, you can't actually multiply a double and a float. However, if you
write 0.3 * 0.7f, you will get a float->double conversion, so in fact
you will multiply two doubles. Why don't you add a few lines to your
main printing this? If it fails, remove parts of your program until
it work. If it works, move these test lines closer to your problem area
until it fails.
Regards,
Michiel Salters
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
Some ideas :
Maybe you have macros redefining something (i had a look at
the code on cvs, and i saw things like #define XY 0, so
maybe some very common names are defined somewhere...
Stack overflow ? (does that kind of thing still exist
nowadays ?) (try adding some dummy variable declarations in
the function (double bigarray[1000] or so)
Check again that optimizations are turned off (I don't see
other reasons for the debugger to hop back and forth in the
code...)
Also, try to turn off cpu specific assembly code generation
(-i686 or so...)
J.K. Becker wrote: Hi there,
I am trying to multiply doubles with floats (actually I tried every possible combination by now) and it never works (well, it does something but it is always wrong). I have no idea what it is and where to look for help, maybe some of you know?
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
What was the resolution of this? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Yaroslav Bulatov |
last post by:
I made an array of 10 million floats timed how long it takes to sum
the elements, here's what I got (millis):
gcc -O2: 21
Python with numarray: 104
Python with Numeric: 302...
|
by: dave |
last post by:
I'm trying to learn this. My problem, I have 2 strings that represent
floats.
I want to add them together.
Should I look at using Cint to convert each character in the string and add...
|
by: Amit Bhatia |
last post by:
Hello everyone.
Sorry to be cross posting this on comp.lang.c++ (moderated)
This is a simple question that is causing some problem in one of the classes
that I have designed.
I have two...
|
by: my.correo.basura |
last post by:
Yesterday I found in a piece of code a float being incremented with ++.
For some reason (wrong, I guess...) I thought that only integer types
could be incremented that way, and I had never seen...
|
by: Mike P |
last post by:
Why does this cause the error 'cannot implicitly convert type 'double'
to 'float'? Can you not multiply doubles by floats without converting
them all to the same datatype?
fltPCRateStd =...
|
by: abdul_n_khan |
last post by:
I have a basic question related to datatype conversion. I am
multiplying currency to float datatype.
fltInterestRate=1.23333;
curAmount = 91000000;
curInterestAmount = curAmount *...
|
by: SpreadTooThin |
last post by:
I have some code...
import array
a = array.array('d')
f = open('file.raw')
a.fromfile(f, 10)
now I need to convert them into floats (32 bit...) what do i do?
|
by: Pavel |
last post by:
Hello,
Does anyone know a (preferably open-source) multi-platform C or C++
library that would be able to write and read C/C++ doubles and floats
to/from streambuf, char array or similar device...
|
by: jerry.teshirogi |
last post by:
I have the following class and main:
//////////////////////////////////////////////////////////
#include <iostream.h>
class myVector
{
public:
double x, y, z:
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |