forums.silverfrost.com

[davidb]

I have uncovered a bug with logical comparisons of character variables in arrays.

Fortran's logical comparison == (or .eq.) should work for arrays (and array sections) on an element by element basis. For character variables this should be done on the same basis as for scalars, i.e. the character variable with the smallest length should first be padded with trailing blanks so both character variables have the same length.

However, this doesn't seem to work for arrays of character variables where the elements have a trimmed length of 1 (i.e. only one non-blank character in the first position).

In the following code, test 1 passes, but test 2 fails in two different ways.

I get the following output. Strangely the last array printed only has one element (Maybe there's a second bug with print logical array, but I have not looked hard at this).


TEST 1

Should print T F (AND DOES!)
T F

TEST 2

Should print T F (BUT DOESN'T!)
F F
Should print T F (BUT DOESN'T)
F

Hopefully, the code below is small enough to allow this to be debugged.

[PaulLaidler]

My initial thought is that character variables and character arrays are different types objects so I would not attempt the test for equality. I have not looked at the Standard to see if it has anything to say about this.

The compiler does not appear to handle this kind of code very well - error messages are missing or have little or no meaning, results are produced when I would expect a compilation error.

I could check this out but I am wondering why you would want to do this kind of test for equality.

[davidb]

Hi Paul

The standard says that the comparison should be done element by element, and where one operand is a scalar it should be broadcast to an array of the same shape and size first. This is the basic rule for integer, real variables. For character there is the additional rule of appending sufficient blanks to make the characters being compared the same size.

There is no error in the code I posted, so you should not get a compiler error. I didn't when I tried it. Moreover, you will see that Test 1 clearly works and meets the standard, while Test 2 does not. It is simply the case that the compiler does not correctly append blanks (spaces) to the array elements before doing the comparison.

Typically, you might use this functionality with the intrinsic function any. E.g. to check if an item is in a list you could write the following.

[PaulLaidler]

Can you give me the reference to the paragraph in Fortran 95 Standard and I will check it out.

[davidb]

I only have a draft of the standard here. This is what it says in three relevant sections. The first section is about conformable arrays, the second section refers to the need for intrinsic operations (+, *, /, == etc) to work with arrays as well as scalars, whilst the third is all about how to check characters for equality.

The bold text is my emphasis, just so you can see the main bits of interest.

ISO/IEC 1539-1 (Part 1) - the base language

2.4.5 Array

Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any intrinsic operation defined for scalar objects may be applied to conformable objects. Such operations are performed element-by-element to produce a resultant array conformable with the array operands. Element-by-element operation means corresponding elements of the operand arrays are involved in a "scalar-like" operation to produce the corresponding element in the result
array, and all such element operations may be performed in any order or simultaneously. Such an operation is described as elemental

7.2 Interpretation of intrinsic operations.

"The intrinsic operations are those defined in 7.1.2. These operations are divided into the following categories: numeric, character, relational, and logical. The interpretations defined in the following sections apply to both scalars and arrays; the interpretation for arrays is obtained by applying the interpretation for scalars element by element."

7.2.3. Relational intrinsic operations

"For a character relational intrinsic operation, the operands are compared one character at a time in order, beginning with the first character of each character operand. If the operands are of unequal length, the shorter operand is treated as if it were extended on the right with blanks to the length of the longer operand. If both x1 and x2 are of zero length, x1 is equal to x2; if every character of x1 is the same as the character in the corresponding position in x2, x1 is equal to x2. Otherwise, at the first position where the character operands differ, the character operand x1 is considered to be less than x2 if the character value of x1 at this position precedes the value of x2 in the collating
sequence (4.3.2.1.1); x1 is greater than x2 if the character value of x1 at this position follows the value of x2 in the collating sequence."

Regards
David.

PS. If you have Metcalf, Reid and Cohen's "Explained" book you might look at the example of comparing arrays in Section 3.10, p. 46 in my edition.

[PaulLaidler]

Forgive me but I am still missing the point. If for simplicity I work with integers then the following code

[PaulLaidler]

Correction L needs a dimension L(4).
Maybe I am getting somewhere.

[PaulLaidler]

Finally! Yes there is a bug in the compiler and I will aim to get it fixed.

[davidb]

Excellent! Glad the penny's dropped.

Your integer case works, giving T T T T in the first case, and F T F F in the second (T is .true., F is .false.). So the principle is clear. But there are issues with characters.

I did try to convert your integer case to character verbatim, but I got an internal compiler error. This is different behaviour from what I saw in my Test 2 above (which compiled and gave the wrong result). So maybe the same bug manifests itself in different ways

I narrowed the code down to the following (by deleting things).

This compiles in DEBUG mode but not using CHECKMATE.

[davidb]

Paul, did this get fixed?

I am still getting incorrect behaviour with v6.2.

I can provide a simple example of a code which demonstrates the issue if needed.

David.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

[PaulLaidler]

We have had a go at this bug but it turns out to be a very tricky one to fix.

Hence it remains unfixed but not forgotten.

[PaulLaidler]

I have now fixed this bug for the next release.

[davidb]

Thank you.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl