Prev: Best Jewellery Online Shopping
Next: How you can save fuel and the environment
From: glen herrmannsfeldt on 9 Jan 2010 16:06
steve <kargls(a)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
From: robin on 9 Jan 2010 17:45
"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:hi9p0c$hkt$1(a)naig.caltech.edu...
| 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.

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.




From: Paul van Delst on 11 Jan 2010 10:53
Harald Anlauf wrote:
> On Jan 9, 6:07 pm, Stormin <norman.kir...(a)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
From: Richard Maine on 11 Jan 2010 11:21
Paul van Delst <paul.vandelst(a)noaa.gov> wrote:

> Harald Anlauf wrote:
> > On Jan 9, 6:07 pm, Stormin <norman.kir...(a)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
From: Paul van Delst on 11 Jan 2010 13:15
Richard Maine wrote:
> Paul van Delst <paul.vandelst(a)noaa.gov> wrote:
>
>> Harald Anlauf wrote:
>>> On Jan 9, 6:07 pm, Stormin <norman.kir...(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Best Jewellery Online Shopping
Next: How you can save fuel and the environment