Mail Archives: pgcc/2000/03/06/17:30:00
As would I be. Order of ops (PEMDAS [for those who desire review, that's
Parentheses, Exponents, Multiply/Divide, and Add/Subtract]) should take care of
this. If not, then it would definitely be a bug, a very horrible broken bug.
I admit, quite often when I write my code, I put parentheses in anyway, just to
make it more readable, particularly on long expressions. This may be fairly common
as well. But as anyone who does science w/ C or FORTRAN knows, it is important
that order of ops is maintained.
One possibility is that he did put in parantheses, but f2c removed them. Still
very bad, not so much because it would necessarily remove necessary parentheses,
but b/c it would mean more code in f2c in order to do this, and likely no real
advantage. FORTRAN is better for math anyway, and has its own compiler now, g77.
Anyway, I ramble on, but it should be looked into to make sure that the optimizer
is not making this mistake. If someone wants an optimizer to simplify expressions,
I think they may very well might be off their rocker. A compiler's job is not to
simplify expressions, except in very well defined places (such as mul's into
shifts and adds, i.e x=x*1024 ~ x=x<<10, and in some cases, is faster). Otherwise,
if you want to simplify expressions, use Maple, do it by hand, or get another
program to do it.
If it's about readability, then you merely need to have two versions of the
expressions, one commented out. Can make for larger source files, but the comments
should be out stripped by the compiler. Besides, you would probably start out with
the normal, straightforward expressions, to test it, then simplify them later,
Right????
David Pyke wrote:
> did you try using brackets at all???
>
> altho if that was the problem i'd be very surprised.
>
> ie...
> static inline mycomplex
> zmlt (mycomplex z1, mycomplex z2)
> {
> mycomplex z;
>
> z.re = (z1.re * z2.re) - (z1.im * z2.im);
> z.im = (z1.re * z2.im) + (z1.im * z2.re);
>
> return z;
> }
>
- Raw text -