Fortran - Acceptable Pack args

Author

Acceptable Pack args

David Frank

2005-08-24, 7:56 am

Because the discussion how PACK operates in Reduce_Blanks shows no sign of
ending due to the continued blather of 2 posters there, I submit following
proof that its NOT the mask arg array sizes that drives the PACK,
its the array being packed.

My assertion is:
as long as "b,c" arrays are at least the size of "a" there wont be a
bounds fault in CVF,
does this assertion hold for your compiler?

! ------------
program test
character :: a(5)
character,allocatable :: b(:), c(:)

allocate (b(20), c(1000) )
a = 'a' ; b = ' ' ; b = ' '

write (*,*) pack(a, b==' '.or.c==' ') ! outputs aaaaa
end program

Joost

2005-08-24, 7:56 am

NAG f95 gives the following two run time messages, which are correct :

Rank 1 of C has extent 1000 instead of 20
Program terminated by fatal error
Abort (core dumped)

Shape mismatch: Dimension 1 extents are 5 and 20
Program terminated by fatal error
Abort (core dumped)

Cheers,

Joost

David Frank

2005-08-24, 7:56 am

"Joost" <jv244@cam.ac.uk> wrote in message
news:1124880931.358434.223010@g14g2000cwa.googlegroups.com...
> NAG f95 gives the following two run time messages, which are correct :
>
> Rank 1 of C has extent 1000 instead of 20
> Program terminated by fatal error
> Abort (core dumped)
>
> Shape mismatch: Dimension 1 extents are 5 and 20
> Program terminated by fatal error
> Abort (core dumped)
>
> Cheers,
>
> Joost
>

OK, thanks, then I accept that this code is not portable, but your
runtime messages are NOT actual memory access faults, just NAG compiler
intercepting and refusing to allow the perfectly safe code to execute,
yes/no?

Rich Townsend

2005-08-24, 6:59 pm

David Frank wrote:
> Because the discussion how PACK operates in Reduce_Blanks shows no sign of
> ending due to the continued blather of 2 posters there, I submit following
> proof that its NOT the mask arg array sizes that drives the PACK,
> its the array being packed.
>
> My assertion is:
> as long as "b,c" arrays are at least the size of "a" there wont be a
> bounds fault in CVF,
> does this assertion hold for your compiler?
>
> ! ------------
> program test
> character :: a(5)
> character,allocatable :: b(:), c(:)
>
> allocate (b(20), c(1000) )
> a = 'a' ; b = ' ' ; b = ' '
>
> write (*,*) pack(a, b==' '.or.c==' ') ! outputs aaaaa
> end program

c is not defined anywhere in the program, and the code is therefore
non-standard. Assuming that you meant to write

a = 'a' ; b = ' ' ; c = ' '

....then the code is *STILL* non-standard. As already pointed out in the
error message pointed out by Joost, the problem is that the b and c
arrays are not conformable. The .OR. operator requires that its
operators be conformable -- either a scalar an array, or two arrays of
exactly the same shape.

PACK has nothing to do with this problem. The problem persists if the
PACK() call is removed completely, so that the write statement reads:

write (*,*) b==' '.or.c==' '

It appears that your confusion with pack stems from your lack of
understanding of the PACK() intrinsic. The logical expression used for
the MASK argument is evaluated in its entirety *before* it is passed to
PACK. It is not evaluated on a per-element basis within PACK.

cheers,

Rich

David Frank

2005-08-24, 6:59 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:dehtsr$6kg$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> c is not defined anywhere in the program, and the code is therefore
> non-standard. Assuming that you meant to write
>
> a = 'a' ; b = ' ' ; c = ' '
>
> ...then the code is *STILL* non-standard. As already pointed out in the
> error message pointed out by Joost, the problem is that the b and c arrays
> are not conformable. The .OR. operator requires that its operators be
> conformable -- either a scalar an array, or two arrays of exactly the same
> shape.
>
> PACK has nothing to do with this problem. The problem persists if the
> PACK() call is removed completely, so that the write statement reads:
>
> write (*,*) b==' '.or.c==' '
>

I agree you have a problem with code above, but thats not related to PACK.

> It appears that your confusion with pack stems from your lack of
> understanding of the PACK() intrinsic. The logical expression used for the
> MASK argument is evaluated in its entirety *before* it is passed to PACK.
> It is not evaluated on a per-element basis within PACK.
>

As best as I can determine from looking at the assy code, it is evaluated on
a per-element basis within PACK,

e.g. PACK( a, mask)

What I think I see is:
char a(i) is fetched and the corresponding mask is evaluated (trivial in
this case its just mask(i) ) and chr is either packed or discarded
depending on the mask evaluation and the loop continues..

and similiarly for PACK (a, b==' ')

Does my code run on your computer?

Rich Townsend

2005-08-24, 6:59 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:dehtsr$6kg$1@scrotar.nss.udel.edu...
>
>
>
> I agree you have a problem with code above, but thats not related to PACK.
>
>
>
>
> As best as I can determine from looking at the assy code, it is evaluated on
> a per-element basis within PACK,
>
> e.g. PACK( a, mask)
>
> What I think I see is:
> char a(i) is fetched and the corresponding mask is evaluated (trivial in
> this case its just mask(i) ) and chr is either packed or discarded
> depending on the mask evaluation and the loop continues..
>
> and similiarly for PACK (a, b==' ')
>
> Does my code run on your computer?
>

No, it crashes due to the shape mismatch between b and c.

Your interpretation of PACK is contrary to the standard. While a
compiler may operate as you describe for optimization reasons, the end
result must be the same as if the MASK argument was evaluated in toto,
and only then passed to PACK as a one dimensional logical array.

Unfortunately, since b and c are not conformable, the expression used to
define mask is broken. What size do you think the logical array should
have? SIZE(b) or SIZE(c)?

cheers,

Rich

David Frank

2005-08-24, 6:59 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:dei08p$79v$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> No, it crashes due to the shape mismatch between b and c.
>

Crashes a-la NAG refuses to run the valid code, or crashes a-la
array-bound exceeded fault?

> Your interpretation of PACK is contrary to the standard. While a compiler
> may operate as you describe for optimization reasons, the end result must
> be the same as if the MASK argument was evaluated in toto, and only then
> passed to PACK as a one dimensional logical array.
>
> Unfortunately, since b and c are not conformable, the expression used to
> define mask is broken. What size do you think the logical array should
> have? SIZE(b) or SIZE(c)?
>

SIZE(a) as a minimum

Rich Townsend

2005-08-24, 6:59 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:dei08p$79v$1@scrotar.nss.udel.edu...
>
>
>
> Crashes a-la NAG refuses to run the valid code, or crashes a-la
> array-bound exceeded fault?

The exact error message (Lahey lf95 Express, 6.20c for Linux) is:

Two entities must be in shape conformance (b,c).
Error occurs at or near line 8 of MAIN__

>
>
>
>
> SIZE(a) as a minimum

So you don't think that b and c should be conformable, as required by
the Fortran 2003 standard? Remind me, which computer language are we
talking about?

cheers,

Rich

David Frank

2005-08-24, 6:59 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:dei8s9$9m7$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> The exact error message (Lahey lf95 Express, 6.20c for Linux) is:
>
> Two entities must be in shape conformance (b,c).
> Error occurs at or near line 8 of MAIN__
>

And what does your CVF say?

> So you don't think that b and c should be conformable, as required by the
> Fortran 2003 standard? Remind me, which computer language are we talking
> about?
>

They EACH obviously have to be as long as array being packed's size, but
any excess is irrelevant

If it turns out that you are right, that its not a element-by-element pack
or discard decision, then I will investigate a FASTER PACK added to my
string functions module (perhaps as a challenge topic),
hmmm, what would be a good name APACK ?

Rich Townsend

2005-08-24, 6:59 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:dei8s9$9m7$1@scrotar.nss.udel.edu...
>
>
>
> And what does your CVF say?

I don't have CVF. That's why I have to ask other people to run code for me.

>
>
>
>
> They EACH obviously have to be as long as array being packed's size, but
> any excess is irrelevant

No, b and c must be conformable. It's in the F2003 standard; I quote:

--
7.1.5 Conformability rules for elemental operations

An elemental operation is an intrinsic operation or a defined elemental
operation. Two entities are in shape conformance if both are arrays of
the same shape, or one or both are scalars.

For all elemental binary operations, the two operands shall be in shape
conformace. In the case where one is a scalar and the other an array,
the scalar is treated as if it were an array of the same shape as the
array operand with every element, if any, of the array equal to the
value of the scalar
--

Let's apply this to the current case. Both b and c are arrays, yes? And,
from table 7.1 of the standard, we see that .OR. is an elemental binary
operator. But b and c do not have the same shape. Therefore, your code
is in violation of section 7.1.5 of the standard.

>
> If it turns out that you are right, that its not a element-by-element pack
> or discard decision, then I will investigate a FASTER PACK added to my
> string functions module (perhaps as a challenge topic),
> hmmm, what would be a good name APACK ?

I look forward to seeing how you can make such a function work with any
generic logical test.

cheers,

Rich

glen herrmannsfeldt

2005-08-24, 6:59 pm

Rich Townsend wrote:

(snip)

> It appears that your confusion with pack stems from your lack of
> understanding of the PACK() intrinsic. The logical expression used for
> the MASK argument is evaluated in its entirety *before* it is passed to
> PACK. It is not evaluated on a per-element basis within PACK.

As far as I know, this is true for all array operations in Fortran.

Unless the compiler can determine that doing it any other way will
have the same result, the entire operation must be done before any
variable is changed. Though the aliasing rules should also
apply here.

-- glen

Dick Hendrickson

2005-08-25, 6:59 pm

Rich Townsend wrote:
> David Frank wrote:
>
>
>
> I don't have CVF. That's why I have to ask other people to run code for me.
>
>
>
> No, b and c must be conformable. It's in the F2003 standard; I quote:
>
> --
> 7.1.5 Conformability rules for elemental operations
>
> An elemental operation is an intrinsic operation or a defined elemental
> operation. Two entities are in shape conformance if both are arrays of
> the same shape, or one or both are scalars.
>
> For all elemental binary operations, the two operands shall be in shape
> conformace. In the case where one is a scalar and the other an array,
> the scalar is treated as if it were an array of the same shape as the
> array operand with every element, if any, of the array equal to the
> value of the scalar
> --
>
> Let's apply this to the current case. Both b and c are arrays, yes? And,
> from table 7.1 of the standard, we see that .OR. is an elemental binary
> operator. But b and c do not have the same shape. Therefore, your code
> is in violation of section 7.1.5 of the standard.
>
There is also a restriction on PACK arguments.
"MASK shall be of type logical and shall be conformable
with ARRAY"
so even if b and c had the same shape, they would also have
to have the same shape as the first argument.

The conformability rules have essentially no exceptions.
That's by desigh to allow compilers to do all of the array
operation in any order and not have to treat one of the
arrays as special.

Dick Hendrickson
>
>
> I look forward to seeing how you can make such a function work with any
> generic logical test.
>
> cheers,
>
> Rich

Rich Townsend

2005-08-25, 6:59 pm

Dick Hendrickson wrote:
>
>
> Rich Townsend wrote:
>
> There is also a restriction on PACK arguments.
> "MASK shall be of type logical and shall be conformable with ARRAY"
> so even if b and c had the same shape, they would also have
> to have the same shape as the first argument.
>
> The conformability rules have essentially no exceptions.
> That's by desigh to allow compilers to do all of the array
> operation in any order and not have to treat one of the
> arrays as special.
>

From today's deafening silence in c.l.f, I can only assume that DF has
*finally* taken these points on board. I'm glad for him, and wish him
luck in his continued journey toward being able to program in Fortran.

cheers,

Rich

David Frank

2005-08-25, 6:59 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:dekmmn$1vo$1@scrotar.nss.udel.edu...
> Dick Hendrickson wrote:
>
> From today's deafening silence in c.l.f, I can only assume that DF has
> *finally* taken these points on board. I'm glad for him, and wish him luck
> in his continued journey toward being able to program in Fortran.
>
> cheers,
>
> Rich

Well I do accept "the rules" and offer no further comment in this topic
EXCEPT to point out
NO-ONE SHOWED my "assertion" for CVF was false for the sample program
(see below excerpt from 1st message)
OR for any other compiler (there were no bounds faults)

================
My assertion is:
as long as "b,c" arrays are at least the size of "a" there wont be a
bounds fault in CVF,
does this assertion hold for your compiler?

! ------------
program test
character :: a(5)
character,allocatable :: b(:), c(:)

allocate (b(20), c(1000) )
a = 'a' ; b = ' ' ; c = ' '

write (*,*) pack(a, b==' '.or.c==' ') ! outputs aaaaa
end program

Dick Hendrickson

2005-08-25, 6:59 pm

David Frank wrote:

> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:dekmmn$1vo$1@scrotar.nss.udel.edu...
>
>
>
> Well I do accept "the rules" and offer no further comment in this topic
> EXCEPT to point out
> NO-ONE SHOWED my "assertion" for CVF was false for the sample program
> (see below excerpt from 1st message)
> OR for any other compiler (there were no bounds faults)

Bounds checking is one of the things that is not required in
Fortran. The main reason for this is execution speed. It's
believed by some that bounds checking (and other related
mere correctness checks) slow down codes unacceptably.
This belief is enhanced by the various benchmarks that
measure raw speed only.

In any event, array bounds can only generally be checked
at run time. Try turning on the command line options
for array bounds checking and whatever else CVF offers.
There's likely to be some sort of option that checks for
array mis-conformance. Most compilers eventually add
this feature.

During code developement it's a good idea to check
everything. What would have happened in your model if
you had a(20) and b(5) for the array sizes? You'd get
pure random noise for the output.

Dick Hendrickson
>
> ================
> My assertion is:
> as long as "b,c" arrays are at least the size of "a" there wont be a
> bounds fault in CVF,
> does this assertion hold for your compiler?
>
> ! ------------
> program test
> character :: a(5)
> character,allocatable :: b(:), c(:)
>
> allocate (b(20), c(1000) )
> a = 'a' ; b = ' ' ; c = ' '
>
> write (*,*) pack(a, b==' '.or.c==' ') ! outputs aaaaa
> end program
>
>
>
>
>
>

David Frank

2005-08-25, 6:59 pm

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:hwlPe.671989$cg1.127070@bgtnsc04-news.ops.worldnet.att.net...
>
>
> What would have happened in your model if
> you had a(20) and b(5) for the array sizes?

I would never provide such a case since it DISOBEYS my assertion.
[color=darkred]

glen herrmannsfeldt

2005-08-25, 6:59 pm

Dick Hendrickson wrote:
(snip)

> Bounds checking is one of the things that is not required in
> Fortran. The main reason for this is execution speed. It's
> believed by some that bounds checking (and other related
> mere correctness checks) slow down codes unacceptably.
> This belief is enhanced by the various benchmarks that
> measure raw speed only.

For array operators, which bounds does it use?

I suppose with the requirement that all operands have
the appropriate bounds the compiler is free to choose,
but it does complicate the question.

-- glen

David Frank

2005-08-25, 6:59 pm

"Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
news:p8urg1dsq5hi14rka49hjeb8k9fvlddd2e@
4ax.com...
> On Thu, 25 Aug 2005 15:17:14 GMT, "David Frank" <dave_frank@hotmail.com>
> wrote:
>
>
> CVF's lack of checking for conformance to this rule of the standard is a
> deficiency, not a feature. You lucked out that the program did what you
> wanted it to, but there is no guarantee that the compiler might not choose
> to
> take the array length from the mask instead. CVF (and Intel Fortran at
> present) does not do shape conformance checking, some other compilers, as
> noted, do. That's a plus for them. I have seen many cases where
> non-conformable shapes leads to erroneous run-time results (primarily with
> assignments.) Adding such checking is high on our list for future
> enhancements.
>
> Steve Lionel

FYI, not sure but I believe it was because my function that used PACK was
in module that CVF did not issue a conformance error. when the same function
was contained in a test program (not a module) CVF did issue a conformance
error.

Further info,
my code accompanying my "assertion" overrode CVF conformance by declaring
"B,C" array allocatable
which it appears to override compile time error for other compilers as well
but other compilers NAG, DID have runtime error checks that stopped
execution of what I contend was likely NO bounds fault code.

Rich Townsend

2005-08-25, 6:59 pm

David Frank wrote:
> "Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
> news:p8urg1dsq5hi14rka49hjeb8k9fvlddd2e@
4ax.com...
>
>
>
> FYI, not sure but I believe it was because my function that used PACK was
> in module that CVF did not issue a conformance error. when the same function
> was contained in a test program (not a module) CVF did issue a conformance
> error.
>
> Further info,
> my code accompanying my "assertion" overrode CVF conformance by declaring
> "B,C" array allocatable
> which it appears to override compile time error for other compilers as well
> but other compilers NAG, DID have runtime error checks that stopped
> execution of what I contend was likely NO bounds fault code.

As I pointed out in a previous post, most compilers do not have problems
checking for conformance of static (ie, fixed size) arrays. Whereas,
Lahey's compiler is the only one (that I've checked) which can do
conformance checking on dynamic arrays, via the --chk s command-line switch.

With the Lahey compiler run with conformance checking, your assertion is
meaningless because the code will not even compile.

By the way, you still haven't retracted your claim that CVF cannot do
bounds checking from the command line. In this particular case, bounds
checking is a bit of a red herring, since it is *conformance* checking
that is the principal issue. Nevertheless, you tried to bullshit me
that bounds checking cannot be done from the command line in CVF. Are
you willing to explain why you did this?

cheers,

RIch

David Frank

2005-08-25, 6:59 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:dekvs2$4ku$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> As I pointed out in a previous post, most compilers do not have problems
> checking for conformance of static (ie, fixed size) arrays. Whereas,
> Lahey's compiler is the only one (that I've checked) which can do
> conformance checking on dynamic arrays, via the --chk s command-line
> switch.
>
> With the Lahey compiler run with conformance checking, your assertion is
> meaningless because the code will not even compile.
>

BTW, how does it manage to check conformance at compile time, analyze the
runtime allocate statements?

> By the way, you still haven't retracted your claim that CVF cannot do
> bounds checking from the command line. In this particular case, bounds
> checking is a bit of a red herring, since it is *conformance* checking
> that is the principal issue. Nevertheless, you tried to bullshit me that
> bounds checking cannot be done from the command line in CVF. Are you
> willing to explain why you did this?
>

Ignorance, for some reason I didnt spot the option before, no conspiracy
involved.

> cheers,
>
> RIch

robin

2005-08-26, 6:59 pm

David Frank wrote in message ...
>
>"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
>news:dei8s9$9m7$1@scrotar.nss.udel.edu...
>
[color=darkred]
>They EACH obviously have to be as long as array being packed's size, but
>any excess is irrelevant

Nonsense.

>If it turns out that you are right, that its not a element-by-element pack >or
discard decision, then I will investigate a FASTER PACK added to my
>string functions module (perhaps as a challenge topic),
>hmmm, what would be a good name APACK ?

Something descriptive like DONT_USE_FF_PACK

[JvO]

2005-08-26, 6:59 pm

! ------------
program test
implicit NONE
character, dimension(5) :: a
character, allocatable ,dimension(:) :: b, c

allocate (b(20), c(1000) )
a = "a"
b = " "
c = " "

write (UNIT=*,FMT=*) "|", pack(a, b == " " .or. c == " "), "|" !
outputs aaaaa
! Non-conformant arrays FTN95
end program test

This program crashes with FTN95, but runs as DF (wrongly) expected with
Absoft V7.5

[JvO]

Sponsored Links