topic Jim Dempsey wrote: then the in Intel® Fortran Compiler

MIN vs IOR

jimdempseyatthecove — Thu, 11 Jul 2013 14:20:08 GMT

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

I would suspect a matter of

lklawrie — Thu, 11 Jul 2013 15:06:17 GMT

I would suspect a matter of precedence would be confusing.

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

I wanted that featrure as

andrew_4619 — Thu, 11 Jul 2013 15:15:07 GMT

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.

Use IANY for this - it

Steven_L_Intel1 — Thu, 11 Jul 2013 15:19:32 GMT

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

Thanks for that Steve I just

andrew_4619 — Thu, 11 Jul 2013 15:34:23 GMT

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)))

Thanks Steve,

jimdempseyatthecove — Thu, 11 Jul 2013 16:01:35 GMT

Thanks Steve,

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

This leaves out IXOR

Jim Dempsey

True, but how many times do

Steven_L_Intel1 — Thu, 11 Jul 2013 17:03:00 GMT

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

Steve,

jimdempseyatthecove — Thu, 11 Jul 2013 17:33:52 GMT

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

I am unaware of any recent

Steven_L_Intel1 — Thu, 11 Jul 2013 17:52:47 GMT

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.

Quote:jimdempseyatthecove

JVanB — Fri, 12 Jul 2013 01:39:03 GMT

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

Here's how I've been doing

Paul_Curtis — Fri, 12 Jul 2013 02:33:44 GMT

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]

Thank you Repeat Offender ,

andrew_4619 — Fri, 12 Jul 2013 07:30:45 GMT

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

IPARITY for IXOR great. Now

jimdempseyatthecove — Fri, 12 Jul 2013 12:43:37 GMT

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

Quote:Jim Dempsey wrote: then

mecej4 — Fri, 12 Jul 2013 12:50:00 GMT

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.

Had completely forgotten

Steven_L_Intel1 — Fri, 12 Jul 2013 12:58:58 GMT

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

Jim Dempsey wrote: then the

andrew_4619 — Fri, 12 Jul 2013 15:44:35 GMT

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....

Steve,

jimdempseyatthecove — Fri, 12 Jul 2013 16:21:40 GMT

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

I will make that suggestion.

Steven_L_Intel1 — Fri, 12 Jul 2013 17:04:59 GMT

I will make that suggestion.

Quote:Steve Lionel (Intel)

JVanB — Fri, 12 Jul 2013 17:06:36 GMT

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.)?

RO, I am used to the concept

Steven_L_Intel1 — Fri, 12 Jul 2013 17:18:54 GMT

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.