Hello,

The posts on this group discussing an IDE for Fortran on Linux are all 
more than a few years old, if Google groups search isn't lying to me.

Eclipse is the up-and-coming IDE, and there is even a Fortran plugin 
(Photran) for it.  Not only that, Intel has written an adaptation for 
its Fortran compiler and donated it to the Photran project.

So far, so good.  As with most GUI's, everything that is supposed to be 
intuitively obvious on Eclipse has been mostly a mystery to me, with 
many missteps even to learn how to use it with the c plugin (cdt) for 
Eclipse.

To try to minimize similar bumbling with the Intel Fortran compiler 
(which otherwise I like very much), I've poked around a bit as to what 
people are using for a Fortran IDE, and in particular ifort, under Linux.

What I have read is not encouraging, with one discussion thread ending 
in, "Have you tried to use EMACS?"

One problem is that Real FORTRAN Programmers [tm] do not use IDE's. 
Maybe, since I was at least once a Real FORTRAN Programmer [tm], I'll 
end up going the same route.  For the moment, though, I'd like to find 
out if anyone has anything encouraging to say about a Linux IDE for 
Fortran that doesn't exclusively use the gcc toolchain.

Robert.

Robert Myers wrote:
> Hello,
>
> The posts on this group discussing an IDE for Fortran on Linux are all
> more than a few years old, if Google groups search isn't lying to me.
>
> Eclipse is the up-and-coming IDE, and there is even a Fortran plugin
> (Photran) for it. Not only that, Intel has written an adaptation for its
> Fortran compiler and donated it to the Photran project.
>
> So far, so good. As with most GUI's, everything that is supposed to be
> intuitively obvious on Eclipse has been mostly a mystery to me, with
> many missteps even to learn how to use it with the c plugin (cdt) for
> Eclipse.
>
> To try to minimize similar bumbling with the Intel Fortran compiler
> (which otherwise I like very much), I've poked around a bit as to what
> people are using for a Fortran IDE, and in particular ifort, under Linux.
>
> What I have read is not encouraging, with one discussion thread ending
> in, "Have you tried to use EMACS?"
>
> One problem is that Real FORTRAN Programmers [tm] do not use IDE's.
> Maybe, since I was at least once a Real FORTRAN Programmer [tm], I'll
> end up going the same route. For the moment, though, I'd like to find
> out if anyone has anything encouraging to say about a Linux IDE for
> Fortran that doesn't exclusively use the gcc toolchain.
>
> Robert.


I use Eclipse/Photran on Linux and find it quite usable, once you get 
through the setup which can be complex.

Anjuta can be used with almost any compiler if configured properly.

Incidentially, I also believe that Visual Studio runs on Linux with 
WINE, so you might be able to use the Intel Visual Fortran IDE (which is 
based on VS) with ifort, which works extremely well and is highly intuitive.

-- 
-- Philipp Emanuel Weidmann

Hi, my name is Mariano Mendez from Universidad Nacional de La Llata,
Argentina. I'm working on Photran project developing refactorings for
Fortran. I setup a web site www.fortranrefactoring.com.ar with a
catalog of these refactorings and a detailed description of it is
shown. I am interested in upgrading old fortran source code and in
refactorings for Fortran. I apreciate every comment on this subject.

Now, I'm working on :

 - Change Fixed-format to Free-Format refactoring: Allowing
programmers to change old fixed format files to free format .

 - Standarizing Iinput / Output : remove all format statement and
replacing it with character(len),parameter FmtString replacing all
format labels with format string.

*Philipp E. Weidmann* wrote:

> I use Eclipse/Photran on Linux and find it quite usable, once you get 
> through the setup which can be complex.

About one year ago I tried to setup Eclipse/Photran to have an IDE to
work with one Fortran project. Even if I used GFortran (which probably
is easier to setup), I couldn't find any guide that describes how to
use Eclipse for Fortran projects.
I have to admit that I never used Eclipse before. Do you have any useful
suggestion guide/howto/book for Eclipse and Photran?

-- 
Lurkos

Lurkos wrote:
> About one year ago I tried to setup Eclipse/Photran to have an IDE to
> work with one Fortran project. Even if I used GFortran (which probably
> is easier to setup), I couldn't find any guide that describes how to
> use Eclipse for Fortran projects.
> I have to admit that I never used Eclipse before. Do you have any useful
> suggestion guide/howto/book for Eclipse and Photran?
>


Well, as you probably know, the Photran installation guide and 
documentation is at 
http://wiki.eclipse.org/PTP/photran/documentation/photran6. I strongly 
recommend using the procedure described under "Installing on a Machine 
With Internet Access".

Once Photran is installed, all you need to do is create a new Fortran 
project, add files to it using the source tree and hit Ctrl+B (Build 
All). This should create your executable, at least with gfortran.

For existing projects not created using Eclipse, you can also try 
setting up a Makefile project. This way, you can use your existing 
makefile, with special modifications (and different compilers!) of your 
choice.


One thing that you must take care of with Eclipse is that you are using 
the right *perspective* (Fortran / Debug) when editing code. 
Perspectives are perhaps the single concept about Eclipse that is not 
entirely intuitive at first glance; you can read about the Fortran 
perspective at 
http://wiki.eclipse.org/PTP/photran/documentation/photran6#The_Fortran_Perspective.


Cheers!

-- 
-- Philipp Emanuel Weidmann

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTYXQs
IDEwIEp1bCAyMDEwIDE0OjQwOjIyIC0wNzAwIChQRFQpLCBtYXJpYW5vIG1lbmRleiB3cm90ZSBh
Ym91dA0KUmU6IElERSBmb3IgaWZvcnQgb24gTGludXg6DQoNCltzbmlwXQ0KPiAtIENoYW5nZSBG
aXhlZC1mb3JtYXQgdG8gRnJlZS1Gb3JtYXQgcmVmYWN0b3Jpbmc6IEFsbG93aW5nDQo+cHJvZ3Jh
bW1lcnMgdG8gY2hhbmdlIG9sZCBmaXhlZCBmb3JtYXQgZmlsZXMgdG8gZnJlZSBmb3JtYXQgLg0K
DQpJJ20gc3VyZSB0aGF0IGlzIGEgbmljZSBhZXN0aGV0aWMgZmVhdHVyZS4NCg0KPiAtIFN0YW5k
YXJpemluZyBJaW5wdXQgLyBPdXRwdXQgOiByZW1vdmUgYWxsIGZvcm1hdCBzdGF0ZW1lbnQgYW5k
DQo+cmVwbGFjaW5nIGl0IHdpdGggY2hhcmFjdGVyKGxlbikscGFyYW1ldGVyIEZtdFN0cmluZyBy
ZXBsYWNpbmcgYWxsDQo+Zm9ybWF0IGxhYmVscyB3aXRoIGZvcm1hdCBzdHJpbmcuDQoNClRoYXQg
aXMgY291bnRlci1wcm9kdWN0aXZlLg0KDQpRdWl0ZSBvZnRlbiBhIGZvcm1hdCBpcyB1c2VkIGlu
IG1hbnkgcGxhY2VzLCBzbyByZWZlcnJpbmcgdG8gYSBsYWJlbCBpcw0KdmVyeSBjb252ZW5pZW50
LCBiZWNhdXNlIGFueSBjaGFuZ2UgdG8gdGhlIGZvcm1hdCBjYW4gYmUgYXBwbGllZCBpbiBhDQpz
aW5nbGUgcGxhY2UgYW5kIGFsbCByZWZlcmVuY2VzIHBpY2sgaXQgdXAgYXV0b21hdGljYWxseS4g
IElmIHlvdSBwdXQNCmNoYXJhY3RlciBzdHJpbmcgZm9ybWF0cyBhbGwgb3ZlciB0aGUgcGxhY2Us
IGFueSBjaGFuZ2VzIG5lZWQgdG8gYmUNCmFwcGxpZWQgYWxsIG92ZXIgdGhlIHBsYWNlIHRvby4N
Ci0gLS0gDQpSZWdhcmRzLA0KDQpEYXZlICBbUkxVICMzMTQ0NjVdDQo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K
ZHdub29uQHNwYW10cmFwLm50bHdvcmxkLmNvbSAoRGF2aWQgVyBOb29uKQ0KUmVtb3ZlIHNwYW0g
dHJhcCB0byByZXBseSBieSBlLW1haWwuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tLS1CRUdJTiBQR1Ag
U0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuMTUgKEdOVS9MaW51eCkNCg0KaUVZ
RUFSRUNBQVlGQWt3NXdIa0FDZ2tROU1xYVVKUXcyTW1JRGdDZlQ0NHlsc3VETFZYNDFIeVEybnYr
TVJlbw0KUkhzQW4xYW5iT3NKOWJMOU9nYVIrL3V3eGNLc0twWHYNCj1velFnDQotLS0tLUVORCBQ
R1AgU0lHTkFUVVJFLS0tLS0NCg==

David W Noon wrote:
....
> On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about
> Re: IDE for ifort on Linux:
> 
....

>> - Standarizing Iinput / Output : remove all format statement and
>> replacing it with character(len),parameter FmtString replacing all
>> format labels with format string.
> 
> That is counter-productive.
> 
> Quite often a format is used in many places, so referring to a label is
> very convenient, because any change to the format can be applied in a
> single place and all references pick it up automatically.  If you put
> character string formats all over the place, any changes need to be
> applied all over the place too.
....

In addition to which it's not likely that the compiler would find 
duplicate strings this way and will thus store every copy in the 
executable instead of referring to one.

Agree this doesn't seem like _a_good_thing_ (tm) in general practice.

--

On 2010-07-11 10:40:45 -0300, dpb <none@non.net> said:

> David W Noon wrote:
> ...
>> On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about
>> Re: IDE for ifort on Linux:
>> 
> ...
> 
>>> - Standarizing Iinput / Output : remove all format statement and
>>> replacing it with character(len),parameter FmtString replacing all
>>> format labels with format string.
>> 
>> That is counter-productive.
>> 
>> Quite often a format is used in many places, so referring to a label is
>> very convenient, because any change to the format can be applied in a
>> single place and all references pick it up automatically.  If you put
>> character string formats all over the place, any changes need to be
>> applied all over the place too.
> ...

If there are formats for both a heading and the contents of a table the
formats can be placed together to make it easy to change both it the
details of how the table is to be presented ever change. If one wants
to use character strings they must be literals with the stated disadvantages,
variables with the problem that they will need to be defined or parameters
with the disadvantage that they will need to be in the declarations.

There are other examples of where grouping the formats makes good sense
even when the references are scattereed.

> In addition to which it's not likely that the compiler would find 
> duplicate strings this way and will thus store every copy in the 
> executable instead of referring to one.
> 
> Agree this doesn't seem like _a_good_thing_ (tm) in general practice.

On Jul 11, 6:00=A0am, David W Noon <dwn...@spamtrap.ntlworld.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 10 Jul 2010 14:40:22 -0700 (PDT), mariano mendez wrote about
> Re: IDE for ifort on Linux:
>
> [snip]
>
> > - Change Fixed-format to Free-Format refactoring: Allowing
> >programmers to change old fixed format files to free format .
>
> I'm sure that is a nice aesthetic feature.
>
> > - Standarizing Iinput / Output : remove all format statement and
> >replacing it with character(len),parameter FmtString replacing all
> >format labels with format string.
>
> That is counter-productive.
>
> Quite often a format is used in many places, so referring to a label is
> very convenient, because any change to the format can be applied in a
> single place and all references pick it up automatically. =A0If you put
> character string formats all over the place, any changes need to be
> applied all over the place too.

I believe that you may have misread what Mariano wrote.  I don't
see much difference in the following code:

program a
   call b
   call c
end program a

subroutine b
   real :: x =3D 42, y =3D 1066
   write(*, 10) x
   write(*, 10) y
10 format (ES12.4)
end subroutine b

subroutine c
   character(len=3D10), parameter :: fmt =3D '(ES12.4)'
   real :: x =3D 42, y =3D 1066
   write(*, fmt) x
   write(*, fmt) y
end subroutine c

It seems that you are interpreting Mariano's statement to
mean

subroutine c
   real :: x =3D 42, y =3D 1066
   write(*, '(ES12.4)') x
   write(*, '(ES12.4)') y
end subroutine c

which is not what he wrote.

--
steve

> subroutine c
> =A0 =A0character(len=3D10), parameter :: fmt =3D '(ES12.4)'
> =A0 =A0real :: x =3D 42, y =3D 1066
> =A0 =A0write(*, fmt) x
> =A0 =A0write(*, fmt) y
> end subroutine c
>

Steve this is exactly what I mean! intead of having :

subroutine b
   real :: x =3D 42, y =3D 1066
   write(*, 10) x
   write(*, 10) y
10 format (ES12.4)
end subroutine b

Mariano

> I have to admit that I never used Eclipse before. Do you have any useful
> suggestion guide/howto/book for Eclipse and Photran?
>
> --
> Lurkos

Lurkos: Please feel free to contact me for any question about Eclipse
or Photran.

Regards

Mariano

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTdW4s
IDExIEp1bCAyMDEwIDA5OjI1OjM2IC0wNzAwIChQRFQpLCBzdGV2ZSB3cm90ZSBhYm91dCBSZTog
SURFIGZvcg0KaWZvcnQgb24gTGludXg6DQoNCltzbmlwXQ0KPkkgYmVsaWV2ZSB0aGF0IHlvdSBt
YXkgaGF2ZSBtaXNyZWFkIHdoYXQgTWFyaWFubyB3cm90ZS4gIEkgZG9uJ3QNCj5zZWUgbXVjaCBk
aWZmZXJlbmNlIGluIHRoZSBmb2xsb3dpbmcgY29kZToNCj4NCj5wcm9ncmFtIGENCj4gICBjYWxs
IGINCj4gICBjYWxsIGMNCj5lbmQgcHJvZ3JhbSBhDQo+DQo+c3Vicm91dGluZSBiDQo+ICAgcmVh
bCA6OiB4ID0gNDIsIHkgPSAxMDY2DQo+ICAgd3JpdGUoKiwgMTApIHgNCj4gICB3cml0ZSgqLCAx
MCkgeQ0KPjEwIGZvcm1hdCAoRVMxMi40KQ0KPmVuZCBzdWJyb3V0aW5lIGINCj4NCj5zdWJyb3V0
aW5lIGMNCj4gICBjaGFyYWN0ZXIobGVuPTEwKSwgcGFyYW1ldGVyIDo6IGZtdCA9ICcoRVMxMi40
KScNCj4gICByZWFsIDo6IHggPSA0MiwgeSA9IDEwNjYNCj4gICB3cml0ZSgqLCBmbXQpIHgNCj4g
ICB3cml0ZSgqLCBmbXQpIHkNCj5lbmQgc3Vicm91dGluZSBjDQoNCkFoYS4gIFNvIHdoYXQgZG9l
cyB0aGlzIGJ1eSBtZT8NCi0gLS0gDQpSZWdhcmRzLA0KDQpEYXZlICBbUkxVICMzMTQ0NjVdDQo9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PQ0KZHdub29uQHNwYW10cmFwLm50bHdvcmxkLmNvbSAoRGF2aWQgVyBOb29u
KQ0KUmVtb3ZlIHNwYW0gdHJhcCB0byByZXBseSBieSBlLW1haWwuDQo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K
LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuMTUgKEdO
VS9MaW51eCkNCg0KaUVZRUFSRUNBQVlGQWt3Nk9nTUFDZ2tROU1xYVVKUXcyTWszL0FDZlU2Qzd0
QjBreCswY3RKL0l4dUwrTlJCVA0KWVYwQW4yd3lHcWZjUmVueEFQeTlXL1pEZzhxNjluR1kNCj1F
eDdoDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==

On Jul 11, 2:39=A0pm, David W Noon <dwn...@spamtrap.ntlworld.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 11 Jul 2010 09:25:36 -0700 (PDT), steve wrote about Re: IDE for
> ifort on Linux:
>
> [snip]
>
>
>
> >I believe that you may have misread what Mariano wrote. =A0I don't
> >see much difference in the following code:
>
> >program a
> > =A0 call b
> > =A0 call c
> >end program a
>
> >subroutine b
> > =A0 real :: x =3D 42, y =3D 1066
> > =A0 write(*, 10) x
> > =A0 write(*, 10) y
> >10 format (ES12.4)
> >end subroutine b
>
> >subroutine c
> > =A0 character(len=3D10), parameter :: fmt =3D '(ES12.4)'
> > =A0 real :: x =3D 42, y =3D 1066
> > =A0 write(*, fmt) x
> > =A0 write(*, fmt) y
> >end subroutine c
>
> Aha. =A0So what does this buy me?
> - --

See Dan Nagle's reply.

module formats
  implicit none
  character(len=3D10), parameter :: &
  &   fmt_f =3D '(ES14.6)'  &  ! 7 digits
  &   fmt_d =3D '(ES22.13)'    ! 14 digits.
end module formats

Now, use this module everywhere in your project.  If
you find out that double precision actually has 15 digits
of precision, then you only need to change one line of
code for the entire project.

--
steve

On 7/11/2010 4:29 PM, steve wrote:
> On Jul 11, 2:39 pm, David W Noon<dwn...@spamtrap.ntlworld.com>  wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Sun, 11 Jul 2010 09:25:36 -0700 (PDT), steve wrote about Re: IDE for
>> ifort on Linux:
>>
>> [snip]
>>
>>
>>
>>> I believe that you may have misread what Mariano wrote.  I don't
>>> see much difference in the following code:
>>
>>> program a
>>>    call b
>>>    call c
>>> end program a
>>
>>> subroutine b
>>>    real :: x = 42, y = 1066
>>>    write(*, 10) x
>>>    write(*, 10) y
>>> 10 format (ES12.4)
>>> end subroutine b
>>
>>> subroutine c
>>>    character(len=10), parameter :: fmt = '(ES12.4)'
>>>    real :: x = 42, y = 1066
>>>    write(*, fmt) x
>>>    write(*, fmt) y
>>> end subroutine c
>>
>> Aha.  So what does this buy me?
>> - --
>
> See Dan Nagle's reply.
>
> module formats
>    implicit none
>    character(len=10), parameter ::&
>    &    fmt_f = '(ES14.6)'&   ! 7 digits
>    &    fmt_d = '(ES22.13)'    ! 14 digits.
> end module formats
>
> Now, use this module everywhere in your project.  If
> you find out that double precision actually has 15 digits
> of precision, then you only need to change one line of
> code for the entire project.

Stupid question:

Can you remove the '(len=10)'?  Having to count the characters in the 
string seems like a Bad Thing, inviting unfavorable comparison with C 
(where you can do things like 'const char *fmt = "(f12.6)") and bringing 
back unpleasant memories of Hollerith format strings...

Louis

Louis Krupp wrote:
....

>>    character(len=10), parameter ::&
>>    &    fmt_f = '(ES14.6)'&   ! 7 digits
>>    &    fmt_d = '(ES22.13)'    ! 14 digits.
....

> Stupid question:
> 
> Can you remove the '(len=10)'?  ...

Yes...

LEN=*

(I'm not sure if later than F90/95 syntax allows for even that to go 
away or not...)

--

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTdW4s
IDExIEp1bCAyMDEwIDE1OjI5OjQ4IC0wNzAwIChQRFQpLCBzdGV2ZSB3cm90ZSBhYm91dCBSZTog
SURFIGZvcg0KaWZvcnQgb24gTGludXg6DQoNCj5PbiBKdWwgMTEsIDI6MzmgcG0sIERhdmlkIFcg
Tm9vbiA8ZHduLi4uQHNwYW10cmFwLm50bHdvcmxkLmNvbT4gd3JvdGU6DQpbc25pcF0NCj4+IEFo
YS4goFNvIHdoYXQgZG9lcyB0aGlzIGJ1eSBtZT8NCj4NCj5TZWUgRGFuIE5hZ2xlJ3MgcmVwbHku
DQo+DQo+bW9kdWxlIGZvcm1hdHMNCj4gIGltcGxpY2l0IG5vbmUNCj4gIGNoYXJhY3RlcihsZW49
MTApLCBwYXJhbWV0ZXIgOjogJg0KPiAgJiAgIGZtdF9mID0gJyhFUzE0LjYpJyAgJiAgISA3IGRp
Z2l0cw0KPiAgJiAgIGZtdF9kID0gJyhFUzIyLjEzKScgICAgISAxNCBkaWdpdHMuDQo+ZW5kIG1v
ZHVsZSBmb3JtYXRzDQo+DQo+Tm93LCB1c2UgdGhpcyBtb2R1bGUgZXZlcnl3aGVyZSBpbiB5b3Vy
IHByb2plY3QuICBJZg0KPnlvdSBmaW5kIG91dCB0aGF0IGRvdWJsZSBwcmVjaXNpb24gYWN0dWFs
bHkgaGFzIDE1IGRpZ2l0cw0KPm9mIHByZWNpc2lvbiwgdGhlbiB5b3Ugb25seSBuZWVkIHRvIGNo
YW5nZSBvbmUgbGluZSBvZg0KPmNvZGUgZm9yIHRoZSBlbnRpcmUgcHJvamVjdC4NCg0KVGhpcyBt
aWdodCBzZWVtIHRoZSB3cm9uZyB3YXkgYXJvdW5kLCBidXQgSSBmaXJzdCBkZWNpZGUgaG93IG11
Y2gNCmRpc3BsYXkgcHJlY2lzaW9uIEkgbmVlZCBhbmQgdGhlbiBkZWNsYXJlIHZhcmlhYmxlcyBv
ZiBzdWl0YWJsZSB0eXBlIHRvDQpzdXBwbHkgdGhhdCBkaXNwbGF5LiAgSWYgSSBuZWVkIHRvIHBy
aW50IGZyb20gbXVsdGlwbGUgbG9jYXRpb25zLCBJDQpjb2RlIGEgcHJpbnQgc3Vicm91dGluZSB3
aXRoIHRoZSBhcHByb3ByaWF0ZSBmb3JtYXQocykgYW5kIGNhbGwgdGhhdA0KZnJvbSB3aGVyZXZl
ciBJIG5lZWQuICBJIGhhdmUgYmVlbiBkb2luZyB0aGluZ3MgdGhhdCB3YXkgZm9yIG92ZXIgMzUN
CnllYXJzIGFuZCBpdCBoYXMgd29ya2VkIHdlbGwgc28gZmFyLg0KDQpUaGUgdXBzaG90IGlzIHRo
YXQgSSBhbSBzbyBteW9waWMgdGhhdCBJIHN0aWxsIGRvbid0IHNlZSB3aGF0IHRoZSBhYm92ZQ0K
YnV5cyBtZS4gIFtJLmUuLCB0aGlzIGlzIHVuZG91YnRlZGx5IGNoYW5nZSwgYnV0IEknbSBub3Qg
Y29udmluY2VkIHRoYXQNCml0IGlzIHByb2dyZXNzLl0NCi0gLS0gDQpSZWdhcmRzLA0KDQpEYXZl
ICBbUkxVICMzMTQ0NjVdDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KZHdub29uQHNwYW10cmFwLm50bHdvcmxk
LmNvbSAoRGF2aWQgVyBOb29uKQ0KUmVtb3ZlIHNwYW0gdHJhcCB0byByZXBseSBieSBlLW1haWwu
DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PQ0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246
IEdudVBHIHYyLjAuMTUgKEdOVS9MaW51eCkNCg0KaUVZRUFSRUNBQVlGQWt3NlppQUFDZ2tROU1x
YVVKUXcyTW15Q3dDYUF4R016bFViQWZycS9PNnRWQXA3eHhUbg0KdVVRQW4wMVBub0FKUy9OdUhJ
S0xXdjduR1R2SE1sRTANCj1DQ1FEDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==

On Jul 12, 12:47=A0pm, David W Noon <dwn...@spamtrap.ntlworld.com>
wrote:


> This might seem the wrong way around, but I first decide how much
> display precision I need and then declare variables of suitable type to
> supply that display. ... I have been doing things that way for over 35
> years and it has worked well so far.

If so, you have never had a numerical problem like the volcanological
one I had a few months ago, where double precision (15 significant
digits) was not good enough to give 3 correct significant digits in
the answers, but extended precision (18 digits) was good enough for 5,
as shown by quadruple precision (33 digits) giving the same results.
(Fortunately, g95 on some platforms allows all those real kinds, and
in one of the rare exceptions to Murphy's law I needed none of the
quad precision features that g95 hasn't implemented yet.) The reason
was the usual one: if x and y are much nearer each other than either
is to zero, then the relative error in x-y can be (and by Murphy's
law, usually is) much larger than that in x or y.

-- John Harper

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBNb24s
IDEyIEp1bCAyMDEwIDE0OjQwOjQ5IC0wNzAwIChQRFQpLCBqZmggd3JvdGUgYWJvdXQgUmU6IElE
RSBmb3INCmlmb3J0IG9uIExpbnV4Og0KDQo+T24gSnVsIDEyLCAxMjo0N6BwbSwgRGF2aWQgVyBO
b29uIDxkd24uLi5Ac3BhbXRyYXAubnRsd29ybGQuY29tPg0KPndyb3RlOg0KPg0KPg0KPj4gVGhp
cyBtaWdodCBzZWVtIHRoZSB3cm9uZyB3YXkgYXJvdW5kLCBidXQgSSBmaXJzdCBkZWNpZGUgaG93
IG11Y2gNCj4+IGRpc3BsYXkgcHJlY2lzaW9uIEkgbmVlZCBhbmQgdGhlbiBkZWNsYXJlIHZhcmlh
YmxlcyBvZiBzdWl0YWJsZSB0eXBlDQo+PiB0byBzdXBwbHkgdGhhdCBkaXNwbGF5LiAuLi4gSSBo
YXZlIGJlZW4gZG9pbmcgdGhpbmdzIHRoYXQgd2F5IGZvcg0KPj4gb3ZlciAzNSB5ZWFycyBhbmQg
aXQgaGFzIHdvcmtlZCB3ZWxsIHNvIGZhci4NCj4NCj5JZiBzbywgeW91IGhhdmUgbmV2ZXIgaGFk
IGEgbnVtZXJpY2FsIHByb2JsZW0gbGlrZSB0aGUgdm9sY2Fub2xvZ2ljYWwNCj5vbmUgSSBoYWQg
YSBmZXcgbW9udGhzIGFnbywgd2hlcmUgZG91YmxlIHByZWNpc2lvbiAoMTUgc2lnbmlmaWNhbnQN
Cj5kaWdpdHMpIHdhcyBub3QgZ29vZCBlbm91Z2ggdG8gZ2l2ZSAzIGNvcnJlY3Qgc2lnbmlmaWNh
bnQgZGlnaXRzIGluDQo+dGhlIGFuc3dlcnMsIGJ1dCBleHRlbmRlZCBwcmVjaXNpb24gKDE4IGRp
Z2l0cykgd2FzIGdvb2QgZW5vdWdoIGZvciA1LA0KPmFzIHNob3duIGJ5IHF1YWRydXBsZSBwcmVj
aXNpb24gKDMzIGRpZ2l0cykgZ2l2aW5nIHRoZSBzYW1lIHJlc3VsdHMuDQo+KEZvcnR1bmF0ZWx5
LCBnOTUgb24gc29tZSBwbGF0Zm9ybXMgYWxsb3dzIGFsbCB0aG9zZSByZWFsIGtpbmRzLCBhbmQN
Cj5pbiBvbmUgb2YgdGhlIHJhcmUgZXhjZXB0aW9ucyB0byBNdXJwaHkncyBsYXcgSSBuZWVkZWQg
bm9uZSBvZiB0aGUNCj5xdWFkIHByZWNpc2lvbiBmZWF0dXJlcyB0aGF0IGc5NSBoYXNuJ3QgaW1w
bGVtZW50ZWQgeWV0LikgVGhlIHJlYXNvbg0KPndhcyB0aGUgdXN1YWwgb25lOiBpZiB4IGFuZCB5
IGFyZSBtdWNoIG5lYXJlciBlYWNoIG90aGVyIHRoYW4gZWl0aGVyDQo+aXMgdG8gemVybywgdGhl
biB0aGUgcmVsYXRpdmUgZXJyb3IgaW4geC15IGNhbiBiZSAoYW5kIGJ5IE11cnBoeSdzDQo+bGF3
LCB1c3VhbGx5IGlzKSBtdWNoIGxhcmdlciB0aGFuIHRoYXQgaW4geCBvciB5Lg0KDQpJIGhhdmUg
bmV2ZXIgd29ya2VkIGluIHZvbGNhbm9sb2d5LCBidXQgaW4gdGhlIDE5NzBzIGFuZCBlYXJseSAx
OTgwcyBJDQp3b3JrZWQgaW4gYSBjaGVtaWNhbCBsYWJvcmF0b3J5LiAgSSB3YXMgb2NjYXNpb25h
bGx5IGNvbmZyb250ZWQgd2l0aA0KcHJvYmxlbXMgaW52b2x2aW5nIGNoZW1pY2FsIHJlYWN0aW9u
cyBhbmQgdGhlaXIgYXNzb2NpYXRlZA0KdGhlcm1vZHluYW1pY3MgdGhhdCBwb3NlZCB0aGUgc2Ft
ZSBpc3N1ZXMgb2YgbG9zcyBvZiBzaWduaWZpY2FuY2UgYW5kDQpvdGhlciBzeW1wdG9tcyBvZiBp
bGwtY29uZGl0aW9uaW5nLiAgSSB3YXMgYWx3YXlzIGx1Y2t5IGVub3VnaCB0byBzcG90DQp0aGVz
ZSBpc3N1ZXMgYmVmb3JlIGNvZGluZywgc28gSSBoYXZlIG5ldmVyIGhhZCB0byByZXdvcmsgdGhl
IGNvZGUgdG8NCmFkZHJlc3MgdGhlbS4NCg0KT2YgY291cnNlLCBvbmUgZmFjdG9yIHdhcyB3aGV0
aGVyIG9yIG5vdCB0aGUgY2hlbWlzdCBvciBjaGVtaWNhbA0KZW5naW5lZXIgd2hvICJvd25lZCIg
dGhlIHByb2JsZW0gY291bGQgY2FwdHVyZSBkYXRhIGFjY3VyYXRlbHkgZW5vdWdoIHRvDQpzYXkg
dGhhdCB0aGUgaW5wdXQgbnVtYmVycyB3ZXJlIHdvcnRoeSBvZiBkb3VibGUgcHJlY2lzaW9uLCBl
eHRlbmRlZA0KcHJlY2lzaW9uLCBldGMuICBCdXQgdGhhdCBpcyBub3QgYSBwcm9ibGVtIGFueSBw
cm9ncmFtbWluZyBsYW5ndWFnZSBjYW4NCmFkZHJlc3MuDQotIC0tIA0KUmVnYXJkcywNCg0KRGF2
ZSAgW1JMVSAjMzE0NDY1XQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCmR3bm9vbkBzcGFtdHJhcC5udGx3b3Js
ZC5jb20gKERhdmlkIFcgTm9vbikNClJlbW92ZSBzcGFtIHRyYXAgdG8gcmVwbHkgYnkgZS1tYWls
Lg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT0NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u
OiBHbnVQRyB2Mi4wLjE1IChHTlUvTGludXgpDQoNCmlFWUVBUkVDQUFZRkFrdzdyMW9BQ2drUTlN
cWFVSlF3Mk1uV1lRQ2RFcTQ3dkFQU2llSFlZYkc3enB6TlJQQ3UNCm5YUUFvSUpaeEhINUZxS0VY
M3gxVGZxc3BaYXNPK3d6DQo9QTVnSg0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo=