I've had trouble with matric inversion with Slatec. I've noticed that a test in PDL::Stats::GLM fails on 64-bit systems using Slatec matrix inversion. The same test runs fine on 32-bit systems and with PDL::MatrixOps matrix inversion on 64-bit systems.
I meant to send an example to the list but I haven't got a chance to do so since I'm mostly on 32-bit systems. Maggie On Mon, Nov 9, 2009 at 10:09 AM, Chris Marshall <[email protected]> wrote: > * We use our own copy of a *subset* of SLATEC to > build the PDL bindings. Issues with the full > SLATEC release should be minimal. > > * f2c works fine for computational routines. > The hard work is in the IO stuff which I > don't believe we are using and if you are > trying to interoperate with fortran. > > * Fixing the f77/fortran compiler issues for > PDL builds for such a basic functionality > as matrix inversion would be a big win. > > * The conversion should be straightforward > and would be a nice fix until something > better comes along.... > > Regards, > Chris > > David Mertens writes: >> >> I've sometimes wondered about how we can get >> slatec support when using gcc-4.x.x (no g77) >> as the compiler. Is there some general advice >> (ie not specific to any particular OS) on how >> this can be achieved? >> >> >> I believe that Chris has suggested running >> f2c on the Slatec code and then including >> that in our source code. I don't know how >> well the f2c code works, though I think this >> could potentially solve the problem. If it >> did 90% of the work for us, we could probably >> get the last 10% done by hand. Normally I >> wouldn't suggest tweaking auto-generated code >> by hand, but the Slatec code base hasn't >> changed since the early 90s, so I think we >> could safely do this once and never have to >> touch it again. >> >> I'm not sure if we want to do this, however. >> It's not clear to me if the Slatec code is >> thread-safe: if it uses global variables or >> even function-static variables, this would >> impose a major hurdle to creating a true >> multi-threaded PDL. I believe GSL provides >> all all of the capabilities of Slatec and >> much more, and is thread safe, but this would >> require that we rewrite some of the basic PDL >> modules (linear fitting is one I'm aware of) >> to use GSL code instead of Slatec code. >> >> But, as a first-solution to the problem, >> running f2c on the Slatc code might work. >> >> David > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
