fatal error #2204: Floating-point expression too complex

[kamesh001]

When I click on the error #2204: Floating-point expression too complex. the IDE is pointing to the following function in the source file (see the actual code at the bottom of this note)

I noticed a few strange things about this code: the first is the use of #if 0. I have never seen that before. I'm assuming this means that the compiler will ignore everything starting from #if 0 up to #else. Is that a correct assumption? I'm not sure why the author chose to use #if 0 instead of just commenting the code.

The second thing is I'm not exactly sure is which floating expression is too complex in this function. The compiler is just pointing to the function, not the specific line number or expression.

So I decided that the most complex line in the #else section is this expression:

 r = ((atpress - 80) / 930 / (1 + 0.00008 * (r + 39) * (attemp - 10)) * r) / 60.0;

I looked up the operator precedence and replaced the above line with a series of simple expressions and recompiled the code, but I am still getting the same fatal error:

Here are a series of simpler expressions I used to replace the above complex expression with: (Also, can someone confirm I'm using the right precedence operations?):

Code: [Select]

temp1 = 0.00008 * (r + 39);
temp2 = 1 + temp1 * (attemp - 10);
temp3 = temp2 * r;

temp4 = (atpress - 80) / 930;
temp5 = temp4/temp3;

  r = temp5/60.0;

So here's the code:

Code: [Select]

static double calc_astronomical_refr(double inalt,double atpress, double attemp)
{
#if 0
  /* formula based on G.G. Bennett, The calculation of astronomical refraction in marine navigation,
  * Journal of Inst. Navigation, No. 35, page 255-259, 1982,
  * page 257 for refraction formula: formula H
  * and page 259 for atmospheric compensation
  */
  double refractaccent = 1/tan(DEGTORAD*(inalt + 7.31/(inalt+4.4)));
  double r = (refractaccent - 0.06 * sin(DEGTORAD*(14.7*refractaccent +13)));
  r = ((atpress - 80) / 930 / (1 + 0.00008 * (r + 39) * (attemp - 10)) * r)/60;
 return r;
#else
  /* Formula by Sinclair, see article mentioned above, p. 256. Better for
   * apparent altitudes < 0;  */
  double r;
  if (inalt > 17.904104638432) { /* for continuous function, instead of '>15' */
    r = 0.97 / tan(inalt * DEGTORAD);
  } else {

   r = (34.46 + 4.23 * inalt + 0.004 * inalt * inalt) / (1 + 0.505 * inalt + 0.0845 * inalt * inalt);
  }

   r = ((atpress - 80) / 930 / (1 + 0.00008 * (r + 39) * (attemp - 10)) * r) / 60.0;
  return r;
#endif
}
I'm attaching the source file and the header files it uses as a zip file.  I would appreciate some pointers on how to get around this issue.

Thanks for your help in advance.

[Bitbeisser]

I noticed a few strange things about this code: the first is the use of #if 0. I have never seen that before. I'm assuming this means that the compiler will ignore everything starting from #if 0 up to #else. Is that a correct assumption? I'm not sure why the author chose to use #if 0 instead of just commenting the code.

Well, kind of laziness (which isn't necessarily a bad thing in this particular case). With changing just one character (changing the line from "#if 0" to "#if 1", one can decide which of the two formulas is being used....

The second thing is I'm not exactly sure is which floating expression is too complex in this function. The compiler is just pointing to the function, not the specific line number or expression.

Doubtful, I have seen/programmed much more complex things that this.

What however throws me off is that I end up getting an error 1014 "No target architecture" when trying to compile this.

As this whole thing is pretty convoluted, could you try to reduce this project to just the alleged erroneous functions and then ZIP up the whole project (including your project settings, right click on the top most file in the right file pane and then select "ZIP project files") so we can really talk about the same things...

Ralf

[TimoVJL]

Things to try:
- compile without optimization.
- move that function to separate file.

[kamesh001]

Things to try:
- compile without optimization.
- move that function to separate file.

Compiling without optimization removed the error message. Is there a way to apply optimization only to the specific file and NOT to the entire project? I don't want to lose the speed and size advantages from optimization for the rest of the code.

[TimoVJL]

Is there a way to apply optimization only to the specific file and NOT to the entire project? I don't want to lose the speed and size advantages from optimization for the rest of the code.

There is #pragma for it:
#pragma optimize(none)
#pragma optimize()

[CommonTater]

Things to try:
- compile without optimization.
- move that function to separate file.

Compiling without optimization removed the error message. Is there a way to apply optimization only to the specific file and NOT to the entire project? I don't want to lose the speed and size advantages from optimization for the rest of the code.

You can take Timo's suggestion and use the pragmas ...

However; this is an ongoing issue with Pelles C since version 6.0.  If you can track it down to the specific sequence that causes the "expression too complex" error with optimizations on but not when they are off... you should make a bug report about it.  (Be sure to make a project with the minimum amount of code that demonstrates the problem and attach it to your report.)

Since this is an ongoing issue I did some testing and discovered there is very little difference in the speed or size of most programs with the optimizations off vs on.  So, until this is fixed, I compile all my projects with optimizations off.