[Rd] R-3.0.1 - "transient" make check failure in splines-EX.r

[Adler, Avraham]

I just found this thread on StackOverflow <http://stackoverflow.com/questions/13871818/ns-varies-for-no-apparent-reason/13878936> which had the same problem with the `ns` call changing with Revolution, and the answer given by tech support was that the MKL BLAS sometime returns ever-so-slightly different floating point results than a reference BLAS. The problem with that answer is that if it is true, the runs should not change *on the same machine* but it is another example of this issue. Unfortunately, it seems to dead-end too.

Avraham


-----Original Message-----
From: Adler, Avraham 
Sent: Thursday, May 30, 2013 3:12 PM
To: Paul Gilbert
Cc: r-devel at r-project.org
Subject: RE: R-3.0.1 - "transient" make check failure in splines-EX.r

Thank you very much, Paul.

Serendipitously, I seem to have stumbled on a solution. In my parallel (still unsuccessful) attempt to build a BLAS for a 64bit machine (see <https://stat.ethz.ch/pipermail/r-devel/2013-May/066731.html>) I remembered from ATLAS that under the newer Windows there is a divergence from the "standard" ABI (see <http://math-atlas.sourceforge.net/atlas_install/node57.html>).

Looking through the various makefiles under OpenBLAS, I found the following:

		ifeq ($(C_COMPILER), GCC)
		#Test for supporting MS_ABI
		GCCVERSIONGTEQ4 := $(shell expr `$(CC) -dumpversion | cut -f1 -d.` \>= 4)
		GCCVERSIONGT4 := $(shell expr `$(CC) -dumpversion | cut -f1 -d.` \> 4)
		GCCMINORVERSIONGTEQ7 := $(shell expr `$(CC) -dumpversion | cut -f2 -d.` \>= 7)
		ifeq ($(GCCVERSIONGT4), 1)
		# GCC Majar version > 4
		# It is compatible with MSVC ABI. 
		CCOMMON_OPT	+= -DMS_ABI
		endif
		
I had been building OPBL using gcc4.8.0, which is ostensibly "compatible" with the newer ABI, but Rtools still lives in 4.6.3, which isn't. Recompiling the BLAS with MinGW32 for 4.6.3 created a file that has passed `make check-all` twice now. I plan on comparing the speed with the ATLAS-based blas, and if it is faster, I hope to e-mail the dll and check results to Dr. Ligges.

I say "stumbled serendipitously" because when using the 64 bit version of MinGw 4.6.3 resulted in the same `optim`-based error in `factanal` which I describe in the thread linked-to above. I will try using different versions of MinGW or even trying under Cygwin, I guess.

In any event, Paul, I am curious if when you were trying to compile and had the same issue, were you using a different version or generation of gcc in the BLAS compilation than in the R compilation?

Once again, thank you very much.

Avraham Adler


-----Original Message-----
From: Paul Gilbert
Sent: Thursday, May 30, 2013 12:26 AM
To: Adler, Avraham
Subject: Re: R-3.0.1 - "transient" make check failure in splines-EX.r

Avraham

I resolved this only by switching to a different BLAS on the 32 bit machine.Since no one else seemed to be having problems, I considered it possible that there was a hardware issue on my old 32 bit machine. The R check test failed somewhat randomly, but often. most disconcertingly, it failed because it gives different answers. If you source the code in an R session a few times you have no trouble reproducing this. It gives the impression of an improperly zeroed matrix.

(All this from memory, I'm on the road.)

Paul

On 13-05-28 06:36 PM, Adler, Avraham wrote:
>
> Hello.
>
> I seem to be having the same problem that Paul had in the thread titled "[Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"" from October of last year <https://stat.ethz.ch/pipermail/r-devel/2012-October/065103.html> Unfortunately, that thread ended without an answer to his last question.
>
> Briefly, I am trying to compile an Rblas for Windows NT 32bit using OpenBlas (successor to GotoBlas) (Nehalem - corei7), and the compiled version passes all tests except for the "splines-Ex" test in the exact same place that Paul had issues:
>
> ~~~~
>> stopifnot(identical(ns(x), ns(x, df = 1)),
> +           identical(ns(x, df = 2), ns(x, df = 2, knots = NULL)), # not true till 2.15.2
> +           !is.null(kk <- attr(ns(x), "knots")), # not true till 1.5.1
> +           length(kk) == 0)
> Error: identical(ns(x, df = 2), ns(x, df = 2, knots = NULL)) is not 
> TRUE ~~~~
>
> Yet, opening up R and running the actual code shows that the error is transient:
>
> ~~~~
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] FALSE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] TRUE
>> identical(ns(x, df = 2), ns(x, df = 2, knots = NULL))
> [1] FALSE
> ~~~~
>
> This is the only error I have on the 32-bit version, I believe (trying to build a blas for 64-bit on SandyBridge is a completely different kettle of fish that is causing me to pull out what little hair I have left), and if it can be solved that would be great.
>
> Thank you,
>
> Avraham