Speaking of Atlas, I recently did some beta-testing on R 2.1 and found some minor numerical issues on my Athlon Thunderbird in the Atlas 3.6.0 libraries built by Gentoo ebuilds. These weren't ghastly problems -- just a low-end bit or two in some linear regressions -- but they were enough to trigger some rather sensitive error tests in the R test suite. The tests were in fact so sensitive that the R developers made them more lenient as a result of my bug reports. :)
The interesting thing, though, is that I was the *only* tester that reported these issues, and that they went away when I built Atlas, both 3.6.0 and the latest, 3.7.8, directly from source, rather than from the ebuild, and used the hand-built version in building R. I never followed this path further, to try to figure out what the Atlas 3.6.0 ebuild was doing that a hand build from source wasn't, or vice versa, or whether my Athlon XP or Pentium III suffered from the same issues. In any event, if your target packages contain numerical accuracy tests, be sure to run them if you use Atlas and file bugs if you get something reproducible. And ... you might want to see about getting an Atlas 3.7.8 ebuild into Portage. It's a development version, but I believe it has much better optimization for 64-bit architectures than the current stable 3.6.0. I guess if you know enough about this stuff to want R, scipy, octave and other things that use Atlas, you know enough to figure out when it's broken and whether the issue is in the ebuild or upstream :). Darren Dale wrote: >Hello group, > >I thought I might try to get some work done on a few science-related python >packages. A reminder of what was at issue: > >Numeric, numarray and scipy all have the ability to link to blas,lapack and >atlas libraries. By default, numeric and numarray will build against their >own internal, and slower, libraries. > >I had submitted an ebuild for Numeric which, if USE=atlas, modified the >install script to link to the libraries provided by lapack-atlas (and its >dependency, blas-atlas), and made lapack-atlas a dependency. One of the devs >improved upon my initial offering, suggesting that they were no longer using >the atlas use flag, and changed the dependency to virtual lapack. > >Numeric, numarray, and scipy all need atlas specific information during the >build, if it is available. How can I get the atlas information into the setup >scripts, if it is appropriate to do so? > >What happens if Numeric is built against lapack-atlas, and then I use >lapack-config to switch to MKL? Numeric would still be linked to libatlas.*, >is that a problem? > >Darren > > -- [email protected] mailing list
