Re: Shortcut logicals (was: Re: F200x )

Re: Shortcut logicals (was: Re: F200x )

[James Van Buskirk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:mXzLd.100$xR1.94@bgtnsc04-news.ops.worldnet.att.net...

> Well, I have the F2003 FCD open right now, in �7.4.3 Masked array
> assignment - WHERE.  So, perhaps you can point out what part of
> it resolves the issue I raised:

>    cond1 .and. cond2 .andthen. cond3 .and. cond4

> Is COND4 permitted to be evaluated or not?  I don't see that
> WHERE tells me.  It has a concept of "pending control" which
> I see can be applied on nested constructs, but in the above
> expression, not of the terms actually present are part of any
> "pending" condition.  Or, are you talking about some other
> aspect of WHERE entirely?

OK, I have added comp.lang.ada, so hopefully someone there
can answer the question about the effect of precedence on
your snippet, and also discuss the ergonomics of Ada short-
circuiting logical operators, or whatever they call them.

I would answer your question above, assuming cond1 .AND. cond2
evaluate to scaler .FALSE._lk to be that it all depends; either
cond3 or cond4 or neither or both could be 'short-circuited'.
In the f95 standard I see some verbiage to the effect that:

"If a nonelemental function reference occurs in the expr or
variable of a where-assignment-statement or in a mask-expr, the
function is evaluated without any masked control; that is, all
of its argument expressions are fully evaluated and the function
is fully evaluated.  If the result is an array and the reference
is not within the argument list of a nonelemental function,
elements corresponding to true values in the control mask are
selected for use in evaluating the expr, variable, or mask-expr.

"If an elemental operation or function reference occurs in the expr
or variable of a where-assignment-stmt or in a mask-expr, and is not
within the argument list of a nonelemental function reference, the
operation is performed or the function is evaluated only for the
elements corresopnding to true values of the control mask.

"If an array constructor appears in a where-assignment-stmt or in
a mask-expr, the array constructor is evaluated without any masked
control and then the where-assignment-stmt is executed or the
mask-expr is evaluated."

For .AND_THEN. and .OR_ELSE., if added to the Fortran language,
the language would have to be changed somewhat to make it in
terms of evaluating expressions rather than masked assignment.
Also there should be something about scalar function references
in there as well.  I'm not even sure about what the standard
thinks in WHERE, if an elemental function reference is used in
a scalar context, such as

WHERE(cond1) x = f(y)*g(z)

given that cond1, x, and g(z) all have the same shape, f is
elemental, and y is scalar.  Is any(cond1) == .FALSE. then
is the standard saying you still have to evaluate f(y) if it's
a scalar function but not if it's elemental.  This last
paragraph shouldn't be considered a well-formed thought.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Re: Shortcut logicals (was: Re: F200x )

[Robert A Duff]

"James Van Buskirk" <not_valid@comcast.net> writes:

> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:mXzLd.100$xR1.94@bgtnsc04-news.ops.worldnet.att.net...
> 
> > Well, I have the F2003 FCD open right now, in �7.4.3 Masked array
> > assignment - WHERE.  So, perhaps you can point out what part of
> > it resolves the issue I raised:
> 
> >    cond1 .and. cond2 .andthen. cond3 .and. cond4
> 
> > Is COND4 permitted to be evaluated or not?  I don't see that
> > WHERE tells me.  It has a concept of "pending control" which
> > I see can be applied on nested constructs, but in the above
> > expression, not of the terms actually present are part of any
> > "pending" condition.  Or, are you talking about some other
> > aspect of WHERE entirely?
> 
> OK, I have added comp.lang.ada, so hopefully someone there
> can answer the question about the effect of precedence on
> your snippet, and also discuss the ergonomics of Ada short-
> circuiting logical operators, or whatever they call them.

Sorry, I've no idea what the Fortran rules are.

In Ada, the above expression is syntactically illegal -- compile time
error.  You can write:

    (cond1 and cond2) and then (cond3 and cond4)

or:

    ((cond1 and cond2) and then cond3) and cond4)

for example.

"and" is just a function call.  If you say "X and Y" then X and Y are
both evaluated (in either order) and passed to the "and" function.  The
predefined version of "and" returns True if both are True.  But "and
then" is a short-circuit control form: if you say "X and then Y", X is
evaluated first, and if it's True, you're done.  Otherwise (X is False)
Y is evaluated.

And the syntax rules forbid mixing "and" and "and then" -- you have to
use parens.  All of these ("and", "and then", "or", "or else", "xor")
are lower precedence than most other operators in Ada.  So you can
write:

    A <= B and B <= C

which means the same as:

    (A <= B) and (B <= C)

The point of "and then" is so you can write things like:

    Y /= 0 and then X/Y < 10

where X/Y makes no sense if Y is zero.

- Bob

Re: Shortcut logicals (was: Re: F200x )

[James Giles]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3878 bytes --]

James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:mXzLd.100$xR1.94@bgtnsc04-news.ops.worldnet.att.net...
>
>> Well, I have the F2003 FCD open right now, in �7.4.3 Masked array
>> assignment - WHERE.  So, perhaps you can point out what part of
>> it resolves the issue I raised:
>
>>    cond1 .and. cond2 .andthen. cond3 .and. cond4
>
>> Is COND4 permitted to be evaluated or not?  I don't see that
>> WHERE tells me.  It has a concept of "pending control" which
>> I see can be applied on nested constructs, but in the above
>> expression, not of the terms actually present are part of any
>> "pending" condition.  Or, are you talking about some other
>> aspect of WHERE entirely?
>
> OK, I have added comp.lang.ada, so hopefully someone there
> can answer the question about the effect of precedence on
> your snippet, and also discuss the ergonomics of Ada short-
> circuiting logical operators, or whatever they call them.
>
> I would answer your question above, assuming cond1 .AND. cond2
> evaluate to scaler .FALSE._lk to be that it all depends; either
> cond3 or cond4 or neither or both could be 'short-circuited'.

But, that's just the problem.  The whole purpose of the separate
short-circuit operators is to eliminate ambiguities about whether
a given condition is evaluated.  That allows the programmer
to prevent evaluation of conditions if such evaluation would cause
exceptions or program termination.

Merely saying "it depends" doesn't help.  But, making a different
rule - that the new operators are lower precedence than the non-shortcut
ones, for example - does help.  That makes the example unambiguous.

The standard permits logical operators (and their operands) to be
evaluated in any order that produces a logically equivalent result.
Presumably that would be changed with respect to the shortcut
operators to require the right operand be evaluated conditionally
based on the value of the left.  In the example in question, assuming
that the operators all have the same precedence, the actual order
of evaluation might be pretty much anything.  COND1, COND2,
and COND4 might all be ecaluated before any of the operators
are done at all.  So, the expression might be as if it were rewritten
as either of (as well as others):

       cond4 .and. cond1 .and. cond2 .andthen. cond3
       cond2 .andthen. cond3 .and. cond4 .and. cond1

In fact, the only requires order (as far as I can tell) is that COND3
can't be evaluated before COND2 is found to be .true.  (If COND2
is array valued, the elements of COND3 corresponding to those
elements of COND2 that were .true. would also *may* have to be
evaluated.  I can see that in this case only an analogy to how WHERE
works is appropriate.) But this is the same result as if the shortcut
operator had lower precedence than the non-shortcut operator.

Now consider:

   cond1 .or. cond2 .andthen. cond3 .or. cond4

Even given that .andthen. has higher precedence than .or., the
rules of Fortran still suggest that COND1, COND2, and COND3
might all be evaluated before the .andthen. operator is executed.
After all, reordering the .or. operator is still permitted.  Both the
following are allowed interpretations as well as others):

   cond4 .or. cond1 .or. cond2 .andthen. cond3
   cond2 .andthen. cond3 .or. cond4 .or. cond1

Now, not only do I find this confusing, I'm sure it will hide latent
errors in the code of others.  Requiring parentheses or using a
function-call notation eliminates all ambiguities.  Making the new
operators lower precedence than everything else helps a little.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Re: Shortcut logicals (was: Re: F200x )

[James Van Buskirk]

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:i9BLd.316$xR1.179@bgtnsc04-news.ops.worldnet.att.net...

> Now, not only do I find this confusing, I'm sure it will hide latent
> errors in the code of others.  Requiring parentheses or using a
> function-call notation eliminates all ambiguities.  Making the new
> operators lower precedence than everything else helps a little.

Jeez, it took me so much time to punch all that stuff from the
standard in and you didn't even bother to read it.  Precedence
has nothing to do with the question of whether cond4 is evaluated
in your original expression.  Hint: suppose cond4 has rank 1 and
all others are scalar.  Same thing happens in WHERE except that
the question is: how do you do shape matching unless you get
far enough through an expression to determine its shape even
though the mask it will be subjected to is all false?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Re: Shortcut logicals (was: Re: F200x )

[James Giles]

James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:i9BLd.316$xR1.179@bgtnsc04-news.ops.worldnet.att.net...
>
>> Now, not only do I find this confusing, I'm sure it will hide latent
>> errors in the code of others.  Requiring parentheses or using a
>> function-call notation eliminates all ambiguities.  Making the new
>> operators lower precedence than everything else helps a little.
>
> Jeez, it took me so much time to punch all that stuff from the
> standard in and you didn't even bother to read it.  Precedence
> has nothing to do with the question of whether cond4 is evaluated
> in your original expression.  [...]

I might say the same thing.  On the other hand, you did explicitly
state that even if the value of cond1.and.cond2 were .false. the
answer still "depends".  That seemed like an ambiguous response
to me.

> [...]                            Hint: suppose cond4 has rank 1 and
> all others are scalar.  [...]

Hint: suppose they're *all* scalars.  I still don't see the subtle
point you're making.  If it requires me to assume that any of the
operands are not scalar befor the answer is apparent, I'll need
more than a hint.

But it does seem to me that a paragraph beginning "If an array
constructor appears ..." it's not immediately obvious how that
applies to an example with no arrays at all.  Similarly, it's difficult
to figure how other things you quote apply when the conditional
expression in my example may not even involve WHERE.

> [...]            Same thing happens in WHERE except that
> the question is: how do you do shape matching unless you get
> far enough through an expression to determine its shape even
> though the mask it will be subjected to is all false?

Well, if all the operands are scalar, the shape is pretty obvious.
The question isn't shape (or even value).  The question is whether
the program crashes or continues running.  Explain again how
the disection of WHERE allows me to decide whether the original
example may be legally rearranged (asuming scalar X):

   x/=0.0 .and. cond2 .andthen. cond3 .and. 5.0/x>10.0

?=>

   5.0/x>10.0 .and. x/=0.0 .and. cond2 .andthen. cond3
or
   cond2 .andthen. cond3 .and. 5.0/x>10.0 .and. x/=0.0
etc.

One of the reasons it took me a while to respond is that I *did*
read what you wrote (and couldn't find the subtle relevance you
assert) - I've just reread it again.  My puzzlement still remains.
It does seem to me that the case where all operands are scalar
ought to be simpler than more exotic possibilities.  And a simple
IF (or even a scalar logical assignment statement) ought to be
simpler to discuss that a WHERE construct.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Re: Shortcut logicals (was: Re: F200x )

[James Van Buskirk]

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:ZaCLd.474$xR1.216@bgtnsc04-news.ops.worldnet.att.net...

>    x/=0.0 .and. cond2 .andthen. cond3 .and. 5.0/x>10.0

> ?=>

>    5.0/x>10.0 .and. x/=0.0 .and. cond2 .andthen. cond3

>    cond2 .andthen. cond3 .and. 5.0/x>10.0 .and. x/=0.0

Obviously the first short-circuits the DIVCHK and the last two
don't.

> One of the reasons it took me a while to respond is that I *did*
> read what you wrote (and couldn't find the subtle relevance you
> assert) - I've just reread it again.  My puzzlement still remains.
> It does seem to me that the case where all operands are scalar
> ought to be simpler than more exotic possibilities.  And a simple
> IF (or even a scalar logical assignment statement) ought to be
> simpler to discuss that a WHERE construct.

Obviously you don't get it.  How do you know what array gets
passed to sub:

module mymod
   implicit none
   contains
      subroutine sub(x)
         logical, intent(in) :: x(:)

         write(*,*) size(x)
      end subroutine sub

      function f(n)
         integer, intent(in) :: n
         logical f(n)
         integer i

         f = mod(mod((17+(/(i,i=1,n)/))**2,97),2) == 0
      end function f
end module mymod

program test
   use mymod
   implicit none
   integer n
   real x

   write(*,'(a)',advance='no') 'Enter the size of the array:> '
   read(*,*) n
   write(*,'(a)',advance='no') 'Enter a number:> '
   read(*,*) x

   call sub(x/=0 .AND_THEN. n > 0 .AND. f(n))
end program test

So pick apart the first typo you find and tell me you still
don't get it... [sigh].

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Re: Shortcut logicals (was: Re: F200x )

[James Giles]

James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:ZaCLd.474$xR1.216@bgtnsc04-news.ops.worldnet.att.net...
>
>>    x/=0.0 .and. cond2 .andthen. cond3 .and. 5.0/x>10.0
>
>> ?=>
>
>>    5.0/x>10.0 .and. x/=0.0 .and. cond2 .andthen. cond3
>
>>    cond2 .andthen. cond3 .and. 5.0/x>10.0 .and. x/=0.0
>
> Obviously the first short-circuits the DIVCHK and the last two
> don't.

But, *all* are allowed rearrangements of the first!  That's the
existing Fortran rule.  Notice I *did* assume that rearrangement
of the .andthen. operation could *not* be rearranged, but the above
still remain permitted implementation dependent rearrangements
with respect to .and.

> Obviously you don't get it.  How do you know what array gets
> passed to sub:

You're right, I don't get it.  You still insist on answering the
question with an irrelevant excursion into arrayhood.  Until
I see the answer for scalars, I'm not sure I even want to ask
about arrays.

>    call sub(x/=0 .AND_THEN. n > 0 .AND. f(n))

I think that even after *my* question is answered, your's still
is not.  If the implementation of .andthen. required parenthesis,
that would answer my question.  Notice that ends the relevance of
Ada to this thread, since we've already been told that Ada does
require parentheses.  With the required parentheses rule, the above
would not be syntactiaclly allowed and you would have to write:

   call sub(x/=0 .AND_THEN. (n > 0 .AND. f(n) ) )

But the issue you are concerned with would still exist.  I suppose
*this* issue address might really be solved with reference to WHERE.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Re: Shortcut logicals

[Martin Dowie]

Robert A Duff wrote:
> Sorry, I've no idea what the Fortran rules are.
> 
> In Ada, the above expression is syntactically illegal -- compile time
> error.  You can write:
> 
>     (cond1 and cond2) and then (cond3 and cond4)
> 
> or:
> 
>     ((cond1 and cond2) and then cond3) and cond4)
> 
> for example.
> 
> "and" is just a function call.  If you say "X and Y" then X and Y are
> both evaluated (in either order) and passed to the "and" function.  The
> predefined version of "and" returns True if both are True.  But "and
> then" is a short-circuit control form: if you say "X and then Y", X is
> evaluated first, and if it's True, you're done.  Otherwise (X is False)
> Y is evaluated.

Bob,

For clarity, I think you got the last bits a little wrong... If X is 
"True" then Y is evaluated otherwise (X is "False"), Y is not evaluated.

What you said would be right if it was an "or else" short-circuit form.

Cheers

-- Martin

Re: Shortcut logicals (was: Re: F200x )

[Martin Krischik]

Robert A Duff wrote:

> And the syntax rules forbid mixing "and" and "and then" -- you have to
> use parens.ￜￜAllￜofￜtheseￜ("and",ￜ"andￜthen",ￜ"or",ￜ"orￜelse",ￜ"xor")
> are lower precedence than most other operators in Ada.ￜￜSoￜyouￜcan
> write:

Are you sure? I did not find anything in the RM to support that. I checked
both the RM and AARM:

http://www.adaic.com/standards/95lrm/html/RM-4-5-1.html
http://www.adaic.com/standards/95aarm/html/AA-4-5-1.html

(To the Fortran comunity: the the first is the general public version, the
later the compiler vendor version).

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Shortcut logicals

[Robert A Duff]

Martin Dowie <martin.dowie@btopenworld.com> writes:

> Bob,
> 
> For clarity, I think you got the last bits a little wrong... If X is
> "True" then Y is evaluated otherwise (X is "False"), Y is not evaluated.
> 
> What you said would be right if it was an "or else" short-circuit form.

Oops.  Thanks for catching that bug.

- Bob

Re: Shortcut logicals

[Jan Vorbrüggen]

> In maths, folks usually presume that "and" has higher
> precedence than "or".  I'm pretty happy with the Ada rule, though.  In
> general, I don't think programming languages should use precedence and
> associativity rules beyond the ones folks know by age 9.  Many people
> disagree with that, though -- they think "extra" parens cause too much
> clutter, and make the code hard to read.

I'm with you all the way. Anything to make the text clear by itself,
without reliance on external information (in this case, operator precedence
rules). It also forces the programmer to think about what he is writing,
and not go by the seats of his pants, as it were.

	Jan