Re: Is this a compiler error?



"Michael Trover" <mtrover@xxxxxxxxxxxxx> wrote in message news:sM6dneYZKpiwxSHQnZ2dnUVZ_sCdnZ2d@xxxxxxxxxxxxxxxx
| On 4/30/2011 2:28 PM, Richard Maine wrote:
| > Michael Trover<mtrover@xxxxxxxxxxxxx> wrote:
| >
| > [an incomplete example]
| >
| > Little can be concluded from the excerpt you showed. We would need to
| > actually see the functions - not just a description of their interface.
| > Yes, it matters. A lot.
| >
| > As is, we have no guarantee that the code is even valid Fortran at all.
| > There are many things that you could do in the functions that would make
| > the code invalid in ways that might not be obvious to you. Function side
| > effects are *VERY* high on that list. WIthout seeing more data, that
| > would be my guess as to what might be happening, but that depends very
| > much on the functions, which you didn't show.
| >
| >> Isn't Fortran suppose to be associative and commutative?
| >
| > No. Those words don't even appear in the Fortran standard. (I just
| > grepped the source of the f2003 standard to make sure I was telling the
| > truth). So you'd first have to very precisely define exactly what you
| > meant in the context of a programming language. No the definitions you
| > learned in grade school arithmetic are not sufficient to directly apply
| > to programming languages.
| >
| > As for associative, absolutely *NO* *NO* *NO*. Finite precision floating
| > point arithmetic is never associative. That's not a language matter;
| > that's computer hardware.
| >
| > There has also been hardware that was not commutative for some basic
| > arithmetic operations. I forget the details, and it was an oddball case,
| > but such have existed.
| >
| > At a higher level, which does get into language issues, it is up to you,
| > the programmer, to write your functions in such a way that their side
| > effects don't cause "oddities". In most cases of oddities like the one
| > you show the code is technically illegal Fortran, but illegal in a way
| > that compilers don't tend to catch for you. Failing to catch such things
| > is not a compiler bug; the standard doesn't require it, and it is often
| > impractical for a compiler to do.
| >
| > Using PURE functions greatly increases the odds of the compiler catching
| > things like that. Unfortunately, PURE functions are so limitted that
| > many things can't be done with them. For example, you can't have
| > diagnostic output in them.
| >
| The functions are kind of complex and I'm still working on them.
|
| Maybe this will help,

Not even a little.


.