(j3.2006) BEQ, BNE?

[Van Snyder]

On Tue, 2013-01-29 at 21:53 -0800, Robert Corbett wrote:
> On 01/29/13 20:24, Van Snyder wrote:
> > On Tue, 2013-01-29 at 19:54 -0800, Robert Corbett wrote:
> >> On 01/29/13 18:22, Van Snyder wrote:
> >>> We did BLT, BLE, etc., but why not BEQ and BNE?
> >>>
> >>> One might be tempted to use == and /=, but these are required to fail
> >>> for +/- zero on ones-complement and sign-magnitude machines because
> >>> Fortran doesn't distinguish +0 from -0 for integers.
> >>>
> >>> Should we add BEQ and BNE, or suggest that users write something like
> >>>
> >>>     if ( BLE(I,J) .and. BLE(J,I) ) then ! I and J are equal bit strings
> >>>       ....
> >>>     end if
> >>>
> >>> or is there another way to do it that I've overlooked?
> >>
> >> I prefer
> >>
> >>
> >>         IF ( POPCNT(IEOR(I, J)) .EQ. 0) THEN ! I and J are equal bit strings
> >
> > Sounds more expensive than BEQ(I,J) would be on architectures that can
> > do an unsigned integer compare but don't have a fast POPCNT.
> 
> Any optimizing compiler worth being called an optimizing compiler can recognize 
> idioms and produce good code for them.

The poor human who has to read this code next year, or in ten years'
time, will spend more time figuring out what this means than BEQ(I,J).
Some other poor human spent a deal of time figuring out that the
suggested idiom is equivalent to BEQ(I,J).  It would be less costly all
around, and more reliable, just to have BEQ(I,J).

> Bob Corbett
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3