Home > Archive > Fortran > September 2004 > "14 % 8" for example...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"14 % 8" for example...
|
|
| kepler 2004-09-27, 9:01 pm |
| Hi,
I'm trying to translate a piece of fortran code into Perl. I was able to
understand all the functions in the code, except for this one; what
operation is c = a % b ? Is it the same of int(a/b)?
Please - someone - answer as soon as possible.
Best regards,
Kepler
| |
| Dick Hendrickson 2004-09-27, 9:01 pm |
|
kepler wrote:
> Hi,
>
> I'm trying to translate a piece of fortran code into Perl. I was able to
> understand all the functions in the code, except for this one; what
> operation is c = a % b ? Is it the same of int(a/b)?
No, it's not an arithmetic operation, it's a structure
selector. Someplace you'll find "b" declared with
something like
type (some_type_name) :: b
and if you look in the definition of some_type_name
you'll see that it has a component named "c".
The syntax selects that component.
Dick Hendrickson
>
> Please - someone - answer as soon as possible.
>
> Best regards,
>
> Kepler
>
| |
| Dick Hendrickson 2004-09-27, 9:01 pm |
| Sorry, I've got the b's and c's in the wrong order ;(
Dick Hendrickson wrote:
>
>
> kepler wrote:
>
>
>
> No, it's not an arithmetic operation, it's a structure
> selector. Someplace you'll find "b" declared with
> something like
> type (some_type_name) :: b
That should be a
> and if you look in the definition of some_type_name
> you'll see that it has a component named "c".
That should be b
> The syntax selects that component.
>
> Dick Hendrickson
>
>
| |
| Richard E Maine 2004-09-27, 9:01 pm |
| "kepler" <ruifernandes@tvtel.pt> writes:
> I'm trying to translate a piece of fortran code into Perl. I was able to
> understand all the functions in the code, except for this one; what
> operation is c = a % b ? Is it the same of int(a/b)?
If the code is actually Fortran, then a%b means the component b of the
derived type object (structure) a. However....
1. I find it hard to imagine that you would understand everything other
than this in a Fortran code that uses it. That would mean that
you would have understood the derived type definition and declarations.
Sort of hard to understand derived type definitions and declarations
without understanding at least something about how one would use a
derived type (and a%b is about as basic as such usage gets).
2. Neither a nor b can be numbers - they are names. Although you use
names in the text of the posting, you use numbers in the subject
line.
The above 2 points make me suspicious that what you have might be some
vendor extension to F77 instead of being standard Fortran of any
variety. If that's the case, then I have no idea what it means.
--
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
| |
| Janne Blomqvist 2004-09-27, 9:01 pm |
| In article <m1hdpj8mjx.fsf@MLMCE0000L22801.local>, Richard E Maine wrote:
> "kepler" <ruifernandes@tvtel.pt> writes:
>
>
> If the code is actually Fortran, then a%b means the component b of the
> derived type object (structure) a. However....
>
> 1. I find it hard to imagine that you would understand everything other
> than this in a Fortran code that uses it. That would mean that
> you would have understood the derived type definition and declarations.
> Sort of hard to understand derived type definitions and declarations
> without understanding at least something about how one would use a
> derived type (and a%b is about as basic as such usage gets).
>
> 2. Neither a nor b can be numbers - they are names. Although you use
> names in the text of the posting, you use numbers in the subject
> line.
>
> The above 2 points make me suspicious that what you have might be some
> vendor extension to F77 instead of being standard Fortran of any
> variety. If that's the case, then I have no idea what it means.
Some (popular) languages use "a % b" to mean modulo(a,b), i.e. the
remainder of a/b. Perhaps some vendor decided to borrow this from C?
--
Janne Blomqvist
| |
| Janne Blomqvist 2004-09-27, 9:01 pm |
| In article <m1hdpj8mjx.fsf@MLMCE0000L22801.local>, Richard E Maine wrote:
> "kepler" <ruifernandes@tvtel.pt> writes:
>
>
> If the code is actually Fortran, then a%b means the component b of the
> derived type object (structure) a. However....
>
> 1. I find it hard to imagine that you would understand everything other
> than this in a Fortran code that uses it. That would mean that
> you would have understood the derived type definition and declarations.
> Sort of hard to understand derived type definitions and declarations
> without understanding at least something about how one would use a
> derived type (and a%b is about as basic as such usage gets).
>
> 2. Neither a nor b can be numbers - they are names. Although you use
> names in the text of the posting, you use numbers in the subject
> line.
>
> The above 2 points make me suspicious that what you have might be some
> vendor extension to F77 instead of being standard Fortran of any
> variety. If that's the case, then I have no idea what it means.
Some (popular) languages use "a % b" to mean mod(a,b), i.e. the
remainder of a/b. Perhaps some vendor decided to borrow this from C?
--
Janne Blomqvist
| |
| glen herrmannsfeldt 2004-09-27, 9:01 pm |
|
Richard E Maine wrote:
> "kepler" <ruifernandes@tvtel.pt> writes:
[color=darkred]
> If the code is actually Fortran, then a%b means the component b of the
> derived type object (structure) a. However....
> 1. I find it hard to imagine that you would understand everything other
> than this in a Fortran code that uses it. That would mean that
> you would have understood the derived type definition and declarations.
> Sort of hard to understand derived type definitions and declarations
> without understanding at least something about how one would use a
> derived type (and a%b is about as basic as such usage gets).
I might believe it. Lately I have been working on a project in verilog,
but sometimes I have to read files in VHDL. I don't know VHDL,
but usually I can figure out the important part, the equivalent
of the executable statements. I can imagine reading Fortran without
knowing the meaning of the declaration statements. Fortran is similar
enough to some other languages that it wouldn't take too long.
If you are used to Fortran and don't know Perl, it would probably be
about the same level of understanding.
-- glen
| |
|
| Janne Blomqvist wrote:
>
> Some (popular) languages use "a % b" to mean mod(a,b), i.e. the
> remainder of a/b. Perhaps some vendor decided to borrow this from C?
No, this syntactic eyesore was decided on by the misguided committee
even though all principal vendors supported (and still do) the *dot*.
| |
| glen herrmannsfeldt 2004-09-29, 5:00 am |
| bv wrote:
> Janne Blomqvist wrote:
[color=darkred]
> No, this syntactic eyesore was decided on by the misguided committee
> even though all principal vendors supported (and still do) the *dot*.
I was guessing that it would be ambiguous with certain operators
that are dot delimited.
X=A.GE.B
-- glen
| |
| Jan Vorbrüggen 2004-09-29, 5:00 am |
| >> No, this syntactic eyesore was decided on by the misguided committee
> I was guessing that it would be ambiguous with certain operators
> that are dot delimited.
Yes. And even Steve & Co., who had been supporting this extension for two
decades now at least, had to fix a bug in the compiler's context-dependant
guessing of the dot's meaning quite recently. But all that has been explained
to bv multiple times in the past, and he just refuses to acknowledge reality.
Jan
| |
|
| glen herrmannsfeldt wrote:
>
> I was guessing that it would be ambiguous with certain operators
> that are dot delimited.
>
> X=A.GE.B
Considering the ways how ADA could parse such an expression it would
seem incredulous that an old timer like Fortran could stumble on its own
*keyword*.
| |
| James Giles 2004-09-30, 8:59 pm |
| bv wrote:
> glen herrmannsfeldt wrote:
>
> Considering the ways how ADA could parse such an expression it would
> seem incredulous that an old timer like Fortran could stumble on its own
> *keyword*.
First, it's not a keyword, it's an intrinsic operator.
Second, even if it was a keyword, keywords are not reserved
in Fortran.
Both intrinsic operators and keywords must be use in ways consistent
with the rules of Fortran or they're likely to be ambiguous or just
wrong. The rules of Fortran don't permit the above to be interpreted
as a subobject name. Implementations the permit such extensions
should do so carefully and not misinterpret the above. I wouldn't
use the extension anyway. Nor would I recommend that anyone
else do so.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|
|
|
|
|