Hi Martin and Tomas,
Thanks for your reasoned replies. It seems that improving this is going to
take more effort in pinning down exactly what is appropriate than I
anticipated.
Sorry if the intention was to keep the initial discussion of this off the
list, I didn't mean to cause offence by copying my reply to the list.
I think I have to acknowledge that I am insufficiently familiar with R to
be able to do what you require in a reasonable time, so I will have to
leave this to someone else to pursue if they are so inclined. (I am an
infrastructure engineer rather than an R programmer.) For now, then, I will
continue as before, and locally patch that test to pass with the external
BLAS library on CentOS 7.
cheers,
Simon
On 5 January 2018 at 21:56, Martin Maechler
wrote:
> >>>>> Tomas Kalibera
> >>>>> on Fri, 5 Jan 2018 00:41:47 +0100 writes:
>
> > In practical terms, failing tests are not preventing anyone from
> using
> > an optimized BLAS/LAPACK implementation they trust. Building R with
> > dynamically linked BLAS on Unix is supported, documented and easy for
> > anyone who builds R from source. It is also how Debian/Ubuntu R
> packages
> > are built by default, so R uses whichever BLAS is installed in the
> > system and the user does not have to build from source. There is no
> > reason why not to do the same thing with another optimized BLAS on
> > another OS/distribution.
>
> > You may be right that reg-BLAS is too strict (it is testing matrix
> > products, expecting equivalence to naive three-loop algorithm, just
> part
> > of it really uses BLAS). I just wanted a concrete example to think
> about
> > as I can't repeat it (e.g. it passes with openblas), but maybe
> someone
> > else will be able to repeat and possibly adjust.
>
> > Tomas
>
> Yes, indeed! I strongly agree with Thomas: This is about
> serious quality assurance of an important part of R,
> and replacing all identical() checks there with all.equal()
> -- which has a default tolerance of allowing __HALF__ of the
>precision being lost !! -- in the way you, Simon, proposed,
> is definitely basically destroying the QC/QA we have in place there.
>
> As Tomas said, *some* of the checks possibly should be done
> all.equal, but with a very a small tolerance; however other
> checks should not allow a tolerance, e.g., all the arithmetic involving
> very small integer valued numbers should definitely be exact.
>
> That's why Tomas' (private!) reply, asking for specific details
> is 100% appropriate, indeed.
>
> With R we have had a philosophy of trying hard to be correct
> first, and fast second... and indeed the last 20 years have
> shown many cases where R's use (and checks) actually have
> reveiled not only inaccuracies but sometimes also bugs in
> LAPACK/BLAS implementations where it sometimes seems, some are
> only interested in speed, rather than correctness.
>
> Martin Maechler
> ETH Zurich
>
> > On 01/04/2018 09:23 PM, Simon Guest wrote:
> >> Hi Tomas,
> >>
> >> Thanks for your reply.
> >>
> >> I find your response curious, however. Surely the identical() test
> is
> >> simply incorrect when catering for possibly different BLAS
> >> implementations? Or is it the case that conformant BLAS
> >> implementations all produce bit-identical results, which seems
> >> unlikely? (Sorry, I am unfamiliar with the BLAS spec.) Although
> >> whatever the answer to this theoretical question, the CentOS 7
> >> external BLAS library evidently doesn't produce bit-identical
> results.
> >>
> >> If you don't agree that replacing identical() with all.equal() is
> >> clearly the right thing to do, as demonstrated by the CentOS 7
> >> external BLAS library failing the test, then I think I will give up
> >> now trying to help improve the R sources. I simply can't justify to
> >> my client more time spent on making this work, when we already have
> a
> >> local solution (which I hoped others would be able to benefit
> from).
> >> Ah well.
> >>
> >> cheers,
> >> Simon
> >>
> >> On 5 January 2018 at 00:07, Tomas Kalibera <
> tomas.kalib...@gmail.com
> >> <mailto:tomas.kalib...@gmail.com>> wrote:
> >>
> >> Hi Simon,
> >>
> >> we'd need more information to consider this - particularly which
> >> expression g
