Print

---

Thorsten Ohl wrote:

>        ...
>        call one_over (y_array, x_array, err_array)
>        if (any (err_array)) then
>           print *, "one_over: invalid argument: x = 0"
>           stop
>        end if
>        ...
> 

Bill Long <[log in to unmask]> writes:

> A far simpler, and more efficient, version of the above would be:
> 
> 	   if (any(x_array == 0.)) then
> 	      print *, "one_over: invalid argument: x = 0"
> 	      stop
> 	   else
> 	      call one_over(y_array,x_array)
> 	   end if
> 
> In this version, the one_over routine would have not need any tests.

OK, I was expecting this :-).  In his example, any(x_array==0.0) is
simple enough, but I'm thinking of more complex applications

	   if (any (verify_args_for_complex_procedure (x_array))) then
	      print *, "complex_procedure: invalid argument"
	      stop
	   else
	      call complex_procedure (y_array, x_array)
	   end if


where verify_args_for_complex_procedure() would need to do most of the
computations of complex_procedure() before it can make a decision.  In
this case it's both a performonce hit and a maintenance nightmare.

John Blair-Fish <[log in to unmask]> writes:

> My understanding was that PURE procedures could be run in
> parallel. If they were going to do I/O there would be all the
> potential problems of several instances of a procedure trying to do
> I/O to the same file or device.

Thorsten Ohl wrote:

> That's an (unfortunately very relevant) implementation issue, that,
> in the ebst of all worlds, would not compromise language design.

Bill Long <[log in to unmask]> writes:

> On this last point I completely disagree.  John Blair-Fish is right.
> A central issue in language design is the avoidance of ambiguity.

Agreed.  Maybe I misunderstood John's point: I thought that he was
referring to the non-reentrancy of many legacy implementations of the
Fortran I/O subsystem.

> I assume an elemental procedure would be called with array arguments. In
> that case, the order in which the various calls is executed is
> completely random.  If the procedure does output, the order of the
> output operations would be random, leading to completely different
> output files from different runs.  It is a basic function of language
> design to avoid this sort of disaster.

But this is not necessarily a disaster.  If the array under
consideration is an array of complex objects, I can give unique names
to each instant.  Then I can prefix every message with this unique
name and the output remains useful (sort(1) and grep(1) are assumed to
be available :-).

The obvious case are error conditions, but there are more examples:
consider a adaptive integration routine which is split in parallel
channels.  If I want to include the option to monitor the evolution of
the grids, I can nolonger use ELEMENTAL, PURE and FORALL to express
parallelism.

I'm not arguing that arbitrary I/O should be allowed and I'm sharing
all your concerns.  I'm just arguing that some output can be very
useful, even if it arrives in random order.

But returning to me second question: how _are_ you debugging your PURE
and ELEMENTAL procedures?

Cheers,
-Thorsten

-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- [log in to unmask]
http://crunch.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%