FORTRAN from FreePascal

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: FORTRAN from FreePascal

Adriaan van Os-2
Mark Morgan Lloyd wrote:

> Oh really? Well I'll let you travel back in time and argue with numerous
> former colleagues who've routinely found differences between their
> "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in
> those days tended to be separate programs even if supplied together.

What contributes to a discussion are precise technical facts, not hear-say talk. If these former
colleagues are/were capable engineers, they know the technical specs and peculiarities of the
languages and compilers they are working with. If they don't, they must find themselves another
profession.

A. van Os

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FORTRAN from FreePascal

Schindler Karl-Michael-2
In reply to this post by brian-3

> Am 20.11.2017 um 12:00 schrieb [hidden email]:
>
> Date: Sun, 19 Nov 2017 11:14:50 +0000
> From: Mark Morgan Lloyd <[hidden email]>
> To: [hidden email]
> Subject: Re: [fpc-pascal] FORTRAN from FreePascal
> Message-ID: <ourp3a$fub$[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Oh really? Well I'll let you travel back in time and argue with numerous
> former colleagues who've routinely found differences between their
> "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in
> those days tended to be separate programs even if supplied together.

Wasn't the problem somewhat different? There have always been "fast-math" version of some costly function. So, the point was, whether the faster routines could be used at the price of their larger numerical errors. Similarly, the choice of the optimization level of a compiler needed to be checked.

Furthermore, the wide spread use of fortran for numerical intense simulation up to this date stands in contrast to your statement, in particular in the field called high performance computing.

MiSchi.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FORTRAN from FreePascal

Mark Morgan Lloyd-5
On 20/11/17 12:00, Schindler Karl-Michael wrote:
>> Am 20.11.2017 um 12:00 schrieb [hidden email]:> > Date: Sun, 19 Nov 2017 11:14:50 +0000> From: Mark Morgan Lloyd <[hidden email]>> To: [hidden email]> Subject: Re: [fpc-pascal] FORTRAN from FreePascal> Message-ID: <ourp3a$fub$[hidden email]>> Content-Type: text/plain; charset=utf-8; format=flowed> > Oh really? Well I'll let you travel back in time and argue with numerous > former colleagues who've routinely found differences between their > "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in > those days tended to be separate programs even if supplied together.
> Wasn't the problem somewhat different? There have always been "fast-math" version of some costly function. So, the point was, whether the faster routines could be used at the price of their larger numerical errors. Similarly, the choice of the optimization level of a compiler needed to be checked.
> Furthermore, the wide spread use of fortran for numerical intense simulation up to this date stands in contrast to your statement, in particular in the field called high performance computing.

Possibly. It might be that the "fast" variant of the compiler was
actually pulling in different libraries.

However, the situation as described to me has always been in terms of
"if you have problems don't use the 'fast' compiler" or, with more
recent development tools "the first thing to try is turning optimisation
off". And this advice seems to /particularly/ apply to FORTRAN.

And leaving aside for the moment a small number of specialists who I
only know from subscription online services etc. (such things do still
exist), I've had this in most detail from well-respected senior academic
colleagues one of whom had been involved with the design of the
Manchester computers back when 2K words was "more than a man can keep
track of".

Oh, and the story about Turing suggesting using gin in the delay lines
is inaccurate. He merely observed that gin, as an aqueous alcohol
mixture with trace oil content, was excellent for cleaning the
transducers before the line was filled with mercury.

But this is getting way off topic and we'll get a "moderatorial cough"
any moment :-)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FORTRAN from FreePascal

Santiago A.
In reply to this post by Adriaan van Os-2
El 19/11/2017 a las 11:06, Adriaan van Os escribió:
> Mark Morgan Lloyd wrote:
>
>> That obviously applies to all languages, I've never come across
>> something which can represent 1/3 or pi exactly.
>
> If you do read what is written in the link - that is not the issue.
> The issue is how to interpret floating-point constants and how to
> convert single-precision floating-point to decimal. In BCD, that
> conversion is exact.

No. It is not.

n := 1 - (1/3) - (1/3) - (1/3);

n:=1.000000 - 0.333333 - 0.333333 - 0.333333;

n is never zero, no matter what representation you pick, unless you
have  infinite digits.

The problem is that periodic numbers can't be stored without infinite
digits. And the second problem is that depending upon the base, binary,
decimal, hex, have different periodic numbers and, unfortunately, 1/10,
in base 10, is periodic number in binary.

So you are right 0.10 can't be represented with an exact value in
floating-point, but it can be represented with exact value in BCD
(nevertheless,  you can represent 1/10 with an exact constant but not
1/3) . But internal operations won't be executed in BCD but using the
floating-point processor representation, so, the aftermath is the same.

Once I played with fraction representation, just for fun

TFraction=record
   Negative:boolean;
    IntPart:Integer;
    Numerator:Integer;
    Denominator:Integer;
end;

Except for irrational numbers pi, e, etc, it had full precision.
Obviously  it was too slow. And, by the way, BCD is also too slow for
numeric operations.

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12