Prev: Best Jewellery Online Shopping
Next: How you can save fuel and the environment
From: ralf.schaa on 8 Jan 2010 21:36
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
From: Richard Maine on 8 Jan 2010 23:28
ralf.schaa <ralf.schaa(a)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
From: Harald Anlauf on 9 Jan 2010 03:33
On Jan 9, 3:36 am, "ralf.schaa" <ralf.sc...(a)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
From: Harald Anlauf on 9 Jan 2010 03:43
On Jan 9, 3:36 am, "ralf.schaa" <ralf.sc...(a)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
From: Richard Maine on 9 Jan 2010 04:37
Harald Anlauf <anlauf.2008(a)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
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Best Jewellery Online Shopping
Next: How you can save fuel and the environment