[Rd] make check on DU4 with R-1.1.0 snapshot

[Martin Maechler]

>>>>> "KH" == Kurt Hornik <hornik@ci.tuwien.ac.at> writes:

>>>>> Prof Brian D Ripley writes:
    >> On Fri, 2 Jun 2000, Albrecht Gebhardt wrote:
    >>> On Fri, 2 Jun 2000, Albrecht Gebhardt wrote:
    >>> 
    >>> > On Fri, 2 Jun 2000, Albrecht Gebhardt wrote:
    >>> > 
    >>> > > 
    >>> > > I just tried the rsync version of R-1.1.0 on one of my alphas:
    >>> > > It compiles without problems (gcc/g77 2.95.2, system is DU4.0E)
    >>> > > .........
    >>> > > 
    >>> > > I compiled --whithout-dxml, so I'm not using any special
    >>> numeric library.
    >>> > > 
    >>> > 
    >>> > Sorry I mixed something up in my report: In this compile I used
    >>> the alpha > specific DXML library, in my rpms I omit it with
    >>> --without-dxml (because > it sometimes crashes). I will try once
    >>> more now without dxml, may be this > changes something, don't know
    >>> if it gets used at all in the svd code.
    >>> > 
    >>> 
    >>> That was the reason. Now without DXML I pass the test without
    >>> modifying Eps:

    >> Nevertheless, the tolerance was too low. Most machines (e.g. Linux,
    >> Solaris and Windows) are giving errors of 8 or 9 times the machine
    >> precision, and with dxml you got 10x (and this failed as Eps was
    >> exactly 10x). eigen's help page has tolerances of 60x and 1000x, and
    >> I've given svd's 100x.

    >> [...]

    >>> So may be it is better do disable dxml support by default in
    >>> ./configure?

    >> Well, what does dxml support do for you?  Making the errors 1x
    >> machine precision larger than without is hardly critical.  On the
    >> other hand, I am not convinced that these optimized blas operations
    >> are worthwhile for all but the most unusual uses of R.

    >> On the other hand, I think it would be worth omitting the check for
    >> -ldxml and -latlas except on appropriate platforms (whatever they
    >> are).

For Atlas, [3-6]86  *are* appropriate from what I've read on the  octave
mailing list about this, and these probably account for 80%+  (?). 
Actually some people there where giving loud praises about
speed improvements for octave using Atlas -- I think not only on Intel&clones.

    KH> If we can give precise meaning to this, we can of course change the
    KH> configure time defaults accordingly.  Any suggestion?

(one of us would have to read Atlas docu).
The improvements for R wouldn't be so big, for one reason because we do NOT
use BLAS consistently
Btw, (commenting to things of yesterday or so):
     BLAS is much more basic than solve(.); solve(.) is Linpack level 
     which is on top of BLAS).

    KH> On the other hand, if we turn too much OFF by default, we will need
    KH> a mechanism for developers to store their standard R configure
    KH> arguments somewhere so that they do not have to retype them all the
    KH> time ...

;-)

Martin
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._