Re: [Rd] Renjin?
> Brian G Peterson
> on Sun, 29 Oct 2017 10:58:31 -0500 writes:
> Renjin is not R. Renjin is an R language interpreter
> written in Java.
> It has become exceedingly obvious that you are making user
> errors. That's not a bug in the language.
> If you want to use Renjin, there are mailing lists devoted
> to Renjin, and also Stack Overflow and Renjin list
> questions that cover exactly what you've asked about
> (loading packages in Renjin when Renjin is used as a Java
> library). So I have to conclude that you didn't look very
> hard before posting (again).
> In any event, the R-devel list is for the development of
> the R language itself, and issues *with the core
> language*. It is not a user help list. (this is all
> described in the list signup page:
> https://stat.ethz.ch/mailman/listinfo/r-devel )
> Regards,
> Brian
Yes, indeed!
Thank you Brian.
Morkus: Do *STOP* using the R-devel mailing list for now, and
use R-help instead. You are absolutely misusing R-devel currently!
Martin Maechler
ETH Zurich (and co-maintainer of the R-devel list)
> On Sun, 2017-10-29 at 11:50 -0400, Morkus wrote:
>> Brian,
>>
>> Huh?
>>
>> I did read the documentation, but I didn't understand how
>> to do what I wanted from what I read -- as there was no
>> example of what I was trying to do.
>>
>> Hence a posting.
>>
>> Isn't that how (development) forums work?
>>
>> I really don't understand why posting a developer
>> question on the development forum elicits a response like
>> yours.
>>
>> I'm baffled by these kinds of replies.
>>
>> And we both know if I post code on the regular R-help
>> list, I'll get a snarky response that I should have put
>> that posting on the R- Develop list.
>>
>> I get it if you don't know the answer, but please try to
>> be nice and assume the best about the poster.
>>
>> Thanks.
>>
>> Sent from ProtonMail, Swiss-based encrypted email.
>>
>>
>>
>> > Original Message > Subject: Re: [Rd]
>> Renjin? > Local Time: October 29, 2017 11:37 AM > UTC
>> Time: October 29, 2017 3:37 PM > From:
>> br...@braverock.com > To: Morkus ,
>> r-devel@r-project.org r-project.org>
>> >
>> > Please move this to r-help. It is clear that this is
>> not a problem > with R itself, but with your ability to
>> search the internet and > read > the documentation and
>> the code before posting.
>> >
>> > On Sun, 2017-10-29 at 11:34 -0400, Morkus via R-devel
>> wrote:
>> >
>> > Hi All, > OK, in the "back to the drawing board"
>> department, I found what > looks > like a much better
>> solution to using R in Java. Renjin.
>> >
>> > Looking at the docs and then trying a quick example,
>> didn't quite > work.
>> >
>> > Of course I'm missing something. > Although I'm
>> telling the engine to require ("biotools") just like I >
>> would in R itself, when I get to the line of code that
>> does the > actual call
>> >
>> > engine.eval("boxMResult <- boxM(inputIris [,-5],
>> inputIris[,5])"); > Then, I get: > Exception in thread
>> "main" org.renjin.eval.EvalException: could not > find
>> function 'boxM'
>> >
>> > Am I using Renjin as intended? Biotools is installed in
>> R and works > fine from RStudio.
>> >
>> > I didn't see any examples in the docs (please excuse if
>> I missed) > that bring in any libraries.
>> >
>> > Entire Java source below. > Thanks in advance,
>> >
>> > public class RCallerExample{ > public static void
>> main(String[] args) > { > // create a script engine
>> manager:RenjinScriptEngineFactory factory > = > new
>> RenjinScriptEngineFactory(); > // create a Renjin
>> engine:ScriptEngine engine = > factory.getScriptEngine();
>> >
>> > try{ > engine.eval("require(biotools)");
>> >
>> > String inputIris = "5.1,3.5,1.4,0.2,setosa\n" + >
>> "4.9,3,1.4,0.2,setosa\n" + > "4.7,3.2,1.3,0.2,setosa\n" +
>> > "4.6,3.1,1.5,0.2,setosa\n" + > "5,3.6,1.4,0.2,setosa\n"
>> + > "5.4,3.9,1.7,0.4,setosa\n" + >
>> "4.6,3.4,1.4,0.3,setosa\n" + > "5,3.4,1.5,0.2,setosa\n" +
>> > "4.4,2.9,1.4,0.2,setosa\n" + >
>> "4.9,3.1,1.5,0.1,setosa\n" + > "5.4,3.7,1.5,0.2,setosa\n"
>> + > "4.8,3.4,1.6,0.2,setosa\n" + >
>> "4.8,3,1.4,0.1,setosa\n" + > "4.3,3,1.1,0.1,setosa\n" + >
>> "5.8,4,1.2,0.2,setosa\n" + > "5.7,4.4,1.5,0.4,setosa\n" +
>> > "5.4,3.9,1.3,0.4,setosa\n" + >
>> "5.1,3.5,1.4,0.3,setosa\n" + > "5.7,3.8,1.7,0.3,setosa\n"
>> + > "5.1,3.8,1.5,0.3,setosa\n" + >
>> "5.4,3.4,1.7,0.2,setosa\n" + > "5.1,3.7,1.5,0.4,setosa\n"
>> + > "4.6,3.6,1,0.2,setosa\n" + >
>> "5.1,3.3,1.7,0.5,setosa\n" + > "4.8,3.4,1.9,0.2,setosa\n"
Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?
On Sun, Oct 29, 2017 at 11:09 PM, Dirk Eddelbuettel wrote: > > On 29 October 2017 at 22:01, Kenny Bell wrote: > | User here: incorporating Intel's MKL, as MRO does, would be a very welcome > | addition. > | > | I was an MRO user before and it improved my experience with medium data > | immensely. > | > | They did, however, leave behind bugs here and there, especially related to > | development with Rcpp, so I switched back to vanilla R. > > With all due respect: You may miss something. MKL has always worked with > 'Base R'. > > As a point of reference and comparison, I set up a benchmarking and > comparison package _well over half a decade ago_ and while it never get fully > finished to the point of a submitted paper the vignette still stands---and > demonstrates that _dropping in MKL is a one-line operation_. > > And always has been. There may have been some license arbitrage: Intel was > an early investor in Revo, so MKL was pushed hard. With GotoBLAS and later > OpenBLAS I cared less, but IIRC the license of MKL is a little simpler for > "mere use" now. > > See https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf for > more. FWIW, I've been using openBlas for years now, based on this and other benchmarks. It provides performance comparable to MKL while being really free. Best, Ista > > Hth, Dirk > > | > | On Mon, Oct 30, 2017, 9:42 AM Juan Telleria wrote: > | > | > Dear R Developers, > | > > | > First of all, I would like to thank you Jeroen Ooms for taking the binary > | > Window Builds from Duncan. I firmly believe that the R Community will > | > benefit a lot from his work. > | > > | > However, the debate I would like to open is about if some of Microsoft R > | > Open Code shall be ported from R Open to Mainstream R. > | > > | > There are some beneficts in R Open such as multithreaded performance: > | > https://mran.microsoft.com/documents/rro/multithread/ > | > > | > Maybe, the R Consortium, and in particular, Microsoft R Team, could > | > collaborate, if appropriate, in such duty. > | > > | > Thank you, > | > Juan Telleria > | > > | > [[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 > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > 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] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?
I think the thing that is missing is a simple way for end users on windows to replace blas/lapack libraries with MKL-a package that you install that puts the libraries in the right place. Microsoft provides something for their distro, but we don't have the equivalent if you get R from cran. On 29 October 2017 at 22:01, Kenny Bell wrote: | User here: incorporating Intel's MKL, as MRO does, would be a very welcome | addition. | | I was an MRO user before and it improved my experience with medium data | immensely. | | They did, however, leave behind bugs here and there, especially related to | development with Rcpp, so I switched back to vanilla R. With all due respect: You may miss something. MKL has always worked with 'Base R'. As a point of reference and comparison, I set up a benchmarking and comparison package _well over half a decade ago_ and while it never get fully finished to the point of a submitted paper the vignette still stands---and demonstrates that _dropping in MKL is a one-line operation_. And always has been. There may have been some license arbitrage: Intel was an early investor in Revo, so MKL was pushed hard. With GotoBLAS and later OpenBLAS I cared less, but IIRC the license of MKL is a little simpler for "mere use" now. See https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf for more. Hth, Dirk [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?
[Sent offlist accidentally] What concerns me first and foremost is that the licensure would have to be ironclad (including for commercial use like vanilla R now) as well as ensuring that R remains completely FLOSS. Anything “added” to R has to be a no-strings-attached gift to R. Also, I would think that it would have to play nice with existing workflows (like OpenBLAS instead of MKL) unless there is such a benefit that it is worth breaking compatibility. Avi On Sun, Oct 29, 2017 at 6:01 PM, Kenny Bell wrote: > User here: incorporating Intel's MKL, as MRO does, would be a very welcome > addition. > > I was an MRO user before and it improved my experience with medium data > immensely. > > They did, however, leave behind bugs here and there, especially related to > development with Rcpp, so I switched back to vanilla R. > > On Mon, Oct 30, 2017, 9:42 AM Juan Telleria wrote: > >> Dear R Developers, >> >> First of all, I would like to thank you Jeroen Ooms for taking the binary >> Window Builds from Duncan. I firmly believe that the R Community will >> benefit a lot from his work. >> >> However, the debate I would like to open is about if some of Microsoft R >> Open Code shall be ported from R Open to Mainstream R. >> >> There are some beneficts in R Open such as multithreaded performance: >> https://mran.microsoft.com/documents/rro/multithread/ >> >> Maybe, the R Consortium, and in particular, Microsoft R Team, could >> collaborate, if appropriate, in such duty. >> >> Thank you, >> Juan Telleria >> >> [[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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?
On Mon, Oct 30, 2017 at 12:45 PM, Cohn, Robert S wrote: > I think the thing that is missing is a simple way for end users on windows to > replace blas/lapack libraries with MKL-a package that you install that puts > the libraries in the right place. > > Microsoft provides something for their distro, but we don't have the > equivalent if you get R from cran. > Dr. Ei-ji Nakama has some compiled GotoBLAS Rblas DLLs on his site [1], but they are rather old now. I've toyed with the idea of doing something similar for OpenBLAS—which requires tricking R into thinking it's ATLAS [2]—and hosting at least a Sandy Bridge and a dynamic version. I'm not sure how the licenses and copyrights would interact though. Also, that only works for the BLAS. Using an optimized LAPACK is even more difficult. On Unix-likes, the manual does not recommend it but it's allowed as an option in the configure [3]. For OpenBLAS (and ATLAS for that matter), even though one can build an optimized LAPACK, there is no way to access the build of the LAPACK on Windows through Mkrules.local, and R_HOME/src/modules/lapack/README makes it seem to be rather difficult, if not impossible. I believe the MKL includes a specialized LAPACK; I do not know if this is compiled into M$ R, though. Thanks, Avi [1] https://prs.ism.ac.jp/~nakama/SurviveGotoBLAS2/binary/windows/ [2] https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ [3] https://cran.r-project.org/doc/manuals/r-release/R-admin.html#LAPACK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?
On Mon, Oct 30, 2017 at 12:45 PM, Cohn, Robert S wrote: > I think the thing that is missing is a simple way for end users on windows to > replace blas/lapack libraries with MKL-a package that you install that puts > the libraries in the right place. > > Microsoft provides something for their distro, but we don't have the > equivalent if you get R from cran. I don't have any interest in using a proprietary BLAS when a perfectly good free alternative exists. If we just care about performance, swapping out the reference BLAS for openBLAS is pretty simple apparently: - Download pre-compiled openblas from https://sourceforge.net/projects/openblas/files/ (windows binaries currently available for 2.19 but not 2.20) - Unzip and copy libopenblas.dll to C:\Program Files\R\R-3.4.x\bin\x64 and rename it "Rblas.dll" - Download the mingw dll's (e.g., from https://sourceforge.net/projects/openblas/files/v0.2.15/mingw64_dll.zip/download), unzip and copy all the dll's to C:\Program Files\R\R-3.4.x\bin\x64 Best, Ista > > > On 29 October 2017 at 22:01, Kenny Bell wrote: > > | User here: incorporating Intel's MKL, as MRO does, would be a very welcome > > | addition. > > | > > | I was an MRO user before and it improved my experience with medium data > > | immensely. > > | > > | They did, however, leave behind bugs here and there, especially related to > > | development with Rcpp, so I switched back to vanilla R. > > > > With all due respect: You may miss something. MKL has always worked with > 'Base R'. > > > > As a point of reference and comparison, I set up a benchmarking and > > comparison package _well over half a decade ago_ and while it never get fully > > finished to the point of a submitted paper the vignette still stands---and > > demonstrates that _dropping in MKL is a one-line operation_. > > > > And always has been. There may have been some license arbitrage: Intel was > > an early investor in Revo, so MKL was pushed hard. With GotoBLAS and later > > OpenBLAS I cared less, but IIRC the license of MKL is a little simpler for > > "mere use" now. > > > > See https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf for > more. > > > > Hth, Dirk > > > [[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
