From Kurt.Hornik@ci.tuwien.ac.at  Tue Jun  6 18:04:02 2000
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Tue, 6 Jun 2000 19:04:02 +0200
Subject: [Rd] make check on DU4 with R-1.1.0 snapshot
In-Reply-To: <Pine.OSF.4.21.0006051216460.25005-100000@zidsrv.sci.uni-klu.ac.at>
References: <Pine.GSO.4.05.10006030612260.5027-100000@auk.stats>
 <Pine.OSF.4.21.0006051216460.25005-100000@zidsrv.sci.uni-klu.ac.at>
Message-ID: <200006061704.TAA00374@aragorn.ci.tuwien.ac.at>

>>>>> Albrecht Gebhardt writes:

> On Sat, 3 Jun 2000, Prof Brian D Ripley wrote:
>> 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.

> I did not make any performance analysis for dxml, of course it should
> be better than plain BLAS or LAPACK. But I have it disabled in my
> setups for long now, because I ran frequently into troubles with
> special LAPACK routines. I remember the case where I used DSYEVX
> (selected symmetric eigenvalues/vectors) in one of my development
> libraries and got reproducable crashes, if R was linked with dxml, it
> was fine without. It even crashed when I downloaded the dsyevx source
> from netlib and put it into my library, R still jumped into DSYEVX
> from dxml and crashed.

Is that a problem with dxml or with R?  If dxml is buggy and does not
gain performance, then surely we should disable it by default.

> I guess I could gain much more performance if I could revert from
> using gcc/g77 back to DEC cc/f77, but this seems impossible or at
> least very difficult (R-1.1.0 compiles with DEC cc/f77 but has
> problems loading libjpeg when accessing the X11 code, and crashes with
> memory allocation problems in make check if called with --gui=none)

Hmm ... any ideas what is going on there?

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


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