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 > userwritten 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 Helbigundress 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 floatingpoint 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)netb.de>, Tobias Burnus <burnus(a)netb.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 offtopic 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 errorcatching > mechanism for elemental procedures  the only thing that seems to work > is to provide an error resultvalue, so that the error has to be > handled in the callingprogram, 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 