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

Salford Fortran - Double Precision product


Hi everybody. I am recently new in fortran programing, and I have
experienced the first problems using Salford Fortran 95 for Win32 (Plato
v2.21). I solved all of them but the double precision product.

The following piece of code is not working as it should:

       program euclidean_norm
       double precision x(2)
       x(1) = 2.70753335146
       x(2) = 1.52316362648
       write(*,*)x
       write(*,*)norm(x)
       end

       double precision function norm(x)
       double precision x(2)
       norma = sqrt(x(1)**2+x(2)**2)
       end

Furthermore, when using this code in a larger program, I get my programs
haged when executing some write() after calling this function.

I have tried several workarounds like using any of these:
2.0d+0 instead of 2
**0.5 instead of sqrt()
etc...
but I still get serveral different errors (including overflows) when
computing the euclidean norm in these ways.

Is there any intrinsinc funcion to compute the norm, or a different way to
get it using double precision?

Many thanks in advance. If you need further data, don't hesitate to ask, as
I am a newbie and thus I don't know if I provided enough information.

Jorge

On May 25, 11:50 am, "Jorge Lopez" <n@telling.com> wrote:

Because you create the function norm as external, you need to notify
the main program that it returns a double precision result:
double precision,external:: norm

Alternatives (recommended) are making the function a module procedure
or internal to the program.

Jorge Lopez <n@telling.com> wrote:
> Hi everybody. I am recently new in fortran programing, and I have
> experienced the first problems using Salford Fortran 95 for Win32 (Plato
> v2.21). I solved all of them but the double precision product.

> The following piece of code is not working as it should:

>       program euclidean_norm
>       double precision x(2)

As highegg already said, you should add here:

        double precision,external:: norm

The "external" attribute is not strictly needed, but recommended. Your
program will probably work then, but will not give you the precision
you probably expect.

>       x(1) = 2.70753335146
>       x(2) = 1.52316362648

2.70753335146 and 1.52316362648 are REAL (not DOUBLE PRECISION)
constants. Use 2.70753335146d0 and 1.52316362648d0 instead.

[...]

--
Klaus Wacker              klaus.wac@udo.edu
Experimentelle Physik V   http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund     Tel.: +49 231 755 3587
D-44221 Dortmund          Fax:  +49 231 755 4547

Jorge Lopez wrote:

> Is there any intrinsinc funcion to compute the norm, or a different way to
> get it using double precision?

For 2-D, a simple trick is
Abs (Cmplx ( x(1), x(2), Kind(0.0d0)))

Jorge Lopez wrote:
>        double precision function norm(x)
>        double precision x(2)
>        norma = sqrt(x(1)**2+x(2)**2)
>        end

Others already mentioned a few problems. I would like to add that your
function is named "norm" but then you assign a value to "norma". Always
using "implicit none" seems useful to me.

Michel Olagnon wrote:
> Jorge Lopez wrote:
>> Is there any intrinsinc funcion to compute the norm, or a different
>> way to get it using double precision?
> For 2-D, a simple trick is
> Abs (Cmplx ( x(1), x(2), Kind(0.0d0)))

That should avoid the overflow problem for larger
x(1) and x(2), also.  It should implement something
similar to:

a=max(x(1),x(2))
b=min(x(2),x(2))
norm=a*sqrt((b/a)**2+1)

probably with additional protection against underflow
in b/a.  In cases that don't underflow/overflow it
is probably faster to do it the obvious way.

-- glen

In article <f36bjf$si@nsnmpen2-gest.nuria.telefonica-data.net>,
 "Jorge Lopez" <n@telling.com> wrote:

> Is there any intrinsinc funcion to compute the norm, or a different way to
> get it using double precision?

Normally for vectors of arbitrary length you might write something
like

   sqrt(dot_product(x,x))

but for vectors of length 2 it isn't clear if this is simpler or
more complicated.  Another expressions might be

   sqrt(sum(x*x))

which might be good for short vectors, but for long vectors, this
results (probably) in the need for the compiler to allocate a large
temporary work vector which isn't really necessary to compute the
final result.  If you have the blas, then instead of your norm()
function you could use

   dnrm2(2,x,1)

As others have suggested, you should use "implicit none" in all of
your programs.  This catches at compile time many common mistakes.

$.02 -Ron Shepard

On 25 mei, 14:08, Daniel Snouck <dsno@yahoo.nospam> wrote:

> Jorge Lopez wrote:
> >        double precision function norm(x)
> >        double precision x(2)
> >        norma = sqrt(x(1)**2+x(2)**2)
> >        end

> Others already mentioned a few problems. I would like to add that your
> function is named "norm" but then you assign a value to "norma". Always
> using "implicit none" seems useful to me.

Indeed! It is all too easy to make mistakes in variable names that do
get
flagged by the compiler.

Though in this case, the compiler should have warned (or most would
have warned)
that the function does not receive a value.

Regards,

Arjen

"Arjen Markus" <arjen.mar@wldelft.nl> escribi en el mensaje
news:1180104207.916207.138220@g4g2000hsf.googlegroups.com...

Thank you for your reply. The naming error was made as I forgot to translate
the Spanish "norma" for "norm", but I tried the right code in the compiler
and
didn't worked. Now my problem is fixed, thanks to the several comments and
solution provided. Thanks for yours!
Wow! It's great to have my problem solved in a record time.
It was so simple and was so lost... Thank you all for your
replies and help. I really appreciate them, and I could finally
fix my problem. I won't forget!

"Klaus Wacker" <wac@physik.uni-dortmund.de> escribi en el mensaje
news:f36hup$9pr$1@nx6.HRZ.Uni-Dortmund.DE...

That's another thing I forgot to keep in mind. Thanks.

"Arjen Markus" <arjen.mar@wldelft.nl> wrote in message

news:1180104207.916207.138220@g4g2000hsf.googlegroups.com...

The error messages that FTN95 produces are:

    NO ERRORS  [<EUCLIDEAN_NORM> FTN95/Win32 v4.9.0]
0011)        norma = sqrt(x(1)**2+x(2)**2)
WARNING - Variable NORMA has been given a value but never used
0009)        double precision function norm(x)
WARNING - The result of FUNCTION NORM has never been set
    NO ERRORS, 2 WARNINGS  [<NORM> FTN95/Win32 v4.9.0]

The rather older FTN77 produces this:

    NO ERRORS  [<EUCLIDEAN_NORM>FTN77 Ver 4.03]
0012)        end
WARNING - NORM has not been given an initial value (see -undef and
-only_undef options)
    NO ERRORS,1 WARNINGS  [<NORM>FTN77 Ver 4.03]

Adding IMPLICIT NONE to the offending function is not particularly helpful
in
tracking down the root cause in this situation, viz.

    NO ERRORS  [<EUCLIDEAN_NORM> FTN95/Win32 v4.9.0]
0012)        norma = sqrt(x(1)**2+x(2)**2)
WARNING - Variable NORMA has been given a value but never used
0009)        double precision function norm(x)
WARNING - The result of FUNCTION NORM has never been set
0012)        norma = sqrt(x(1)**2+x(2)**2)
*** NORMA must appear in a type declaration because IMPLICIT NONE has been
    used
    1 ERROR, 2 WARNINGS  [<NORM> FTN95/Win32 v4.9.0]
*** Compilation failed

... although it stops compilation in its tracks, which might be helpful in
some cases.

E

Edward N Bromhead <edward.bromh@deletethisbitbinternet.com> wrote:

> The error messages that FTN95 produces are:

>     NO ERRORS  [<EUCLIDEAN_NORM> FTN95/Win32 v4.9.0]
> 0011)        norma = sqrt(x(1)**2+x(2)**2)
> WARNING - Variable NORMA has been given a value but never used
> 0009)        double precision function norm(x)
> WARNING - The result of FUNCTION NORM has never been set

That seems pretty helpful to me. let's see... NORMA is given a value
that is never used, but NORM is never given a value. I don't think it
requires a tremendous leap of intuition to make the connection there.
There is only so far one can reasonably expect a compiler to be able to
go in diagnosis. Seems to me this compiler has gone that far in this
case.

> The rather older FTN77 produces this:

[just a warning about norm; nothing about norma]

> Adding IMPLICIT NONE to the offending function is not particularly helpful
> in tracking down the root cause in this situation, viz.

>     NO ERRORS  [<EUCLIDEAN_NORM> FTN95/Win32 v4.9.0]
> 0012)        norma = sqrt(x(1)**2+x(2)**2)
> WARNING - Variable NORMA has been given a value but never used
> 0009)        double precision function norm(x)
> WARNING - The result of FUNCTION NORM has never been set
> 0012)        norma = sqrt(x(1)**2+x(2)**2)
> *** NORMA must appear in a type declaration because IMPLICIT NONE has been
>     used

The only reason is isn't helpful is that FTN95 was pretty good about
already giving messages without it. It all but said what the problem
was. Hard to be much more helpful than that.

Many compilers would not have warned about the set-but-not-used problem.
You give one example of such a compiler (FTN77).  In that case the
implicit none would have added useful information. Furthermore, if the
function had been just slightly more complicated - say if norma was used
in the function (perhaps because its computation had two parts or was
iterative), then again there wouldn't have been a message about norms
without implicit none.

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

<snipped all previous discussion>

FTN95 pretty much tells you what the problem is .... and so it does. The OP
appears to be using
FTN95, and therefore must see the same error messages as I do (actually,
they are Warnings, as
FTN95 is still able to generate code  - dodgy code, but code nevertheless -
in this case). Just in
case the version of FTN95 the OP is using is not quite so explicit, I went
all the way back to FTN77,
and while that was less helpful, it was quite good enough. The
set-but-not-used and not-set-before-used
messages in FTN95 are about as good as one could ever expect to get, and it
seems to me that the main
problem is not reading the compiler output !

The message generated as a result of IMPLICIT NONE is not so helpful,
because a novice's first
response might be to go off and declare the type of NORMA (assuming the
fortran source code is
long and complicated, so that the penny didn't drop immediately, and not the
rather trivial example),
which wouldn't solve the problem, and indeed, is not the underlying problem.

I went back and tried FTN77 with and without IMPLICIT NONE (all compiler
options the same in both
cases, and are the defaults on installation). With it, the relevant error
messages are:

0012)        norma = sqrt(x(1)**2+x(2)**2)
*** NORMA has not appeared in a type specification statement (Type
INTEGER*2  assumed)
     1 ERRORS  [<NORM>FTN77 Ver 4.03]
*** Compilation failed

and without IMPLICIT NONE, the output was:

0012)        end
WARNING - NORM has not been given an initial value (see -undef and
-only_undef options)
    NO ERRORS,1 WARNINGS  [<NORM>FTN77 Ver 4.03]

I wasn't expecting this result - that the IMPLICIT NONE actually inhibits
the output of the more helpful
diagostic - but then it does have a result of ERROR rather than WARNING
severity, so one would
not be able to blithely go on to run the program, which is helpful in its
own way. (One can't be lulled into
believing erroneous results if there are no results!)

FTN95 does not have this side effect, and IMPLICIT NONE adds an extra
message.

I have long believed that a test compilation of a program using an
alternative compiler (or more than one)
is a very helpful thing to do, although I have to say that FTN95 is
extraordinarily good in finding source code
oddities - for example, it gives a Warning if it encounters a malformed DO
(like DO 10 I=1.99 where the
comma has been replaced by a full stop) and will highlight the potentially
unreferenced 10 CONTINUE or
the unreferenced END DO.

Of course, no matter how good the compiler diagnostics are, they turn out to
be useless if one never reads
them. They are easy enough to ignore if one is a native English speaker - it
must be worse if one is (like the OP)
programming, compiling and debugging in two foreign languages - Fortran AND
English.

EB

Edward N Bromhead <edward.bromh@deletethisbitbinternet.com> wrote:

> I wasn't expecting this result - that the IMPLICIT NONE actually inhibits
> the output of the more helpful diagostic

I also find that a bit surprising.

> but then it does have a result of ERROR rather than WARNING
> severity,

I suppose this might be related to why. Perhaps it doesn't directly
inhibit the warning, but stops compilation before the stage of analysis
where the warning is generated. One way to test that theory would be to
fix the error by adding a declaration and see if the warning then comes
up.

(I agree with your other comments. Well, I agree with this one too; I
just had an extra idea to add on this one.)

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

On 2007-05-27 13:08:22 -0300, nos@see.signature (Richard Maine) said:

Sometimes this shorter list of problems is deliberate as error cascades
can be rather intimidating to beginners. Remember that Salford is student
oriented debugging compiler.

After a while one learns to fix the first diagnostic and ignore the rest.

Think about the trouble that might arise from fixing the last one and then
trying to work up the list. I do not have fond memories of a system that
was line number oriented so one had to edit from the listing by working
up from the end to the front if one wanted the line numbers to be of any
use.

> Remember that Salford is student
> oriented debugging compiler.

I'm not entirely sure I agree with this ... it seems as fully-featured and
relatively
error free as anything else I've ever tried, if not more so. The DBOS
version of FTN77
had the fastest execute time of any PC Fortran when I compared it to a whole
bunch of
Fortran 77s, and it only got slower when Salford/Silverfrost threw their lot
in with
Windows .... (Compile time was also very short, notwithstanding the thorough
error reporting).

I can no longer check the Polyhedron benchmarks for myself, as FTN95 is the
only Fortran 90/95 compiler I have access to. However, it seems blazingly
fast to me
(my best example is the program that used to run in 3 hours back in 1973 now
runs in
under 1 sec - Elliot 4120 v. AMD Athlon 3200 - and now it graphs all the
results too).

> After a while one learns to fix the first diagnostic and ignore the rest.

> Think about the trouble that might arise from fixing the last one and then
> trying to work up the list. I do not have fond memories of a system that
> was line number oriented so one had to edit from the listing by working
> up from the end to the front if one wanted the line numbers to be of any
> use.

It is a good idea to work from the end backwards through the text in
correcting
anything where the errors are given by page and/or line number - PhD theses
annotated by examiners being one other such case, fortran source being
another!

EB

Edward N Bromhead <edward.bromh@deletethisbitbinternet.com> wrote:

> It is a good idea to work from the end backwards through the text in
> correcting
> anything where the errors are given by page and/or line number - PhD theses
> annotated by examiners being one other such case, fortran source being
> another!

Wow do I disagree with that! The benefit of that is just that it helps
finding the cited line number. But, as Gordon mentioned, a *FAR* larger
issue is that the errors near the end are likely to be meaningless. I've
helped peopel with things like that many times. Someone will be staring
at the last message and it will make no sense at all to tthem. They ask
for help. The problem is that the last message doesn't make any sense
unless you have seen the first message. There is likely an error in the
declarations or something like that. It is really only one error, but
generates hundreds of cascaded ones.

Being able to easily find the line number is pretty irrelevant if the
message about that line number is nonsense and the problem doesn't ie
there.

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

On 2007-05-28 11:39:21 -0300, "Edward N Bromhead"
<edward.bromh@deletethisbitbinternet.com> said:

>> Remember that Salford is student
>> oriented debugging compiler.

> I'm not entirely sure I agree with this ... it seems as fully-featured and
> relatively
> error free as anything else I've ever tried, if not more so. The DBOS
> version of FTN77
> had the fastest execute time of any PC Fortran when I compared it to a whole
> bunch of
> Fortran 77s, and it only got slower when Salford/Silverfrost threw their lot
> in with
> Windows .... (Compile time was also very short, notwithstanding the thorough
> error reporting).

Fast compilation and extensive error messages are a start for a debugging
compiler system. Add on the undefined variable checking and you have one
of the better debugging compilers. The previous example of such was WatFor
which also came out a university.

Being a student oriented debugging compilers simpley says that the relative
ordering of a couple priorities is not the same as for an optimizing
production code compiler. It is not a crticism. In fact it is a complement
when there are several others that do not share their ordering of priorities.

A student oriented compiler had better not miss any features as might be
tolerated on a production compiler if it promised great optimization.

> I can no longer check the Polyhedron benchmarks for myself, as FTN95 is the
> only Fortran 90/95 compiler I have access to. However, it seems blazingly
> fast to me
> (my best example is the program that used to run in 3 hours back in 1973 now
> runs in
> under 1 sec - Elliot 4120 v. AMD Athlon 3200 - and now it graphs all the
> results too).

Nothing like a little bit of good electrical engineering (i.e. a faster
clock) to make a program seem much faster. If you were doing a lot of
formatted output it takes just a bit of speed up in the conversion
routines to reinforce the speed up. And if that output is going to disk
the new disks are rather fast, especially if their buffers are larger than
your records. The lastest buffers are now 16M bytes on $100 disks!
Overlapped I/O is no longer just for big iron mainframes and workstations.

My take is that Salford execution times are not bad but they do not lead the
pack. It is rather hard to improve on basically clean code. That is why
the optimization phase of many compilers can be so bleeping!! slow. If
you have small modules then they have a much easier job but they then can
not find that last 0.01% either.

>> After a while one learns to fix the first diagnostic and ignore the rest.

>> Think about the trouble that might arise from fixing the last one and then
>> trying to work up the list. I do not have fond memories of a system that
>> was line number oriented so one had to edit from the listing by working
>> up from the end to the front if one wanted the line numbers to be of any
>> use.

> It is a good idea to work from the end backwards through the text in
> correcting
> anything where the errors are given by page and/or line number - PhD theses
> annotated by examiners being one other such case, fortran source being
> another!

Working from the back is how to treat line numbered text but it sucks on
programs where the only relevent diagnostics will be at the front. Sometimes
the error cascades can be really quite funny as long as you know to not take
then at all seriously.

"Richard Maine" <nos@see.signature> wrote in message

news:1hytc86.4lvlojn5tir7N%nospam@see.signature...

Your last para accepted, of course.

I had in mind a list of a handful of errors, each arising from a separate
cause at
widely separate points in the source code, not a cascade of errors all
arising
out of the same glitch.

Doesn't the sequence of such errors (in a cascade) depend
on how the compiler is programmed to order them, rather than on some
AI based rule as to the most probable cause?

The last error message is often the key one: "Missing END statement" ....

Eddie B

Edward N Bromhead wrote:
> "Richard Maine" <nos@see.signature> wrote in message

(snip)

>>Wow do I disagree with that! The benefit of that is just that it helps
>>finding the cited line number. But, as Gordon mentioned, a *FAR* larger
>>issue is that the errors near the end are likely to be meaningless.
(snip)
>>Being able to easily find the line number is pretty irrelevant if the
>>message about that line number is nonsense and the problem doesn't ie
>>there.

(snip)

> I had in mind a list of a handful of errors, each arising

 > from a separate cause at widely separate points in the source code,
 > not a cascade of errors all arising out of the same glitch.

> Doesn't the sequence of such errors (in a cascade) depend
> on how the compiler is programmed to order them, rather than on some
> AI based rule as to the most probable cause?

I would say that the answer is somewhere in between.

If you miss a declaration statement you often get many cascaded
errors off of that one.  Many others only affect one statement.
The best way may change as the program is being debugged, and
also how often one wants to recompile.

-- glen

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