MIN vs IOR

MIN vs IOR

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

www.quickthreadprogramming.com
28 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

I would suspect a matter of precedence would be confusing.

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

Linda

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 accepts an array for which you can use an array constructor.  IALL is an AND operation

Steve - Intel Developer Support

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,

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

This leaves out IXOR

Jim Dempsey

www.quickthreadprogramming.com

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

Steve - Intel Developer Support

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

www.quickthreadprogramming.com

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.

Steve - Intel Developer Support

Citation :

jimdempseyatthecove a écrit :

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 this, not elegant but it sure works:

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

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

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 

Jim Dempsey

www.quickthreadprogramming.com

Citation :

Jim Dempsey a écrit :
 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 about IPARITY! Odd name for this function, though.

Steve - Intel Developer Support

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,

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

www.quickthreadprogramming.com

I will make that suggestion.

Steve - Intel Developer Support

Citation :

Steve Lionel (Intel) a écrit :

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

Steve - Intel Developer Support

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?

.XOR. is a logical operator not to be confused with an intrinsic function IEOR, IXOR, IPARITY (though I wish IPARITY would accept a list of variables in addition to an array of variables).

In the documentation Summary of Operator Precedence it lists defined binary operators as having lowest priority (less than .XOR.). It does not state that this is affected by the  /standard-semantics switch.

Jim Dempsey

www.quickthreadprogramming.com

The precedence of defined operators doesn't change with /standard-semantics. What does change is whether or not .xor. is recognized as a predefined operator. Without /standard-semantics, if you have a user-defined operator .xor. that supercedes the predefined one.

The situation where this can make a difference is if you overload .xor. with a signature different from the intrinsic.

Steve - Intel Developer Support

This program prints '/standard-semantics is in effect.' on gfortran, and 'Non-standard precedence detected.' on ifort without the /standard-semantics switch in effect. What does it print with that switch enabled?

module m
   implicit none
   private
   public operator(.MyOp.), operator(.XOR.)
   interface operator(.MyOp.)
      module procedure p1
   end interface operator(.MyOp.)
   interface operator(.XOR.)
      module procedure p2
   end interface operator(.XOR.)
   contains
      function p1(x,y)
         integer p1
         integer, intent(in) :: x, y
         p1 = 0
      end function p1
      function p2(x,y)
         integer p2
         integer, intent(in) :: x, y
         p2 = 1
      end function p2
end module m
program p
   use m
   implicit none
   if((0 .MyOp. 0 .XOR. 0) ==  1) then
      print '(a)', '/standard-semantics is in effect.'
   else
      print '(a)', 'Non-standard precedence detected.'
   end if
end program p

C:ProjectsQ697475Console3>ifort /standard-semantics ro.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.198 Build 20130607
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.
-out:ro.exe
-subsystem:console
ro.obj
C:ProjectsQ697475Console3>ro.exe
/standard-semantics is in effect.

Steve - Intel Developer Support

Steve,

I am a little bit confused with respect to /standard-sematics and non-standard semantics as it applies to Repeat Offenders post.

In his post, he has overloaded operator .XOR.

Your reply seems to indicate that depending on /standard-sematics or lack thereof that the compiler will (silently) use either the user specified overloaded .XOR. or the internal (intrinsic) .XOR.

On the other hand you could have ment the /standard-sematics or lack thereof only affecte the precidence, and in both cases the user specified overloaded .XOR. is used.

Jim Dempsey

www.quickthreadprogramming.com

Without /standard-semantics, one can overload (extend the generic) .xor. but you get the compiler's non-standard precedence for it. With /standard-semantics, the compiler doesn't provide .xor. so RO's definition is the only one.

Steve - Intel Developer Support

"Additional intrinsic functions for bit manipulation [mostly 5.3]" The array reduction intrinsic functions IALL, IANY and IPARITY appear to be Fortran 2008 additions, perahsp that is why we are not so familliar....

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui