MIN vs IOR

[jimdempseyatthecove]

While MIN can take several arguments MIN(A,B,C), why not permit the elemental intrinsic bit manipulation functions take more than two variables: IOR(I,J,K), same with the other bit manipulation functions.

(I expect "it's not done")

Jim Dempsey

[lklawrie]

I would suspect a matter of precedence would be confusing.

(i.e., which pair gets done first)

[andrew_4619]

I wanted that featrure as well, with bit parameters for sdk calls you often need to ior several parameters and end up with a messy nesting of IOR.

@Linda - the order does not matter for ior.

[Steven_L_Intel1]

Use IANY for this - it accepts an array for which you can use an array constructor.  IALL is an AND operation

[andrew_4619]

Thanks for that Steve I just looked at the help example, the key is constructing this array in the call e.g.

IANY ([I, J, K.L])

is much nicer than IOR(I,IOR(J,IOR(K.L)))

[jimdempseyatthecove]

Thanks Steve,

IANY is equivilent to IOR of all args
IALL is equivilent to IAND of all args

This leaves out IXOR

Jim Dempsey

[Steven_L_Intel1]

True, but how many times do you need to do that? If it's a lot, you can write your own.

[jimdempseyatthecove]

Steve,

Assuming I do wish to write my own, say a generic function (not necessarily IXOR), has there been any discussion with the FORTRAN standards comittee to provide a means of variable number of arguments? I do not mean a defined number of optional arguments, nor do I mean an array of values, rather something similar to the C/C++ elipsis (...) that can be used in place of a list of arguments (zero or more). This permits me to have the equivilent to an array of (unnamed) references. While IXOR could be satisified with an array of values, other functions/subroutines may require the references such that these references may get modified but the function/subroutine.

Jim Dempsey

[Steven_L_Intel1]

I am unaware of any recent standard proposals to provide the ability to write routines with a variable nunber of arguments such as MIN and MAX have, and none have been discussed at any of the meetings I have attended over the years.

[JVanB]

jimdempseyatthecove wrote:

Thanks Steve,

IANY is equivilent to IOR of all args
IALL is equivilent to IAND of all args

This leaves out IXOR

Jim Dempsey

IPARITY

[Paul_Curtis]

Here's how I've been doing this, not elegant but it sure works:

[fortran]

INTEGER FUNCTION MOR (f1, f2, f3, f4, f5, f6, f7, f8)
    IMPLICIT NONE
    INTEGER,INTENT(IN)            :: f1, f2
    INTEGER,INTENT(IN),OPTIONAL    :: f3, f4, f5, f6, f7, f8
    
    !    MultiOR of multiple arguments, as supplied
    MOR = IOR(f1, f2)
    IF (.NOT.PRESENT(f3)) RETURN
    MOR = IOR(MOR,f3)
    IF (.NOT.PRESENT(f4)) RETURN
    MOR = IOR(MOR,f4)
    IF (.NOT.PRESENT(f5)) RETURN
    MOR = IOR(MOR,f5)
    IF (.NOT.PRESENT(f6)) RETURN
    MOR = IOR(MOR,f6)
    IF (.NOT.PRESENT(f7)) RETURN
    MOR = IOR(MOR,f7)
    IF (.NOT.PRESENT(f8)) RETURN
    MOR = IOR(MOR,f8)
END FUNCTION MOR
[/fortran]

[andrew_4619]

Thank you Repeat Offender  , IPARITY is duly noted , I wrote my own function for this but an instrinsic is  a much neater way

[jimdempseyatthecove]

IPARITY for IXOR great. Now if the standards committee can only agree to aliasing IALL, IANY and IPARITY to IAND, IOR, IXOR then the programmer won't have to re-read through the library functions to find a function name that is not quite self explanitory.

Paul,

Your function MOR would be fine for cases where the caller supplies known arguments. In situations where the caller receives unknown (not known to be present) arguments, then any of the arguments (not just the tail end arguments) might not be present. Consider:

[fortran]
INTEGER FUNCTION MOR (f1, f2, f3, f4, f5, f6, f7, f8) 
     IMPLICIT NONE
     INTEGER,INTENT(IN),OPTIONAL    :: f1, f2, f3, f4, f5, f6, f7, f8 
       
     !    MultiOR of multiple arguments, as supplied
     MOR = 0
     IF(PRESENT(f1)) MOR = IOR(MOR, f1)
     IF(PRESENT(f2)) MOR = IOR(MOR, f2)
     IF(PRESENT(f3)) MOR = IOR(MOR, f3)
     IF(PRESENT(f4)) MOR = IOR(MOR, f4)
     IF(PRESENT(f5)) MOR = IOR(MOR, f5)
     IF(PRESENT(f6)) MOR = IOR(MOR, f6)
     IF(PRESENT(f7)) MOR = IOR(MOR, f7)
     IF(PRESENT(f8)) MOR = IOR(MOR, f8)
END FUNCTION MOR
[/fortran]

Jim Dempsey

[mecej4]

Jim Dempsey wrote:
 then the programmer won't have to re-read through the library functions to find a function name that is not quite self-explanatory

Seconded. It is easy to look up what a function with a given name does. Doing the reverse look up, i.e., finding a function with a set of desired capabilities, can be quite hard and time-consuming.

[Steven_L_Intel1]

Had completely forgotten about IPARITY! Odd name for this function, though.

[andrew_4619]

Jim Dempsey wrote: then the programmer won't have to re-read through the library functions to find a function name that is not quite self-eexplanatory

Thirded, After Jims post I looked in the instrinsics begining with I to see if there was a function but IPARITY escaped my gaze....

[jimdempseyatthecove]

Steve,

Could you possibly ask the IVF document writers to include in the See Also sections of IAND, IOR, and IXOR hyperlinks to IALL, IANY and IPARITY respectively. I think this would be very helpful for any programmer that knows what they want but doesn't know the flavor of the cookie that the cookie monster wants. In reading the responses here, as an example the preceeding response from app4619, having this hyperlink in IXOR See Also section would have eliminated a tiersome search through the documentation (as well as help you un-forget your completely forgotten about IPARITY).

Jim Dempsey

[Steven_L_Intel1]

I will make that suggestion.

[JVanB]

Steve Lionel (Intel) wrote:

Had completely forgotten about IPARITY! Odd name for this function, though.

ANY, ALL, PARITY

IANY, IALL, IPARITY

What's so odd about that, except that PARITY is .TRUE. if parity is odd? Jim Dempsey's spelling of IEOR as IXOR seems to me a little dangerous, however: ifort doesn't actually have an IXOR intrinsic, does it? And doesn't the precedence of operator(.XOR.) change depending on the status of the /standard-semantics switch, making it more risky to use than operator(.NEQV.)?

[Steven_L_Intel1]

RO, I am used to the concept of parity having variants odd and even - IPARITY satisfies only one of those.

ifort does accept IXOR (and XOR) as a non-standard spelling of IEOR.

As for .XOR., if you say /standard-semantics, .XOR. is not defined as an intrinsic at all, so there is no precedence issue.

[JVanB]

The odd parity thing was just a play on words on your usage of the word 'odd' :)

OK, I didn't look under the documentation of IEOR which one has to do to find the alternate spellings.

Doesn't (A .MyOp. B .XOR. C), where the programmer has defined operator(.MyOp.) and operator(.XOR.) then change its meaning according to the state of the /standard-semantics switch?