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.


.



Relevant Pages

  • Re: Bugs at my web site
    ... >> I don't think it's being maintained now, but given that Fortran 77 isn't ... >what might prove fatal with a new compiler. ... >that I think they are good traditional fortran, whatever some standard might ... guess at heart I'm still a scientist rather than a Real Programmer :-) ...
    (comp.lang.fortran)
  • Re: Bugs at my web site
    ... what might prove fatal with a new compiler. ... that I think they are good traditional fortran, whatever some standard might ... I hope the g95 people, after taking a good long vacation to ...
    (comp.lang.fortran)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... Your compiler supports SIZEOF as do several others including my ... to be other than 8bits when cheap memory came on the scene and BURIED ...
    (comp.lang.fortran)
  • Re: Starting to doubt fortran
    ... that there were absolutely no "clever" tricks. ... time a new version of the vendors C compiler comes out. ... Fortran), it could be reliably depended upon in a portable way. ... That's beyond the standard, but many tend to be so ...
    (comp.lang.fortran)
  • Re: Is this a compiler error?
    ... we have no guarantee that the code is even valid Fortran at all. ... Those words don't even appear in the Fortran standard. ... meant in the context of a programming language. ... impractical for a compiler to do. ...
    (comp.lang.fortran)