Dear friends,

I have some problem in selecting specified columns from a character
array.
The story is as follows...

Below are the file names, the data in which I want to merge into a
single file.
07-Jul-2001-23-59-59.txt
08-Jul-2001-23-59-59.txt
09-Jul-2001-23-59-59.txt
19-Aug-2001-23-59-59.txt
20-Aug-2001-23-59-59.txt

In order to name the output file... I thought to select the dates of
first & last files.
I wrote like this...!!

outfname=fname(1,1:7) // fname(num,1:6)

fname(1,1:7) - first row & 1 to 7 columns
fname(num,1:6) - last row & 1 to 6 columns

What I get is:

outfname=fname(1,1:7)//fname(num,1:6)
               1             2
Error: Shapes for operands at (1) and (2) are not conformable

Can any one help to resolve this problem.

Thanks a lot in advance.

Best regards
Praveen.

Fortran_follower wrote:
> Dear friends,
> 
> I have some problem in selecting specified columns from a character
> array.
> The story is as follows...
> 
> outfname=fname(1,1:7)//fname(num,1:6)
>                1             2
> Error: Shapes for operands at (1) and (2) are not conformable
> 
> Can any one help to resolve this problem.

I didn't read too carefully (for the start, you didn't give
us the declaration of fname), but you probably want:

outfname=fname(1)(1:7)//fname(num)(1:6)

This is -- as far as I can tell offhan -- the only situation
where Fortran syntax requires two consecutive brackets.

--
Jugoslav
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Fortran_follower <ezeepraveen4u@gmail.com> wrote:

> I have some problem in selecting specified columns from a character
> array.
....
> outfname=fname(1,1:7) // fname(num,1:6)

As Jugoslav mentions, you didn't show the declarations. They matter. A
lot. That means all I can do is fairly wild speculation. For future
urposes, be aware that declarations usually matter a lot. A large
fraction of the problems people report here turn out to be related to
the declarations... and a large fraction of the questions unfortunately
fail to include the needed declarations.

For my speculation, I willl guess that perhaps you actually mean exactly
what you say when you use the term "character array" - that is, your
fname is a 2-D array of single characters. More common for something
like this in Fortran would be to have a 1-D array of character strings.

If indeed you have a 2-D array of characters, then fname(1,1:7) and
fname(num,1:6) are both array slices. They are *NOT* character strings.
Concatenation is not an array operation; it is for strings. What the
aboev syntax indicates would be an elemental operation on the two array
slices, but the slices are different sizes, which isn't allowed for
elemental operations. That's what the error message sounds like and it
is consistent with your description. But an elemental operation isn't at
all what you want.

If you really want to keep your data as a character array, then you need
an array operation. You could do it with an array constructor as

  outfname = [fname(1,1:7), fname(num,1:6)]

(where I'm using the f2003 [] for array constructors as I think it much
nicer than the older form).

But I fairly strongly advise against doing Fortran character stuff as
arrays instead of strings. It is possible, and there are cases where it
is a good idea, but for ordinary uses I would avoid it. It certainly
will confuse you if you aren't pretty fluent in such things because most
of the Fortran character manipulation features don't work with character
arrays (which is exactly what you ran into).

Alternatively, if you do have 1-D arrays of character strings, then you
would need the syntax Jugoslav showed. I would have expected a different
error message from the compiler in that case, but my expectations could
be wrong.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Dear Richard Maine,

Thank you for your detailed reply to my query.
Please have a look at my declaration below:
      character,allocatable,dimension(:,:) :: fname
      character*100 :: outfile,infile,outfname
      character*150 :: infpath,outfpath,line
      integer       :: num,i,j,col
c
      col=50
      i=1
      j=1
c
      write(*,*)'Enter no.of files to merge'
      read(*,*)num
      allocate(fname(num,col))
c

>   outfname = [fname(1,1:7), fname(num,1:6)]

For the solution you have mentioned, I am getting the following error.
 outfname = [fname(1,1:7), fname(num,1:6)]
      1
Error: Incompatible ranks 0 and 1 in assignment at (1)

Can you please let me know...whether the problem is with the
declaration or with something else...!!

Thanking you.

Praveen.

Dear Richard Maine,

Thank you for your detailed reply to my query.
Please have a look at my declaration below:
      character,allocatable,dimension(:,:) :: fname
      character*100 :: outfile,infile,outfname
      character*150 :: infpath,outfpath,line
      integer       :: num,i,j,col
c
      col=50
      i=1
      j=1
c
      write(*,*)'Enter no.of files to merge'
      read(*,*)num
      allocate(fname(num,col))
c

>   outfname = [fname(1,1:7), fname(num,1:6)]

For the solution you have mentioned, I am getting the following error.
 outfname = [fname(1,1:7), fname(num,1:6)]
      1
Error: Incompatible ranks 0 and 1 in assignment at (1)

Can you please let me know...whether the problem is with the
declaration or with something else...!!

Thanking you.

Praveen.

Fortran_follower <ezeepraveen4u@gmail.com> wrote:

> Please have a look at my declaration below:
>       character,allocatable,dimension(:,:) :: fname
>       character*100 :: outfile,infile,outfname
>       character*150 :: infpath,outfpath,line
>       integer       :: num,i,j,col
> c
>       col=50
>       i=1
>       j=1
> c
>       write(*,*)'Enter no.of files to merge'
>       read(*,*)num
>       allocate(fname(num,col))
> c
> 
> >   outfname = [fname(1,1:7), fname(num,1:6)]
> 
> For the solution you have mentioned, I am getting the following error.
>  outfname = [fname(1,1:7), fname(num,1:6)]
>       1
> Error: Incompatible ranks 0 and 1 in assignment at (1)
> 
> Can you please let me know...whether the problem is with the
> declaration or with something else...!!

Ah, Ok. Mostly in the declaration, though a bit of both.

Yes, you do have a 2-D array of characters. One could make that work,
but it would just cause a continuing series of complications. The
"incompatible rank" error is because the right-hand-side of that
assignment is now a valid expression, but it gives a 1-D character
array, which you can't assign to a character string. One could change
the declaration of outfname to be a character array, but that will just
cause more problems later.

To make your fname be a 1-D array of character strings, declare it
something more like

  character*50, allocatable, dimension(:) :: name

(I tried to stay with the general declaration style you used; variations
of stylistic detail are possible.) You can't make the character length
allocatable until full f2003 compilers are out (and that seems to be one
of the later fetaures to be done in partial implementations), but it
doesn't look to me like you really need the length to be allocatable;
I'm guessing that was just forced on you by using the 2-D array and
wanting the other rank allocatable.

Then you'll have to change your allocate statement to correspond to
fname, which is now a 1-D array, which the allocate needs to reflect.

  allocate(fname(num))

Then use the syntax shown in Jugoslav's post - namely

  outfname = fname(1)(1:7) // fname(num)(1:6)

In brief explanation of that syntax, the (1) and (num) are the array
index values, while the 1:7 and 1:6 are substring designations. Although
substrings look a lot like array slices, they aren't the same thing.
When you have both a substring and array index of the same variable, the
two go into separate sets of parens like this.

I'm also assuming that whatever you did to define values for fname will
be appropriate for a 1-D array of strings. Odds are that it already is
and that it in fact would not have worked correctly for the 2-D array
you declared. (Just because it might have compiled doesn't mean it would
have worked).

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

"Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
news:3a33e589-6416-49cc-9279-4227ede8ec3e@y12g2000yqh.googlegroups.com...

> For the solution you have mentioned, I am getting the following error.
> outfname = [fname(1,1:7), fname(num,1:6)]
>      1
> Error: Incompatible ranks 0 and 1 in assignment at (1)

outfname = transfer([fname(1,1:7), fname(num,1:6)],repeat('x',7+6))

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

"Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
news:dd63bcc5-aa09-411d-a44c-ff4815e2e10b@v25g2000yqk.googlegroups.com...
> Dear Richard Maine,
>
> Thank you for your detailed reply to my query.
> Please have a look at my declaration below:
>      character,allocatable,dimension(:,:) :: fname
>      character*100 :: outfile,infile,outfname
>      character*150 :: infpath,outfpath,line
>      integer       :: num,i,j,col
> c
>      col=50
>      i=1
>      j=1
> c
>      write(*,*)'Enter no.of files to merge'
>      read(*,*)num
>      allocate(fname(num,col))
> c
>
>>   outfname = [fname(1,1:7), fname(num,1:6)]
>
> For the solution you have mentioned, I am getting the following error.
> outfname = [fname(1,1:7), fname(num,1:6)]
>      1
> Error: Incompatible ranks 0 and 1 in assignment at (1)
>
> Can you please let me know...whether the problem is with the
> declaration or with something else...!!
>
> Thanking you.
>
> Praveen.

outfname is a character variable (string). fname(1,1:7) is an array slice. 
It is NOT a string of characters.

outfname='ABCDEFG' is not the same as outfname = 
['A','B','C','D','E','F','G']

--- e
e-mail: epc8 at juno dot com

On 2010-01-25 22:34:59 -0400, "e p chandler" <epc8@juno.com> said:

> 
> "Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
> news:dd63bcc5-aa09-411d-a44c-ff4815e2e10b@v25g2000yqk.googlegroups.com...
Dear 
> 
>> Richard Maine,
>> 
>> Thank you for your detailed reply to my query.
>> Please have a look at my declaration below:
>>      character,allocatable,dimension(:,:) :: fname
>>      character*100 :: outfile,infile,outfname
>>      character*150 :: infpath,outfpath,line
>>      integer       :: num,i,j,col
>> c
>>      col=50
>>      i=1
>>      j=1
>> c
>>      write(*,*)'Enter no.of files to merge'
>>      read(*,*)num
>>      allocate(fname(num,col))
>> c
>> 
>>>   outfname = [fname(1,1:7), fname(num,1:6)]
>> 
>> For the solution you have mentioned, I am getting the following error.
>> outfname = [fname(1,1:7), fname(num,1:6)]
>>      1
>> Error: Incompatible ranks 0 and 1 in assignment at (1)
>> 
>> Can you please let me know...whether the problem is with the
>> declaration or with something else...!!
>> 
>> Thanking you.
>> 
>> Praveen.
> 
> outfname is a character variable (string). fname(1,1:7) is an array 
> slice. It is NOT a string of characters.
> 
> outfname='ABCDEFG' is not the same as outfname = ['A','B','C','D','E','F','G']

Is there a nice idiom for doing the conversion? On the few occasions I have had
to do this I ended up with a loop assigninng single characters. There 
are special
rules on the use of character arrays as formats in i/o that do the 
conversion for
you. Either that is a slick feature for that case or an indication of a missing
ability elsewhere.

Nice does not include the use of transfer or changing all the commas above to
concatenate symbols. (I tend to rate transfer as "too clever for words" and to
be avoided.)

> --- e
> e-mail: epc8 at juno dot com

"Gordon Sande" <g.sande@worldnet.att.net> wrote in message 
news:2010012609284916807-gsande@worldnetattnet...
> On 2010-01-25 22:34:59 -0400, "e p chandler" <epc8@juno.com> said:
>
>>
>> "Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
>> news:dd63bcc5-aa09-411d-a44c-ff4815e2e10b@v25g2000yqk.googlegroups.com...
> Dear
>>
>>> Richard Maine,
>>>
>>> Thank you for your detailed reply to my query.
>>> Please have a look at my declaration below:
>>>      character,allocatable,dimension(:,:) :: fname
>>>      character*100 :: outfile,infile,outfname
>>>      character*150 :: infpath,outfpath,line
>>>      integer       :: num,i,j,col
>>> c
>>>      col=50
>>>      i=1
>>>      j=1
>>> c
>>>      write(*,*)'Enter no.of files to merge'
>>>      read(*,*)num
>>>      allocate(fname(num,col))
>>> c
>>>
>>>>   outfname = [fname(1,1:7), fname(num,1:6)]
>>>
>>> For the solution you have mentioned, I am getting the following error.
>>> outfname = [fname(1,1:7), fname(num,1:6)]
>>>      1
>>> Error: Incompatible ranks 0 and 1 in assignment at (1)
>>>
>>> Can you please let me know...whether the problem is with the
>>> declaration or with something else...!!
>>>
>>> Thanking you.
>>>
>>> Praveen.
>>
>> outfname is a character variable (string). fname(1,1:7) is an array 
>> slice. It is NOT a string of characters.
>>
>> outfname='ABCDEFG' is not the same as outfname = 
>> ['A','B','C','D','E','F','G']
>
> Is there a nice idiom for doing the conversion?

Not AFAIK. It would be "nice" from the point of view of letting the OP do 
what he thinks he wants to do to have strings be the same as 1-D character 
vectors, as they are in APL, or have an APL like catenate function. But then 
what does catenate mean for a numeric array?

A <- 1 2 3 4 5
I <- ,A
I
   12345

?????

> On the few occasions I have had
> to do this I ended up with a loop assigninng single characters. There are 
> special
> rules on the use of character arrays as formats in i/o that do the 
> conversion for
> you. Either that is a slick feature for that case or an indication of a 
> missing
> ability elsewhere.

Yes. But that is deceptive. It's an artifact of the output being serialized. 
So printing A$ is the same as printing B[1:7].

> Nice does not include the use of transfer or changing all the commas above 
> to
> concatenate symbols. (I tend to rate transfer as "too clever for words" 
> and to
> be avoided.)

Well JVB does write some "nice" write only code with it. [smile]

BUT, I think we are missing the point here, aside from giving the OP a 
better conceptual understading of Fortran. [smile]. Why use a 2-D character 
array when an array of strings will do? Why use an array of strings when 
simple strings will do? IMO new programmers tend to want to keep everything 
in memory. For example, I remember a program posted in this newsgroup which 
solved a system of differential equations. It used one dimension of the 
array for the iteration number. It could have used just two arrays, one for 
the system's current state and one for the system's new state. Then copy 
new_state to old_state as an array operation.

--- e

Gordon Sande wrote:
> On 2010-01-25 22:34:59 -0400, "e p chandler" <epc8@juno.com> said:
> 
>>
>> "Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
>> news:dd63bcc5-aa09-411d-a44c-ff4815e2e10b@v25g2000yqk.googlegroups.com...
> Dear
>>
>>> Richard Maine,
>>>
>>> Thank you for your detailed reply to my query.
>>> Please have a look at my declaration below:
>>>      character,allocatable,dimension(:,:) :: fname
>>>      character*100 :: outfile,infile,outfname
>>>      character*150 :: infpath,outfpath,line
>>>      integer       :: num,i,j,col
>>> c
>>>      col=50
>>>      i=1
>>>      j=1
>>> c
>>>      write(*,*)'Enter no.of files to merge'
>>>      read(*,*)num
>>>      allocate(fname(num,col))
>>> c
>>>
>>>>   outfname = [fname(1,1:7), fname(num,1:6)]
>>>
>>> For the solution you have mentioned, I am getting the following error.
>>> outfname = [fname(1,1:7), fname(num,1:6)]
>>>      1
>>> Error: Incompatible ranks 0 and 1 in assignment at (1)
>>>
>>> Can you please let me know...whether the problem is with the
>>> declaration or with something else...!!
>>>
>>> Thanking you.
>>>
>>> Praveen.
>>
>> outfname is a character variable (string). fname(1,1:7) is an array 
>> slice. It is NOT a string of characters.
>>
>> outfname='ABCDEFG' is not the same as outfname = 
>> ['A','B','C','D','E','F','G']
> 
> Is there a nice idiom for doing the conversion? On the few occasions I 
> have had
> to do this I ended up with a loop assigninng single characters. There 
> are special
> rules on the use of character arrays as formats in i/o that do the 
> conversion for
> you. Either that is a slick feature for that case or an indication of a 
> missing
> ability elsewhere.

If the variables are static, then EQUIVALENCE is a reasonable
solution.  Declare and array and a string and equivalence them.

Dick Hendrickson
> 
> Nice does not include the use of transfer or changing all the commas 
> above to
> concatenate symbols. (I tend to rate transfer as "too clever for words" 
> and to
> be avoided.)
> 
>> --- e
>> e-mail: epc8 at juno dot com
> 
> 

"Gordon Sande" <g.sande@worldnet.att.net> wrote in message 
news:2010012609284916807-gsande@worldnetattnet...

> Nice does not include the use of transfer

Sigh.

C:\gfortran\clf\conv_char>type conv_char.f90
module convert
   implicit none
   interface conv_char
      module procedure string2array
      module procedure array2string
   end interface conv_char
   contains
      pure function string2array(string)
         character(*), intent(in) :: string
         character string2array(len(string))

         string2array = s2a(string,len(string))
      end function string2array
      pure function s2a(array,n)
         integer, intent(in) :: n
         character, intent(in) :: array(n)
         character s2a(n)

         s2a = array
      end function s2a
      pure function array2string(array)
         character, intent(in) :: array(:)
         character(size(array)) :: array2string

         array2string = a2s(array,size(array))
      end function array2string
      pure function a2s(string,n)
         integer, intent(in) :: n
         character(n), intent(in) :: string(1)
         character(n) a2s

         a2s = string(1)
      end function a2s
end module convert

program test
   use convert
   implicit none

   write(*,'(a,i0)') 'LEN(''ABCDEFG'') = ', LEN('ABCDEFG')
   write(*,'(a,i0)') 'LEN(conv_char(''ABCDEFG'')) = ', &
      LEN(conv_char('ABCDEFG'))
   write(*,'(a,i0)') 'SIZE(conv_char(''ABCDEFG'')) = ', &
      SIZE(conv_char('ABCDEFG'))
   write(*,'(a)') 'conv_char(''ABCDEGF'') = ', conv_char('ABCDEFG')

   write(*,'()')
   write(*,'(a,i0)') 'LEN([''A'',''B'',''C'',''D'',''E'',''F'',''G'']) = ', 
&
      LEN(['A','B','C','D','E','F','G'])
   write(*,'(a,i0)') 'SIZE([''A'',''B'',''C'',''D'',''E'',''F'',''G'']) = ', 
&
      SIZE(['A','B','C','D','E','F','G'])
   write(*,'(a,i0)') 'LEN(conv_char( &
      &[''A'',''B'',''C'',''D'',''E'',''F'',''G''])) = ', &
      LEN(conv_char(['A','B','C','D','E','F','G']))
   write(*,'(a)') 'conv_char( &
      &[''A'',''B'',''C'',''D'',''E'',''F'',''G'']) = ', &
      conv_char(['A','B','C','D','E','F','G'])
end program test

C:\gfortran\clf\conv_char>gfortran -std=f2003 conv_char.f90 -oconv_char

C:\gfortran\clf\conv_char>conv_char
LEN('ABCDEFG') = 7
LEN(conv_char('ABCDEFG')) = 1
SIZE(conv_char('ABCDEFG')) = 7
conv_char('ABCDEGF') =
A
B
C
D
E
F
G

LEN(['A','B','C','D','E','F','G']) = 1
SIZE(['A','B','C','D','E','F','G']) = 7
LEN(conv_char( ['A','B','C','D','E','F','G'])) = 7
conv_char( ['A','B','C','D','E','F','G']) =
ABCDEFG

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

On 2010-01-26 11:32:52 -0400, "e p chandler" <epc8@juno.com> said:

> 
> "Gordon Sande" <g.sande@worldnet.att.net> wrote in message 
> news:2010012609284916807-gsande@worldnetattnet...
>> On 2010-01-25 22:34:59 -0400, "e p chandler" <epc8@juno.com> said:
>> 
>>> 
>>> "Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
>>> news:dd63bcc5-aa09-411d-a44c-ff4815e2e10b@v25g2000yqk.googlegroups.com...
Dear

Richard 
>>> 
>>>> Maine,
>>>> 
>>>> Thank you for your detailed reply to my query.
>>>> Please have a look at my declaration below:
>>>>      character,allocatable,dimension(:,:) :: fname
>>>>      character*100 :: outfile,infile,outfname
>>>>      character*150 :: infpath,outfpath,line
>>>>      integer       :: num,i,j,col
>>>> c
>>>>      col=50
>>>>      i=1
>>>>      j=1
>>>> c
>>>>      write(*,*)'Enter no.of files to merge'
>>>>      read(*,*)num
>>>>      allocate(fname(num,col))
>>>> c
>>>> 
>>>>>   outfname = [fname(1,1:7), fname(num,1:6)]
>>>> 
>>>> For the solution you have mentioned, I am getting the following error.
>>>> outfname = [fname(1,1:7), fname(num,1:6)]
>>>>      1
>>>> Error: Incompatible ranks 0 and 1 in assignment at (1)
>>>> 
>>>> Can you please let me know...whether the problem is with the
>>>> declaration or with something else...!!
>>>> 
>>>> Thanking you.
>>>> 
>>>> Praveen.
>>> 
>>> outfname is a character variable (string). fname(1,1:7) is an array 
>>> slice. It is NOT a string of characters.
>>> 
>>> outfname='ABCDEFG' is not the same as outfname = ['A','B','C','D','E','F','G']
>> 
>> Is there a nice idiom for doing the conversion?
> 
> Not AFAIK. It would be "nice" from the point of view of letting the OP 
> do what he thinks he wants to do to have strings be the same as 1-D 
> character vectors, as they are in APL, or have an APL like catenate 
> function. But then what does catenate mean for a numeric array?
> 
> A <- 1 2 3 4 5
> I <- ,A
> I
>    12345
> 
> ?????
> 
>> On the few occasions I have had
>> to do this I ended up with a loop assigninng single characters. There 
>> are special
>> rules on the use of character arrays as formats in i/o that do the 
>> conversion for
>> you. Either that is a slick feature for that case or an indication of a missing
>> ability elsewhere.
> 
> Yes. But that is deceptive. It's an artifact of the output being 
> serialized. So printing A$ is the same as printing B[1:7].

Read the fine print on run time formats. An array of characters will be 
concatenated
to construct the format. Rather special case that has nothing to do with the
actual output the format produces. I would guess it is a legacy 
requirement from
something F77 did.

>> Nice does not include the use of transfer or changing all the commas above to
>> concatenate symbols. (I tend to rate transfer as "too clever for words" and to
>> be avoided.)
> 
> Well JVB does write some "nice" write only code with it. [smile]

And I thought it was compiler testing code! ;-)


> 

On 2010-01-26 11:53:37 -0400, Dick Hendrickson <dick.hendrickson@att.net> said:

> Gordon Sande wrote:
>> On 2010-01-25 22:34:59 -0400, "e p chandler" <epc8@juno.com> said:
>> 
>>> 
>>> "Fortran_follower" <ezeepraveen4u@gmail.com> wrote in message 
>>> news:dd63bcc5-aa09-411d-a44c-ff4815e2e10b@v25g2000yqk.googlegroups.com...
Dear

Richard 
>>> 
>>>> Maine,
>>>> 
>>>> Thank you for your detailed reply to my query.
>>>> Please have a look at my declaration below:
>>>>      character,allocatable,dimension(:,:) :: fname
>>>>      character*100 :: outfile,infile,outfname
>>>>      character*150 :: infpath,outfpath,line
>>>>      integer       :: num,i,j,col
>>>> c
>>>>      col=50
>>>>      i=1
>>>>      j=1
>>>> c
>>>>      write(*,*)'Enter no.of files to merge'
>>>>      read(*,*)num
>>>>      allocate(fname(num,col))
>>>> c
>>>> 
>>>>>   outfname = [fname(1,1:7), fname(num,1:6)]
>>>> 
>>>> For the solution you have mentioned, I am getting the following error.
>>>> outfname = [fname(1,1:7), fname(num,1:6)]
>>>>      1
>>>> Error: Incompatible ranks 0 and 1 in assignment at (1)
>>>> 
>>>> Can you please let me know...whether the problem is with the
>>>> declaration or with something else...!!
>>>> 
>>>> Thanking you.
>>>> 
>>>> Praveen.
>>> 
>>> outfname is a character variable (string). fname(1,1:7) is an array 
>>> slice. It is NOT a string of characters.
>>> 
>>> outfname='ABCDEFG' is not the same as outfname = ['A','B','C','D','E','F','G']
>> 
>> Is there a nice idiom for doing the conversion? On the few occasions I have had
>> to do this I ended up with a loop assigninng single characters. There 
>> are special
>> rules on the use of character arrays as formats in i/o that do the 
>> conversion for
>> you. Either that is a slick feature for that case or an indication of a missing
>> ability elsewhere.
> 
> If the variables are static, then EQUIVALENCE is a reasonable
> solution.  Declare and array and a string and equivalence them.

It is just transfer in disguise but with better syntax checking available.
I have done it but was not very happy.

> Dick Hendrickson
>> 
>> Nice does not include the use of transfer or changing all the commas above to
>> concatenate symbols. (I tend to rate transfer as "too clever for words" and to
>> be avoided.)
>> 
>>> --- e
>>> e-mail: epc8 at juno dot com

On 2010-01-26 12:50:25 -0400, "James Van Buskirk" <not_valid@comcast.net> said:

> "Gordon Sande" <g.sande@worldnet.att.net> wrote in message
> news:2010012609284916807-gsande@worldnetattnet...
> 
>> Nice does not include the use of transfer
> 
> Sigh.
> 
> C:\gfortran\clf\conv_char>type conv_char.f90
> module convert
>    implicit none
>    interface conv_char
>       module procedure string2array
>       module procedure array2string
>    end interface conv_char
>    contains
>       pure function string2array(string)
>          character(*), intent(in) :: string
>          character string2array(len(string))
> 
>          string2array = s2a(string,len(string))
>       end function string2array
>       pure function s2a(array,n)
>          integer, intent(in) :: n
>          character, intent(in) :: array(n)
>          character s2a(n)
> 
>          s2a = array
>       end function s2a
>       pure function array2string(array)
>          character, intent(in) :: array(:)
>          character(size(array)) :: array2string
> 
>          array2string = a2s(array,size(array))
>       end function array2string
>       pure function a2s(string,n)
>          integer, intent(in) :: n
>          character(n), intent(in) :: string(1)
>          character(n) a2s
> 
>          a2s = string(1)
>       end function a2s
> end module convert
> 
> program test
>    use convert
>    implicit none
> 
>    write(*,'(a,i0)') 'LEN(''ABCDEFG'') = ', LEN('ABCDEFG')
>    write(*,'(a,i0)') 'LEN(conv_char(''ABCDEFG'')) = ', &
>       LEN(conv_char('ABCDEFG'))
>    write(*,'(a,i0)') 'SIZE(conv_char(''ABCDEFG'')) = ', &
>       SIZE(conv_char('ABCDEFG'))
>    write(*,'(a)') 'conv_char(''ABCDEGF'') = ', conv_char('ABCDEFG')
> 
>    write(*,'()')
>    write(*,'(a,i0)') 'LEN([''A'',''B'',''C'',''D'',''E'',''F'',''G'']) = ',
> &
>       LEN(['A','B','C','D','E','F','G'])
>    write(*,'(a,i0)') 'SIZE([''A'',''B'',''C'',''D'',''E'',''F'',''G'']) = ',
> &
>       SIZE(['A','B','C','D','E','F','G'])
>    write(*,'(a,i0)') 'LEN(conv_char( &
>       &[''A'',''B'',''C'',''D'',''E'',''F'',''G''])) = ', &
>       LEN(conv_char(['A','B','C','D','E','F','G']))
>    write(*,'(a)') 'conv_char( &
>       &[''A'',''B'',''C'',''D'',''E'',''F'',''G'']) = ', &
>       conv_char(['A','B','C','D','E','F','G'])
> end program test
> 
> C:\gfortran\clf\conv_char>gfortran -std=f2003 conv_char.f90 -oconv_char
> 
> C:\gfortran\clf\conv_char>conv_char
> LEN('ABCDEFG') = 7
> LEN(conv_char('ABCDEFG')) = 1
> SIZE(conv_char('ABCDEFG')) = 7
> conv_char('ABCDEGF') =
> A
> B
> C
> D
> E
> F
> G
> 
> LEN(['A','B','C','D','E','F','G']) = 1
> SIZE(['A','B','C','D','E','F','G']) = 7
> LEN(conv_char( ['A','B','C','D','E','F','G'])) = 7
> conv_char( ['A','B','C','D','E','F','G']) =
> ABCDEFG

I appreciate the notion but it suffers from the fault of most object oriented
code that a naive reader can not determine what is going on without reading
in exhaustive detail large amounts of the surrounding code.

The opinion that I have formed, and been told by many others, is that unless
the abstraction is well designed, heavily used, fixed and imposed by others
it will cause much more harm than it cures. The obvious example is a wondowing
package which works nicely as it follows the requirements stated. The 
next usefull
example has still not been provided!

On Jan 26, 12:46=A0pm, Gordon Sande <g.sa...@worldnet.att.net> wrote:

re: array of characters versus a string in I/O

> Read the fine print on run time formats. An array of characters will be
> concatenated
> to construct the format. Rather special case that has nothing to do with =
the
> actual output the format produces. I would guess it is a legacy
> requirement from
> something F77 did.

Aha! Now I understand that you were referring to the format specifier.
I was talking about the items in the I/O list and did not get your
point at all.

-- e
e-mail: epc8 at juno dot com
sig: I'm at the office so I'm stuck with Google here.