(j3.2006) BEQ, BNE?

Keith Bierman khbkhb
Fri Feb 1 12:10:20 EST 2013


On Fri, Feb 1, 2013 at 9:35 AM, Dick Hendrickson
<dick.hendrickson at att.net>wrote:

>
>
>
> On Thu, Jan 31, 2013 at 9:01 PM, Keith Bierman <khbkhb at gmail.com> wrote:
>
>> Thanks for sleuthing out f95
>>
>> I have no recollection of why we added integer +-0 as new text at that
>> time
>> Keith Bierman (nook)
>>
>> Actually, in FORTRAN 77 it says pretty much the same thing.
>
> "4.1.3 Data Type Properties
> .... For real, double precision, and integer data, the value zero is
> considered neither positive nor negative. The value of a signed zero is the
> same as the value of an unsigned zero."
>


Ah. I'd only ever had to deal with the fp part, and had forgotten the
integer part. Guess my memory isn't what it ought to be.
I do recall working on a CDC mixing Pascal and Fortran programs that
passing floating point zero from Fortran to Pascal would sometimes misfire
(and tracked it to -0, the Pascal runtime didn't handle it correctly). The
workaround was to change every call to Pascal to have something like

CALL Pascal(x+0.0e0, y+0.0e0) ! obviously, for x,y as REAL

Obviously there's no assurance that such a trick would work for some
conjectured future processor with two forms of integer 0. It really would
boggle the mind to envision anyone building it.
Obviously, fixing the Standard as Van suggests is a trivial change to the
Standard. We've probably spent more  committee cycles in this email
discussion than the edits to add the new intrinsics would have taken.
The no so obvious thing is what cost(s) that may impose on the
implementors. Folks who were certain there were fixed numbers of intrinsics
may have "hard" limits, the interactions with optimization and debuggers,
etc. Different implementors could face very different costs (from what very
little I recall of the NAG compiler, once upon a time I think it would have
been small for Malcolm). For some other compilers, not so small (not huge,
but the combination of scarce development, integration and test resources
for most compiler groups should never be underestimated. The more highly
optimizing the environment, the more likely it is that even trivial changes
will have more considerable impact).

No doubt the Committee rejected interpreting "value ....is the same as...."
for the binary ops as meaning just test for equality and make the runtime
"normalize" any negative zeros as needed. That would have limited the pain
and implementation suffering to just the folks daft enough to have two
forms of zero ;>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130201/0c209126/attachment-0001.html 



More information about the J3 mailing list