Bitwise functions with more arguments?
glen herrmannsfeldt
IOR, and IEOR only allow for two arguments. It is not
unusual to use these functions on more than one argument,
such as ORing, ANDing, or ExclusiveORing more than two values.
Note, for comparison, that the MIN and MAX functions do allow
for more than two arguments, though one could nest the two
argument versions for similar functionality.
As a side note, exclusive OR is commonly abbreviated XOR,
and rarely, if ever, EOR.
-- glen
Richard Maine
The bit logical functions were "imported" from the MIL STD.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> I was just noticing that the bitwise logical functions IAND,
>> IOR, and IEOR only allow for two arguments. It is not
>> unusual to use these functions on more than one argument,
>> such as ORing, ANDing, or ExclusiveORing more than two values.
>> Note, for comparison, that the MIN and MAX functions do allow
>> for more than two arguments, though one could nest the two
>> argument versions for similar functionality.
>> As a side note, exclusive OR is commonly abbreviated XOR,
>> and rarely, if ever, EOR.
> The bit logical functions were "imported" from the MIL STD.
I suppose the MIL STD version should not have variable argument
functions, as that would preclude user level implementation of them.
It would seem that the standard could have extended them, but
I suppose I am not surprised that it didn't. Also, IXOR as
an alias for IEOR would have been nice.
Cryptography likes to do multiple such operations, where the
'more than two argument' functions are very useful.
-- glen
Richard Maine
> IXOR as an alias for IEOR would have been nice.
Note that it is easy to make your own aliases for intrinsic functions.
No need for it to be in the standard. Doing it that way has the
advantage that you don't have to argue with other people about what the
best choices of names are. I personally think IXOR is abominable, though
that's for the same reason I dislike IAND and IOR as names. If I were
going to redo things instead of just importing the MIL STD as is, the
first thing I'd do would be to lose the spurious "I" prefixes. XOR would
be fine, but not IXOR. As long as you are doing it in user code instead
of in the standard, you don't need to care about what I might think.
Put an intrinsic statement in a module to make the intrinsic accessible
via USE. Then use the RENAME feature of USE. If you don't wnat to have
to do such a rename alll over the place, you could encapsulate it in
another level of module.
Ron Shepard
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> As a side note, exclusive OR is commonly abbreviated XOR,
> and rarely, if ever, EOR.
IEOR() was part of the milstd standard in 1979, and has been
included in the fortran standard since f90. With that long
pedigree, I would not call the notation "rare".
The odd thing is that this is the second post today where I
referenced milstd 1753.
$.02 -Ron Shepard
glen herrmannsfeldt
> In article <hksv2c$1tg$1...@naig.caltech.edu>,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> As a side note, exclusive OR is commonly abbreviated XOR,
>> and rarely, if ever, EOR.
> IEOR() was part of the milstd standard in 1979, and has been
> included in the fortran standard since f90. With that long
> pedigree, I would not call the notation "rare".
There are twice as many google hits for XOR as for EOR.
It looks like most hits for XOR are for exclusive or, but
few hits for EOR are. The first is Enhanced Oil Recovery,
and it goes down from there. Ethiopian Orphan Relief,
European Ordering Rules, Epoch of Reionization, End of Record,
Exams on Request, Epping Ongar Railway, Equal Opportunity Review...
Everything except Exclusive OR.
> The odd thing is that this is the second post today where I
> referenced milstd 1753.
That is odd.
I always thought that they were the IBM extensions needed
to write the Fortran H compiler. Unlike DEC, IBM never allowed
the use of Fortran logical operators on integer values.
-- glen
m_b_metcalf
>
> It would seem that the standard could have extended them, but
> I suppose I am not surprised that it didn't.
The Fortran 90 standard did extend them, to array-valued arguments.
Regards,
Mike Metcalf
robin
| > In article <hksv2c$1tg$1...@naig.caltech.edu>,
| > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
|
| >> As a side note, exclusive OR is commonly abbreviated XOR,
| >> and rarely, if ever, EOR.
|
| > IEOR() was part of the milstd standard in 1979, and has been
| > included in the fortran standard since f90. With that long
| > pedigree, I would not call the notation "rare".
|
| There are twice as many google hits for XOR as for EOR.
|
| It looks like most hits for XOR are for exclusive or, but
| few hits for EOR are. The first is Enhanced Oil Recovery,
| and it goes down from there. Ethiopian Orphan Relief,
| European Ordering Rules, Epoch of Reionization, End of Record,
| Exams on Request, Epping Ongar Railway, Equal Opportunity Review...
|
| Everything except Exclusive OR.
EOR stands for End Of Record.
robin
|I was just noticing that the bitwise logical functions IAND,
| IOR, and IEOR only allow for two arguments. It is not
| unusual to use these functions on more than one argument,
That's right, namely, two arguments.
(What's the sound of one hand clapping?)
| such as ORing, ANDing, or ExclusiveORing more than two values.
You can nest the operations for that.
robin
|I was just noticing that the bitwise logical functions IAND,
| IOR, and IEOR only allow for two arguments. It is not
| unusual to use these functions on more than one argument,
That's right, namely, they require at least 2 arguments!
(What's the sound of one hand clapping?)
| such as ORing, ANDing, or ExclusiveORing more than two values.
You can nest the operations for that.