uppercase
Dirk Geyer
a very simple question : does anybody know where f90 /f95 functions to
convert characters to upper/lower case analogue the Matlab functions
lower are available ?
Thanks,
Dirk
Jugoslav Dujic
"Dirk Geyer" <ge...@ekt.tu-darmstadt.de> wrote in message
news:3E6EF02D...@ekt.tu-darmstadt.de...
It's simple to roll your own; here are my versions. Disclaimer: these
work only with ASCII; you'll need to add some refinements if you want
to include e.g. umlaut letters mapping. Conversion to subroutines, if
necessary, is trivial (I find function form more convenient to use,
although it's less efficient since it involves single or even double
copying (once from sString to TOUPPER, and once from function result
to the variable being assigned to)).
MODULE STRINGS
IMPLICIT NONE
!======================================================================
FUNCTION TOUPPER(sString)
CHARACTER(*),INTENT(IN):: sString
CHARACTER(LEN=LEN(sString)):: TOUPPER
INTEGER:: i, iAsc
TOUPPER=sString
DO i=1,LEN(sString)
iAsc=ICHAR(sString(i:i))
IF (iAsc.GE.97 .AND. iAsc.LE.122) TOUPPER(i:i)=CHAR(iAsc-32)
END DO
END FUNCTION TOUPPER
!======================================================================
FUNCTION TOLOWER(sString)
CHARACTER(*),INTENT(IN):: sString
CHARACTER(LEN=LEN(sString)):: TOLOWER
INTEGER:: i, iAsc
TOLOWER=sString
DO i=1,LEN(sString)
iAsc=ICHAR(sString(i:i))
IF (iAsc.GE.65 .AND. iAsc.LE.90) TOLOWER(i:i)=CHAR(iAsc+32)
END DO
END FUNCTION TOLOWER
!======================================================================
END MODULE STRINGS
--
Jugoslav
___________
www.geocities.com/jdujic
Dr Ivan D. Reid
wrote in <3E6EF02D...@ekt.tu-darmstadt.de>:
> a very simple question : does anybody know where f90 /f95 functions to
> convert characters to upper/lower case analogue the Matlab functions
> lower are available ?
I don't believe there is one, since the standard doesn't specify
a collating sequence on the character set. You need to write your own
for the local character-set you use (most probably ASCII, but EBCDIC, e.g.,
is still in use). You could probably do it with a statement function
if you only need to access it from one (sub)programme.
--
Ivan Reid, Electronic & Computer Eng., Brunel Uni. Ivan...@brunel.ac.uk
Michael Prager
<ge...@ekt.tu-darmstadt.de>
wrote in <3E6EF02D...@ekt.tu-darmstadt.de>:
> a very simple question : does anybody know where f90 /f95 functions to
> convert characters to upper/lower case analogue the Matlab functions
> lower are available ?
As others have said, it's not difficult to write your own
routines. However, if you want them already written, you can
find them at as part of "FLIB":
http://www.pnl.gov/berc/flib/
--
Mike Prager
NOAA, Beaufort, NC
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
David Ham
> On Wed, 12 Mar 2003 09:30:37 +0100, Dirk Geyer <ge...@ekt.tu-darmstadt.de>
> wrote in <3E6EF02D...@ekt.tu-darmstadt.de>:
>
> > a very simple question : does anybody know where f90 /f95 functions to
> > convert characters to upper/lower case analogue the Matlab functions
> > lower are available ?
>
> I don't believe there is one, since the standard doesn't specify
> a collating sequence on the character set.
According to M&R 2nd Ed. s8.5.1, achar and iachar use the ASCII
collating order so you could do this portably using them. As a
previous poster pointed out, this doesn't help when it comes to
characters (eg accented letters) which are not in ASCII.
David
Tim Prince
> On Wed, 12 Mar 2003 11:40:17 +0100, "Jugoslav Dujic"
> <jdujic...@uns.ns.ac.yu> wrote:
>
> [snip]
>>
>>MODULE STRINGS
>>
>>IMPLICIT NONE
>>!======================================================================
>>FUNCTION TOUPPER(sString)
>>
>>CHARACTER(*),INTENT(IN):: sString
>>CHARACTER(LEN=LEN(sString)):: TOUPPER
> Sorry for a dumb question, but is the statement above something that
> came in with Fortran 9x? I have previously tried with FORTRAN 77 to
> use a CHARACTER*(*) FUNCTION but never had a compiler which allowed
> that.
>
right, in f77 you can return a variable length string only via subroutine
argument. I find it somewhat annoying that these current Fortran compilers
give such vociferous warnings about use of CHARACTER*(*), even though g77
supports character(len=*), so there is a portable solution.
--
Tim Prince
Richard Maine
...
> >!======================================================================
> >FUNCTION TOUPPER(sString)
> >
> >CHARACTER(*),INTENT(IN):: sString
> >CHARACTER(LEN=LEN(sString)):: TOUPPER
> Sorry for a dumb question, but is the statement above something that
> came in with Fortran 9x? I have previously tried with FORTRAN 77 to
> use a CHARACTER*(*) FUNCTION but never had a compiler which allowed
> that.
F77 has character*(*) functions, but they do *NOT* do what you'd
think. I regard how they work in f77 as extremely obscure and next to
useless. They are one of the very few things deleted in f95....um,
no I'm wrong on that; they are on the obsolescent list instead of the
deleted one. I've heard several people complain that this shouldn't
be obsolescent because it is a really useful feature. With exactly
one exception (who's name I forget, but I think it was on a posting
here), these people didn't actually understand the feature in question
and were confusing it with something else.
Note that the above sample is not a character*(*) function. Instead
it is something actually useful. :-) The *(*) thing above is the
dummy argument. The function length is len(sString), which yes,
is an f90-ism.
For cases where you can't express the desired length so concisely,
what you probably want is a function with allocatable character
length. That's coming with f2k (in the draft anyway). It is often
possible to hack around the omission of such a thing, but it is
often a pretty ugly hack.
Oh yes, back to f77. If you really do declare a function to return
a character*(*) result, that does *NOT* mean that the length of
the result is determined at run-time. Recall that f77 has nothing
that is dynamically sized (adjustable arrays just being remappings
of memory set aside somewhere else). What a character*(*) function
result means is that the length is still specified at compile time,
but just in a different place. The length is specified in the
invoking scoping unit instead of in the function itself. The
invoking scoping unit may *NOT* specify the length as *(*), but
must give a real length.
To my knowledge, this works in all f77 compilers, though it is
obscure enough that I wouldn't be shocked to find that f77 compilers
existed where it had never been tested and doesn't actually work.
If it failed for you, I bet that you tried to declare the function
as character*(*) in the invoking scoping units, which you can't do.
--
Richard Maine | Good judgment comes from experience;
email: my last name at host.domain | experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov | -- Mark Twain
Paul van Delst
> news:3E6EF02D...@ekt.tu-darmstadt.de...
> | Hello,
> |
> | a very simple question : does anybody know where f90 /f95 functions to
> | convert characters to upper/lower case analogue the Matlab functions
> | lower are available ?
Here's what I use - adapted from examples in Cooper Redwine's "Upgrading to Fortran 90"
book. I prefer this sort of method to using the ASCII number value - but they may be less
efficient if you're doing a lot of upper to/from lower case conversion. I don't see why
you also couldn't extend the usage to characters like á, ó, ö, ü, ã, é, ç etc. by simply
including them in the lower_case and upper_case strings. (BTW, I used IDL a lot before
Fortran90, hence the names strupcase and strlowcase).
MODULE string_processing
IMPLICIT NONE
PRIVATE
PUBLIC :: strupcase
PUBLIC :: strlowcase
CHARACTER( LEN = 26 ), PRIVATE, PARAMETER :: lower_case = 'abcdefghijklmnopqrstuvwxyz'
CHARACTER( LEN = 26 ), PRIVATE, PARAMETER :: upper_case = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
FUNCTION strupcase ( input_string ) RESULT ( output_string )
! -- Argument and result
CHARACTER( * ), INTENT( IN ) :: input_string
CHARACTER( LEN( input_string ) ) :: output_string
! -- Local variables
INTEGER :: i, n
! -- Copy input string
output_string = input_string
! -- Loop over string elements
DO i = 1, LEN( output_string )
! -- Find location of letter in lower case constant string
n = INDEX( lower_case, output_string( i:i ) )
! -- If current substring is a lower case letter, make it upper case
IF ( n /= 0 ) output_string( i:i ) = upper_case( n:n )
END DO
END FUNCTION strupcase
FUNCTION strlowcase ( input_string ) RESULT ( output_string )
! -- Argument and result
CHARACTER( * ), INTENT( IN ) :: input_string
CHARACTER( LEN( input_string ) ) :: output_string
! -- Local variables
INTEGER :: i, n
! -- Copy input string
output_string = input_string
! -- Loop over string elements
DO i = 1, LEN( output_string )
! -- Find location of letter in upper case constant string
n = INDEX( upper_case, output_string( i:i ) )
! -- If current substring is an upper case letter, make it lower case
IF ( n /= 0 ) output_string( i:i ) = lower_case( n:n )
END DO
END FUNCTION strlowcase
END MODULE string_processing
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Ph: (301)763-8000 x7748
Fax:(301)763-8545
dud_a...@xparadise.net.nz
....... snip
This came up a few years ago (& probably several other times as well).
My preference the "opposite" - ie. to use the ASCII number value.
Based on a James Van B (I think it was) post, the code requires only a
single line ( FORALL - don't even need it in a function). From timing
tests I have found it a LOT faster to skip the branching cost &
"convert" the whole string. Code snippet as below ... (watch the text
wrapping). Apologies to the purists, but to me this is both simpler
code & faster.
David
~~~~~~~~~~~~~~ Convert to Upper Case ~~~~~~~~~~~~~~
! Map for conversion to UPPER_CASE
integer :: ido
character(LEN=1), parameter :: upper_case(0:255) = (/ (achar(ido), &
ido=0,96), (achar(ido-32), ido=97,122), (achar(ido), ido=123,255) /)
! Convert "string" to upper case
FORALL (i=1:LEN_TRIM(string)) string(i:i) =
upper_case(iachar(string(i:i)))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Of course "string" needs to be declared too! (use dependant). As
mentioned by Paul, there is no reason why the same approach cannot be
extended to other character conversions. Can modify "upper_case" to
whatever you want.
BTW - I extended this to 0:255 characters a while back - struck some
oddball characters that caused problems. Normally should need only
0:127 for text, but I have left it at 255 to (hopefully) avoid future
problems. Should have minimal, if any effect on conversion speed.
Dan Nagle
Since the lexical comparative functions all require comparison
based on ASCII codes, virtually _all_ Fortran processors
use ASCII as the sole character kind ( = 1).
Thus, your strategy may be _much_ more portable than you think!
*This* portability "purist" need no apology :-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
On Sat, 15 Mar 2003 11:08:24 +1300, dud_a...@xparadise.net.nz
wrote:
<snip>
>
>Based on a James Van B (I think it was) post, the code requires only a
>single line ( FORALL - don't even need it in a function). From timing
>tests I have found it a LOT faster to skip the branching cost &
>"convert" the whole string. Code snippet as below ... (watch the text
>wrapping). Apologies to the purists, but to me this is both simpler
>code & faster.
>
>David
<snip>
Richard Maine
> Since the lexical comparative functions all require comparison
> based on ASCII codes, virtually _all_ Fortran processors
> use ASCII as the sole character kind ( = 1).
There is at least one an f90 compiler for IBM mainframes. NAG does
one as I recall. I've never used it and I don't recall what it does
for character. Someone might have mentioned it here before, but I
don't recall. It is possible that it uses ASCII as its sole character
kind, ignoring EBCDIC. I'd think that a bit odd, but odder things
have been true.
--
Richard Maine
email: my last name at domain
domain: isomedia dot com
Dan Nagle
On Sat, 15 Mar 2003 03:14:42 GMT, Richard Maine <nos...@see.signature>
wrote:
>Dan Nagle <dna...@erols.com> writes:
>
<snip>
>
>There is at least one an f90 compiler for IBM mainframes. NAG does
>one as I recall. I've never used it and I don't recall what it does
>for character. Someone might have mentioned it here before, but I
>don't recall. It is possible that it uses ASCII as its sole character
>kind, ignoring EBCDIC. I'd think that a bit odd, but odder things
>have been true.
The IBM rep on J3 indicated that all IBM compilers for sale
use ASCII as the sole character kind. In the CD, this is forced
by 40:14-15. (I bet f95 has similar language, but I'm too lazy
to find it.)
I've been researching this as part of the "character wars"
ongoing during the final editing of the CD.
James Giles
Dan Nagle <dna...@erols.com> wrote:
...
> On Sat, 15 Mar 2003 03:14:42 GMT, Richard Maine <nos...@see.signature>
> wrote:
>> There is at least one an f90 compiler for IBM mainframes. NAG does
>> one as I recall. I've never used it and I don't recall what it does
>> for character. Someone might have mentioned it here before, but I
>> don't recall. It is possible that it uses ASCII as its sole
>> character kind, ignoring EBCDIC. I'd think that a bit odd, but
>> odder things have been true.
>
> The IBM rep on J3 indicated that all IBM compilers for sale
> use ASCII as the sole character kind. In the CD, this is forced
> by 40:14-15. (I bet f95 has similar language, but I'm too lazy
> to find it.)
I don't see how the requirements of the lexical intrinsic functions
inply that ASCII must be the sole (or even allowed) character set.
The purpose of those functions was to allow character sets other
than ASCII to be used as the default (and maybe only) character
set in the implementation and still allow portable comparisons.
Those intrinsics are only required to work for characters that
are actually present in the implementation's character set. For
example, if a character set doesn't have a character corresponding
to ASCII(17), the DC1 control character, the lexical comparison
functions don't do anything for that character.
There were (in F95 and before) displayable (ie. not control)
characters that Fortran didn't require be supported. Similarly,
some other character set my support displayable characters that
aren't in ASCII. Some set may have, for example, 姣 characters
(the French quotation marks). The lexical compare intrinsic
functions are not required to operate on those characters.
Note that EBCDIC has several forms, but at least one of them supports
all the displayable characters of ASCII. The lexical compare intrinsic
functions could be fully implemented in F2kV using EBCDIC.
--
J. Giles
Richard Maine
> The IBM rep on J3 indicated that all IBM compilers for sale
> use ASCII as the sole character kind.
Was he talking about compilers for sale by IBM or by 3rd parties?
I didn't think that IBM made an f90 for their mainframes, though
NAG does. Not that I keep very close track of IBM mainframe
ongoings, so my memories may be jumbled. I seem to recall him
posting here regularly (hi Rob) and I'm sure he knows better than
I do.
> In the CD, this is forced by 40:14-15.
Are we reading the same CD at all????? Doesn't seem like it.
Those are the lines that say that the LGT, LGE, LLE and LLT
intrinsics exist (and for details see the intrinsic descriptions).
Perhaps being editor drives me to read words to literally, but it
seems to me that you just said that these lines force ASCII to be the
sole character kind?
Since those intrinsics are only even defined for arguments of type
default character, I don't see what they even have to do with any
other kind. If you are trying to argue that the material in pg 41
implies that these intrinsics can be used for all kinds and therefore
that there can be no kinds other than default, I strongly disagree
with that interpretation; there seems to be rather a lot of material
in the standard suggesting the possibility of multiple kinds.
Indeed, the descriptions of these intrinsics say "If either string
contains a character not in the ASCII character set, the result is
processor dependent." This doesn't sound to me like a restriction to
ASCII. It sounds like it is pretty explicitly not restricted to
ASCII. Unless I've missed something, I think I could write these
intrinsics for an EBCDIC machine in no more than a few minutes
(most of which would be finding an EBCDIC table...I'm sure I've
got one around here somewhere). THis doesn't seem like something
so horrendous as to drive fundamental compiler decisions.
Dan Nagle
On 15 Mar 2003 13:17:40 -0800, Richard Maine <nos...@see.signature>
wrote:
>Dan Nagle <dna...@erols.com> writes:
<snip>
>
>> In the CD, this is forced by 40:14-15.
>
>Are we reading the same CD at all????? Doesn't seem like it.
>Those are the lines that say that the LGT, LGE, LLE and LLT
>intrinsics exist (and for details see the intrinsic descriptions).
>Perhaps being editor drives me to read words to literally, but it
>seems to me that you just said that these lines force ASCII to be the
>sole character kind?
>
As an economic practicality, if the lexical comparators
always return comparisons based on ASCII collating sequences,
then the default character kind will be ASCII.
I'm not arguing what the _standard_ requires, but what the _market_
requires, given the requirements of the standard.
Even compilers supporting .NET, which uses UTF-16, will not
support UTF-16, they'll be ASCII-only (and link to .NET via
conversion functions).
In fact, and I've checked with quite a few vendors, no compiler
I've ever found supports, or plans to support, any character kind
other than ASCII. The reason cited is the engineering one:
increased cost without increased value (for Fortran's usual
applications).
I don't want to the standard to require ASCII only, I'm only
saying that, as is, modern Fortran is an ASCII only language.
The only hints I've ever heard is for a second character kind
to be a C-string kind. This has null for blank, and backslash
is an escape character, and other C-isms (which I don't like,
but at least they're segregated in a separate kind).
<snip>
Richard Maine
> As an economic practicality, if the lexical comparators
> always return comparisons based on ASCII collating sequences,
> then the default character kind will be ASCII.
I don't buy that either. At least that argument makes sense
to me, but I don't agree with the economic evaluation.
As I mentioned in my previous post, I think I could write the lexical
comparison functions in Fortran for, say, an EBCDIC character kind
with no more that a few minutes of work. That doesn't sound
within quite a few orders of magnitude of an economic issue
sufficient to determine what the default character kind will be.
I can picture it:
"Hey Joe. Do you have an EBCDIC table handy that you could email me?"
"No, but there's one in whatever-book-author on the bookshelf there."
"All the way across the room? Forget it! Let's stick with ASCII."
> I'm not arguing what the _standard_ requires, but what the _market_
> requires, given the requirements of the standard.
Well, I'm closer to agreeing with that, but I still disgree with
part of it. I do agree that the market seems to require ASCII as
at least one character kind, with significant pressure for it to be the
default kind. And I agree that the market doesn't seem to have pushed
very hard for a second character kind. I take the existing compilers
as evidence of this, though I think it unreliable to extrapolate
such evidence to the future; indeed, I suspect there will be
increasing pressure to adopt one of the unicode variants, though
I wouldn't bet much on my predictive abilities on that.
Anyway, though I agree that there is market pressure in this direction,
I still think you are overstating the influence of the standard. Yes,
I'm aware that you backed down to just saying "given the requirements
of the standard", but I still think that an overstatement. I don't
think that there are any requirements of the standard that have anything
at all to do with that market pressure. For example, if the standard
didn't require the lexical comparison functions (which are what you
cited), I don't think it would make any difference at all in the
market pressure.
Indeed, my suspicion is that if the standard didn't require the lexical
functions, most of the market wouldn't even notice. I haven't observed
them to be very widely used, and they would be easy for anyone to
replace.
So I think your statement above is true, but I think it would be just
as true if it said
I'm not arguing what the _standard_ requires, but what the _market_
requires, given that pi is irrational.
> The only hints I've ever heard is for a second character kind
> to be a C-string kind. This has null for blank....
Eh? That doesn't even make sense to me. C has a perfectly ordinary
blank that doesn't act at all like null. This wouldn't seem a very
good match for C strings. The newsgroups would be full of complaints
about how it worked incorrectly whenever there were embedded blanks.
Better not try storing Windows file names in those strings (or unix
ones either, in theory, though names with embedded blanks are less
commonly used in unix - they seem almost the rule any more in
Windows).
Dan Nagle
I suspect I'm not expressing myself very well,
but I'll try again.
On Sun, 16 Mar 2003 17:27:30 GMT, Richard Maine <nos...@see.signature>
wrote:
>Dan Nagle <dna...@erols.com> writes:
>
>> As an economic practicality, if the lexical comparators
>> always return comparisons based on ASCII collating sequences,
>> then the default character kind will be ASCII.
>
>I don't buy that either. At least that argument makes sense
>to me, but I don't agree with the economic evaluation.
>
I've never heard of a compiler supporting more than
one character kind _in a standard way_, specifically,
a character kind which has a one scalar character (len= 1)
requiring the same storage for all characters in the set.
(Read: The only compilers I've ever heard of supporting
more than one character kind are Japanese compilers
supporting Japanese character sets. but those have
the property that some characters fit in one byte,
some fit in two bytes. Compiler writers recoil in shock
at the thought. Further, the _versions_ of the Japanese compilers
sold outside Japan support only ASCII.)
>As I mentioned in my previous post, I think I could write the lexical
>comparison functions in Fortran for, say, an EBCDIC character kind
>with no more that a few minutes of work. That doesn't sound
>within quite a few orders of magnitude of an economic issue
>sufficient to determine what the default character kind will be.
But if there's zero advantage in the market, even a little effort
appears to be wasted.
<snip>
>
>> I'm not arguing what the _standard_ requires, but what the _market_
>> requires, given the requirements of the standard.
>
>Well, I'm closer to agreeing with that, but I still disgree with
>part of it. I do agree that the market seems to require ASCII as
>at least one character kind, with significant pressure for it to be the
>default kind. And I agree that the market doesn't seem to have pushed
>very hard for a second character kind. I take the existing compilers
>as evidence of this, though I think it unreliable to extrapolate
>such evidence to the future; indeed, I suspect there will be
>increasing pressure to adopt one of the unicode variants, though
>I wouldn't bet much on my predictive abilities on that.
The standard requires the results of the lexical comparators
be as if done in ASCII. That means, at least the default character
kind will be ASCII. (Unless you want to argue that compiler
vendors will choose a greater complexity and cost solution than
required.) Since there's no market interest in second
standard conforming character kinds, QED.
>
<snip>
>
>Indeed, my suspicion is that if the standard didn't require the lexical
>functions, most of the market wouldn't even notice. I haven't observed
>them to be very widely used, and they would be easy for anyone to
>replace.
Except that you want to use the lexical comparators to implement
the standard required <, <=, >, >= for characters. You can't
remove those even if the named variants aren't popular.
<snip>
>
>... C has a perfectly ordinary
>blank that doesn't act at all like null. This wouldn't seem a very
>good match for C strings. The newsgroups would be full of complaints
>about how it worked incorrectly whenever there were embedded blanks.
>Better not try storing Windows file names in those strings (or unix
>ones either, in theory, though names with embedded blanks are less
>commonly used in unix - they seem almost the rule any more in
>Windows).
By "designated blank", I mean the requirement of 24:16-18,
the second clause of the sentence. For non-default character sets,
the vendor must designate a character to act as blank for padding
on assignments, PAD= in I/O, etc. These's nothing to stop a vendor
from choosing null as the pad character (or 'P' either, FTM).
Interoperability with C is far more important, I think,
than character operations in Fortran. If a vendor says
that the designated blank of character kind= 2 is null,
then you automatically get the behavior C programmers
expect, without forcing the // char( 0) every time.
And you can use the \n et al. without offending folks
like me (and you too, IIRC) who think it's an abomination.
BTW, note that R906 <file-name-expr> is <scalar-default-char-expr>,
so you're going to use an ASCII filename anyway (w/o the C-isms).
The difference is that a <file-name-expr> is only what is allowed
by the processor.
James Giles
Actually, the reason that multiple KINDs of character is not
a widely demanded fearture is that nearly all implementations
actually already support 8-bit characters and not merely ASCII.
A compliant implementation supporting only ASCII could
regularly mask off the eighth bit in processing and be compliant.
(I did this on the Cray. It allowed me to do things like converting
between upper- and lower-case in 5/8 of a clock per character.
But I had to use the eighth bit as a flag inside the algorithm which
was then masked off the result.)
Since most modern Fortran implementations support 8-bit characters
for which ASCII is a subset consisting of the first 128 codes, all the
ISO 8859 variants can be processed. All it takes is to set your text
editor (external to Fortran) to display the national variant of your
choice. I use full Latin-1 all the time with every Fortran compiler
I have. Works just fine.
If Fortran implementations really did support ASCII only, the demands
for some additional KINDs would be pouring in.
--
J. Giles
Toon Moene
> Dan Nagle <dna...@erols.com> writes:
>>The IBM rep on J3 indicated that all IBM compilers for sale
>>use ASCII as the sole character kind.
> Was he talking about compilers for sale by IBM or by 3rd parties?
> I didn't think that IBM made an f90 for their mainframes, though
> NAG does.
There still is a target in GCC that defines HOST_EBCDIC (target, in
GCC-speak, is the designation of an architecture for which code can be
generated), i.c. i370. However, the more modern s390 target presumes an
ASCII environment.
[ Strictly speaking, this doesn't pertain to Fortran 90 until GNU
Fortran 95 is released, but g77 on an i370 would
be using EBCDIC as its "native" character set ]
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
Gary L. Scott
>
> Richard Maine wrote:
>
> > Dan Nagle <dna...@erols.com> writes:
>
> >>The IBM rep on J3 indicated that all IBM compilers for sale
> >>use ASCII as the sole character kind.
>
> > Was he talking about compilers for sale by IBM or by 3rd parties?
> > I didn't think that IBM made an f90 for their mainframes, though
> > NAG does.
>
> There still is a target in GCC that defines HOST_EBCDIC (target, in
> GCC-speak, is the designation of an architecture for which code can be
> generated), i.c. i370. However, the more modern s390 target presumes an
> ASCII environment.
Only if running a more "modern" OS? MVS and VM are still EBCDIC and
still available for 390. If you have one of the newer versions which
have basically merged MVS and VM with a UNIX dialect, maybe the defaults
are different (I don't really think so and I don't have OS/390 to
investigate). Besides, EBCDIC is arguably "more advanced" than ASCII.
>
> [ Strictly speaking, this doesn't pertain to Fortran 90 until GNU
> Fortran 95 is released, but g77 on an i370 would
> be using EBCDIC as its "native" character set ]
>
> --
> Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
> Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
> GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
--
Gary Scott
mailto:gary...@ev1.net
Support the GNU Fortran G95 Project: http://g95.sourceforge.net
James Giles
Gary L. Scott <gary...@ev1.net> wrote:
...
> [...] Besides, EBCDIC is arguably "more advanced"
> than ASCII.
One advantage ASCII has is that it doesn't use the eighth bit.
So, you can use one of the ISO-8859 variants (use the one that
suits your mood, or the language you speak). Most ASCII based
Fortran implementations handle that just fine. So you can
process strings with degree symbols °, or you can write code
to talk about null sets Ø, and so on. I think there are international
variants of EBCDIC, but I don't think they keep the base character
set as well.
--
J. Giles
Gary L. Scott
With the plethora of different code pages available on the Mainframe, I
never had trouble locating one with a "standard" symbol that I needed.
You can make your own code pages (and fonts, image or vector) on the
mainframe quite easily. I've used this capability to create the unique
fonts for various aircraft displays. My needs for using a different
symbol set (font) or symbol than one available wouldn't be solved by a
simple change to ISO-8859 or some other "code page". This is one of the
things that irks me about PCs and in particular PC graphics packages.
They assume that the font you need is already available and so they do
not provide you with any font editors (or object (graphic) library
maintenance tools for that matter). I was once quite adept at creating
new symbol sets -- tedious but fun.
> --
> J. Giles
Gary L. Scott
Tedious but fun??
Jugoslav Dujic
| "Gary L. Scott" wrote:
| Tedious but fun??
Although it does seem strange, I understood you :-). Back in
my student days (when I had plethora of time), when my
roommate got his PC, I was about to write a card game. However,
for complete look & feel, I wanted Deutsch (aka Magyar) cards
to be used. Not having internet or scanner available, I drew
them pixel-by-pixel (some 80x150 pixels each). That was
definitely "tedious but fun" :-).
The expected outcome: The game was never finished, and the
bitmap got lost forever after an eventual disk format :-((.
--
Jugoslav
___________
www.geocities.com/jdujic
James Giles
> I never had trouble locating one with a "standard" symbol that I
> needed. You can make your own code pages (and fonts, image or vector)
> on the mainframe quite easily. I've used this capability to create
> the unique fonts for various aircraft displays. My needs for using a
> different symbol set (font) or symbol than one available wouldn't be
> solved by a simple change to ISO-8859 or some other "code page".
> This is one of the things that irks me about PCs and in particular PC
> graphics packages. They assume that the font you need is already
> available and so they do not provide you with any font editors (or
> object (graphic) library maintenance tools for that matter). I was
> once quite adept at creating new symbol sets -- tedious but fun.
I have two different freeware font editors somewhere (I suspect
they're only left around on on of my old Zip disks). I'm sure there
are others on the web. I can't say that I do font editing all the time,
but it can be done fairly easily. You don't even have to go pixel-at-a-time.
The ones I have let you draw freehand. One let me scan images in
for a starting point.
Of course, modern fonts aren't just bitmaps, but are parameterized
outlines and are scalable. So, just having a scanned image is not
alone sufficient. Well, I think you *can* define that a font is merely
a bitmap and not scalable, but I've never done it.
--
J. Giles
Gary L. Scott
>
> In 3E77139D...@ev1.net,
> Gary L. Scott <gary...@ev1.net> wrote:
> ...
> > With the plethora of different code pages available on the Mainframe,
> > I never had trouble locating one with a "standard" symbol that I
> > needed. You can make your own code pages (and fonts, image or vector)
> > on the mainframe quite easily. I've used this capability to create
> > the unique fonts for various aircraft displays. My needs for using a
> > different symbol set (font) or symbol than one available wouldn't be
> > solved by a simple change to ISO-8859 or some other "code page".
> > This is one of the things that irks me about PCs and in particular PC
> > graphics packages. They assume that the font you need is already
> > available and so they do not provide you with any font editors (or
> > object (graphic) library maintenance tools for that matter). I was
> > once quite adept at creating new symbol sets -- tedious but fun.
>
> I have two different freeware font editors somewhere (I suspect
> they're only left around on on of my old Zip disks). I'm sure there
> are others on the web. I can't say that I do font editing all the time,
> but it can be done fairly easily. You don't even have to go pixel-at-a-time.
> The ones I have let you draw freehand. One let me scan images in
> for a starting point.
>
> Of course, modern fonts aren't just bitmaps, but are parameterized
> outlines and are scalable.
That's what I meant by "vector" fonts above. IBM has had vector fonts
(primitives consisting of line, arc, shading instructions, character box
size definitions, various other attributes), since the 60's, long before
truetype or adobe.
So, just having a scanned image is not
> alone sufficient. Well, I think you *can* define that a font is merely
> a bitmap and not scalable, but I've never done it.
>
> --
> J. Giles
James Giles
...
>> Of course, modern fonts aren't just bitmaps, but are parameterized
>> outlines and are scalable.
>
> That's what I meant by "vector" fonts above. IBM has had vector fonts
> (primitives consisting of line, arc, shading instructions, character
> box
> size definitions, various other attributes), since the 60's, long
> before truetype or adobe.
Well, my memory of vector fonts is that they were line or arc
segments filled internally with color. Scaling them made the
discontinuities in the edges pretty obvious. Modern fonts outlines
using splines. They appear smoothly even when scaled very large
indeed. Of course, at the other end is the arcane craft of hinting
for very small scaling.
--
J. Giles
Gary L. Scott
Vector (GDDM) fonts consisted also of bezier curves (actually, I don't
think arcs were used, only beziers). There were never problems with
line/arc/bezier segment end points meeting at any scaling factor from
11x17 to 0.5 point in my experience. The only issue was that the
rasterization routines for the outline line segments were not very
accurate at small character box sizes/line widths. This was admitted by
an IBM rep as a consequence of choosing an algorithm that minimized
mainframe CPU usage at expense of quality, rather than inherent in the
font definition. This typically wasn't noticed at 600DPI or greater.
Unforunately, most of our printers were 240DPI. I tried to get them to
add an option for "high quality" rastorization. They seemed to agree
that it was a good idea, but they seemed afraid to touch those assembly
routines and they (an IBM Hersley rep) indicated that the guy that wrote
them had retired.
James Giles
that you can't do fonts on PCs has gone. Now it has devolved
into defence of *how* the mainframes did so. So, evidently
the claim that PCs don't allow it has been abandoned.
--
J. Giles
Gary L. Scott
Hmmm. I never made the claim that it couldn't be done on the PC or that
it was really all that difficult to find such a tool, merely that the PC
graphics/GUI library vendors don't supply this simple tool by default
(or an icon editor or a basic object library maintenance tool either).
Sorry if I misled you.