COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

### Elemental procedures and Error catching

• Follow

```I am struggling with implementation of a suitable error-catching
mechanism for elemental procedures - the only thing that seems to work
is to provide an error result-value, so that the error has to be
handled in the calling-program, which is not always convenient. Are
there other ways? What do you use?

Cheers
-Ralf
```
 0
Reply ralf.schaa (62) 1/9/2010 2:36:40 AM

```ralf.schaa <ralf.schaa@gmail.com> wrote:

> I am struggling with implementation of a suitable error-catching
> mechanism for elemental procedures - the only thing that seems to work
> is to provide an error result-value, so that the error has to be
> handled in the calling-program, which is not always convenient. Are
> there other ways? What do you use?

I pretty much don't use elemental procedures for anything that isn't
almost trivial. That's a big reason. It has to be simple enough that
errors aren't at issue.

--
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain
```
 0
Reply nospam 1/9/2010 4:28:54 AM

```On Jan 9, 3:36=A0am, "ralf.schaa" <ralf.sc...@gmail.com> wrote:
> I am struggling with implementation of a suitable error-catching
> mechanism for elemental procedures - the only thing that seems to work
> is to provide an error result-value, so that the error has to be
> handled in the calling-program, which is not always convenient. Are
> there other ways? What do you use?

That exactly the same as I use.

I guess that the constraints on elemental procedures are formulated as
to make the code efficient on a vector machine, and the conditions for
vectorization appear to be a superset of these.

I actually don't understand Richard's last remark.  Even a simple
elemental function like "sqrt(x)" somehow needs to deal with errors,
e.g. x<0.
Here the error result value is encoded in the function result as an
NaN.

Harald
```
 0
Reply Harald 1/9/2010 8:33:13 AM

```On Jan 9, 3:36=A0am, "ralf.schaa" <ralf.sc...@gmail.com> wrote:
> I am struggling with implementation of a suitable error-catching
> mechanism for elemental procedures - the only thing that seems to work
> is to provide an error result-value, so that the error has to be
> handled in the calling-program, which is not always convenient. Are
> there other ways? What do you use?

That's exactly the same as I use.

I guess that the constraints on elemental procedures are formulated as
to make the code efficient on a vector machine, and the conditions for
vectorization appear to be a superset of these.

I actually don't understand Richard's last remark.  Even a simple
elemental function like "sqrt(x)" somehow needs to deal with errors,
e.g. x<0.
Here the error result value is encoded in the function result as an
NaN.

Harald
```
 0
Reply Harald 1/9/2010 8:43:20 AM

```Harald Anlauf <anlauf.2008@arcor.de> wrote:

> I actually don't understand Richard's last remark.  Even a simple
> elemental function like "sqrt(x)" somehow needs to deal with errors,
> e.g. x<0.
> Here the error result value is encoded in the function result as an
> NaN.

Not according to the standard. The standard just says that it is illegal
to call sqrt with a negative argument. It does *NOT* say that you will
get a NaN result, or any other particular result. That falls in the
class of error that allows the compiler to do anything.

I forget whether the IEEE standard specifies anything about sqrt of
negative values. If it does, and if IEEE_SUPPORT_SQRT returns true for
some kind, then arguably that might be required for that kind, although
I don't see such an exception mentioned in the definition of the sqrt
intrinsic in chapter 13, so I'd probably argue instead that it was an
inconsistency in the standard (if the mentioned conditions hold.)

Yes, when I said pretty trivial, I really meant it. I meant things that
require no error handling at all. If I wanted to handle errors in a
user-written version of sqrt, I wouldn't do it elementally.

Returning special values as error codes has all kinds of problems. I
have seen very real bugs from software that returned special error
values... and then forgot to handle them. Once you add handling of them,
it gets messy enough (and often inefficient enough) that you might as
well not have made the procedure elemental, in which case you might as
well not have encoded the error as a value. No, I don't do that. I used
to, long ago, but I stopped that practice. Been there, done that,
regretted it, not going back.

--
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain
```
 0
Reply nospam 1/9/2010 9:37:57 AM

```Richard Maine <nospam@see.signature> wrote:
> Harald Anlauf <anlauf.2008@arcor.de> wrote:

>> I actually don't understand Richard's last remark.  Even a simple
>> elemental function like "sqrt(x)" somehow needs to deal with errors,
>> e.g. x<0.
>> Here the error result value is encoded in the function result as an
>> NaN.

> Not according to the standard. The standard just says that it is illegal
> to call sqrt with a negative argument. It does *NOT* say that you will
> get a NaN result, or any other particular result. That falls in the
> class of error that allows the compiler to do anything.

Fortran 66 compilers I remember printed out a nice message
and the stopped.  A quick tests shows gfortran gives NaN.

> I forget whether the IEEE standard specifies anything about sqrt of
> negative values. If it does, and if IEEE_SUPPORT_SQRT returns true for
> some kind, then arguably that might be required for that kind, although
> I don't see such an exception mentioned in the definition of the sqrt
> intrinsic in chapter 13, so I'd probably argue instead that it was an
> inconsistency in the standard (if the mentioned conditions hold.)

I forget, too.  The wikipedia NaN page suggests that NaN should
be returned for sqrt of negative values, but doesn't mention IEEE.
The wikipedia IEEE_754 page makes it seem like a recommendation,
not a requirement, but doesn't explicitly mention sqrt.

> Yes, when I said pretty trivial, I really meant it. I meant things that
> require no error handling at all. If I wanted to handle errors in a
> user-written version of sqrt, I wouldn't do it elementally.

It seems to me that the complaint is that intrinsic elemental
functions are allowed to do things that user written ones
are not.  Especially print error messages.

-- glen
```
 0
Reply glen 1/9/2010 11:23:56 AM

```In article <1jc0ost.12ddglz1u00vjiN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> I pretty much don't use elemental procedures for anything that isn't
> almost trivial. That's a big reason. It has to be simple enough that
> errors aren't at issue.

Doesn't the restriction come from the fact that elemental procedures
must be pure, meaning they can't do I/O?  In other words, the only
possibility is to code the error in the result and deal with it in the
caller, which is not always the cleanest thing to do.

```
 0
Reply helbig 1/9/2010 11:29:15 AM

```Richard Maine <nospam@see.signature> wrote:
>> Returning special values as error codes has all kinds of problems. I
>> have seen very real bugs from software that returned special error
>> values... and then forgot to handle them.

I think returning NaN (sometimes also INF or -INF) are quite save values
for special error values - numbers such as "42" are less so. Ignoring
for the moment the problem whether NaN/INF/-INF are available. (NaN also
comes in two flavors: Signalling and quiet, which is finally anticipated
in IEEE Std. 754:2008.)

>> I forget whether the IEEE standard specifies anything about sqrt of
>> negative values. If it does, and if IEEE_SUPPORT_SQRT returns true for
>> some kind, then arguably that might be required for that kind, although
>> I don't see such an exception mentioned in the definition of the sqrt
>> intrinsic in chapter 13, so I'd probably argue instead that it was an
>> inconsistency in the standard (if the mentioned conditions hold.)

IEEE Std. 754:2008 has:

"The operation squareRoot(x) computes √x [= sqrt(x)]. It has a positive
sign for all operands >= 0, except that squareRoot(−0) shall be −0.The
preferred exponent is floor(Q(x) / 2)."

(And squareRoot(+Inf) = +Inf.)

And later in "7.2 Invalid operation":

"For operations producing results in floating-point format, the default
result of an operation that signals the invalid operation exception
shall be a quiet NaN that should provide some diagnostic information
(see 6.2). These operations are: [...]
g) squareRoot if the operand is less than zero"

Tobias
```
 0
Reply Tobias 1/9/2010 12:13:48 PM

```In article <4B4872FC.2060706@net-b.de>,
Tobias Burnus <burnus@net-b.de> wrote:

> IEEE Std. 754:2008 has:
>
> "The operation squareRoot(x) computes √x [= sqrt(x)]. It has a positive
> sign for all operands >= 0, except that squareRoot(-0) shall be -0.The
> preferred exponent is floor(Q(x) / 2)."

At the risk of following an off-topic tangent, what exactly does
that last sentence mean.  Are there IEEE floating point numbers that
can be represented with more than one exponent?

\$.02 -Ron Shepard
```
 0
Reply Ron 1/9/2010 4:43:04 PM

```On Jan 9, 2:36=A0am, "ralf.schaa" <ralf.sc...@gmail.com> wrote:
> I am struggling with implementation of a suitable error-catching
> mechanism for elemental procedures - the only thing that seems to work
> is to provide an error result-value, so that the error has to be
> handled in the calling-program, which is not always convenient. Are
> there other ways? What do you use?
>
> Cheers
> -Ralf

can the elemental procedure appear inside a module which handles
errors at the level of the module?

The following is not working fortran but gives my idea

module my_sqrt
implicit none
integer, private :: error=3D0
contains
elemental function calc_my_sqrt(x)
real ::x
if(x.lt. 0.0)then
error =3D1
else
blah
endif
end function calc_my_sqrt
function report_my_sqrt_error
report_my_sqrt_error =3D error
end function
end module

program
use my_sqrt
implicit none
real :: y
....
y =3D calc_my_sqrt(z)
if(report_my_sqrt_error.ne.0) then
print...
endif
end

A function in the module can report the exact nature of the error.
Does this rather long winded approach violate the concept of an
elemental procedure?

In parallel code I guess that one of several calls could have raised
the error before we get to detect that one of the calls has caused an
error?

Sorry Ralf this is not an answer - but would add to my understanding!

Norman
```
 0
Reply Stormin 1/9/2010 5:07:55 PM

```Stormin <norman.kirkby@gmail.com> wrote:

> can the elemental procedure appear inside a module which handles
> errors at the level of the module?

No.

> The following is not working fortran but gives my idea
[code elided]

That trivially violates on of the most fundamental properties of a pure
(and thus elemental) procedure. Pure procedures cannot have side
effects. Ok, the definition of "side effect" can be tricky (I have heard
people suggest that consuming CPU time is a side effect), but I'm just
using that as a broad general description here. The standard is a lot
more specific and precise about this one, which is one of the most
straightforward cases. In particular, you can't change the value of a
variable accessed via host association (or ay other way of getting at
"outside" variables, but host association is the one used here and one
that is specifically prohibitted in the standard).

My general description of prohibitting side effects is to give you a
conceptual context to keep from wasting time looking for other ways to
achieve a simillar effect. If you manage to find one, that would
probably be a bug in the standard; prohibition of such things is the
idea.

Like most of the requirements on pure procedures, this one is a
constraint, which means that compilers are required to be able to
diagnose it.

--
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain
```
 0
Reply nospam 1/9/2010 5:37:45 PM

```On Jan 9, 6:07=A0pm, Stormin <norman.kir...@gmail.com> wrote:
> A function in the module can report the exact nature of the error.
> Does this rather long winded approach violate the concept of an
> elemental procedure?

Yes, this is illegal, as Richard pointed out.  If you want a separate
error status, you must use a subroutine.

Here is a working example:

module my_sqrt
implicit none
contains
elemental subroutine calc_my_sqrt (x, y, stat)
real, intent(in)     :: x
real, intent(out)    :: y
integer, intent(out) :: stat
if(x.lt. 0.0)then
stat =3D 1
y =3D -HUGE (x)
else
stat =3D 0
y =3D sqrt (x)
endif
end subroutine calc_my_sqrt
end module my_sqrt

program test
use my_sqrt
implicit none
integer, parameter    :: N =3D 5
real,    dimension(N) :: y, z
integer, dimension(N) :: status
integer :: errloc

call random_number (z)
call calc_my_sqrt (x=3Dz, y=3Dy, stat=3Dstatus)
if (any (status /=3D 0)) then
errloc =3D maxloc (status, dim=3D1)
print *, "Error: the following argument was illegal:", z(errloc)
endif
print *, y
end program test

You may modify one element of the argument z to see how error handling
works.

Harald
```
 0
Reply Harald 1/9/2010 5:52:36 PM

```Since the OP's question was rather general in scope, I'd like to
comment that the below is not true if you take derived types into
consideration.

By adding an extra component which indicates the validity of an
entity to a type definition

type :: foo
: ! whatever data I need
integer :: status = 0
end type

(plus a set of constants describing the needed kinds of stati) it
is clearly possible to write elemental subroutines or even functions
which use entities of type(foo) as arguments or function results,
without introducing side effects.
Clearly, separate checking for each array element (if the actual
argument is an array entity) is still required - something along the
lines of

if (any(obj_foo%status /= status_ok)) then
! perform error treatment
end if

Regards,

Reinhold

Am 09.01.2010 18:52, schrieb Harald Anlauf:
> On Jan 9, 6:07 pm, Stormin <norman.kir...@gmail.com> wrote:
>> A function in the module can report the exact nature of the error.
>> Does this rather long winded approach violate the concept of an
>> elemental procedure?
>
> Yes, this is illegal, as Richard pointed out.  If you want a separate
> error status, you must use a subroutine.
>
> Here is a working example:
>
> module my_sqrt
>   implicit none
> contains
>   elemental subroutine calc_my_sqrt (x, y, stat)
>     real, intent(in)     :: x
>     real, intent(out)    :: y
>     integer, intent(out) :: stat
>     if(x.lt. 0.0)then
>        stat = 1
>        y = -HUGE (x)
>     else
>        stat = 0
>        y = sqrt (x)
>     endif
>   end subroutine calc_my_sqrt
> end module my_sqrt
>
> program test
>   use my_sqrt
>   implicit none
>   integer, parameter    :: N = 5
>   real,    dimension(N) :: y, z
>   integer, dimension(N) :: status
>   integer :: errloc
>
>   call random_number (z)
>   call calc_my_sqrt (x=z, y=y, stat=status)
>   if (any (status /= 0)) then
>      errloc = maxloc (status, dim=1)
>      print *, "Error: the following argument was illegal:", z(errloc)
>   endif
>   print *, y
> end program test
>
>
> You may modify one element of the argument z to see how error handling
> works.
>
> Harald

```
 0
Reply Reinhold 1/9/2010 7:03:21 PM

```Ron Shepard <ron-shepard@nospam.comcast.net> wrote:
> In article <4B4872FC.2060706@net-b.de>,
> Tobias Burnus <burnus@net-b.de> wrote:

>> IEEE Std. 754:2008 has:
>
>> "The operation squareRoot(x) computes ???x [= sqrt(x)]. It has a positive
>> sign for all operands >= 0, except that squareRoot(-0) shall be -0.The
>> preferred exponent is floor(Q(x) / 2)."

> At the risk of following an off-topic tangent, what exactly does
> that last sentence mean.  Are there IEEE floating point numbers that
> can be represented with more than one exponent?

My understanding is that it relates to rounding.  Since the exponent
changes at integer values, it seems that means that
sqrt(3.99999999) should not be, for example, 2.00000001 and
sqrt(4.00000001) should not be, for example, 1.99999999

-- glen
```
 0
Reply glen 1/9/2010 7:56:35 PM

```On Jan 9, 11:56=C2=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Ron Shepard <ron-shep...@nospam.comcast.net> wrote:
> > In article <4B4872FC.2060...@net-b.de>,
> > Tobias Burnus <bur...@net-b.de> wrote:
> >> IEEE Std. 754:2008 has:
>
> >> "The operation squareRoot(x) computes ???x [=3D sqrt(x)]. It has a pos=
itive
> >> sign for all operands >=3D 0, except that squareRoot(-0) shall be -0.T=
he
> >> preferred exponent is floor(Q(x) / 2)."
> > At the risk of following an off-topic tangent, what exactly does
> > that last sentence mean. =C2=A0Are there IEEE floating point numbers th=
at
> > can be represented with more than one exponent?
>
> My understanding is that it relates to rounding. =C2=A0Since the exponent
> changes at integer values, it seems that means that
> sqrt(3.99999999) should not be, for example, 2.00000001 and
> sqrt(4.00000001) should not be, for example, 1.99999999

Not likely for sqrt() with base 2 floating point.  I only have the
final committee draft of the new IEEE 754 standard.  It states

The squareRoot operation is defined and has a positive sign for
all operands greater or equal to 0, except that squareRoot(=E2=80=930)
shall be =E2=80=930.  For inexact decimal results, the preferred expone=
nt
is the least possible.  For exact decimal results, the preferred
exponent is floor(Q(x) / 2).

If Tobias quoted the ratified standard, then the language has changed.
For base 2 floating point, sqrt() can be correctly rounded in all
rounding modes.  The draft further states

For certain computational operations, if the result is inexact,
the cohort member of least possible exponent is used to get the
longest possible significand; if the result is exact, the cohort
member is selected based on the preferred exponent for a result
of that operation, a function of the exponents of the inputs.

For other computational operations, whether or not the result is
exact, the cohort member is selected based on the preferred
exponent
for a result of that operation. Thus for finite x, depending on
the
representation of zero, 0 + x might result in a different member
of x=E2=80=99s cohort.

If the result=E2=80=99s cohort does not include a member with the
preferred
exponent, the member with the exponent closest to the preferred
exponent is used.

In the descriptions that follow, Q(x) is the exponent q of the
representation of a finite floating-point number x.  If x is
infinite,
Q(x) is +=E2=88=9E.

Without digging deeper, I suspect that this prevents unnormal numbers.

--
steve
```
 0
Reply steve 1/9/2010 8:37:53 PM

```steve <kargls@comcast.net> wrote:
(snip on preferred exponents)

> Without digging deeper, I suspect that this prevents unnormal numbers.

I thought about that, but didn't write it.  The usual IEEE binary
formats don't have unnormal (not to be confused with denormal) numbers.
I believe the Intel x87 temporary real does not have a hidden one
and so could allow for unnormalized values.  I don't remember how
that fits in with the standard, though.

For decimal, which can't have a hidden one, you could have unnormalized
values.  So, maybe that is that they mean.  Wouldn't it be easier
to just say that the results should be normalized?

-- glen
```
 0
Reply glen 1/9/2010 9:06:18 PM

```"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:hi9p0c\$hkt\$1@naig.caltech.edu...
| Richard Maine <nospam@see.signature> wrote:
| > Harald Anlauf <anlauf.2008@arcor.de> wrote:
|
| >> I actually don't understand Richard's last remark.  Even a simple
| >> elemental function like "sqrt(x)" somehow needs to deal with errors,
| >> e.g. x<0.
| >> Here the error result value is encoded in the function result as an
| >> NaN.
|
| > Not according to the standard. The standard just says that it is illegal
| > to call sqrt with a negative argument. It does *NOT* say that you will
| > get a NaN result, or any other particular result. That falls in the
| > class of error that allows the compiler to do anything.
|
| Fortran 66 compilers I remember printed out a nice message
| and the stopped.  A quick tests shows gfortran gives NaN.

And back then PL/I compiled code did the same by default.
But in PL/I you could also have (still can) an error handler -- either
within the procedure or external to it, and which enabled
continuation, if required.
Furthermore, you can also have an output statement in the procedure,
which can print some nice message -- for any kind of error, not just for SQRT.

```
 0
Reply robin 1/9/2010 10:45:56 PM

```Harald Anlauf wrote:
> On Jan 9, 6:07 pm, Stormin <norman.kir...@gmail.com> wrote:
>> A function in the module can report the exact nature of the error.
>> Does this rather long winded approach violate the concept of an
>> elemental procedure?
>
> Yes, this is illegal, as Richard pointed out.  If you want a separate
> error status, you must use a subroutine.

Must? Why?

But to get to the main point of this reply....

> Here is a working example:
>
> module my_sqrt
>   implicit none
> contains
>   elemental subroutine calc_my_sqrt (x, y, stat)
>     real, intent(in)     :: x
>     real, intent(out)    :: y
>     integer, intent(out) :: stat
>     if(x.lt. 0.0)then
>        stat = 1
>        y = -HUGE (x)
>     else
>        stat = 0
>        y = sqrt (x)
>     endif
>   end subroutine calc_my_sqrt
> end module my_sqrt
>
> program test
>   use my_sqrt
>   implicit none
>   integer, parameter    :: N = 5
>   real,    dimension(N) :: y, z
>   integer, dimension(N) :: status
>   integer :: errloc
>
>   call random_number (z)
>   call calc_my_sqrt (x=z, y=y, stat=status)
>   if (any (status /= 0)) then
>      errloc = maxloc (status, dim=1)
>      print *, "Error: the following argument was illegal:", z(errloc)
>   endif
>   print *, y
> end program test

What if the test program has the following declarations:

real,    dimension(N) :: y, z
integer :: status

A scalar status variable is still conformable with the DIMENSION(N) x and y arguments in
the elemental call. In the case of one element of x being invalid, but the others being
o.k., can a scalar status argument reliably indicate that? I don't see how.

cheers,

paulv
```
 0
Reply Paul 1/11/2010 3:53:18 PM

```Paul van Delst <paul.vandelst@noaa.gov> wrote:

> Harald Anlauf wrote:
> > On Jan 9, 6:07 pm, Stormin <norman.kir...@gmail.com> wrote:
> >> A function in the module can report the exact nature of the error.
> >> Does this rather long winded approach violate the concept of an
> >> elemental procedure?
> >
> > Yes, this is illegal, as Richard pointed out.  If you want a separate
> > error status, you must use a subroutine.
>
> Must? Why?

Because a pure function is not allowed to pass data out via arguments.
The *ONLY* output from a pure function is the function result.

> What if the test program has the following declarations:
>
>   real,    dimension(N) :: y, z
>   integer :: status
>
> A scalar status variable is still conformable with the DIMENSION(N) x and
> y arguments in the elemental call. In the case of one element of x being
> invalid, but the others being o.k., can a scalar status argument reliably
> indicate that? I don't see how.

It can't. That's sort of the whole point of 12.7.3 of f2003. You can't
have a scalar output argument in an elemental call unless all the
arguments are scalar. Input arguments are fine; output ones are not.

This is all related to why I said that once you add error handling, the
elementalness doesn't buy you much. You are going to have to get an
array of status values. Then if you want to actually do anything, you
are likely to need a loop construct anyway, unless all you do is
something along the line of

if (any(status/=0)) ....

and don't bother to do anything that ties to the specific elements with
problems.

--
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain
```
 0
Reply nospam 1/11/2010 4:21:17 PM

```Richard Maine wrote:
> Paul van Delst <paul.vandelst@noaa.gov> wrote:
>
>> Harald Anlauf wrote:
>>> On Jan 9, 6:07 pm, Stormin <norman.kir...@gmail.com> wrote:
>>>> A function in the module can report the exact nature of the error.
>>>> Does this rather long winded approach violate the concept of an
>>>> elemental procedure?
>>> Yes, this is illegal, as Richard pointed out.  If you want a separate
>>> error status, you must use a subroutine.
>> Must? Why?
>
> Because a pure function is not allowed to pass data out via arguments.
> The *ONLY* output from a pure function is the function result.

Considering I spent a good deal of last November writing elemental functions in modules,
all I can say is "d'oh!". I even recall changing procedures from functions to subroutines
for exactly that reason.

I'm beginning to suspect the lead in the water pipes having something to do with
increasing frequency of brainfade as I age..... :o/

>> What if the test program has the following declarations:
>>
>>   real,    dimension(N) :: y, z
>>   integer :: status
>>
>> A scalar status variable is still conformable with the DIMENSION(N) x and
>> y arguments in the elemental call. In the case of one element of x being
>> invalid, but the others being o.k., can a scalar status argument reliably
>> indicate that? I don't see how.
>
> It can't. That's sort of the whole point of 12.7.3 of f2003. You can't
> have a scalar output argument in an elemental call unless all the
> arguments are scalar. Input arguments are fine; output ones are not.

That makes perfect sense.... and it's also something I've never tested for. I'll be adding
to the unit tests of the abovementioned modules. Although I guess that will really only be
testing for compiler adherence to the standard since a user can still call it incorrectly.
Still....

> This is all related to why I said that once you add error handling, the
> elementalness doesn't buy you much. You are going to have to get an
> array of status values. Then if you want to actually do anything, you
> are likely to need a loop construct anyway, unless all you do is
> something along the line of
>
>   if (any(status/=0)) ....
>
> and don't bother to do anything that ties to the specific elements with
> problems.

Yep. No argument there.

cheers,

paulv
```
 0
Reply Paul 1/11/2010 6:15:11 PM

```glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> It seems to me that the complaint is that intrinsic elemental
> functions are allowed to do things that user written ones
> are not.  Especially print error messages.

There is a long history of intrinsic procedures being able to do things
that user procedures couldn't. Some of these things have later turned
into capabilities of user procedures. Others haven't.

Of the top of my head

1. Generic procedures started as intrinsic only.

2. Likewise for elemental.

3. Likewise for use in specification expressions.

I'd say that a current one of significance is the way that the return
kind of an intrinsic can depend on the value of an argument (the kind
argument). Still can't do that with user code.

--
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain
```
 0
Reply nospam 1/11/2010 6:39:58 PM

```"ralf.schaa" <ralf.schaa@gmail.com> wrote in message

>I am struggling with implementation of a suitable error-catching
> mechanism for elemental procedures - the only thing that seems to work
> is to provide an error result-value, so that the error has to be
> handled in the calling-program, which is not always convenient. Are
> there other ways? What do you use?

Cheat.  C binding should let you do it:

module elem_err
implicit none
integer, parameter :: dp = selected_real_kind(15,300)
contains
elemental function my_sqrt(x)
real(dp), intent(in) :: x
real(dp) my_sqrt
interface
pure subroutine sub1(x) bind(C,name='sub2')
use ISO_C_BINDING, only: C_DOUBLE
implicit none
real(C_DOUBLE), intent(in) :: x
end subroutine sub1
end interface
procedure(sub1), pointer :: sub4
if(x < 0) then
sub4 => sub1
call sub4(x)
my_sqrt = 0
else
my_sqrt = sqrt(x)
end if
end function my_sqrt
subroutine sub3(x) bind(C,name='sub2')
use ISO_C_BINDING, only: C_DOUBLE
real(C_DOUBLE), intent(in) :: x
write(*,*) 'Argument out of bounds for my_sqrt:',x
stop
end subroutine sub3
end module elem_err

program test
use elem_err
implicit none
real(dp) x, y

x = -0.707
y = my_sqrt(x)
write(*,*) 'my_sqrt(',x,') =',y
end program test

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

```
 0
Reply James 1/13/2010 1:43:05 AM

21 Replies
136 Views

(page loaded in 0.252 seconds)