From: glen herrmannsfeldt on
robin <robin51(a)> wrote:
> "glen herrmannsfeldt" <gah(a)> wrote in message news:hte7fq$tqe$1(a)

> | In the days of ones complement and sign magnitude integers,
> | a system could use negative zero as an illegal value,

> Not when such values are ordinarily generated in the course of
> any arithmetic.

Then the system (hardware and software) couldn't use it.

It is easy, though, if you do ones complement addition as subtracting
the complement, and subtraction as subtraction, then you never get
a negative zero result. For sign magnitude, it is easier.

Stories are that WATFOR on the 7040 used the parity error trick.

-- glen
From: mecej4 on
Friedrich wrote:

> On Sun, 23 May 2010 14:43:51 -0700, nospam(a)see.signature (Richard Maine)
> wrote:
> <snipping almost full reply>
> Mr. Maine,
> thank you for an
> I-can't-believe-somebody-would-write-an-explanation-of-this-
> length-just-to-help-a-newbie explanation. I won't say I understand it
> perfectly now (for there is a lot probably I still don't know I don't
> know), but this answered all my questions involving the SAVE statement,
> and also, a question I was about to post, about why in some libraries,
> variables/arrays are declared in "empty" modules, like this:
>> module m
>> integer :: i
>> end module m
> I guess my main confusion with the SAVE statement, in an example which I
> produced, while I was trying to "figure it out" was the fact that Intel's
> Visual Fortran (I do not have it on the computer I'm writing this from, so
> I'm unsure somewhat of the version, but it's one of the more recent) is
> probably one of those compilers which save variables values, regardless of
> ----------------------------------------
> subroutine save(j)
> implicit none
> integer :: i = 0, j
> save i
> i = i + j
> write(*,*)i
> end subroutine save
> program test_save
> implicit none
> integer :: j
> j = 1
> call save(j)
> call save(j)
> end program test_save
> ------------------ OUTPUT: -------------
> 1
> 2
> ----------------------------------------
> Because of it, I saw no change
> upon removing the aforementioned from below the subroutine declaration,
> and that made me going crazy, because I thought I was doing something
> wrong, fundamentally.
> If I may trouble you for just one tiny detail. In the above simple
> example, were we to follow the standard "to the letter", what should
> exactly happen ? To my reasoning, it should go like;
> - j is declared, and assigned the value 1
> - first call to save
> - i is declared, and assigned the value 0, and the SAVE property
> - thanks to j, i is increased to 1, and written out
> - subroutine returns "focus" to main program
> - second call to save
> - i is declared again, and assigned the value 0 again ... should the
> problem arise here (can declared values be "declared again" ?),
> or is this the correct behaviour, that the value of i (1) is preserved,
> therefore increased to 2 few lines later on ?
> I'm puzzled about SAVEd values and this kind of declaration&assignment of
> values, what behaviour should one expect ?
> In any case, thank you for the effort you put in.
> Regards,
> Friedrich

Richard Maine has (as usual) given a detailed and very helpful reply. Here
is another point that may help you along your way:

Your thinking (as suggested by your explanation of SAVE above) is more
appropriate to an _interpreted_ language, such as Ruby or Python. In a
compiled language such as Fortran, there are two main categories of
statements: those that are executed, and those that are not.

The most significant among the "non-executable" statements are
declarations -- it is _conceptually_ helpful to think of declarations as
non-executable, even though they may actually generate some executed
machine instructions, such as pushing arguments on a stack, etc.

Once you obtain a firm grasp of the differences between interpreted and
compiled languages, you may allow yourself the luxury of realizing that the
boundary between "interpreted" and "compiled" is much more elastic/blurred
nowadays. In fact, there is at least one interpreted dialect of Fortran,
and a similar one for C. And, when you use a symbolic debugger for compiled
Fortran, the combination may sometimes resemble an interpreted language!

-- mecej4