[Rd] Is it possible to shrink an R object in place?
Suppose I generate an integer vector with e.g. SEXP iv = PROTECT(allocVector(INTSXP, 100)); and later want to shrink the object, e.g. shrink(iv, 50); would simply re-set the length to 50, and allow R to reclaim the memory that was previously used. Is it possible to do this while respecting how R manages memory? The motivation: there are many operations where the length of the output is not known ahead of time, and in such cases one typically uses a data structure that can grow efficiently. Unfortunately, IIUC SEXPRECs cannot do this; however, an alternative possibility would involve reserving extra memory, and then shrinking to fit after the operation is complete. There have been some discussions previously that defaulted to answers of the form "you should probably just copy", e.g. https://stat.ethz.ch/pipermail/r-devel/2008-March/048593.html, but I wanted to ping and see if others had ideas, or if perhaps there was code in the R sources that might be relevant. Another reason why this is interesting is due to C++11 and multi-threading: if I can pre-allocate SEXPs that will contain results in the main thread, and then fill these SEXPs asynchronously (without touching R, and hence not getting in the way of the GC or otherwise), I can then fill these SEXPs in place and shrink-to-fit after the computations have been completed. With C++11 support coming with R 3.1.0, functionality like this is very attractive. The obvious alternatives are to 1) determine the length of the output first and hence generate SEXPs of appropriate size right off the bat (potentially expensive), and 2) fill thread-safe containers and copy to an R object (definitely expensive). I am probably missing something subtle (or obvious) as to why this may not work, or be recommended, so I appreciate any comments. Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
On 10 April 2014 at 15:58, Martyn Plummer wrote: | The R configure script is permissive and will enable "C++11" support if | your compiler accepts -std=c++0x. Obviously you will only get partial | support for the C++11 standard (But this is also true of some compilers | that accept -std=c++11). You may be OK if you just want C99 features, | which were missing from the C++98 standard, and features previously | introduced in the TR1 extension. But there are no guarantees. Indeed. I am using that feature (of asking for C++11 and being guaranteed a set of changes relative to C99) in the RcppCNPy upload that went onto CRAN this morning --- as we now have consistent 'long long' support. Which also works with Rtools and g++ 4.6.*. | Cross-platform support for C++11 is going to remain poor for some time | to come, I'm afraid. Precisely. One does have the option of using what R / CRAN now "C++11" incrementally by taking what is provided where it is provided. My simple example finally getting 'long long' via the cstdint header works that way (on my machine, cstdint goes back to the oldest compiler I still have, g++-4.4). But it needs one of the extensions: -std=c++11 where available, -std=c++0x on older systems. And eg Martin Morgan's recent question of how to use 'unordered_map' should work the same way: just turn on C++11 and depend on R 3.1.0. That header is also provided at least as far back as 4.4. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
Le 10 avr. 2014 à 17:58, Martyn Plummer a écrit : > On Thu, 2014-04-10 at 11:14 -0400, Gabor Grothendieck wrote: >> On Tue, Oct 29, 2013 at 1:58 AM, wrote: >>> Le 2013-10-29 03:01, Whit Armstrong a écrit : >>> I would love to see optional c++0x support added for R. >>> >>> >>> c++0x was the name given for when this was in development. Now c++11 is a >>> published standard backed by implementations by major compilers. >>> people need to stop calling it c++0x >>> >>> If there is anything I can do to help, please let me know. >>> >>> >>> Come here https://github.com/romainfrancois/cpp11_article where I'm writing >>> an article on C++11 and what would be the benefits. >>> >> >> Unless you are willing to do it yourself currently Rtools on Windows uses >> g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x . >> >> Ubuntu 12.04 LTS also provides g++ 4.6.3. >> >> g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11 >> >> More info at: >> http://gcc.gnu.org/projects/cxx0x.html > > The R configure script is permissive and will enable "C++11" support if > your compiler accepts -std=c++0x. Obviously you will only get partial > support for the C++11 standard (But this is also true of some compilers > that accept -std=c++11). You may be OK if you just want C99 features, > which were missing from the C++98 standard, and features previously > introduced in the TR1 extension. But there are no guarantees. > > Cross-platform support for C++11 is going to remain poor for some time > to come, I'm afraid. > > Martyn What would be a good enough motivation for distributing a version of Rtools based on a more recent gcc, e.g. in the 4.8 series, which has much better coverage of the standard. I don’t have the skills to build an Rtools distribution, but if I can help one way or another, please let me know. I could, perhaps with other interested parties sponsor someone’s time for example. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
On Thu, 2014-04-10 at 11:14 -0400, Gabor Grothendieck wrote:
> On Tue, Oct 29, 2013 at 1:58 AM, wrote:
> > Le 2013-10-29 03:01, Whit Armstrong a écrit :
> >
> >> I would love to see optional c++0x support added for R.
> >
> >
> > c++0x was the name given for when this was in development. Now c++11 is a
> > published standard backed by implementations by major compilers.
> > people need to stop calling it c++0x
> >
> >
> >> If there is anything I can do to help, please let me know.
> >
> >
> > Come here https://github.com/romainfrancois/cpp11_article where I'm writing
> > an article on C++11 and what would be the benefits.
> >
>
> Unless you are willing to do it yourself currently Rtools on Windows uses
> g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x .
>
> Ubuntu 12.04 LTS also provides g++ 4.6.3.
>
> g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11
>
> More info at:
> http://gcc.gnu.org/projects/cxx0x.html
The R configure script is permissive and will enable "C++11" support if
your compiler accepts -std=c++0x. Obviously you will only get partial
support for the C++11 standard (But this is also true of some compilers
that accept -std=c++11). You may be OK if you just want C99 features,
which were missing from the C++98 standard, and features previously
introduced in the TR1 extension. But there are no guarantees.
Cross-platform support for C++11 is going to remain poor for some time
to come, I'm afraid.
Martyn
---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
On Tue, Oct 29, 2013 at 1:58 AM, wrote: > Le 2013-10-29 03:01, Whit Armstrong a écrit : > >> I would love to see optional c++0x support added for R. > > > c++0x was the name given for when this was in development. Now c++11 is a > published standard backed by implementations by major compilers. > people need to stop calling it c++0x > > >> If there is anything I can do to help, please let me know. > > > Come here https://github.com/romainfrancois/cpp11_article where I'm writing > an article on C++11 and what would be the benefits. > Unless you are willing to do it yourself currently Rtools on Windows uses g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x . Ubuntu 12.04 LTS also provides g++ 4.6.3. g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11 More info at: http://gcc.gnu.org/projects/cxx0x.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
On Thu, 2014-04-10 at 07:22 -0500, Dirk Eddelbuettel wrote: > On 2 December 2013 at 07:04, Dirk Eddelbuettel wrote: > | > | Following up on the thread spawned a while back, I just wanted to say that I > | appreciate today's RSS serving of R-devel NEWS: > | > |CHANGES IN R-devel PACKAGE INSTALLATION > | > |There is _experimental_ support for compiling C++11 code in packages. The > |file ‘src/Makevars’ or ‘src/Makevars.win’ should define the macro > |‘USE_CXX11 = true’. Where needed, an alternative C++11 compiler can be > |specified by setting macros ‘CXX11’, ‘CXX11FLAGS’ and so on, either when > R > |is configured or in a personal ‘Makevars’ file. (The default is to use > |‘$(CXX) -std=c++11’.) > | > | Thanks for initial and incremental changes. They are appreciated. > > And now a big thanks to Martyn and anybody else in R Core who pushed this > through to the R 3.1.0 release this morning. Credit it due to Brian here. Martyn > Having Makevars to let us say CXX_STD = CXX11 (plus the other variants) is a > real step forward, and relying on the information gleaned at configuration > time for R is sensible too. > > It's really good to have this, so thanks again. > > Dirk > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
On 2 December 2013 at 07:04, Dirk Eddelbuettel wrote: | | Following up on the thread spawned a while back, I just wanted to say that I | appreciate today's RSS serving of R-devel NEWS: | |CHANGES IN R-devel PACKAGE INSTALLATION | |There is _experimental_ support for compiling C++11 code in packages. The |file ‘src/Makevars’ or ‘src/Makevars.win’ should define the macro |‘USE_CXX11 = true’. Where needed, an alternative C++11 compiler can be |specified by setting macros ‘CXX11’, ‘CXX11FLAGS’ and so on, either when R |is configured or in a personal ‘Makevars’ file. (The default is to use |‘$(CXX) -std=c++11’.) | | Thanks for initial and incremental changes. They are appreciated. And now a big thanks to Martyn and anybody else in R Core who pushed this through to the R 3.1.0 release this morning. Having Makevars to let us say CXX_STD = CXX11 (plus the other variants) is a real step forward, and relying on the information gleaned at configuration time for R is sensible too. It's really good to have this, so thanks again. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ! LaTeX Error: File `zi4.sty' not found.
On 10 April 2014 at 10:16, Witold E Wolski wrote: | R version 3.1.0 beta (2014-03-28 r65330) -- "Spring Dance" | | When running R CMD check mypackage. | | the check fails with : | | ! LaTeX Error: File `zi4.sty' not found. You failed to state which OS you're on, so barring contradictory information I'll just assume it is similar to mine: edd@max:~$ locate zi4.sty /usr/share/texlive/texmf-dist/tex/latex/inconsolata/zi4.sty edd@max:~$ and edd@max:~$ dpkg -S `locate zi4.sty` texlive-fonts-extra: /usr/share/texlive/texmf-dist/tex/latex/inconsolata/zi4.sty edd@max:~$ As most (La)TeX installations these derive from TeXLive, you probably want to make sure you have current enough and complete enough installation of it. On the Linux distros and releases I use, I never had an issue. (But then I also do not use the very old and stable "Debian stable" or "Ubuntu LTS" variants.) Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ! LaTeX Error: File `zi4.sty' not found.
R version 3.1.0 beta (2014-03-28 r65330) -- "Spring Dance" When running R CMD check mypackage. the check fails with : ! LaTeX Error: File `zi4.sty' not found. a search for this error forwards to similar errors but with an inconsolata.sty file. -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE when detecting mismatch in output, and codes for NOTEs, WARNINGs and ERRORs
On 03/26/2014 06:46 PM, Paul Gilbert wrote:
On 03/26/2014 04:58 AM, Kirill Müller wrote:
Dear list
It is possible to store expected output for tests and examples. From the
manual: "If tests has a subdirectory Examples containing a file
pkg-Ex.Rout.save, this is compared to the output file for running the
examples when the latter are checked." And, earlier (written in the
context of test output, but apparently applies here as well): "...,
these two are compared, with differences being reported but not causing
an error."
I think a NOTE would be appropriate here, in order to be able to detect
this by only looking at the summary. Is there a reason for not flagging
differences here?
The problem is that differences occur too often because this is a
comparison of characters in the output files (a diff). Any output that
is affected by locale, node name or Internet downloads, time, host, or
OS, is likely to cause a difference. Also, if you print results to a
high precision you will get differences on different systems,
depending on OS, 32 vs 64 bit, numerical libraries, etc. A better test
strategy when it is numerical results that you want to compare is to
do a numerical comparison and throw an error if the result is not
good, something like
r <- result from your function
rGood <- known good value
fuzz <- 1e-12 #tolerance
if (fuzz < max(abs(r - rGood))) stop('Test xxx failed.')
It is more work to set up, but the maintenance will be less,
especially when you consider that your tests need to run on different
OSes on CRAN.
You can also use try() and catch error codes if you want to check those.
Thanks for your input.
To me, this is a different kind of test, for which I'd rather use the
facilities provided by the testthat package. Imagine a function that
operates on, say, strings, vectors, or data frames, and that is expected
to produce completely identical results on all platforms -- here, a
character-by-character comparison of the output is appropriate, and I'd
rather see a WARNING or ERROR if something fails.
Perhaps this functionality can be provided by external packages like
roxygen and testthat: roxygen could create the "good" output (if asked
for) and set up a testthat test that compares the example run with the
"good" output. This would duplicate part of the work already done by
base R; the duplication could be avoided if there was a way to specify
the severity of a character-level difference between output and expected
output, perhaps by means of an .Rout.cfg file in DCF format:
OnDifference: mute|note|warning|error
Normalize: [R expression]
Fuzziness: [number of different lines that are tolerated]
On that note: Is there a convenient way to create the .Rout.save files
in base R? By "convenient" I mean a single function call, not checking
and manually copying as suggested here:
https://stat.ethz.ch/pipermail/r-help/2004-November/060310.html .
Cheers
Kirill
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
