|
|
 |
 |
 |
 |
Fortran Programming Language
|
 |
 |
 |
 |
|
|
|
|
add a0 format to language to print trimmed character variables
I wish there were an "a0" format for character variables, analogous to
i0 for integers, which would not print trailing spaces in character
variables. For example,
character (len=5) :: words(4) = (/"one ","two ","three","four "/)
write (*,"(100(1x,a0))") words
would print
one two three four
The TRIM function is not elemental, so one cannot write
write (*,"(100(1x,a))") trim(words)
Currently I write
write (*,"(100(1x,a))") (trim(words(i)),i=1,size(words))
which is slightly awkward IMO.
On Apr 27, 5:25 pm, Beliavsky <beliav@aol.com> wrote:
> I wish there were an "a0" format for character variables, analogous to > i0 for integers, which would not print trailing spaces in character > variables. For example, > character (len=5) :: words(4) = (/"one ","two ","three","four "/)
> write (*,"(100(1x,a0))") words
> would print
> one two three four
> The TRIM function is not elemental, so one cannot write
> write (*,"(100(1x,a))") trim(words)
> Currently I write
> write (*,"(100(1x,a))") (trim(words(i)),i=1,size(words))
> which is slightly awkward IMO.
implement it in g95
Michael
<mich @athenavisual.com> wrote: > On Apr 27, 5:25 pm, Beliavsky <beliav @aol.com> wrote: > > I wish there were an "a0" format for character variables, analogous to > > i0 for integers, which would not print trailing spaces in character > > variables. > I am with you. Did you send your suggestion to Andy? Perhaps he can > implement it in g95
analogy.
The i0 for integers doesn't modify the value printed out. It just avoids
adding blank padding characters.
For the character case, you aren't talking about padding. Instead, you
are talking about modifying the value printed out, as the blanks are
part of the value.
Yes, they both result in fewer blanks, but I see them as conceptually
different.
In any case, I'd recommend against having g95 start adding random new
extensions, particularly ones with such small payoff. Avoiding an
implied DO loop doesn't seem like a big payoff to me. What would happen
if the standard later adopted some different meaning for an A0 edit
descriptor? I think that adding new extensions without spending
significant time considering the cost/benefit is a path towards a mess.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Richard Maine wrote:
(someone wrote)
>>>I wish there were an "a0" format for character variables, analogous to
>>>i0 for integers, which would not print trailing spaces in character
>>>variables.
> I don't see that as analogous. Or at any rate, I don't
> think it a robust analogy.
> The i0 for integers doesn't modify the value printed out. It just avoids
> adding blank padding characters.
> For the character case, you aren't talking about padding. Instead, you
> are talking about modifying the value printed out, as the blanks are
> part of the value.
But there is already an A descriptor that doesn't add padding, and
that is just A. Why isn't the no padding I descriptor just I?
> Yes, they both result in fewer blanks, but I see them as conceptually
> different.
I do agree that avoiding an implied-DO is a silly reason to add
such a feature. Still, since the no-pad form of A already exists,
I don't see that as needing A0. I also don't see a use for I,
other than that already taken by I0. It seems that the standard
is already inconsistent.
-- glen
On Apr 28, 1:57 am, nos@see.signature (Richard Maine) wrote:
> <mich @athenavisual.com> wrote: > > On Apr 27, 5:25 pm, Beliavsky <beliav @aol.com> wrote: > > > I wish there were an "a0" format for character variables, analogous to > > > i0 for integers, which would not print trailing spaces in character > > > variables. > > I am with you. Did you send your suggestion to Andy? Perhaps he can > > implement it in g95 > I don't see that as analogous. Or at any rate, I don't think it a robust
> analogy.
> The i0 for integers doesn't modify the value printed out. It just avoids
> adding blank padding characters.
> For the character case, you aren't talking about padding. Instead, you
> are talking about modifying the value printed out, as the blanks are
> part of the value.
> Yes, they both result in fewer blanks, but I see them as conceptually
> different.
Fortran character variables have a fixed length, IMO an awkward
feature of the language. I think my proposal removes some of the
awkwardness . Many features have been added to Fortran edit
descriptors that are convenient but not absolutely necessary, for
example repeat edit descriptors (and the colon within them) or i0. I
am not sure that printf of C has analogs for all of these. I consider
the implied do loop an irregular feature of the language and try to
avoid using it. The feature is simple enough that I think it would be
used more than some of the other proposed features for Fortran 2008.
I would be wary of using the feature as hypothetical extension of g95
since I use the Intel and gfortran compilers as well.
On Apr 28, 5:07 am, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:
> Richard Maine wrote: > (someone wrote)
> >>>I wish there were an "a0" format for character variables, analogous to
> >>>i0 for integers, which would not print trailing spaces in character
> >>>variables.
> > I don't see that as analogous. Or at any rate, I don't
> > think it a robust analogy.
> > The i0 for integers doesn't modify the value printed out. It just avoids
> > adding blank padding characters.
> > For the character case, you aren't talking about padding. Instead, you
> > are talking about modifying the value printed out, as the blanks are
> > part of the value.
> But there is already an A descriptor that doesn't add padding, and
> that is just A. Why isn't the no padding I descriptor just I?
I don't think that's a standard interpretation of the A descriptor --
the implied width of field with a missing field width specifier is a
compiler-supplied default. For the A descriptor, the default is the
actual length of the specified i/o item.
On 2007-04-28 11:00:00 -0300, dpb <bozart@gmail.com> said:
> On Apr 28, 5:07 am, glen herrmannsfeldt <g @ugcs.caltech.edu> wrote: >> Richard Maine wrote: >> (someone wrote)
>>>>> I wish there were an "a0" format for character variables, analogous to
>>>>> i0 for integers, which would not print trailing spaces in character
>>>>> variables.
>>> I don't see that as analogous. Or at any rate, I don't
>>> think it a robust analogy.
>>> The i0 for integers doesn't modify the value printed out. It just avoids
>>> adding blank padding characters.
>>> For the character case, you aren't talking about padding. Instead, you
>>> are talking about modifying the value printed out, as the blanks are
>>> part of the value.
>> But there is already an A descriptor that doesn't add padding, and
>> that is just A. Why isn't the no padding I descriptor just I?
> ...
> I don't think that's a standard interpretation of the A descriptor --
> the implied width of field with a missing field width specifier is a
> compiler-supplied default. For the A descriptor, the default is the
> actual length of the specified i/o item.
The original request was to have TRIM applied to an array of
character variables produce an array in which each element could
have a different length. The place this would be of use would be
in an I/O list as otherwise an assignment would just get a new
fixed length back. I suppose one could also think of doing a
concatenation of the variable length pieces before doing the
assignment. This would build up full names from first and last names
without the confusion of all the first names being padded to a fixed
length. Perhaps it might be a nice example of FORALL doing something
that a regular array assignment does not have access to.
On Apr 28, 9:00 am, dpb <bozart@gmail.com> wrote:
> On Apr 28, 5:07 am, glen herrmannsfeldt <g @ugcs.caltech.edu> wrote: > > Richard Maine wrote:
> > (someone wrote)
> > >>>I wish there were an "a0" format for character variables, analogous to
> > >>>i0 for integers, which would not print trailing spaces in character
> > >>>variables.
> > > I don't see that as analogous. Or at any rate, I don't
> > > think it a robust analogy.
> > > The i0 for integers doesn't modify the value printed out. It just avoids
> > > adding blank padding characters.
> > > For the character case, you aren't talking about padding. Instead, you
> > > are talking about modifying the value printed out, as the blanks are
> > > part of the value.
> > But there is already an A descriptor that doesn't add padding, and
> > that is just A. Why isn't the no padding I descriptor just I?
> ...
> I don't think that's a standard interpretation of the A descriptor --
> the implied width of field with a missing field width specifier is a
> compiler-supplied default. For the A descriptor, the default is the
> actual length of the specified i/o item.
meaning the same.
Beliavsky wrote:
> ...
> Usually when I have a string with trailing blanks it is because
> Fortran character variables have a fixed length, IMO an awkward
> feature of the language. I think my proposal removes some of the
> awkwardness...
Your idea, IMO, is a fine one. But it is worth noting is that in
F2003, Fortran character variables can have an 'allocatable' length.
Thus, the F2003 feature largely solves the Big Problem.
So I would rather advocate to my Fortran compiler vendors to get
moving on F2003 allocatable character string lengths, than introduce
yet another non-Standard edit descriptor that they then have to
support 'forever'.
Don't let me prevent you from suggesting it in the F2008 public
review though. I think it has some merit.
W.
Walter Spector wrote: > Beliavsky wrote: >> ... >> Usually when I have a string with trailing blanks it is because >> Fortran character variables have a fixed length, IMO an awkward >> feature of the language. I think my proposal removes some of the >> awkwardness... > Your idea, IMO, is a fine one. But it is worth noting is that in
> F2003, Fortran character variables can have an 'allocatable' length.
> Thus, the F2003 feature largely solves the Big Problem.
> So I would rather advocate to my Fortran compiler vendors to get
> moving on F2003 allocatable character string lengths, than introduce
> yet another non-Standard edit descriptor that they then have to
> support 'forever'.
> Don't let me prevent you from suggesting it in the F2008 public
> review though. I think it has some merit.
> W.
suggesting anything to anyone. But, as a practical matter, F2008
has a ton of new stuff and tight (internationally imposed) deadlines.
The odds of a new feature being accepted very late in the game are
rather small in my opinion. For good or bad, the public comment
period now seems to concentrate mostly on fixing errors and
inconsistencies and (occasionally) removing a feature that is
deemed to be unworkable or useless. A more practical thing would be to
build a consensus and work for F2013. Yes, that's a long time
from now. That's just all my personal opinion.
Dick Hendrickson
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc