remove t/flexraw_fortran.t, put notes in IO::FlexRaw - #522

MANIFEST

@@ -197,7 +197,6 @@ t/fits-noafh.t
 t/fits.t
 t/flexraw-iotypes.t
 t/flexraw.t
-t/flexraw_fortran.t
 t/func.t
 t/image2d.t
 t/imagend.t

lib/PDL/Course.pod

@@ -273,7 +273,7 @@ eigenvalues, inverting square matrices, LU-decomposition, and solving
 a system of linear equations.  Though it is not built on L<PDL::Matrix>,
 it should generally work with that module.  Also, the methods
 provided by this module do not depend on external libraries such as
-Slatec or GSL.
+LAPACK or GSL.
 
 =item * L<PDL::Reduce>
 

lib/PDL/IO/FlexRaw.pm

@@ -183,6 +183,76 @@ and return the PDLs mapped before the problem arose.  This can be
 dealt with either by reorganizing the data file (large types first
 helps, as a rule-of-thumb), or more simply by using C<readflex>.
 
+=head2 Fortran code to create data
+
+Until PDL 2.099, the test file F<t/flexraw_fortran.t> compiled a
+Fortran program, ran it, then byte-swapped its output, to test this
+module's ability to do that. Version 2.099 has dropped external
+dependencies, including the use of Fortran. The code it used is
+shown here for historical curiosity:
+
+  c Program to test i/o of F77 unformatted files
+        program rawtest
+        implicit none
+        integer i
+        $f77type a($ndata)
+        do i = 1, $ndata
+          a(i) = $val
+        enddo
+        open(8,file=
+       \$'$data'
+       \$,status='new',form='unformatted')
+        i = $ndata
+        write (8) i
+        write (8) a
+        close(8)
+        end
+
+with this FlexRaw header:
+
+  # FlexRaw file header
+  f77
+  long 1 1
+  # Data
+  $pdltype 1 $ndata
+
+C<$ndata> was set to 10, C<$val> was C<100.*sin(0.01* i)>, C<$data>
+was a filename. C<$f77type> was set to C<real*4> and C<real*8>.
+
+There was also a more complex program:
+
+  c Program to test i/o of F77 unformatted files
+        program rawtest
+        implicit none
+        character a
+        integer*2 i
+        integer*4 l
+        real*4    f
+        real*8    d
+        d = 4*atan(1.)
+        f = d
+        l = 10**d
+        i = l
+        a = ' '
+        open(8,file=
+       \$'$data'
+       \$,status='new',form='unformatted')
+  c Choose bad boundaries...
+        write (8) a,i,l,f,d
+        close(8)
+        end
+
+with this FlexRaw header:
+
+  # FlexRaw file header
+  byte 1 4
+  byte 0
+  short 0
+  long 0
+  float 0
+  double 0
+  byte 1 4
+
 =head1 FUNCTIONS
 
 =cut

lib/PDL/Index.pod

@@ -536,10 +536,6 @@ L<PDL::Reduce> - a C<reduce> function for PDL
 
 =item *
 
-L<PDL::Slatec> - PDL interface to the slatec numerical programming library
-
-=item *
-
 L<PDL::Slices> - Indexing, slicing, and dicing
 
 =item *

lib/PDL/Matrix.pm

@@ -29,7 +29,7 @@ vectors resp and matrices can be typed in using traditional matrix
 convention.
 
 If you want to know more about matrix operation support in PDL, you 
-want to read L<PDL::MatrixOps> or L<PDL::Slatec>.
+want to read L<PDL::MatrixOps> or L<PDL::LinearAlgebra>.
 
 The original pdl class refers to the first index as the first row,
 the second index as the first column of a matrix. Consider

lib/PDL/MatrixOps.pd

@@ -37,8 +37,8 @@ contains utilities for many common matrix operations: inversion,
 determinant finding, eigenvalue/vector finding, singular value
 decomposition, etc.  PDL::MatrixOps routines are written in a mixture
 of Perl and C, so that they are reliably present even when there is no
-FORTRAN compiler or external library available (e.g.
-L<PDL::Slatec> or any of the PDL::GSL family of modules).
+external library available (e.g.
+L<PDL::LinearAlgebra> or any of the PDL::GSL family of modules).
 
 Matrix manipulation, particularly with large matrices, is a
 challenging field and no one algorithm is suitable in all cases.  The
@@ -1030,13 +1030,6 @@ Solve A x = B for matrix A, by back substitution into A's LU decomposition.
   ($x) = simq($A->dupN(1,1,map +($A_dims[$_]//1)==1?$broadcast[$_]:1, 0..$#broadcast)->copy, $B->transpose, 0);
   $x = $x->inplace->transpose;
 
-  # or with Slatec LINPACK
-  use PDL::Slatec;
-  gefa($lu=$A->copy, $ipiv=null, $info=null);
-  # 1 = do transpose because Fortran's idea of rows vs columns
-  gesl($lu, $ipiv, $x=$B->transpose->copy, 1);
-  $x = $x->inplace->transpose;
-
   # or with PDL::LinearAlgebra wrappers of LAPACK
   $x = msolve($A, $B);
 

lib/PDL/Modules.pod

@@ -169,14 +169,9 @@ Linear filtering.
 
 Simplex optimization routines.
 
-=item L<PDL::Slatec>
-
-PDL interface to the Slatec library.
-
 =back
 
 
-
 =head1 COORDINATE TRANSFORMATIONS
 
 =over 5

lib/PDL/PP.pod

@@ -1316,8 +1316,8 @@ further. Perl can help you again(!) in doing this. In many libraries
 you have certain calling conventions. This can be exploited. In short,
 you can write a little parser (which is really not difficult in Perl) that
 then generates the calls to C<pp_def> from parsed descriptions of the
-functions in that library. For an example, please check the I<Slatec>
-interface in the C<Lib> tree of the PDL distribution. If you want to check
+functions in that library. For an example, please check the L<PDL::OpenCV>
+interface on CPAN. If you want to check
 (during debugging) which calls to PP functions your Perl code generated
 then set C<$::PP_VERBOSE> to a true value just before the relevant
 C<pp_def> call, or at the top of the file.