Using parenthesis

O

orac

Active member
I am rebuiulding an old project that was made so long ago the best option for maths was the micromega FPU.
That little chip took care of parenthesis in calculations.
Now I have been playing with using something with an FPU to help with precision. To that i end a decided to have a bit of a test with a teensy 4.0 and FPU.
Now you can imagine i was expecting to handle parenthesis, apparently it does not. Below is the test code doing just one of the equations it will be doing.
While it's no hardship to seperate the thing within the parenthesis i just wanted to check that I had not done anything wrong before moving forward missing an obvious error.

If you are wondering, this is going to the control system for a macro rail with micron level resolution. The over plan is to have it so i can punch in a few values, it work out depth of feild, magnification and distance between shots.

Code: 
double DOF;
double DOF_1;
double DOF_2;
double one;
double two;

void setup() 
{  
  Serial.begin(115200);
}

void loop() 
{
  DOF_1 = 2.0*10.0*0.019948*(1.5733333+1)/(5733333*5733333); // always return 0
  one = 1.5733333+1.0;
  two = 1.5733333*1.5733333;
  DOF_2 = 2.0*10.0*0.019948*one/two;    //returns correct value
  //Serial.println(one,6);
  //Serial.println(two,6);
  Serial.println(DOF_1,6);
  Serial.println(DOF_2,6);
  Serial.println();
  delay(1000);
}
 
In this code is two supposed to replace:(5733333*5733333)
Code: 
  DOF_1 = 2.0*10.0*0.019948*(1.5733333+1)/(5733333*5733333); // always return 0
  one = 1.5733333+1.0;
  two = 1.5733333*1.5733333;
because those are not the same numbers.

All math is processed according to "C" precedence rules. When needed parenthesis, will assure the result is as desired.
 
Well spotted, the correct number is 1.5733333.
Glad i came here for a sanity check. I wasn't displaying enough decimal places for it to reveal the issue in the serial monitor
Thank you.
 
It's all const, so the compiler replaces it with the result. Teensy does not calculate anything for DOF_1 and the FPU certainly not.
 
Still it costs nothing to add .0 at the end of floating point constants! The language standard has surprizing things to say if you have signed integer overflow, basically you cannot rely on anything working after signed integer overflow. I've even hit this in reality, really odd things happening to another operation later in the program.
 
You must log in or register to reply here.
Back
Top