Charaters
Brian Ross
I am porting an old tool called MUSCL. It is a precompiler that creates
Fortran code from MUSCL source. MUSCL is a tabulated fortran programming
language. The need for case conversion is I am accepting command line input
to the precompiler and NT doesn't differentiate case.
The compiler is WATCOM F77 V11a.
Thanks.
Kurt Kaellblad
One of several possibilities is my old F77 routine:
c**************************************************
subroutine uc2lc( str1 )
integer i, is
character str1*(*), str2*(*), upp*26, low*26
data upp /'ABCDEFGHIJKLMNOPQRSTUVWXYZ'/
data low /'abcdefghijklmnopqrstuvwxyz'/
c--------------------------------------------------
do 10 is = 1, len( str1 )
i = index( upp, str1(is:is) )
if( i .gt. 0 ) str1(is:is) = low(i:i)
10 continue
return
c==================================================
entry lc2uc( str2 )
c--------------------------------------------------
do 20 is = 1, len( str2 )
i = index( low, str2(is:is) )
if( i .gt. 0 ) str2(is:is) = upp(i:i)
20 continue
return
end
Good luck,
Kurt
Kurt Kaellblad, PhD <kurt.k...@bkl.lth.se>
Building Science, Lund Institute of Technology
Lund University, Sweden
DaveGemini
integer, parameter :: uc2lc = ichar('a') - ichar('A')
do i = 1,len(string)
ch = string(i:i)
if (ch >= 'A'.AND.ch <= 'Z') ch = char(ichar(ch)+uc2lc)
string(i:i) = ch
end do
Ron Shepard
daveg...@aol.com (DaveGemini) wrote:
Just a word of warning. The above will work on ascii characters, but some
character sets put stuff between the lowercase and uppercase letters.
EBCDIC for example, puts the numerals in there.
This brings up the age-old problem of having to choose between portability
and efficiency. The best solution would be to have a standard conditional
compilation facility (e.g. a preprocessor) that would allow the most
efficient code to be used on any target machine. Then we could write
portable yet machine-dependent code.
!preprocessor-if ASCII
...efficient ascii code here...
!preprocessor-else
...less efficient portable code here...
!preprocessor-endif
I have my own utility to handle this stuff, but then so does every other
fortran programmer out there. It would be much better if a standard one
were available, then we could quit worrying about this stuff and actually
write portable code.
What is the status of standard preprocessors for fortran? Will it be in
Fortran 2000?
$.02 -Ron Shepard
Kurt Kaellblad
>In article <199807192105...@ladder01.news.aol.com>,
>daveg...@aol.com (DaveGemini) wrote:
>
>>Yet another variation in converting upper case -> lower case
>>
>>integer, parameter :: uc2lc = ichar('a') - ichar('A')
>>
>>do i = 1,len(string)
>> ch = string(i:i)
>> if (ch >= 'A'.AND.ch <= 'Z') ch = char(ichar(ch)+uc2lc)
>> string(i:i) = ch
>>end do
>
>Just a word of warning. The above will work on ascii characters, but some
>character sets put stuff between the lowercase and uppercase letters.
>EBCDIC for example, puts the numerals in there.
>
I don't see the problem. As far as A-Z as well as a-z is in order (which is
necessary and I think is the case in most (all?) used character sets) some
characters between them will be handled by uc2lc as well as if the lower
case characters are placed before the upper case characters.
Another problem is non English characters. These are easy to handle in
the routine I suggested 98-07-18 but require several if-blocks in the above
code. These characters should perhaps not be used in a portable code but
they are allowed in e.g. file names in DOS and Windows so the problem is
there.
Greetings,
Ron Shepard
Kaellblad) wrote:
>In article <shepard-2007...@macrls.tcg.anl.gov>,
she...@tcg.anl.gov (Ron Shepard) wrote:
>>In article <199807192105...@ladder01.news.aol.com>,
>>daveg...@aol.com (DaveGemini) wrote:
>>
>>>Yet another variation in converting upper case -> lower case
>>>
>>>integer, parameter :: uc2lc = ichar('a') - ichar('A')
>>>
>>>do i = 1,len(string)
>>> ch = string(i:i)
>>> if (ch >= 'A'.AND.ch <= 'Z') ch = char(ichar(ch)+uc2lc)
>>> string(i:i) = ch
>>>end do
>>
>>Just a word of warning. The above will work on ascii characters, but some
>>character sets put stuff between the lowercase and uppercase letters.
>>EBCDIC for example, puts the numerals in there.
>>
><snip>
>
>I don't see the problem. As far as A-Z as well as a-z is in order (which is
>necessary and I think is the case in most (all?) used character sets) some
>characters between them will be handled by uc2lc as well as if the lower
>case characters are placed before the upper case characters.[...]
My memory failed me to some extent here. In EBCDIC, the letters do not
occur contiguously. There are six ranges of letters:
129-137 a-i
145-153 j-r
162-169 s-z
193-201 A-I
209-217 J-R
226-233 S-Z
And can be seen, the lower case letters do indeed occur in the sequence
before the upper case letters. However, the numerals along with other
characters are scattered in between these ranges, so the simple test
if (ch >= 'A'.AND.ch <= 'Z')
does not work with EBCDIC to select the upper case letters. However, for
those characters that are alphabetic, a constant shift (of -64) does
convert uppercase to lower case.
$.02 -Ron Shepard