Re: [Rd] Community Feedback: Git Repository for R-Devel

[Mark van der Loo]

This question has been discussed before on this list:
http://r.789695.n4.nabble.com/Why-R-project-source-code-is-not-on-Github-td4695779.html

See especially Jeroen's answer.

Best,
Mark

Op do 4 jan. 2018 om 01:11 schreef Juan Telleria :

> UNBIASED FACTS:
> • Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as
> Ticketing platforms for bug pull requests on the R-devel Git Repository.
>
> •  Git Repository Options:
> A) Github (Cloud with Automated backups from GitHub to CRAN Server):
> https://github.com
> B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com
> C) Phabricator (Selfhosted on CRAN): https://www.phacility.com
> D) Microsoft Codeplex: https://www.codeplex.com
> E) Others: Unknown
>
> GOOGLE TRENDS:
> https://trends.google.com/trends/explore?date=all&q=Git,Svn,Github,Gitlab
>
> EXAMPLE
> Git Repository on Core Python: https://github.com/python
>
> PERSONAL OPINION / MOTIVATION:
> I think that moving efforts in this direction is important because it would
> allow a true Open Source Innovation & Open Collaboration in R between:
> * R Community.
> * And R-Core.
> For:
> * R Bug Fixes.
> * And Core Feature Wishlist.
> As anyone would be able to:
> * Check the unassigned bugs in Bugzilla (apart from R-Core).
> * And propose bugs fixes by themselves as Pull requests (by mentioning the
> Bug ID of Bugzilla or the Mailing Lists).
>
> This would allow that _individuals_ either from Universities or Companies
> interested in the Development of R:
> * apart of donating economical resources to the R Foundation.
> * could help to maintain core R Code by themselves.
> Which aligns with the true spirit of R, which shall be done from
> contributing individuals, for individuals themselves.
>
> It would also allow to put the focus on the precise lines of code changed
> with each Commit, and revert changes in an easy way, without verbose
> E-mails: Tidy, Clean, Maintainable, and Fast.
>
> At last, I noticed R-devel Archives do not have an E-mail Id (Unique
> Unsigned Integer), so it would be a good idea to add one for pull requests
> if Git was adopted.
>
> Juan
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Coping with non-standard evaluation in R program analysis

[jan Vitek]

Hi Evan,

You may find some parts of what we are doing with genthat useful.  Genthat is a 
tool
for creating unit tests by recording argument and return values of calls. This 
is
done by instrumentation of the source code.

The git repo with the code is here https://github.com/PRL-PRG/genthat

We don’t really deal with NSE though. It could be something worth thinking 
about for us.
The contact for genthtat is Filip.


We are also writing a tool for analyzing promises and generating execution 
traces
within the R VM.  This is available in 
https://github.com/PRL-PRG/R-dyntrace

Aviral and Konrad are the contacts there.


Best,

jan






Jan Vitek, Professor 
Computer Science, 
Northeastern University

> On Jan 3, 2018, at 7:18 PM, Peter Meilstrup  wrote:
> 
> For 2), it is not exposed in R's standard library but it is exposed in
> the Rinternals API. A promise that is forced in normal evaluation will
> have PRENV set to NULL.
> 
> Peter
> 
> On Tue, Jan 2, 2018 at 4:19 PM, Evan James Patterson
>  wrote:
>> Hello R experts,
>> 
>> 
>> I plan to develop a tool for dynamic analysis of R programs. I would like to 
>> trace function calls at runtime, capturing argument and return values. 
>> Following a suggestion made some time ago on this list, my high-level 
>> implementation strategy is to rewrite the AST, augmenting call expressions 
>> with pre-call and post-call shims to capture the arguments and return value, 
>> respectively.
>> 
>> 
>> I can think of only one fundamental conceptual obstacle to this approach: R 
>> functions are not necessarily referentially transparent. The arguments 
>> received by a function are not values but promises. They can be evaluated 
>> directly ("standard evaluation"), after applying arbitrary syntactic 
>> transformations ("non-standard evaluation", aka NSE), or not at all. 
>> Therefore, if you peek at the values of function arguments before evaluating 
>> the function, you risk altering the semantics of the program, possibly 
>> fatally.
>> 
>> 
>> I'm looking for general advice about how to cope with NSE in this context. I 
>> also have some specific questions:
>> 
>> 
>> 1) Is it possible to determine whether a given function (primitive, in R, or 
>> external) uses NSE on some or all of its arguments?
>> 
>> 
>> 2) Is it possible to inspect the promise objects received by functions, say 
>> to determine whether they have been evaluated, without actually evaluating 
>> them? The R manual is not encouraging in this area:
>> 
>> 
>> https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Promise-objects
>> 
>> 
>> Thank you,
>> 
>> 
>> Evan
>> 
>> 
>>   [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] silent recycling in logical indexing

[Ben Bolker]

  Sorry if this has been covered here somewhere in the past, but ...

  Does anyone know why logical vectors are *silently* recycled, even
when they are incommensurate lengths, when doing logical indexing?  This
is as documented:

  For ‘[’-indexing only: ‘i’, ‘j’, ‘...’ can be logical
  vectors, indicating elements/slices to select.  Such vectors
  are recycled if necessary to match the corresponding extent.

but IMO weird:

> x <- c(TRUE,TRUE,FALSE)
> y <- c(TRUE,FALSE)
> x[y]
[1]  TRUE FALSE

## (TRUE, FALSE) gets recycled to (TRUE,FALSE,TRUE) and selects
##  the first and third elements

If we do logical operations instead we do get a warning:

> x | y
[1] TRUE TRUE TRUE
Warning message:
In x | y : longer object length is not a multiple of shorter object length

  Is it just too expensive to test for incomplete recycling when doing
subsetting, or is there a sensible use case for incomplete recycling?

  Ll. 546ff of main/src/subscript.c suggest that there is a place in the
code where we already know if incomplete recycling has happened ...

 Thoughts?

   cheers
 Ben Bolker

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Fixed BLAS tests for external BLAS library

[Simon Guest]

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  wrote:

> Hi Simon,
>
> we'd need more information to consider this - particularly which
> expression gives an imprecise result with ACML and what are the computed
> values, differences. It is not common for optimized BLAS implementations to
> fail reg-BLAS.R tests, but it is common for them to report numerical
> differences in tests of various recommended packages where more complicated
> computations are done (e.g. nlme), on various platforms.
>
> Best
> Tomas
>
>
> On 12/18/2017 08:56 PM, Simon Guest wrote:
>
>> We build R with dynamically linked BLAS and LAPACK libraries, in order
>> to use the AMD Core Math Library (ACML) multi-threaded implementation
>> of these routines on our 64 core servers.  This is great, and our
>> users really appreciate it.
>>
>> However, when building like this, make check fails on the reg-BLAS.R
>> test.  The reason for this is that the expected test output is checked
>> using identical.  By changing all uses of identical in this file to
>> all.equal, the tests pass.
>>
>> Specifically, I run this command before make check:
>>
>> $ sed -i -e 's/identical/all.equal/g' tests/reg-BLAS.R
>>
>> I suggest that the test is fixed like this in the R source code.
>>
>> Here is the configure command I use, on CentOS 7:
>> $ ./configure --with-system-zlib --with-system-bzlib --with-system-pcre \
>>  --with-blas \
>>  --with-lapack \
>>  --with-tcl-config=/usr/lib64/tclConfig.sh \
>>  --with-tk-config=/usr/lib64/tkConfig.sh \
>>  --enable-R-shlib \
>>  --enable-prebuilt-html
>>
>> cheers,
>> Simon
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] silent recycling in logical indexing

[William Dunlap via R-devel]

One use case is when you want to extract every third item, starting with
the second, of an arbitrary vector with
x[c(FALSE, TRUE, FALSE)]
instead of
x[seq_along(x) %% 3 == 2]

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Jan 4, 2018 at 11:56 AM, Ben Bolker  wrote:

>
>   Sorry if this has been covered here somewhere in the past, but ...
>
>   Does anyone know why logical vectors are *silently* recycled, even
> when they are incommensurate lengths, when doing logical indexing?  This
> is as documented:
>
>   For ‘[’-indexing only: ‘i’, ‘j’, ‘...’ can be logical
>   vectors, indicating elements/slices to select.  Such vectors
>   are recycled if necessary to match the corresponding extent.
>
> but IMO weird:
>
> > x <- c(TRUE,TRUE,FALSE)
> > y <- c(TRUE,FALSE)
> > x[y]
> [1]  TRUE FALSE
>
> ## (TRUE, FALSE) gets recycled to (TRUE,FALSE,TRUE) and selects
> ##  the first and third elements
>
> If we do logical operations instead we do get a warning:
>
> > x | y
> [1] TRUE TRUE TRUE
> Warning message:
> In x | y : longer object length is not a multiple of shorter object length
>
>   Is it just too expensive to test for incomplete recycling when doing
> subsetting, or is there a sensible use case for incomplete recycling?
>
>   Ll. 546ff of main/src/subscript.c suggest that there is a place in the
> code where we already know if incomplete recycling has happened ...
>
>  Thoughts?
>
>cheers
>  Ben Bolker
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] silent recycling in logical indexing

[Berry, Charles]

> On Jan 4, 2018, at 11:56 AM, Ben Bolker  wrote:
> 
> 
>  Sorry if this has been covered here somewhere in the past, but ...
> 
>  Does anyone know why logical vectors are *silently* recycled, even
> when they are incommensurate lengths, when doing logical indexing? 

It is convenient to use a single `TRUE' in programmatic manipulation of 
subscripts in the same manner as using an empty subscript interactively:

> mat<-diag(1:3)
> expr1 <- quote(mat[])
> expr1[[3]] <- TRUE
> expr1[[4]] <- 2
> eval(expr1)
[1] 0 2 0
> mat[,2]
[1] 0 2 0

HTH,

Chuck
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] silent recycling in logical indexing

[Ben Bolker]

Hmm.

Chuck: I don't see how this example represents
incomplete/incommensurate recycling. Doesn't TRUE replicate from
length-1 to length-3 in this case (mat[c(TRUE,FALSE),2] would be an
example of incomplete recycling)?

William: clever, but maybe too clever unless you really need the
speed? (The clever way is 8 times faster in the following case ...)

x <- rep(1,1e6)
rbenchmark::benchmark(x[c(FALSE,TRUE,FALSE)],x[seq_along(x) %% 3 == 2])

On the other hand, it takes 0.025 vs 0.003 seconds per iteration ...
fortunes::fortune("7ms")


On Thu, Jan 4, 2018 at 4:09 PM, Berry, Charles  wrote:
>
>
>> On Jan 4, 2018, at 11:56 AM, Ben Bolker  wrote:
>>
>>
>>  Sorry if this has been covered here somewhere in the past, but ...
>>
>>  Does anyone know why logical vectors are *silently* recycled, even
>> when they are incommensurate lengths, when doing logical indexing?
>
> It is convenient to use a single `TRUE' in programmatic manipulation of 
> subscripts in the same manner as using an empty subscript interactively:
>
>> mat<-diag(1:3)
>> expr1 <- quote(mat[])
>> expr1[[3]] <- TRUE
>> expr1[[4]] <- 2
>> eval(expr1)
> [1] 0 2 0
>> mat[,2]
> [1] 0 2 0
>
> HTH,
>
> Chuck

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] silent recycling in logical indexing

[Ben Bolker]

PS I'm tempted to insert a warning at this point and see how often it
actually gets triggered ...

On Thu, Jan 4, 2018 at 4:44 PM, Ben Bolker  wrote:
> Hmm.
>
> Chuck: I don't see how this example represents
> incomplete/incommensurate recycling. Doesn't TRUE replicate from
> length-1 to length-3 in this case (mat[c(TRUE,FALSE),2] would be an
> example of incomplete recycling)?
>
> William: clever, but maybe too clever unless you really need the
> speed? (The clever way is 8 times faster in the following case ...)
>
> x <- rep(1,1e6)
> rbenchmark::benchmark(x[c(FALSE,TRUE,FALSE)],x[seq_along(x) %% 3 == 2])
>
> On the other hand, it takes 0.025 vs 0.003 seconds per iteration ...
> fortunes::fortune("7ms")
>
>
> On Thu, Jan 4, 2018 at 4:09 PM, Berry, Charles  wrote:
>>
>>
>>> On Jan 4, 2018, at 11:56 AM, Ben Bolker  wrote:
>>>
>>>
>>>  Sorry if this has been covered here somewhere in the past, but ...
>>>
>>>  Does anyone know why logical vectors are *silently* recycled, even
>>> when they are incommensurate lengths, when doing logical indexing?
>>
>> It is convenient to use a single `TRUE' in programmatic manipulation of 
>> subscripts in the same manner as using an empty subscript interactively:
>>
>>> mat<-diag(1:3)
>>> expr1 <- quote(mat[])
>>> expr1[[3]] <- TRUE
>>> expr1[[4]] <- 2
>>> eval(expr1)
>> [1] 0 2 0
>>> mat[,2]
>> [1] 0 2 0
>>
>> HTH,
>>
>> Chuck

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] silent recycling in logical indexing

[Berry, Charles]

> On Jan 4, 2018, at 1:44 PM, Ben Bolker  wrote:
> 
> Chuck: I don't see how this example represents
> incomplete/incommensurate recycling. 


It doesn't. I took your subject line to be the theme of your posting and 
`incommensurate lengths' to be an instance used to emphasize how silent 
recycling might `bite' the user. 

Chuck
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] silent recycling in logical indexing

[William Dunlap via R-devel]

I have never used this construct.  However, part of my job is seeing how
well CRAN packages work in our reimplementation of the R language
and I am continually surprised by the inventiveness of package writers.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Thu, Jan 4, 2018 at 1:44 PM, Ben Bolker  wrote:

> Hmm.
>
> Chuck: I don't see how this example represents
> incomplete/incommensurate recycling. Doesn't TRUE replicate from
> length-1 to length-3 in this case (mat[c(TRUE,FALSE),2] would be an
> example of incomplete recycling)?
>
> William: clever, but maybe too clever unless you really need the
> speed? (The clever way is 8 times faster in the following case ...)
>
> x <- rep(1,1e6)
> rbenchmark::benchmark(x[c(FALSE,TRUE,FALSE)],x[seq_along(x) %% 3 == 2])
>
> On the other hand, it takes 0.025 vs 0.003 seconds per iteration ...
> fortunes::fortune("7ms")
>
>
> On Thu, Jan 4, 2018 at 4:09 PM, Berry, Charles  wrote:
> >
> >
> >> On Jan 4, 2018, at 11:56 AM, Ben Bolker  wrote:
> >>
> >>
> >>  Sorry if this has been covered here somewhere in the past, but ...
> >>
> >>  Does anyone know why logical vectors are *silently* recycled, even
> >> when they are incommensurate lengths, when doing logical indexing?
> >
> > It is convenient to use a single `TRUE' in programmatic manipulation of
> subscripts in the same manner as using an empty subscript interactively:
> >
> >> mat<-diag(1:3)
> >> expr1 <- quote(mat[])
> >> expr1[[3]] <- TRUE
> >> expr1[[4]] <- 2
> >> eval(expr1)
> > [1] 0 2 0
> >> mat[,2]
> > [1] 0 2 0
> >
> > HTH,
> >
> > Chuck
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Community Feedback: Git Repository for R-Devel

[Juan Telleria]

Thank you Mark, this is what I was looking for.

On Sunday I will read again in detail previous discussion's facts, and
attach the pros and cons here, so that they remain for the future, and the
topic can be closed.

Juan

El 4 ene. 2018 11:06 a. m., "Mark van der Loo" 
escribió:

> This question has been discussed before on this list:
> http://r.789695.n4.nabble.com/Why-R-project-source-code-is-
> not-on-Github-td4695779.html
>
> See especially Jeroen's answer.
>
> Best,
> Mark
>
> Op do 4 jan. 2018 om 01:11 schreef Juan Telleria :
>
>> UNBIASED FACTS:
>> • Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as
>> Ticketing platforms for bug pull requests on the R-devel Git Repository.
>>
>> •  Git Repository Options:
>> A) Github (Cloud with Automated backups from GitHub to CRAN Server):
>> https://github.com
>> B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com
>> C) Phabricator (Selfhosted on CRAN): https://www.phacility.com
>> D) Microsoft Codeplex: https://www.codeplex.com
>> E) Others: Unknown
>>
>> GOOGLE TRENDS:
>> https://trends.google.com/trends/explore?date=all&q=Git,Svn,Github,Gitlab
>>
>> EXAMPLE
>> Git Repository on Core Python: https://github.com/python
>>
>> PERSONAL OPINION / MOTIVATION:
>> I think that moving efforts in this direction is important because it
>> would
>> allow a true Open Source Innovation & Open Collaboration in R between:
>> * R Community.
>> * And R-Core.
>> For:
>> * R Bug Fixes.
>> * And Core Feature Wishlist.
>> As anyone would be able to:
>> * Check the unassigned bugs in Bugzilla (apart from R-Core).
>> * And propose bugs fixes by themselves as Pull requests (by mentioning the
>> Bug ID of Bugzilla or the Mailing Lists).
>>
>> This would allow that _individuals_ either from Universities or Companies
>> interested in the Development of R:
>> * apart of donating economical resources to the R Foundation.
>> * could help to maintain core R Code by themselves.
>> Which aligns with the true spirit of R, which shall be done from
>> contributing individuals, for individuals themselves.
>>
>> It would also allow to put the focus on the precise lines of code changed
>> with each Commit, and revert changes in an easy way, without verbose
>> E-mails: Tidy, Clean, Maintainable, and Fast.
>>
>> At last, I noticed R-devel Archives do not have an E-mail Id (Unique
>> Unsigned Integer), so it would be a good idea to add one for pull requests
>> if Git was adopted.
>>
>> Juan
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check warning about compiler warning flags

[Juan Telleria]

I repeat it for all the reason I gave to Duncan on a personal E-mail, It is
a lot of text, and I might be wrong, but I attach it in case it is useful:

A) I feel Version Control (SVN) is great when there is a little group of
people maintaining the code (RCore ~ 20); but Git could allow a bigger
group of people (for example ~200) working simultaneously on perfect and
polish the code without overlapping each other, and RCore (~20) check that
code, and do commits.

This would allow an even more robust base language foundation, or
improvements such as writing some base code more efficiently in C++, etc.

I will put a SQL Transactions simile for further explain this issue:
* SVN is like a Table-Lock.
* And GIT is a Row-Lock in the Table.

Table-Lock works well with very few connections, and as there are only few
connections, users are happy with it.

But it prevents other client connections to query that table at the same
time, and does not allow high concurrency.

B) I feel that Version Control is a little bit obscure for people who are
not from R-Core Mailing List, as:
* We cannot see what gets updated with each R-devel specific version.
* And have communication tools flexible enough to suggest a little patch
(changes in a few lines of code all scattered over R Code) by ourselves
other than E-mails. ¿What if our fixes are very sparse?

Communication and Patches for Collaboration are difficult and tedious for
Non-Core Contributors.

C) Reverting a whole version can cause that bugs that where already fixed,
to be reverted (I've seen it once in R).

D) Making a whole new version for a single change in 1 line of code is
inefficient, and time consuming. In GitHub it would take few seconds.

E) Google Trends indicates that GIT is getting more and more used than SVN
by other developments. If it works for others, why should not work for R?

F) It would also be important to know what the opinion of key R
contributors outside R-Core is, for example:

* Hadley Wickham.
* Other important R Package Authors.

If they would feel more willing to help on R Core Language Development with
GitHub, Gitlab, etc.

Juan

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Fixed BLAS tests for external BLAS library

[Tomas Kalibera]

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

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  > wrote:
>
> Hi Simon,
>
> we'd need more information to consider this - particularly which
> expression gives an imprecise result with ACML and what are the
> computed values, differences. It is not common for optimized BLAS
> implementations to fail reg-BLAS.R tests, but it is common for
> them to report numerical differences in tests of various
> recommended packages where more complicated computations are done
> (e.g. nlme), on various platforms.
>
> Best
> Tomas
>
>
> On 12/18/2017 08:56 PM, Simon Guest wrote:
>
> We build R with dynamically linked BLAS and LAPACK libraries,
> in order
> to use the AMD Core Math Library (ACML) multi-threaded
> implementation
> of these routines on our 64 core servers.  This is great, and our
> users really appreciate it.
>
> However, when building like this, make check fails on the
> reg-BLAS.R
> test.  The reason for this is that the expected test output is
> checked
> using identical.  By changing all uses of identical in this
> file to
> all.equal, the tests pass.
>
> Specifically, I run this command before make check:
>
> $ sed -i -e 's/identical/all.equal/g' tests/reg-BLAS.R
>
> I suggest that the test is fixed like this in the R source code.
>
> Here is the configure command I use, on CentOS 7:
> $ ./configure --with-system-zlib --with-system-bzlib
> --with-system-pcre \
>      --with-blas \
>      --with-lapack \
>      --with-tcl-config=/usr/lib64/tclConfig.sh \
>      --with-tk-config=/usr/lib64/tkConfig.sh \
>      --enable-R-shlib \
>      --enable-prebuilt-html
>
> cheers,
> Simon
>
> __
> R-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>
>
>
>


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel