fortran anyone? 
Author Message
 fortran anyone?

Moving here from C -> fortran <- PL/I  
in reply to Robin's message below...

Quote:

>> Greetings PL/I'ers from a now-retired Fortran user..

>> Perhaps some of you havent been exposed to recent fortran
>> syntax advances..

>> I wonder if current Fortran compilers were available way back when
>> the decision would still be made to inflict yet another language (PL/I)
>> on unsuspecting programming world..
>I'm always thankful that "another language (PL/I)" was
>actually "inflict"ed on the programming world.  Even if Fortran 90
>had been available in 1966, PL/I would still have been
>features ahead!
>FYI, PL/I first started out as Fortran V, being an attempt to
>bring Fortran up-to-date.

Interesting, too bad they didnt introduce it as Fortran V instead
of contributing to the current language babel...

Quote:
>It was to address the serious deficiencies of COBOL, Fortran.
>and Algol.
>Even now, after some 33 years, PL/I still outshines
>Fortran.  Particularly in the areas of Input/Output
>controlled storage,and interupt handling.
>In I/O, Fortran lacks picture formats (and along with it,
>picture data types).

I'm sure a routine could be added to
user's library to handle this item, but wheres the demand?
I have never heard of anyone requesting this feature in
the fortran world I inhabit...

Quote:
>In I/O, Fortran lacks recursion.  It's not possible to
>write out from a function that is invoked in an I/O list.

Not sure thats true, since you can add recursion
with RECURSIVE keyword ahead of FUNCTION or SUBROUTINE..
Have you tried it with your fortran-90 compiler?

Quote:
>In controlled storage, it's not possible to define
>a controlled array and to allocate and free it in
>other procedures.

You can declare globally visible arrays [ALLOCATABLE]  and
ALLOCATE(array)
DEALLOCATE(array)
in any routine..

Quote:
>Fortran still lacks interrupt handling.

In modern parlance, this is a interface to the O.S.
specifically in wintel world, you specify a routine to be a
thread of execution and call the supplied api routine to
connect to the resource...
Now that I am retired, I monkey around with such animals on my pc,
reading stockmarket quotes from a serial port and have global access
in the exec to what the thread has input...

Quote:
>And it still lacks bit strings.

you can manipulate bits with bit diddler routines, for example MVBITS..

Quote:
>and even though it has characher handling, it lacks
>varying strings.

Without knowing how this feature works in PL/I,
I admit to occasionally needing some automated way to handle
string variability in fortran..
This reminds me to ask for this feature in the upcoming Fortran-2000
standard...

Quote:
>FTR, PL/I introduced list processing back in 1966 or 1967.
>It ws not until Fortran 90 (c. 1991) did Fortran have comparable
>facilities.

You have been very silent about how to output a list
when the list has been passed as an argument in PL/I,
You sure you have comparable list processing to C or Fortran?

Quote:
>> Since PL/I is obviously dying for lack of support,
>It is?  Not when I last looked.  In recent years, new
>PL/I compilers have been introduced For OS/2,
>AIX, and Windows.

Is it still an IBM invention?  Does anyone else support it?
Support includes its users, I note this newsgroup has 1/10 of the
message base as fortran  and 1/30 of the message base as C newsgroup.

Quote:
>In the last 12 months or so, the Millennium Language
>Extensions were introduced on these systems. -- incidentally
>the first, even before the COBOL compilers.

Puh-lease no more Y2K hype....

Quote:
>> therefor instead of migrating to C/C++ why not have a look at what
>> Fortran currently offers?
>No-one in his right mind would consider converting PL/I to
>C, nor to Fortran, because they both lack the functionality
>and convenience that PL/I provides.

I see references to doing it in the message base, so its on the
mind of PL/I'ers, but obviously not on your mind...

Dave



Fri, 04 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:

> >In I/O, Fortran lacks picture formats (and along with it,
> >picture data types).

> I'm sure a routine could be added to
> user's library to handle this item, but wheres the demand?
> I have never heard of anyone requesting this feature in
> the fortran world I inhabit...

Things have been quiet this summer.  Nothing like a good troll to liven
it up.  You prbably never heard a request for this because of the
limited range of programming tasks FORTRAN is used for.  I use it
constantly, as do people with a COBOL background.
It's one of (several) major omissions in C.

Quote:
> >Fortran still lacks interrupt handling.

> In modern parlance, this is a interface to the O.S.
> specifically in wintel world, you specify a routine to be a
> thread of execution and call the supplied api routine to
> connect to the resource...

Maybe for interrupts like keyboard, serial port, etc., but what about
hardware interrupts caused by various program errors.  They have to be
handled by the thread causing the interrupt.  For errors that the
hardware does detect, e.g. FIXEDOVERFLOW, it's much more efficient to do
the detection in hardware than to program a test before each statement.
IIRC, FORTRAN doesn't really catch these kinds of errors.

Quote:
> >And it still lacks bit strings.

> you can manipulate bits with bit diddler routines, for example MVBITS..

Sure, you can program almost anything, but it's not as neat, efficient,
or portable as a built-in feature of the language.

Quote:
> >> Since PL/I is obviously dying for lack of support,

> >It is?  Not when I last looked.  In recent years, new
> >PL/I compilers have been introduced For OS/2,
> >AIX, and Windows.

> Is it still an IBM invention?  Does anyone else support it?

Lots of people.  See the PL/I FAQ.  Liant has compilers for a variety of
unix systems.  Stratus
(IIRC).  Digital had a nice PL/I compiler for Vaxen, now adopted by
someone else whose name I can't recall, and others.  PL/I is a complex
language to compile, much more so than FORTRAN or C, so compilers aren't
a-dime-a-dozen, but they're available.  Mre to come, stay tuned.


Fri, 04 Jan 2002 03:00:00 GMT  
 fortran anyone?

(snip)

Quote:
>> >And it still lacks bit strings.

>> you can manipulate bits with bit diddler routines, for example MVBITS..

>Sure, you can program almost anything, but it's not as neat, efficient,
>or portable as a built-in feature of the language.

In C, bit manipulation with &, |, ^ (and, or, xor) is pretty efficient,
reasonably neat for the common operations, and reasonably portable.
For some operations it is not neat or efficient.

PL/I bit strings may be neater, but I don't know about efficient.
Mostly this is because C is a lower level language, and bit operations are
almost at assembly level.  In PL/I they are high level, such as SUBSTR()
function and pseudo-variable, and have enough overhead to be much less
efficient than in C.

Quote:
>> >> Since PL/I is obviously dying for lack of support,

>> >It is?  Not when I last looked.  In recent years, new
>> >PL/I compilers have been introduced For OS/2,
>> >AIX, and Windows.

PL/I has already lasted 10 years longer than C, and is still alive.
It is also much better suited to modern machines than to those available
when it was introduced.  

C was designed for smaller machines, where code size is more important.

PL/I (F) could compile arbitrary sized programs on a 64K machine.
C was also designed around a 64K machine.  Today both are run on much larger
machines.

-- glen



Fri, 04 Jan 2002 03:00:00 GMT  
 fortran anyone?


[commenting robin]

Quote:
> You have been very silent about how to output a list
> when the list has been passed as an argument in PL/I,
> You sure you have comparable list processing to C or Fortran?

Quite sure.

C:

int i = 0;
for( temp = p; temp != NULL; temp = temp->next ) {
  printf( "    %d : %s\n", ++i, (char*)(*temp).entry);
  }

Fortran:

p => p_
i = 0
temp => p
DO WHILE (ASSOCIATED(temp))
    i = i+1
    temp_entry = temp%entry(1)
    WRITE (*,901) "    ",i," : ",T_temp_entry(1:temp%entry(2))
  temp => temp%next
END DO

PL/I:

i=0;
do temp=p repeat next while(temp^=null);
  i=i+1;
  put skip list(i,entry);
end;

I will even say that it is more pleasant in appearance than either C or
Fortran.
But I don't want to start a religious war.  Each language has it's
strenghts.

Gunnar.



Fri, 04 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:


> (snip)

> >> >And it still lacks bit strings.

> >> you can manipulate bits with bit diddler routines, for example MVBITS..

> >Sure, you can program almost anything, but it's not as neat, efficient,
> >or portable as a built-in feature of the language.

> In C, bit manipulation with &, |, ^ (and, or, xor) is pretty efficient,
> reasonably neat for the common operations, and reasonably portable.
> For some operations it is not neat or efficient.

> PL/I bit strings may be neater, but I don't know about efficient.

PL/I on the workstation (AIX, OS/2, Windows) offers a comparable
facility to C via the built-in functions
IAND, IOR, NOT. IEOR, where the data is processed in registers.

Quote:
> Mostly this is because C is a lower level language, and bit operations are
> almost at assembly level.  In PL/I they are high level, such as SUBSTR()
> function and pseudo-variable, and have enough overhead to be much less
> efficient than in C.

PL/I also provides the facility to operate on bit strings of arbitrary
length.  The level of efficiency depends greatly on whether
the hardware supports addressing to tbe bit level.

The bit strings can be fixed-length or varying-length.

- Show quoted text -

Quote:
> -- glen



Fri, 04 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:

> Moving here from C -> Fortran <- PL/I  
> in reply to Robin's message below...


> >> Greetings PL/I'ers from a now-retired Fortran user..

> >> Perhaps some of you havent been exposed to recent fortran
> >> syntax advances..

> >> I wonder if current Fortran compilers were available way back when
> >> the decision would still be made to inflict yet another language (PL/I)
> >> on unsuspecting programming world..

> >I'm always thankful that "another language (PL/I)" was
> >actually "inflict"ed on the programming world.  Even if Fortran 90
> >had been available in 1966, PL/I would still have been
> >features ahead!

> >FYI, PL/I first started out as Fortran V, being an attempt to
> >bring Fortran up-to-date.

> Interesting, too bad they didnt introduce it as Fortran V instead
> of contributing to the current language babel...

Yes, but when it became apparent that the new features
couldn't be incorporated into something that looked like
Fortran, it was (thankfully) decided that a new language
was required.  Recall that Fortran still had only if (expression) 1,2,3
[otherwise known as arithmetic IF], DO 30 I=1,10
with a numbered statement as the terminal of the loop,
arcane format statements, and of course no dynamic memory
allocation, and countless other obsolete features.

They made the right decision.

Quote:
> >It was to address the serious deficiencies of COBOL, Fortran.
> >and Algol.
> >Even now, after some 33 years, PL/I still outshines
> >Fortran.  Particularly in the areas of Input/Output
> >controlled storage,and interupt handling.

> >In I/O, Fortran lacks picture formats (and along with it,
> >picture data types).

> I'm sure a routine could be added to
> user's library to handle this item, but wheres the demand?
> I have never heard of anyone requesting this feature in
> the fortran world I inhabit...

They are the trade in commercial applications, and even
BASIC has them.

Quote:
> >In I/O, Fortran lacks recursion.  It's not possible to
> >write out from a function that is invoked in an I/O list.

> Not sure thats true, since you can add recursion
> with RECURSIVE keyword ahead of FUNCTION or SUBROUTINE..

This was discussed recently on one of the FORTRAN forums.

Quote:
> Have you tried it with your fortran-90 compiler?

Indeed.

Quote:
> >In controlled storage, it's not possible to define
> >a controlled array and to allocate and free it in
> >other procedures.

> You can declare globally visible arrays [ALLOCATABLE]  and
> ALLOCATE(array)
> DEALLOCATE(array)
> in any routine..

Try it woithout globals.  try it as an argument!

Quote:
> >Fortran still lacks interrupt handling.

> In modern parlance, this is a interface to the O.S.
> specifically in wintel world, you specify a routine to be a
> thread of execution and call the supplied api routine to
> connect to the resource...
> Now that I am retired, I monkey around with such animals on my pc,
> reading stockmarket quotes from a serial port and have global access
> in the exec to what the thread has input...

This is the ability to intercept and recover from
run-time errors such as ficxed-point overflow,
floating-point overflow, subscript errors,
and quite a few others.  it's about interrupting
a running program and enquiring about the values of
variables, which procedure it's running now, and which statement;
in all about 20 or so different run-time problems.

Quote:
> >And it still lacks bit strings.

> you can manipulate bits with bit diddler routines, for example MVBITS..

You can move them.

But can you do logical and, logical or etc
on bit strings of arbitrary length as easily as
a = b // c in fortran?

- Show quoted text -

Quote:
> >and even though it has characher handling, it lacks
> >varying strings.

> Without knowing how this feature works in PL/I,
> I admit to occasionally needing some automated way to handle
> string variability in fortran..
> This reminds me to ask for this feature in the upcoming Fortran-2000
> standard...

> >FTR, PL/I introduced list processing back in 1966 or 1967.
> >It ws not until Fortran 90 (c. 1991) did Fortran have comparable
> >facilities.

> >> therefor instead of migrating to C/C++ why not have a look at what
> >> Fortran currently offers?



Fri, 04 Jan 2002 03:00:00 GMT  
 fortran anyone?
My Gauss method matrix invert routine below has tested to be faster than Crout
and Lapack method invert routines for n < 15..
I am posting it to illustrate some of Fortran's array manipulation syntax.

I challenge someone to translate below to PL/I for readers (including me)
to compare #statements needed and possibly identify additional
problems with passing arguments, to join the problem of passing
a PL/I external  routine a list containing pointers
(which no-one will PUBLICLY admit theres a PL/I  problem,
  altho they do admit it via private email)...

! --------------------------------------------------------------------
SUBROUTINE Gauss (a,n)       ! Invert matrix by Gauss method
! --------------------------------------------------------------------
IMPLICIT NONE

INTEGER :: n
REAL(8) :: a(n,n)

! - - - Local Variables - - -
REAL(8) :: b(n,n), c, d, temp(n)
INTEGER :: i, j, k, m, imax(1), ipvt(n)
! - - - - - - - - - - - - - -

b = a
ipvt = (/ (i, i = 1, n) /)

DO k = 1,n
   imax = MAXLOC(ABS(b(k:n,k)))
   m = k-1+imax(1)

   IF (m /= k) THEN
      ipvt( (/m,k/) ) = ipvt( (/k,m/) )
      b((/m,k/),:) = b((/k,m/),:)
   END IF
   d = 1/b(k,k)

   temp = b(:,k)
   DO j = 1, n
      c = b(k,j)*d
      b(:,j) = b(:,j)-temp*c
      b(k,j) = c
   END DO
   b(:,k) = temp*(-d)
   b(k,k) = d
END DO

a(:,ipvt) = b

END SUBROUTINE Gauss



Sat, 05 Jan 2002 03:00:00 GMT  
 fortran anyone?


Quote:
> problems with passing arguments, to join the problem of passing
> a PL/I external  routine a list containing pointers
> (which no-one will PUBLICLY admit theres a PL/I  problem,
>   altho they do admit it via private email)...

Come on, is the summer hot where you are?

PL/I does not have, and did never have, any problems with passing a list
containing pointers.
A minor problem in the case you refer to was concerning variable-length
strings, which Fortran has no way of dealing with (in your own translation
you had to pass the length as a separate member).

Its raining here.

Gunnar.



Sat, 05 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:

> I challenge someone to translate below to PL/I for readers (including me)
> to compare #statements needed and possibly identify additional
> problems with passing arguments, to join the problem of passing
> a PL/I external  routine a list containing pointers
> (which no-one will PUBLICLY admit theres a PL/I  problem,
>   altho they do admit it via private email)...

Did you look at the example I posted?

It shows a calling statements as well as the procedure
for traversing the linked list.

It's a trivial piece of code.



Sun, 06 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:

> My Gauss method matrix invert routine (below)  has tested to be faster
> than Crout and Lapack method invert routines for n < 15..

The authors of LAPACK (Linear Algebra Package) were top-level
experts in both designing the algorithms and writing FORTRAN.
So, I'm surprised that you can write faster code than they did,
unless you are sacrificing something along the way.

Quote:
> ! --------------------------------------------------------------------
> SUBROUTINE Gauss (a,n)       ! Invert matrix by Gauss method
> ! --------------------------------------------------------------------
> IMPLICIT NONE

> INTEGER :: n
> REAL(8) :: a(n,n)

> ! - - - Local Variables - - -
> REAL(8) :: b(n,n), c, d, temp(n)
> INTEGER :: i, j, k, m, imax(1), ipvt(n)
> ! - - - - - - - - - - - - - -

> b = a
> ipvt = (/ (i, i = 1, n) /)

> DO k = 1,n
>    imax = MAXLOC(ABS(b(k:n,k)))
>    m = k-1+imax(1)

>    IF (m /= k) THEN
>       ipvt( (/m,k/) ) = ipvt( (/k,m/) )
>       b((/m,k/),:) = b((/k,m/),:)
>    END IF

>    d = 1/b(k,k)

Ouch!  Although "floating-point-divide" is much slower,
on most computers, than "floating-point-multiply",
no self-respecting Numerical Analyst would ever code
the above statement, if the intent were to solely to
substitute a "divide" inside the loop (below) by a
"multiply-by-the-approximate-numerical-inverse" operation.

Quote:
>    temp = b(:,k)
>    DO j = 1, n
>       c = b(k,j)*d

Ouch!  Multiplying by one-over-B(K,K) is "numerically-incorrect".

- Show quoted text -

Quote:
>       b(:,j) = b(:,j)-temp*c
>       b(k,j) = c
>    END DO
>    b(:,k) = temp*(-d)
>    b(k,k) = d
> END DO

> a(:,ipvt) = b

> END SUBROUTINE Gauss



Mon, 07 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:
(Melvin Klassen) writes:

>> My Gauss method matrix invert routine (below)  has tested to be faster
>> than Crout and Lapack method invert routines for n < 15..

>The authors of LAPACK (Linear Algebra Package) were top-level
>experts in both designing the algorithms and writing FORTRAN.
>So, I'm surprised that you can write faster code than they did,
>unless you are sacrificing something along the way.

Nope, not sacrificing anything except speed when n gets really large
in fact its LAPACK that sacrifices accuracy for fast runtime
when n is much greater than 100..

How do I know?  look at the TEST_FPU.F90 routine and its results
referred to below..

My Gauss routine is MORE accurate even at large n because its ALWAYS
pivoting with the largest element, but this slows the inversion down
for large n...

It has been widely tested in comp.lang.fortran by dozens
of testers vs. CROUT and LAPACK on a wide range of compilers
and computers with NEVER a hiccup due to your perceived divide problems
try it yourself...
btw, I am the official keeper of the following table, so send me any results.

======================================================
TEST_FPU results for TOP number-crunching computers+F90 compilers

new testers are invited, (see instructions below)...

Test description:
1. Gauss invert 51x51 array, uses F90 array syntax, fits in cache.
2. Crout  invert 51x51 array, more F90 syntax, less cache fit.
3. Crout  invert 501x501 array, stresses L2 cache < 4m
4. Lapack invert 501x501 array, stresses L2 cache < 4m, uses minor
    F90 syntax +Lapack performance library.
Test3/Test4 < 2 implies compiler has very advanced optimizer.

Total              Test                Computer         Compiler
Sec        1     2     3    4    Id/Mhz/Cache    F90/switches     Tester
--------------------------------------------------------------------------
10.4 =  2.7  3.5  2.7  1.4   alpha21164/600/4m   df5.1  (7)   j.lee
24.9 = 10.1  4.3  4.4  6.1b  dec-alpha/533/2m    dvf5.0d (2)  j.vanbuskirk
25.5 =  7.7  4.4  6.7  6.7b  dec-alpha/500       dvf5.0  (3)  i.reid

11.4 =  3.2  4.4  2.4  1.3   sgi-r10k/250/4m  mipspro7.1 (6)   t.prince
16.4 =  4.2  5.5  4.4  2.0   sgi-r10k/195/1m      "            t.prince
17.0 =  2.7 11.6  2.2  0.3   sgi/cray-t90/440/none  (9)      j.mccalpin

16.5 =  3.7  4.8  6.0  2.0   intel-p2/300->464/128k download   p.lunde
17.9 =  6.1  4.9  5.1  1.8   intel-p2/450->504/512k download   n.juffa
19.0 =  6.0  5.2  5.8  1.9   intel-p2/400->448/512k download   miquel
20.0 =  6.9  5.4  5.7  2.0   intel-p2/450/512k   download      n.juffa
23.1 =  5.1  6.6  8.6  2.9   intel-p2/333/128k   download      d.frank
36.9 = 11.2  9.9 11.7  4.0   intel-p2/232/512k   pacific (1)  t.prince
37.2 = 11.4 10.1 12.0  3.7     "       "         download     t.prince
48.4 = 12.6 17.5 15.3  3.1   intel-p2/300/512k  portland(4)  a.nonymous

24.8 =  5.6 11.9  5.2  2.1   hp-c240       f90/+O3+Ovectorize t.prince
35.7 =  7.3 15.6  9.0  3.8   hp-c180/2x1m  f90/+O3+Ovectorize t.prince

30.2 =  9.9  9.7  8.3  2.3   sun-ultra60/360/4m f90-1.2/(8)   j.reiter

212. = 50.0 68.5 53.1 41.8b  cyrix-6x86L/200/?  portland(5)  a.nonymous
-------------------------------------------------------------------------
                             intel-p6/200/256k compiler comparisons
37.5 =  9.7 10.2 13.2  4.3   nt4/dvf5/none                     w.sartory
39.5 = 11.4 11.7 12.0  4.4   nt4/download                      t.prince
49.0 = 15.0 15.0 14.0  5.0   nt4/fps4/ox     fps=1sec timing   w.sartory
117. = 51.7 28.5 20.8 16.7b  nt4/absoft5.0/-o-q100             w.sartory
-------------------------------------------------------------------------
Legend above:
b = blas used in test4 timing (performance library not used)
download = test_fpu.exe created by dvf5.0d used (see creation below)

OS / Compiler switches / tester's comments
-------------------------------------------------------------------
(1) Linux-gnulibc1/vf90/-O2 -march=pentiumpro -funroll-loops
    egcs-19980914, utk blas, pacific-sierra mirror'ed dvf download results
(2) NT 4.0 SP 3/ DVF 5.0D /fast /arch:ev56 /tune:ev56 /pipeline
    using unroll was a net loss
(3) NT4/DVF5/ -fast -arch:host -tune:host -pipeline
(4) RedHat5.1 / pgf90 /-O2 -Mvect -Minfo=all -Munroll -tp p6
    portland group inliner cant deal with code. -Minline crashes.
(5) Linux 2.0.35 / pgf90 / -O2 -Mvect
    portland group f90 Rel 1.7-5.  The Cyrix FPU support stinks,
(6)  -Ofast=ip27 -LNO:prefetch_ahead=1:fission=2 -lblas
(7) Unix/f90v5.1-594O/-O5-fast-tune host -g0 -non_shared
    -WL,-om_compress_lita -WL,-om_dead_code, dxml used for lapack
(8) Solaris 2.6 / Sun f90 1.2 / -fast -xarch=v8plusa
(9) Sgi/Cray UNICOS 10.0 / f90 3.1.0.2.0 /-O task0,vector
    Crout2000 did not vectorize well. Runs were batch mode -- not dedicated.
    I had to switch the "SELECTED_REAL_KIND" to (10,100) to avoid doing
    128-bit arithmetic!!!
 -------------------------------------------------------------------

Avail at:  ftp://members.aol.com/DaveGemini/TEST  <- TEST is upper case
1. TEST_FPU.TXT  this file
2. TEST_FPU.F90  F90 source
3. TEST_FPU.EXE  download for tester comparison with their wintel compiler,
    >DF /unroll:20 TEST_FPU.F90 lapack.obj intel.lib  /link /stack:3000000
4. INTEL.ZIP     contains Intel Performance Library for DVF
                 unzip INTEL.LIB into dvf's /lib directory
5. LAPACK.F      routines for lapack matrix invert
6. BLAS.F        routines linked when performance library not avail.

Instructions:
-------------
Optimize compile LAPACK.F, BLAS.F creating lapack.obj, blas.obj
Optimize compile/link TEST_FPU.90 lapack.obj, blas.obj or perf.lib
Run program, save TEST_FPU.DAT file produced.

If you are wintel compatible and using non-dvf compiler,
pls download TEST_FPU.EXE and run comparison.

If either or both run(s) indicate faster computer/compiler performance
than above listing, or you have new unreported results, then
send TEST_FPU.DAT file(s).. Any results submitted are subject to
posting in comp.lang.fortran.. If you wish to remain anonymous dont
supply name/address on the line provided.  thanks




Mon, 07 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:

> >> My Gauss method matrix invert routine (below)  has tested to be faster
> >> than Crout and Lapack method invert routines for n < 15..

> >The authors of LAPACK (Linear Algebra Package) were top-level
> >experts in both designing the algorithms and writing FORTRAN.
> >So, I'm surprised that you can write faster code than they did,
> >unless you are sacrificing something along the way.

> Nope, not sacrificing anything except speed when n gets really large,
> in fact its LAPACK that sacrifices accuracy for fast runtime
> when n is much greater than 100..

Is there anybody of sound mind who seeks an "accurate" solution
when N is "much greater" than 100?  
Most people would be pleased with *ANY* solution.  :-)

Quote:
> How do I know?  look at the TEST_FPU.F90 routine
> and its results referred to below..

> My Gauss routine is MORE accurate even at large n because its
> ALWAYS pivoting with the largest element, but this slows the
> inversion down for large n...

You previously claimed "faster", and now you're claiming "slower" ?!?!


Mon, 07 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:
(Melvin Klassen) writes:

>You previously claimed "faster", and now you're claiming "slower" ?!?!

You pli'ers are really something, all I claimed was my Gauss invert routine
was faster for n < 15 as you well know..

Whats the prerequisite for being a PLI advocate poster in comp.lang.pl1 ?
You must be a graduate of "obfuscation in newsgroup responding 101"

This newsgroup is loaded with graduates of this course...

Dave



Mon, 07 Jan 2002 03:00:00 GMT  
 fortran anyone?

Should this NG be called the battle-ground for PL/1 vs (C, Pascal, FORTRAN)?
:--)



Quote:
> (Melvin Klassen) writes:

> >You previously claimed "faster", and now you're claiming "slower" ?!?!

> You pli'ers are really something, all I claimed was my Gauss invert
routine
> was faster for n < 15 as you well know..

> Whats the prerequisite for being a PLI advocate poster in comp.lang.pl1 ?
> You must be a graduate of "obfuscation in newsgroup responding 101"

> This newsgroup is loaded with graduates of this course...

> Dave



Mon, 07 Jan 2002 03:00:00 GMT  
 fortran anyone?

Quote:

> Should this NG be called the battle-ground for PL/1 vs (C, PASCAL, FORTRAN)?

It's summer and a lot of people are bored.  The original posting was a
"troll" to get people stirred up.

Quote:
> > Whats the prerequisite for being a PLI advocate poster in comp.lang.pl1 ?
> > You must be a graduate of "obfuscation in newsgroup responding 101"

What's the prerequisite for bein a FORTRAN programmer?  The inability to
compose a question clearly or listen to any answers?


Tue, 08 Jan 2002 03:00:00 GMT  
 
 [ 99 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

1. PL/I and C (was fortran anyone?)

2. fortran anyone?

3. Fortran decimal anyone?

4. Fortran decimal anyone?

5. Anyone for help with DEC (Vax) Fortran-IV ?

6. Anyone using XL Fortran on AIX ?

7. Anyone have a fortran 77 compiler for pc?

8. Anyone want to sell MS Fortran PowerStation?

9. Has anyone used FORTRAN-M in the past?

10. Does anyone have a fortran compiler that is similar to say the C compiler Visual C++

11. Does anyone know some free Fortran compiler for Mac

12. Has anyone used MS fortran powerstation ?

 

 
Powered by phpBB® Forum Software