Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

indentation - unbalanced parentheses


Hi!
I wanted to try writing program using fortran, and I just copied code.
but compiling it I get following error:

pgf90 -fast -I/opt/scali/include  -c -o parallel_mv.o parallel_mv.f
PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 70)
PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 71)

I have gone thought code several times but haven't understood what is
problem? I hope you can help me!

       PROGRAM parallel_mv
                ! global arrays
                real, dimension(16,16) :: a
                real, dimension(16) :: b,y
                ! variables for BLACS initialization
                !and processor grid creation
                integer iam,nprocs,ictxt,nprow,npcol,myrow,mycol
                !variables needed for distributing global
                !arrays across the proc grid
                integer desca(9), descb(9),descy(9),m,n,mb,nb,rsrc,csrc
                integer llda,lldb,info
                ! local arrays
                real, dimension(8,8) :: la
                real, dimension(8) :: lb,ly
                !Initializing the BLACS library (STEP 2)
                call blacs_pinfo (iam,nprocs)
                call blacs_get(-1,0,ictxt)
                !Creating and using the processor grid (STEP 3)
                nprow=2; npcol=2
                call blacs_gridinit(ictxt,'r',nprow,npcol)
                call blacs_gridinfo(ictxt,nprow,npcol,myrow,mycol)
                m=16; n=16
                mb=8; nb=8
                rsrc=0; csrc=0
                llda=8
                call descinit(desca,m,n,mb,nb,rsrc,csrc,ictxt,llda,info)
                n=1; nb=1; lldb=8
                call descinit(descb,m,n,mb,nb,rsrc,csrc,ictxt,lldb,info)
                call descinit(descy,m,n,mb,nb,rsrc,csrc,ictxt,lldb,info)
                ! Filling the global arrays A,b
                open(unit=12,file="a.data")
                read(12,*) a
                open(unit=13,file="b.data")
                read(13,*) b
                ! Each processor fills in its
                !local arrays with correct elements

                ! from the global arrays (STEP 5)
                if(myrow.eq.0.and.mycol.eq.0) then
                        do i_loc=1,8
                                do j_loc=1,8
                                        la(i_loc,j_loc)=a(i_loc,j_loc)
                                end do
                                lb(i_loc)=b(i_loc)
                        end do
                end if

                if(myrow.eq.1.and.mycol.eq.0) then
                        do i_loc=1,8
                                do j_loc=1,8
                                        la(i_loc,j_loc)=a(i_loc+llda,j_loc)
                                end do
                                lb(i_loc)=b(i_loc+lldb)
                        end do
                end if

                if(myrow.eq.0.and.mycol.eq.1) then
                        do i_loc=1,8
                                do j_loc=1,8
                                        la(i_loc,j_loc)=a(i_loc,j_loc+llda)
                                end do
                        end do
                end if

                if(myrow.eq.1.and.mycol.eq.1) then              
                        do i_loc=1,8
                                do j_loc=1,8
                                        la(i_loc,j_loc)=a(i_loc+llda,j_loc+llda)
                                end do
                        end do
                end if
                ! Call the ScaLAPACK routine (STEP 6)
        n=16
        call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &
                                                                                ly,l,l,descy,l)
                        ! Each processor prints out its part of the product
                        !vector y (STEP 7)
                         !!!
                !here is my indentation problem begins
                if(myrow.eq.0.and.mycol.eq.0) then
                        do i=1,8
                                print *,'PE:',myrow,mycol,' y(',i,')=',ly(i)
                        end do
                end if

                if(myrow.eq.1.and.mycol.eq.0) then
                        do i=1,8
                                print *,'PE:',myrow,mycol,' y(',i+lldb,')=',ly(i)
                        end do
                end if
                ! Release the proc grid and BLACS library (STEP 8)
                call blacs_gridexit(ictxt)
                call blacs_exit(0)
        STOP
        END

thank you very much!

Carramba wrote:
> Hi!
> I wanted to try writing program using fortran, and I just copied code.
> but compiling it I get following error:

> pgf90 -fast -I/opt/scali/include  -c -o parallel_mv.o parallel_mv.f
> PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 70)
> PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 71)

> I have gone thought code several times but haven't understood what is
> problem? I hope you can help me!

It looks like your program is indented enough to work as fixed form
code, except that it has a continuation (which doesn't look like 70, 71)
using free form continuation methods.  Be sure to compile it
as free form source.

-- glen

The Portland Group Fortran 90 compiler (pgf90) uses the file suffix to
choose between fixed and free format.  The ".f" format means fixed
format so characters are only read up to column 72.  I have not counted
it out but the error message seems to say that on line 70 a parentheses
is missing, probably in column 73 or greater.  You will not see this
error unless you count out the columns.  To use the free format that the
code seems to be written in rename the file to parallel_mv.f90 and
compile it again.

Bob Stryk

Bob Stryk skrev:

Thank you!
I have tried to rename, but then my compiler doesn't find this file...

makefile

FC     = pgf90
FFLAGS = -fast -I/opt/scali/include
LIBS = -L/opt/scali/lib -lfmpi -lmpi -lpthread
PARLIBS =  -lscalapack  -lblacsF77init -lblacs -lblacsCinit

APPOBJ = parallel_mv.o

APP = parallel_mv

$(APP): $(APPOBJ)
        $(FC) $(FFLAGS) -o $(APP) $(APPOBJ) $PARLIBS $(LIBS)

clean:
        /bin/rm -f $(APP) $(APPOBJ)

What flag for compiler should I use?

You've got a rule for linking, but not a rule for compiling.

Mine looks like this:

%o: %f90
        ${FC} ${F90FLAGS} ${INCS} ${OPTFLAGS} $<

On Wed, 16 May 2007 09:05:34 -0800, glen herrmannsfeldt <g@ugcs.caltech.edu>
 wrote in <79mdnSNZh9LettbbnZ2dnUVZ_uejn@comcast.com>:

> Carramba wrote:
>> I wanted to try writing program using fortran, and I just copied code.
>> but compiling it I get following error:
>> pgf90 -fast -I/opt/scali/include  -c -o parallel_mv.o parallel_mv.f
>> PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 70)
>> PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 71)
>> I have gone thought code several times but haven't understood what is
>> problem? I hope you can help me!
> It looks like your program is indented enough to work as fixed form
> code, except that it has a continuation (which doesn't look like 70, 71)
> using free form continuation methods.  Be sure to compile it
> as free form source.

        I thought the problem was a continuation to a blank line, which
doesn't look like newsreader wrapping:
===
        call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &

        ly,l,l,descy,l)
===

--
Ivan Reid, School of Engineering & Design, _____________  CMS Collaboration,
Brunel University.    Ivan.Reid@[brunel.ac.uk|cern.ch]    Room 40-1-B12, CERN
        KotPT -- "for stupidity above and beyond the call of duty".

Dr Ivan D. Reid wrote:
...

> I thought the problem was a continuation to a blank line, which
> doesn't look like newsreader wrapping:
> ===
>         call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &

>         ly,l,l,descy,l)
> ===

Fortran is rather peculiar in that it permits blank lines (and
lines containing only comments) in the middle of a continuation.

--
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

Dr Ivan D. Reid skrev:

> On Wed, 16 May 2007 09:05:34 -0800, glen herrmannsfeldt <g@ugcs.caltech.edu>
>  wrote in <79mdnSNZh9LettbbnZ2dnUVZ_uejn@comcast.com>:
>> Carramba wrote:

>    I thought the problem was a continuation to a blank line, which
> doesn't look like newsreader wrapping:
> ===
>         call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &

>         ly,l,l,descy,l)
> ===

this is not code wrap..
the actual line is
call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, ly,l,l,descy,l)

but gets  truncated by fortran compiler..
so I thought that adding '&' and braking line would solve this but I
still get complains about parenthesis

James Giles wrote:
> Dr Ivan D. Reid wrote:
> ...

>>I thought the problem was a continuation to a blank line, which
>>doesn't look like newsreader wrapping:
>>        call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &
>>        ly,l,l,descy,l)

In my news reader there is no blank line between these statements,
but there are a few others in the program.  If I remove the blank
lines the above become lines 70 and 71, as in the error.

I believe it is being compiled as fixed form, with the & not in
column 6.

 > Fortran is rather peculiar in that it permits blank lines (and
 > lines containing only comments) in the middle of a continuation.

I don't believe it always did that.  Blank lines were not even
allowed in Fortran 66.  Also comments after the END statement
would generate errors such as END statement missing, and at link
time duplicate MAIN program.  I believe that has been changed.

-- glen

Hello,

glen herrmannsfeldt wrote:

<snip discussion>

> I don't believe it always did that.  Blank lines were not even
> allowed in Fortran 66.  Also comments after the END statement
> would generate errors such as END statement missing, and at link
> time duplicate MAIN program.  I believe that has been changed.

Yes, one of the little things of f03 was to fix
blank lines after an end statement are allowed with no effect.

--

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Wed, 16 May 2007 20:47:51 +0200, Carramba <u@example.net>
 wrote in <464b4dea$0$14077$cc7c7@news.luth.se>:

> Dr Ivan D. Reid skrev:
>>        I thought the problem was a continuation to a blank line, which
>> doesn't look like newsreader wrapping:
>> ===
>>         call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &

>>         ly,l,l,descy,l)
>> ===
> this is not code wrap..
> the actual line is
> call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, ly,l,l,descy,l)
> but gets  truncated by fortran compiler..
> so I thought that adding '&' and braking line would solve this but I
> still get complains about parenthesis

        As others have said, that's not how to continue in fixed-format.
You need 5 spaces and a non-blank (and non-zero?) character in column 6.
Some compilers accept a non-alphabetic character after a tab, but don't
count on its portability.

--
Ivan Reid, School of Engineering & Design, _____________  CMS Collaboration,
Brunel University.    Ivan.Reid@[brunel.ac.uk|cern.ch]    Room 40-1-B12, CERN
        KotPT -- "for stupidity above and beyond the call of duty".

Dan Nagle wrote:

(snip)

>> Also comments after the END statement
>> would generate errors such as END statement missing, and at link
>> time duplicate MAIN program.  I believe that has been changed.
> Yes, one of the little things of f03 was to fix
> blank lines after an end statement are allowed with no effect.

I used to work on a program that had nice comments at the beginning
and end of each subroutine to make them easy to see:

C ********************  SUBROUTINE XYZ  *****************************

and

C ********************* END SUBROUTINE XYZ **************************

When I divided it into separate files, all the END comments were after
the END statement of each subroutine.  Moving them just before the
END wasn't so bad.

-- glen

glen herrmannsfeldt wrote:
> James Giles wrote:
...
>  > Fortran is rather peculiar in that it permits blank lines (and
>  > lines containing only comments) in the middle of a continuation.

> I don't believe it always did that.  Blank lines were not even
> allowed in Fortran 66.  [...

But comment lines were.  And beginning with F77 blank lines
are considered comment lines.  Comment lines between a part
of a statement and its continuation have always been allowed.

> ...]  Also comments after the END statement
> would generate errors such as END statement missing, and at link
> time duplicate MAIN program.  I believe that has been changed.

Conventional implementations have always assumed that
comments have to belong to *some* program unit.  In the past
they have always been assumed to be part ot the program unit
that contains the next statement (or part thereof).  The F2003
standard changed that.  Instead of saying that a comment line
may preceed the first statement of a program unit, it now says
that a comment line may preceed the first statement or follow
the last statement of a program unit.  This can leave ambiguous
which program unit a comment belongs to.  But, since it's
only relevant if the compiler is outputting a listing, and few
people bother with listings any more even if the compiler
is capable of making them, this is not much of an issue.

So, an F2003 implementation shouldn't have any difficulty
with trailing comments.

--
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

In article <464b24b6$0$13493$cc7c7@news.luth.se>,

Carramba  <u@example.net> wrote:
>Hi!
>I wanted to try writing program using fortran, and I just copied code.
>but compiling it I get following error:

>pgf90 -fast -I/opt/scali/include  -c -o parallel_mv.o parallel_mv.f
>PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 70)
>PGF90-S-0023-Syntax error - unbalanced parentheses (parallel_mv.f: 71)

>I have gone thought code several times but haven't understood what is
>problem? I hope you can help me!

Diagnosis: Your compiler probably assumes you are using fixed source
form (that's what program file names ending in .f normally imply) so
your Fortran code must stop on or before space 72 on every line. If so,
a closing parenthesis, i.e. ), after space 72 would cause your trouble.
But you have some & at the ends of long lines so you presumably think
you are using free source form.

Treatment: Change the program file name to end in .f90 or discover and
use your compiler's option to enforce free form for files ending in .f

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

               ! Call the ScaLAPACK routine (STEP 6)
        n=16
        call psgemv('n',m,n,1.0,la,l,l,desca,lb,l,l,descb,1,0.0, &

ly,l,l,descy,l)

I think the problem is in lines 2 through 4 of the above small section
of your program.
You seem to be using fixed format compilation with a compiler that
recognises "!" as an internal comment.
In which case line 2 and 3 start too early in the line and line three
is invalid because the continution symbol should be in column 6 of the
next line.
Line four is then isolated and lines three and four have unmatched
parantheses (lines 70 and 71 in the original, as the error messages
show)..

On May 16, 1:42 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:

> I don't believe it always did that.  Blank lines were not even
> allowed in Fortran 66.

They were allowed as initial lines.  Because FORTRAN 66 did not
allow empty statements, they had to be followed by continuation
lines.  I could cite the appropriate sentences from the FORTRAN 66
standard to substantiate my assertion, but the following statement
from Appendix A of the FORTRAN 77 standard is shorter:

    (1)  A line that contains only blank characters in columns
          1 through 72 is a comment line.  ANSI X3.9-1966
          allowed such a line to be the initial line of a statement.

Bob Corbett

Recently I encountered a similar situation...
A colleague of mine who is a moderately experienced C programmer was
in a college computer room as a teaching assistant. In his spare time
when the students were working on their assignments, he decided to try
out Fortran. Armed with only a single Fortran 90 book, he tried to
print "Hello world", but to no avail. He gave up after an hour. Of
course he was writing free form source and naming it hello.f ;-p.

Good thing he's an open minded fellow and was more amused than
offended by the experience. :-)

In retrospect, I think it would have been better if free source form
was designed to be mixed into fixed source form. After all, most other
Fortran 90 features can be mixed into existing 77 codes.

Say, simple rules for a "unified" source form:
1. "*" or "C" in column one indicates a comment line.
2. A line ending in "&" indicates continuation to the next.
3. For a line not part of a continuation by "&",  blanks in columns
one through five and a digit or a special symbol in column 6 indicates
a continuation of the previous line.

This set of rules is oversimplified, but even as it is it should be
able to read most "well written" fixed form and free form source
without need to specify which it is... Someone should have come up
with this twenty years ago.
--
Yasuki Arasaki

Arasaki <yasuki_aras@yahoo.co.jp> wrote:
> Say, simple rules for a "unified" source form:
> 1. "*" or "C" in column one indicates a comment line.
> 2. A line ending in "&" indicates continuation to the next.
> 3. For a line not part of a continuation by "&",  blanks in columns
> one through five and a digit or a special symbol in column 6 indicates
> a continuation of the previous line.

> This set of rules is oversimplified, but even as it is it should be
> able to read most "well written" fixed form and free form source
> without need to specify which it is... Someone should have come up
> with this twenty years ago.

You've missed the one thing that probably causes more problems in this
area than anything else, a major part of what free source form is about.
You seem to be concentrating on continuation lines, but those are
relatively rare in most code. How about the simpler issue of the
"regular" (non-continuation) lines.

Your scheme won't work unless the "free source form" code is indented to
at least column 7. The single biggest problem in this area comes from
the indentation issue. Even if you allowed unindented code, the special
treatment of columns 1 and 6 would cause problems even with experienced
users unless they indented their code. Change a variable name so that it
starts with C and the code stops working? No thanks. Or happen to have
the "wrong" character land in column 6? Also no thanks.

This looks like a non-starter to me.

Of course, it wouldn't go now anyway, as it is past history. But I don't
think it would have worked then either.

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

On May 17, 7:33 am, Arasaki <yasuki_aras@yahoo.co.jp> wrote:

> Recently I encountered a similar situation...
> A colleague of mine who is a moderately experienced C programmer was
> in a college computer room as a teaching assistant. In his spare time
> when the students were working on their assignments, he decided to try
> out Fortran. Armed with only a single Fortran 90 book, he tried to
> print "Hello world", but to no avail. He gave up after an hour. Of
> course he was writing free form source and naming it hello.f ;-p.

The interpretation of .f is not mandated by the language standard. The
compiler is free to interpret it, ignore it, or look at the form of
the source file, or command line options, or console switches, etc.

This opens a can of worms that IMO is best left closed - what is the
meaning - if any - of blank spaces? Fixed and free format have very
different rules.

If the compiler conforms to a language standard which allows free
form, why use anything else for new code?

Otherwise, put old code in a module and comipile in fixed format if
need be.

"Arasaki" <yasuki_aras@yahoo.co.jp> wrote in message

news:1179401618.774292.48680@n59g2000hsh.googlegroups.com...

> In retrospect, I think it would have been better if free source form
> was designed to be mixed into fixed source form. After all, most other
> Fortran 90 features can be mixed into existing 77 codes.

> Say, simple rules for a "unified" source form:
> 1. "*" or "C" in column one indicates a comment line.
> 2. A line ending in "&" indicates continuation to the next.
> 3. For a line not part of a continuation by "&",  blanks in columns
> one through five and a digit or a special symbol in column 6 indicates
> a continuation of the previous line.

The two can be mixed by observing these rules (MR&C, pp353-354):

1. statement labels in columns 1 to 5 only, statements in 7 to 72 only;

2. treat blanks as significant;

3. use only ! to indicate comment (but not in column 6);

4. for a continued line place & in column 73, for a continuing line place &
in column 6.

Of course, using free form exclusively is far better.

Regards,

Mike Metcalf

On May 17, 7:33 am, Arasaki <yasuki_aras@yahoo.co.jp> wrote:

I disagree. Variables can be begin with "C", and in free source form
the code

C = 2*B

should not have a different meaning depending on whether a space is
inserted at the beginning. Nor should

x = 2 &
* y

have a different meaning if a space is inserted in front of the *.

Metcalf, Reid, and Cohen in Appendix B of the book "Fortran 95/2003
Explained" explain how code can be written to be valid fixed and free
source code:

(1) confine statement labels to positions 1 to 5 and statements to
positions 7 to 72.
(2) treat blanks as being significant.
(3) use ! to indicate a comment (but not in position 6).
(4) for continued statements, place an ampersand in both position 73
of a continued line and position 5 of a continuing line.

I don't follow these guidelines because I don't care if my free source
form code is also valid fixed source.

Beliavsky <beliav@aol.com> wrote:
> Metcalf, Reid, and Cohen in Appendix B of the book "Fortran 95/2003
> Explained" explain how code can be written to be valid fixed and free
> source code:
...
> I don't follow these guidelines because I don't care if my free source
> form code is also valid fixed source.

Those rules are mostly useful when you are writing an include file that
might be used by other people using either source form. I don't follow
the rules either, but that's when oen is most likely to.

--
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:

(snip on rules that allow source to be read as either fixed or free form)

> Those rules are mostly useful when you are writing an include file that
> might be used by other people using either source form. I don't follow
> the rules either, but that's when oen is most likely to.

It would seem like extra work to write that way, but not so hard to
have a program do it.  It shouldn't be hard to write a program to
convert free form to that style.  Also, for fixed form with space
between and no space inside keywords.

-- glen

Arasaki wrote:

...

> In retrospect, I think it would have been better if free source form
> was designed to be mixed into fixed source form. After all, most other
> Fortran 90 features can be mixed into existing 77 codes.

It would even have been better if source form were selected
by a declaration or assertion within the source itself.  Then, as
a matter of habit, people would simply begin each source file
with the appropriate directive.  Using the style of the LWG
Fortran proposal (1982):

      Option(freeform)

Where you put the OPTION statement in column 7 or beyond
(so that it doesn't matter which source form the compiler defaults
to).  The LWG proposal didn't have free source form, but it did
have "compiler directives" which used the OPTION keyword.

--
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

James Giles wrote:

(snip)

> It would even have been better if source form were selected
> by a declaration or assertion within the source itself.  Then, as
> a matter of habit, people would simply begin each source file
> with the appropriate directive.  Using the style of the LWG
> Fortran proposal (1982):
>       Option(freeform)
> Where you put the OPTION statement in column 7 or beyond

It could have even been before column 7, though maybe not
starting in column 6.  Since it doesn't start with C or a
digit there is no ambiguity.  Earlier compilers wouldn't
recognize it in any case.

Would you then allow one to switch form in the middle of
a program unit?

-- glen

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc