Re: [Rd] OpenBLAS in everyday R?

[Avraham Adler]

On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara  wrote:
>
> Check if libopenblas is linked against libomp or libgomp.
>
> I’d be curious to see any errors that arise when an OpenMP version of 
> OpenBLAS is linked with R.
>
> Keith
>

The one time I tried compiling OpenBLAS for Windows 64 with USE OMP =
1, I got an error. I don't recall if it was in the compilation of R or
in use. Regardless, I compile OpenBLAS without setting that flag and
it still plays nicely with all R packages, including those that use
OpenMP.

Avi

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

Re: [Rd] OpenBLAS in everyday R?

[Keith O'Hara]

Check if libopenblas is linked against libomp or libgomp. 

I’d be curious to see any errors that arise when an OpenMP version of OpenBLAS 
is linked with R.

Keith


> On Jan 9, 2018, at 11:01 PM, Benjamin Tyner  wrote:
> 
> I didn't do the compile; is there a way to check whether that was used? If 
> not, I'll inquire with our sysadmin and report back.
> 
> In any case, my suggestion was motivated by the fact that some parts of R use 
> OpenMP while others do not, in the hope that the former could have their 
> OpenBLAS omelet without breaking the OpenMP eggs, so to speak.
> 
> 
> On 01/09/2018 06:41 PM, Keith O'Hara wrote:
>> Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ?
>> 
>> Keith
>> 
>>> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner  wrote:
>>> 
>>> Please pardon my ignorance, but doesn't OpenBLAS still not always play 
>>> nicely with multi-threaded OpenMP? (for example, don't race conditions 
>>> sometimes crop up)? If so, it might be nice to have the ability to 
>>> temporarily disable multi-threaded OpenMP (effectively: 
>>> omp_set_num_threads(1)) for the duration of operations using OpenBLAS.
>>> 
>>> Regards
>>> Ben
>>> 
 Julia using OpenBLAS is *very* reassuring.
 
 I agree that having it included as an options(...) feature should be OK.
 
 On Sun, Dec 17, 2017, 3:22 PM Juan Telleria >>> > wrote:
 
> /Julia Programming Language uses also OpenBlas, and it is actively 
> />/maintained with bugs being fixed as I have checked it out: 
> />//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to 
> be included as an options(...) feature (by default />/off, just for 
> safety), over other Blas libraries. />//>/R could not use Intel MKL for 
> legal reasons (I think), because as long />/that R ships with GPL 
> libraries, shipping R by default with Non-GPL is />/illegal. 
> />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" 
>  > />/escribió: />//>>/On 
> Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell  > wrote: />>/> It seems 
> like many of the multi-threaded BLASes have some sort of />>/> 
> fundamental problem preventing use in the way Juan suggests: />>/> />>/> 
> - Dirk's vignette states that ATLAS "fixes the number of cores used at 
> />>/> compile-time and cannot vary this setting at run-time", so any 
> />>/> user-friendly implementation for R would have to compile ATLAS for 
> 1-16 />>/> threads to allow the user to switch at run-time. This might 
> dramatically />>/> affect install times. />>/> />>/> - MKL seems like 
> it's been outright rejected in the past based on not />>/> being 
> "free-enough". />>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has 
> anyone tried ExBLAS for use with R? />>/> />>/> On Sun, Dec 17, 2017 at 
> 1:03 PM, Peter Langfelder < />>/> peter.langfelder at gmail.com 
> > wrote: />>/> />>/>> I 
> would be very cautious about OpenBLAS in particular... from time to 
> />>/>> time I get complains from users that compiled code calculations in 
> my />>/>> WGCNA package crash or produce wrong answers with large data, 
> and they />>/>> all come from OpenBLAS users. I am yet to reproduce any 
> of their />>/>> crashes when using MKL and ATLAS BLAS implementations. 
> />>/>> />>/>> Just my 2 cents... />>/>> />>/>> Peter />>//>>/I've been 
> building R on Windows 64 bit with OpenBLAS for years and my />>/builds 
> pass check-devel. For a while in the past it failed one check />>/as the 
> tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5 
> or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. 
> I provide descriptions here [1], but I haven't gone so far />>/as to post 
> compiled Rblas.dlls just yet. My personal build sets 4 />>/threads when 
> compiling OpenBLAS itself as I'm currently on a quad-core 
> />>/SandyBridge. In tests I ran a few years ago, both single and multi 
> />>/threaded BLAS compile and then can be compiled into R with no issues 
> />>/(on my platforms, at least). Most matrix operations performed better 
> />>/with multi-threaded except for R's eigenvalue decomposition, to the 
> />>/nest of my recollection. />>//>>/Avi />>//>>/[1] 
> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ 
> />>//>>/__ />>/R-devel at 
> 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.c

Re: [Rd] OpenBLAS in everyday R?

[Benjamin Tyner]

I didn't do the compile; is there a way to check whether that was used? 
If not, I'll inquire with our sysadmin and report back.


In any case, my suggestion was motivated by the fact that some parts of 
R use OpenMP while others do not, in the hope that the former could have 
their OpenBLAS omelet without breaking the OpenMP eggs, so to speak.



On 01/09/2018 06:41 PM, Keith O'Hara wrote:

Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ?

Keith


On Jan 9, 2018, at 6:03 PM, Benjamin Tyner  wrote:

Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely 
with multi-threaded OpenMP? (for example, don't race conditions sometimes crop 
up)? If so, it might be nice to have the ability to temporarily disable 
multi-threaded OpenMP (effectively: omp_set_num_threads(1)) for the duration of 
operations using OpenBLAS.

Regards
Ben


Julia using OpenBLAS is *very* reassuring.

I agree that having it included as an options(...) feature should be OK.

On Sun, Dec 17, 2017, 3:22 PM Juan Telleria https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote:


/Julia Programming Language uses also OpenBlas, and it is actively />/maintained with bugs being fixed as I have checked it out: />//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to be included as an options(...) feature (by default />/off, just for safety), over other Blas libraries. />//>/R could not use Intel MKL for legal reasons (I think), because as long />/that R ships with GPL libraries, shipping R by default with Non-GPL is />/illegal. />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" https://stat.ethz.ch/mailman/listinfo/r-devel>> />/escribió: />//>>/On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote: />>/> It seems like many of the multi-threaded BLASes have some sort of />>/> fundamental problem preventing use in the way Juan suggests: />>/> />>/> - Dirk's vignette states that ATLAS "fixes the number of cores used at />>/> compile-time and cannot vary this setting at run-time", so any />>/> user-friendly 
implementation for R would have to compile ATLAS for 1-16 />>/> threads to allow the user to switch at run-time. This might dramatically />>/> affect install times. />>/> />>/> - MKL seems like it's been outright rejected in the past based on not />>/> being "free-enough". />>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has anyone tried ExBLAS for use with R? />>/> />>/> On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder < />>/> peter.langfelder at gmail.com 
> wrote: />>/> />>/>> I would be very cautious about OpenBLAS in particular... from time to />>/>> time I get complains from users that compiled code calculations in my />>/>> WGCNA package crash or produce wrong answers with large data, and they />>/>> all come from OpenBLAS users. I am yet to reproduce any of their />>/>> crashes when using MKL and ATLAS BLAS implementations. />>/>> />>/>> Just my 2 cents... />>/>> />>/>> Peter 
/>>//>>/I've been building R on Windows 64 bit with OpenBLAS for years and my />>/builds pass check-devel. For a while in the past it failed one check />>/as the tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. I provide descriptions here [1], but I haven't gone so far />>/as to post compiled Rblas.dlls just yet. My personal build sets 4 />>/threads when compiling OpenBLAS itself as I'm currently on a quad-core />>/SandyBridge. In tests I ran a few years ago, both 
single and multi />>/threaded BLAS compile and then can be compiled into R with no issues />>/(on my platforms, at least). Most matrix operations performed better />>/with multi-threaded except for R's eigenvalue decomposition, to the />>/nest of my recollection. />>//>>/Avi />>//>>/[1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ />>//>>/__ />>/R-devel at 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


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

Re: [Rd] OpenBLAS in everyday R?

[Keith O'Hara]

Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ?

Keith

> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner  wrote:
> 
> Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely 
> with multi-threaded OpenMP? (for example, don't race conditions sometimes 
> crop up)? If so, it might be nice to have the ability to temporarily disable 
> multi-threaded OpenMP (effectively: omp_set_num_threads(1)) for the duration 
> of operations using OpenBLAS.
> 
> Regards
> Ben
> 
>> Julia using OpenBLAS is *very* reassuring.
>> 
>> I agree that having it included as an options(...) feature should be OK.
>> 
>> On Sun, Dec 17, 2017, 3:22 PM Juan Telleria > > wrote:
>> 
>> >/Julia Programming Language uses also OpenBlas, and it is actively 
>> >/>/maintained with bugs being fixed as I have checked it out: 
>> >/>//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to 
>> >be included as an options(...) feature (by default />/off, just for 
>> >safety), over other Blas libraries. />//>/R could not use Intel MKL for 
>> >legal reasons (I think), because as long />/that R ships with GPL 
>> >libraries, shipping R by default with Non-GPL is />/illegal. />//>/Cheers, 
>> >/>/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" > >gmail.com > />/escribió: 
>> >/>//>>/On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell > >> wrote: />>/> It seems like 
>> >many of the multi-threaded BLASes have some sort of />>/> fundamental 
>> >problem preventing use in the way Juan suggests: />>/> />>/> - Dirk's 
>> >vignette states that ATLAS "fixes the number of cores used at />>/> 
>> >compile-time and cannot vary this setting at run-time", so any />>/> 
>> >user-friendly implementation for R would have to compile ATLAS for 1-16 
>> >/>>/> threads to allow the user to switch at run-time. This might 
>> >dramatically />>/> affect install times. />>/> />>/> - MKL seems like it's 
>> >been outright rejected in the past based on not />>/> being "free-enough". 
>> >/>>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has anyone tried ExBLAS 
>> >for use with R? />>/> />>/> On Sun, Dec 17, 2017 at 1:03 PM, Peter 
>> >Langfelder < />>/> peter.langfelder at gmail.com 
>> >> wrote: />>/> />>/>> I 
>> >would be very cautious about OpenBLAS in particular... from time to />>/>> 
>> >time I get complains from users that compiled code calculations in my 
>> >/>>/>> WGCNA package crash or produce wrong answers with large data, and 
>> >they />>/>> all come from OpenBLAS users. I am yet to reproduce any of 
>> >their />>/>> crashes when using MKL and ATLAS BLAS implementations. />>/>> 
>> >/>>/>> Just my 2 cents... />>/>> />>/>> Peter />>//>>/I've been building R 
>> >on Windows 64 bit with OpenBLAS for years and my />>/builds pass 
>> >check-devel. For a while in the past it failed one check />>/as the 
>> >tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5 
>> >or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. I 
>> >provide descriptions here [1], but I haven't gone so far />>/as to post 
>> >compiled Rblas.dlls just yet. My personal build sets 4 />>/threads when 
>> >compiling OpenBLAS itself as I'm currently on a quad-core />>/SandyBridge. 
>> >In tests I ran a few years ago, both single and multi />>/threaded BLAS 
>> >compile and then can be compiled into R with no issues />>/(on my 
>> >platforms, at least). Most matrix operations performed better />>/with 
>> >multi-threaded except for R's eigenvalue decomposition, to the />>/nest of 
>> >my recollection. />>//>>/Avi />>//>>/[1] 
>> >https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ 
>> >/>>//>>/__ />>/R-devel at 
>> >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

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

Re: [Rd] OpenBLAS in everyday R?

[Benjamin Tyner]

Please pardon my ignorance, but doesn't OpenBLAS still not always play 
nicely with multi-threaded OpenMP? (for example, don't race conditions 
sometimes crop up)? If so, it might be nice to have the ability to 
temporarily disable multi-threaded OpenMP (effectively: 
omp_set_num_threads(1)) for the duration of operations using OpenBLAS.


Regards
Ben


Julia using OpenBLAS is *very* reassuring.

I agree that having it included as an options(...) feature should be OK.

On Sun, Dec 17, 2017, 3:22 PM Juan Telleria https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote:

>/Julia Programming Language uses also OpenBlas, and it is actively />/maintained with bugs being fixed as I have checked it out: />//>/http://www.openblas.net/Changelog.txt />//>/So I still see it ok to be included as an options(...) feature (by 
default />/off, just for safety), over other Blas libraries. />//>/R could not use Intel MKL for legal reasons (I think), because as long />/that R ships with GPL libraries, shipping R by default with Non-GPL is />/illegal. />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50 a. m., "Avraham Adler" > />/escribió: />//>>/On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell > wrote: />>/> It seems like many of the multi-threaded BLASes have some sort of />>/> fundamental problem preventing use in the way Juan suggests: />>/> />>/> - Dirk's vignette states that ATLAS "fixes the number of cores used at />>/> compile-time and cannot vary this setting at run-time", so any />>/> user-friendly implementation for R would have to compile ATLAS for 
1-16 />>/> threads to allow the user to switch at run-time. This might 
dramatically />>/> affect install times. />>/> />>/> - MKL seems like it's been outright rejected in the past based on not />>/> being "free-enough". />>/> />>/> - OpenBLAS causes crashes. />>/> />>/> Has anyone tried ExBLAS for use with R? />>/> />>/> On Sun, Dec 17, 2017 at 1:03 PM, Peter Langfelder < />>/> peter.langfelder at gmail.com 
> wrote: />>/> />>/>> I would be very cautious about OpenBLAS in particular... from time to />>/>> time I get complains from users that compiled code calculations in my />>/>> WGCNA package crash or produce wrong answers with large data, and 
they />>/>> all come from OpenBLAS users. I am yet to reproduce any of their />>/>> crashes when using MKL and ATLAS BLAS implementations. />>/>> />>/>> Just my 2 cents... />>/>> />>/>> Peter />>//>>/I've been building R on Windows 64 bit with OpenBLAS for years and my />>/builds pass check-devel. For a while in the past it failed one check />>/as the tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5 or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. I provide descriptions here [1], but I haven't gone so far />>/as to post compiled Rblas.dlls just yet. My personal build sets 4 />>/threads when compiling OpenBLAS itself as I'm currently on a quad-core />>/SandyBridge. In tests I ran a few years ago, both single and multi />>/threaded BLAS compile and then can be compiled into R with no issues />>/(on my platforms, at least). Most matrix operations performed better />>/with multi-threaded except for R's eigenvalue decomposition, to the />>/nest of my recollection. />>//>>/Avi />>//>>/[1] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ />>//>>/__ />>/R-devel at 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] Fixed BLAS tests for external BLAS library

[Simon Guest]

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
> >> > 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,
>

Re: [Rd] resolving a names conflict

[Thierry Onkelinx]

Dear Terry,

Why not have the required code in survival and use
importFrom(survival, gchol) in bdsmatrix? Since you maintain both,
that shouldn't be too complicated.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
AND FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given body
of data. ~ John Tukey
///




2018-01-09 16:37 GMT+01:00 Therneau, Terry M., Ph.D. :
> The survival package uses a generalized cholesky decompostition throughout.
> If A is a symmetric matrix A= LDL' where L is lower triangular with 1s on
> the diagonal, D is diagonal, and D[i,i] =0 if column i of A is redundant.
> Being able to read the rank and dependencies directly off of D is very
> handy.
>
> The bdsmatrix package uses the same, but exposes it to the user as gchol and
> solve methods in the NAMESPACE file.
>
> I'd like to expose it in survival as it would make some current development
> easier.
>
> How do I do this without causing warning messages for anyone who loads both,
> e.g., anyone using the coxme package?  The S4 structures are identical, but
> bdsmatrix has a superset of methods.   Adding importFrom(bdsmatrix, gchol)
> is one solution, of course, but it runs afoul of the current requirement
> that recommended packages import only from the core set.
>
> Terry T.
>
> __
> 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] resolving a names conflict

[Therneau, Terry M., Ph.D.]

The survival package uses a generalized cholesky decompostition throughout.  If A is a 
symmetric matrix A= LDL' where L is lower triangular with 1s on the diagonal, D is 
diagonal, and D[i,i] =0 if column i of A is redundant.  Being able to read the rank and 
dependencies directly off of D is very handy.


The bdsmatrix package uses the same, but exposes it to the user as gchol and solve methods 
in the NAMESPACE file.


I'd like to expose it in survival as it would make some current development 
easier.

How do I do this without causing warning messages for anyone who loads both, e.g., anyone 
using the coxme package?  The S4 structures are identical, but bdsmatrix has a superset of 
methods.   Adding importFrom(bdsmatrix, gchol) is one solution, of course, but it runs 
afoul of the current requirement that recommended packages import only from the core set.


Terry T.

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