From: Richard Maine on
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> (Just wondering, why no elemental trim function...)

Come now, it isn't that hard to deduce. Just think about what the result
of such a function would be. In particular, think about the type and
type parameters of the result. Let's see, its type would be character,
and its length would be... umm...

You do recall that, as noted earlier in this thread, that the type
parameters of an array apply to every element of the array and cannot
vary from element to element? So the result would be something that
doesn't exist in the language.

See the len_trim intrinsic. It is elemental.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Richard Maine on
dpb <none(a)non.net> wrote:

> dpb wrote:
> ...
>
> > do i = 1, 3
> > call doit(str(i)(:min(1,len_trim(str(i)))
> > end do
> > end
> >
> > This would pass the full length of the trimmed string but a blank string
> > would be required to have a length of one instead of being of length zero.
> ...
> Well, it would if wrote max() instead of min(), anyway... :)

While on the subject, I'm wondering why you have the max (or min) at
all? I'm confused as to what is intended here and why it isn't just

call doit(trim(str(i)))

I wonder whether you might have been recalling the f77 limitation that
did not allow zero-length substrings.


--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: dpb on
Richard Maine wrote:
> dpb <none(a)non.net> wrote:
>
>> dpb wrote:
>> ...
>>
>>> do i = 1, 3
>>> call doit(str(i)(:min(1,len_trim(str(i)))
>>> end do
>>> end
>>>
>>> This would pass the full length of the trimmed string but a blank string
>>> would be required to have a length of one instead of being of length zero.
>> ...
>> Well, it would if wrote max() instead of min(), anyway... :)
>
> While on the subject, I'm wondering why you have the max (or min) at
> all? I'm confused as to what is intended here and why it isn't just
>
> call doit(trim(str(i)))

My understanding was that OP didn't want a zero-length string in his
routine but didn't like trailing blanks on otherwise non-blank strings,
either; the above simply provided that to the subroutine. If I missed
the target there as well as the backwards logic selection, won't be
first time that's happened, either... :)

> I wonder whether you might have been recalling the f77 limitation that
> did not allow zero-length substrings.

Indeed, I had forgotten about that particular F77 behavior so can't
claim that, either,...

I was only thinking of F95 and later where trim() does return an empty
string(+) and the above objective which may not have been on target,
granted.


(+) OK, if I'm going to be _completely_ candid, I was actually only
thinking about the value of LEN_TRIM and it being zero and had to go
double-check TRIM() behavior to be sure I had it right... :)

--
From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
>> dpb wrote:

>> > do i = 1, 3
>> > call doit(str(i)(:min(1,len_trim(str(i)))
>> > end do
>> > end

(snip)

> While on the subject, I'm wondering why you have the max (or min) at
> all? I'm confused as to what is intended here and why it isn't just

> call doit(trim(str(i)))

> I wonder whether you might have been recalling the f77 limitation that
> did not allow zero-length substrings.

I thought the OP wanted one space between the words, though
that isn't so obvious. He didn't seem to want them jammed together.

call doit(trim(str(i))//' ')

-- glen
From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

>> (Just wondering, why no elemental trim function...)

> Come now, it isn't that hard to deduce. Just think about what the result
> of such a function would be. In particular, think about the type and
> type parameters of the result. Let's see, its type would be character,
> and its length would be... umm...

> You do recall that, as noted earlier in this thread, that the type
> parameters of an array apply to every element of the array and cannot
> vary from element to element? So the result would be something that
> doesn't exist in the language.

Yes, I thought about that, but I did still try putting it
into gfortran. I could have put a :) after the comment.

> See the len_trim intrinsic. It is elemental.

Hmm, now, if you can generate the run-time format from that,
and then use it. Probably not better than the implied-DO, though.

-- glen

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: many runs in one directory
Next: pressure and fortran