non-complex %*% is fundamentally done via a call to dgemm, so the answer is going to depend on the BLAS library in use. When Doug Bates introduced that version of matprod, we did discuss a bit the potential problems of cases like this.
I've cross-checked, and that _is_ what is going on with my Linux box: try tracing around the call to dgemm in matprod in array.c.
Brian
You are right!
Indeed, I used the ATLAS (Athlon) optimized Rblas.dll (that one you provide on CRAN) for R-1.8.0 and R's default Rblas.dll under R-1.7.1.
Using the other version of Rblas.dll changes the outcomes.
So I get "0" for default Rblas.dll, and NA for the Athlon optimzed one.
Uwe Ligges
On Wed, 15 Oct 2003, Duncan Murdoch wrote:
On Wed, 15 Oct 2003 09:06:39 +0200 (MET DST), you wrote:
R-1.8.0: Does not happen for me on WindowsNT4.0 either (self compiled binary, gcc-3.3.1).
Does for me (RedHat, R 1.8.0 and 1.7.0).
I guess the problem is compiler-dependend, because I get that "0" in a self-compiled R-1.7.1 (has been compiled with gcc-3.2.?).
Is your binary self-compiled or from CRAN (Duncan Murdoch compiled the CRAN binary with gcc-3.3.1 as well, AFAIK)?
I get it in Win XP with both 1.8.0 (compiled with 3.3.1) and 1.7.1 (compiled with 3.2.x). I'd guess one of two things:
- it depends on the runtime library. (Windows versions use MSVCRT, but the exact version used depends on the system you're running on.) This doesn't seem to explain what happens on Linux, does it?
- it depends on some uninitialized variable. do_matprod is surprisingly complicated, so I can't tell if this is what's happening. For some reason Insight won't debug that function properly.
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
