Prev: Best Jewellery Online Shopping
Next: How you can save fuel and the environment
From: glen herrmannsfeldt on 9 Jan 2010 06:23
Richard Maine <nospam(a)see.signature> wrote:
> 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.

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
From: Phillip Helbig---undress to reply on 9 Jan 2010 06:29
In article <1jc0ost.12ddglz1u00vjiN%nospam(a)see.signature>,
nospam(a)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.

From: Tobias Burnus on 9 Jan 2010 07:13
Richard Maine <nospam(a)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
From: Ron Shepard on 9 Jan 2010 11:43
In article <4B4872FC.2060706(a)net-b.de>,
Tobias Burnus <burnus(a)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
From: Stormin on 9 Jan 2010 12:07
On Jan 9, 2: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?
>
> 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=0
contains
elemental function calc_my_sqrt(x)
real ::x
if(x.lt. 0.0)then
error =1
else
blah
endif
end function calc_my_sqrt
function report_my_sqrt_error
report_my_sqrt_error = error
end function
end module

program
use my_sqrt
implicit none
real :: y
....
y = 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Best Jewellery Online Shopping
Next: How you can save fuel and the environment