Fortran - How to detect NULL input?

Author

How to detect NULL input?

jane.sync@yahoo.com

2006-01-29, 9:56 pm

Is there a way to determine if the return key is pressed while waiting
for input? I tried to do something like the code below in the line "if
(LLT(str1,'')) then" where I was comparing "str1" to ''. The program
didn't read the enter key...

function evaluateinput(str1) result(string)
implicit none
character(12) str1
character(12) string
if (LLT(str1,'')) then
string = 'less than'
else if (LGT(str1,'')) then
string = 'greater than'
else
string = 'equal'
end if
return
end

Rich Townsend

2006-01-29, 9:56 pm

jane.sync@yahoo.com wrote:
> Is there a way to determine if the return key is pressed while waiting
> for input? I tried to do something like the code below in the line "if
> (LLT(str1,'')) then" where I was comparing "str1" to ''. The program
> didn't read the enter key...
>
> function evaluateinput(str1) result(string)
> implicit none
> character(12) str1
> character(12) string
> if (LLT(str1,'')) then
> string = 'less than'
> else if (LGT(str1,'')) then
> string = 'greater than'
> else
> string = 'equal'
> end if
> return
> end
>

Once again, replace

character(12) str1

by

character(*) str1

....and you should be OK.

cheers,

Rich

jane.sync@yahoo.com

2006-01-29, 9:56 pm

That worked for the string comparison with everything except NULL.
Maybe I goofed something up in the main. The whole program is below.
Did I goof something up?

program test
implicit none
CHARACTER(12) fname
CHARACTER(12) evaluateinput
C CHARACTER(*) fname
C CHARACTER(*) evaluateinput

100 WRITE (*, 101)
101 format ('String: ', $ )
READ (*, *) fname
print *, 'Test ',evaluateinput(fname)
END program

function evaluateinput(str1) result(string)
implicit none
character(*) str1
character(*) string
string = 'world'
if (str1 .EQ. '') then
string = 'equal'
else
string = 'not equal'
end if
return
end

Catherine Rees Lay

2006-01-30, 8:00 am

Are you really using an F77 compiler, or is it a more recent one, but
with F77 code?

F77 doesn't have null strings, but F90 does. I'm not sure what happens
if you compare against one - I'm slightly surprised it gets past an F77
compiler.

What happens if you initialise fname to ' ' and then test against ' ' (
a space)? I'm wondering if it's currently filled with random junk and
pressing return alone doesn't alter it.

Catherine.

jane.sync@yahoo.com wrote:
> That worked for the string comparison with everything except NULL.
> Maybe I goofed something up in the main. The whole program is below.
> Did I goof something up?
>
> program test
> implicit none
> CHARACTER(12) fname
> CHARACTER(12) evaluateinput
> C CHARACTER(*) fname
> C CHARACTER(*) evaluateinput
>
> 100 WRITE (*, 101)
> 101 format ('String: ', $ )
> READ (*, *) fname
> print *, 'Test ',evaluateinput(fname)
> END program
>
> function evaluateinput(str1) result(string)
> implicit none
> character(*) str1
> character(*) string
> string = 'world'
> if (str1 .EQ. '') then
> string = 'equal'
> else
> string = 'not equal'
> end if
> return
> end
>

Herman D. Knoble

2006-01-30, 8:00 am

Richard E Maine

2006-01-30, 7:02 pm

Catherine Rees Lay <spamtrap@polyhedron.com> wrote:

> Are you really using an F77 compiler, or is it a more recent one, but
> with F77 code?

He probably is not using an f77 compiler, even if he thinks he is. A
current f77 compiler would almost certainly accept the "universal"
extensions of long names, mixed case, and implicit none, but the result
clause is another matter.

> F77 doesn't have null strings, but F90 does. I'm not sure what happens
> if you compare against one - I'm slightly surprised it gets past an F77
> compiler.

I think it confuses matters to refer to them as null strings, but
perhaps that's just me. I call them just zero-length strings and there
are no special rules necessary for them. If you know how string
comparison works in the first place, then it works the same way with
zero length ones. In particular, string comparison for strings of
differet lengths always pads the shorter string with blanks to the same
length as the longer one. Without this rule, life with Fortran's
fixed-length strings would be a mess.

I assume you know (if not, you really need to) that

character s*80
s = 'hello'

will cause s to get filled with blank padding after the 'hello'; the
length of s after this assignment is 80, not 5. If you ld be rather a
nuisance if, after the above assignment, (s .eq. 'hello') gave .false.
as a result. BY the same rule, (s .eq. 'hello ') and ('hello' .eq.
'hello ') also return .true. results. If you understood all that, then
zero-length strings should not look like a special case. In particular,
('' .eq. ' ') is .true. in f90. As you correctly note, it is disallowed
in f77.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

robin

2006-01-30, 9:57 pm

jane.sync@yahoo.com wrote in message <1138593234.901437.246450@o13g2000cwo.googlegroups.com>...
>That worked for the string comparison with everything except NULL.
>Maybe I goofed something up in the main. The whole program is below.
>Did I goof something up?
>
> program test
> implicit none
> CHARACTER(12) fname
> CHARACTER(12) evaluateinput
>C CHARACTER(*) fname
>C CHARACTER(*) evaluateinput

The above two commented lines are valid only in a subroutine
or function where the names refer to dummy arguments.
The uncommented form needs to be used in the main program.

> 100 WRITE (*, 101)
>101 format ('String: ', $ )
> READ (*, *) fname
> print *, 'Test ',evaluateinput(fname)
> END program

You need to replace the END program statement by a CONTAINS
statement.
This makes the function visible to the program, and in particular,
makes the TYPE of the function visible.

> function evaluateinput(str1) result(string)
> implicit none
> character(*) str1
> character(*) string
> string = 'world'
> if (str1 .EQ. '') then

This is better as
if (len_trim(str1) == 0) then
[the lines below are not appropriate for this test,
but I expect that you are aware of that.]

> string = 'equal'
> else
> string = 'not equal'
> end if
> return
> end

Move the END program statement here.

Rich Townsend

2006-01-30, 9:57 pm

robin wrote:
> jane.sync@yahoo.com wrote in message <1138593234.901437.246450@o13g2000cwo.googlegroups.com>...
>
>
>
> The above two commented lines are valid only in a subroutine
> or function where the names refer to dummy arguments.
> The uncommented form needs to be used in the main program.
>
>
>
>
> You need to replace the END program statement by a CONTAINS
> statement.
> This makes the function visible to the program, and in particular,
> makes the TYPE of the function visible.
>
>
>
>
> This is better as
> if (len_trim(str1) == 0) then
> [the lines below are not appropriate for this test,
> but I expect that you are aware of that.]
>
>
>
>
> Move the END program statement here.
>
>
>

Aren't you assuming that the program is F9X? From the fixed formatting, it looks
more like F77 --- and thus the compiler will barf if you put in CONTAINS and ==.

cheers,

Rich

Richard Maine

2006-01-31, 4:08 am

Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

> Aren't you assuming that the program is F9X? From the fixed formatting, it
> looks more like F77 --- and thus the compiler will barf if you put in
> CONTAINS and ==.

Fixed source form is valid in either f90 or f77. As I said elsethread,
the result clause in the function statement is neither f77 nor a
common f77 extension. I'd guess that the OP is using an
f90/f95 compiler.

That doesn't mean I agree with the advice and the way it was stated
(which I wouldn't have seen if you hadn't quoted it in full), but I
suspect this aspect was probably correct.

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

Rich Townsend

2006-01-31, 7:58 am

Richard Maine wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
>
>
>
> Fixed source form is valid in either f90 or f77. As I said elsethread,
> the result clause in the function statement is neither f77 nor a
> common f77 extension. I'd guess that the OP is using an
> f90/f95 compiler.
>
> That doesn't mean I agree with the advice and the way it was stated
> (which I wouldn't have seen if you hadn't quoted it in full), but I
> suspect this aspect was probably correct.
>

Fair enough. BTW, was result primarily introduced to support recursive functions?

cheers,

Rich

Richard E Maine

2006-01-31, 7:02 pm

Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

> Fair enough. BTW, was result primarily introduced to support recursive
functions?

That's my impression. It was introduced in f90, before I was on J3, and
I don't recall ever explicitly asking, but I would assign a reasonably
high degree of confidence tothat guess.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt

2006-01-31, 7:02 pm

Richard E Maine <nospam@see.signature> wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
> functions?

> That's my impression. It was introduced in f90, before I was on J3, and
> I don't recall ever explicitly asking, but I would assign a reasonably
> high degree of confidence tothat guess.

In the early days of Fortran, when all variables were static
including the function return value, I could see the problem.

Is there a requirement that the function return variable be
static in versions allowing recursion?

It is more consistent with other languages not to need to assign
to a variable named after the function.

Also, there is a tradition (in the case of ENTRY) that all function
return variables are EQUIVALENCEd. Does it still do that, even
in the case of recursive functions not using a function return variable?

-- glen

Dick Hendrickson

2006-01-31, 7:02 pm

glen herrmannsfeldt wrote:

> Richard E Maine <nospam@see.signature> wrote:
>
>
>
>
>
>
> In the early days of Fortran, when all variables were static
> including the function return value, I could see the problem.
>
> Is there a requirement that the function return variable be
> static in versions allowing recursion?

I think the problem is with recursive functions that are
also array valued. What does
func(3) = func(3) + 1
mean if func is array valued?

I'm pretty sure there is no requirement that anything in
Fortran be static. Heck, there's not even a requirement
that processors have memory ;). That's merely an easy
way to do things. It's hard to imagine how a static
requirement could apply to recursive functions. Each
instance needs to do it's own computation and have a place
to return it's result value.

Dick Hendrickson
>
> It is more consistent with other languages not to need to assign
> to a variable named after the function.
>
> Also, there is a tradition (in the case of ENTRY) that all function
> return variables are EQUIVALENCEd. Does it still do that, even
> in the case of recursive functions not using a function return variable?
>
> -- glen

Richard E Maine

2006-01-31, 7:02 pm

glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:

> Richard E Maine <nospam@see.signature> wrote:
>
>
> In the early days of Fortran, when all variables were static
> including the function return value, I could see the problem.

Huh? I don't even know what that has to do with the problem. The problem
has nothing at all to do with static vs dynamic or anything like that.
It is purely a matter of syntax. If one had, say, a recursive array
function f, then without the result clause, there would be cases where
one could not tell whether f(1) was a recursive function reference or
just a reference to the first element of the result variable for this
function.

> Is there a requirement that the function return variable be
> static in versions allowing recursion?

To my knowledge, the word "static" doesn't even appear in the language
(not that I really bothered to check). It certainly does not appear in
this regard; nor does any other word with the same implication. Rather
the opposite, I don't see an obvious way to implement recursive
functions with a static result variable. If someone can come up with
some obscure way to do so, it certainly isn't the norm. I doubt that a
single such implementation exists.

> Also, there is a tradition (in the case of ENTRY) that all function
> return variables are EQUIVALENCEd. Does it still do that, even
> in the case of recursive functions not using a function return variable?

1. Nothing in that regard is special-cased for recusrion. Yes, it still
works the same way. This seems to me unrelated to the question of why
the result clause was added.

2. *ALL* functions have a function result variable. The only thing that
th eresult clause does is give that variable a different name. But a
variable exists regardless. If you think of functions as not having
result variables, you will be lead down many wrong paths.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt

2006-01-31, 7:02 pm

Richard E Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:

[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> Huh? I don't even know what that has to do with the problem. The problem
> has nothing at all to do with static vs dynamic or anything like that.
> It is purely a matter of syntax. If one had, say, a recursive array
> function f, then without the result clause, there would be cases where
> one could not tell whether f(1) was a recursive function reference or
> just a reference to the first element of the result variable for this
> function.

OK, I was completely

on this one. I thought that
there was now the ability to specify function return values
on the RETURN statement, but it doesn't seem that there is.

[color=darkred]
> To my knowledge, the word "static" doesn't even appear in the language
> (not that I really bothered to check). It certainly does not appear in
> this regard; nor does any other word with the same implication. Rather
> the opposite, I don't see an obvious way to implement recursive
> functions with a static result variable. If someone can come up with
> some obscure way to do so, it certainly isn't the norm. I doubt that a
> single such implementation exists.

I don't think that is what I meant.

[color=darkred]
> 1. Nothing in that regard is special-cased for recusrion. Yes, it still
> works the same way. This seems to me unrelated to the question of why
> the result clause was added.

It does seem that there are complications with ENTRY, such that
array valued functions are not allowed. That is the type of
complication I was thinking of.

> 2. *ALL* functions have a function result variable. The only thing that
> th eresult clause does is give that variable a different name. But a
> variable exists regardless. If you think of functions as not having
> result variables, you will be lead down many wrong paths.

Yes. I was considering complications of ENTRY and recursion,
but it seems that ENTRY forbids array value functions.
Result does allow the convenience of only one name for a return
value for a function with multiple ENTRY points.

-- glen

Richard E Maine

2006-01-31, 7:02 pm

glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:

> It does seem that there are complications with ENTRY, such that
> array valued functions are not allowed.

That's not entirely accurate as it stands. Array functions are allowed
with entry. What is not allowed is array function entries that do the
"funny" entry equivalence thing. That funny equivalence thing is
basically an obsolescent feature (although not explicitly labelled that
way). You an tell because of the very short list of cases where it is
allowed - no derived types, not even intrinsic types other than the ones
in f77 (for example, no integers other than of default kind).

Entries can be arrays as long as they have the same characteristics as
the function result.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

robin

2006-01-31, 7:02 pm

Rich Townsend wrote in message ...
>robin wrote:
>
>Aren't you assuming that the program is F9X? From the fixed formatting, it looks
>more like F77

"function evaluateinput(str1) result(string)"
looks like Fortran 90 or later to me.

> --- and thus the compiler will barf if you put in CONTAINS and ==.

Sponsored Links