Simon Sobisch

OK, then all compiler agree with the standard here (apart from MF reasoning that as a statement) and we can close this; note that cobc -std=ibm will likely display identical as IBM (as that dialect disables "pretty printing).

plus/minus need a space before numbers to be recognized as arithmetic operator

TAN "should" not raise an error as COS should not result in zero - those functions return an approximation, so something like .0000000000000000000000000000000000000000000000000000000000000001 as intermediate values is totally fine; we possibly should round (not necessarily truncate) in case of moving from the internal mpf to the mpz.

Where do we stand with that? MF errors on that with "recognizing" it as an unknown verb GnuCOBOL says "error: syntax error, unexpected Literal" gcobol says <source>:18:33: error: syntax error, unexpected numeric literal 18 | compute num-4 = (3/2)+3 | ^~ cobol1: error: failed compiling <source> ... and my guess is that IBM will error similar. So - just close this as "not a bug"?

Tangent function possibly nees a zero-checl

I'm not sure - that only happens in cases of calculations with exactly pi, which we don't have. The standard says because of this that the return value is only an approximation. GMP docs say that we'd get a signal (crash) if that happens - can you produce a crash here? If yes, we need a check if (mpz_sgn (vf2) == 0) (not sure what we should do then, according to the standard we may should set vf2 to 0.000000000000000001 in that case), but otherwise pointing this out in a comment could be useful.

you can easily try on your own online: https://cobol.godbolt.org/z/sj5rYx67x (if you do that then you get a non-integer in every case - otherwise you'd have the expected values with gcobol)

The simple "rounded" should be enough, no? Side note: that floating result shows that we can improve the optimizing part - it currently stops when seeing division, but as long as all are constants this should still be handled in the optimizer (for a test that cannot be optimized easily: MOVE 3 TO wRESULT. compute wRESULT = (1 / wRESULT ) *3.)