Radford Neal:
> > there's a danger of getting carried away and essentially rewriting
> > malloc. To avoid this, one might try just calling "free" on the
> > no-longer-needed object, letting "malloc" then figure out when it can
> > be re-used.
Nathan Kurz:
> Yes, I think that's what I was anticipa
On Wed, Feb 18, 2015 at 7:19 AM, Radford Neal wrote:
>> ... with assignments inside of loops like this:
>>
>> reweight = function(iter, w, Q) {
>> for (i in 1:iter) {
>> wT = w * Q
>> }
>> }
>> ... before the RHS is executed, the LHS allocation would be added
>> to a small fixed length lis
Dear R-devel,
my Bioconductor EDASeq package has a function MDPlot that uses the
smoothScatter() function from the graphics package. When I test this
package on travis-ci.org (R CMD check) I get the following error
(which I don't get on my machine nor on the Bioconductor build
system).
* checking
On 18 February 2015 at 14:44, Bryan Hanson wrote:
| On this feed, which I think is the place we should monitor upcoming changes:
|
| http://developer.r-project.org/blosxom.cgi/R-devel/NEWS
|
| What is the significance of the green and pink highlighting?
Same as in some code diff tools: green i
> On Feb 18, 2015, at 1:44 PM, Bryan Hanson wrote:
>
> On this feed, which I think is the place we should monitor upcoming changes:
>
> http://developer.r-project.org/blosxom.cgi/R-devel/NEWS
>
> What is the significance of the green and pink highlighting?
>
> Thanks, Bryan
I stand to be co
On Feb 18, 2015, at 2:44 PM, Bryan Hanson wrote:
>
> On this feed, which I think is the place we should monitor upcoming changes:
>
> http://developer.r-project.org/blosxom.cgi/R-devel/NEWS
>
> What is the significance of the green and pink highlighting?
>
It highlights the changes since last
On this feed, which I think is the place we should monitor upcoming changes:
http://developer.r-project.org/blosxom.cgi/R-devel/NEWS
What is the significance of the green and pink highlighting?
Thanks, Bryan
__
R-devel@r-project.org mailing list
https
The C++ code is used to increase the speed. It receives an empty matrix, in
a "for" loop it calculates the matrix elements and returns it to R. The
problem is, using the official R, it calculates the matrix correctly but
using R-devel, it returns the empty matrix with no errors and I get "error"
wh
Sarah,
We don't really have enough information to begin helping you with the
problem. We don't know what the c++ code is doing, which package you are
talking about, etc. See the posting guidelines.
That said, your code is "probably" doing something it shouldn't if things
have suddenly stopped wor
Hi,
I am using an R package which includes C++ code inside. The package is
functioning well under latest official R version but not under R-devel. I
know that the C++ part is not functioning properly and I get an error using
R-devel (it returns nothing to the R part of the program). Do I need to
d
> ... with assignments inside of loops like this:
>
> reweight = function(iter, w, Q) {
> for (i in 1:iter) {
> wT = w * Q
> }
> }
> ... before the RHS is executed, the LHS allocation would be added
> to a small fixed length list of available space which is checked
> before future allocati
Hi Gabriel,
thanks for your reply - it does solve the problem of my toy function,
but does come with some other problems though.
a) as.list(f)[[1]] yields an expression, not a function. In order to
go the route you are suggesting, I would more likely use "deparse" in
order to get the original back
On Wed, Feb 18, 2015 at 6:43 AM, Holger Hoefling wrote:
>
> b) and more seriously - as.list strips the environment of the function
> (and thus associated information) as well as information about parent
> environments. For the execution of a function, this would however be
> crucial. This is also
Luke, thank you so much - that solves my problem!
Holger
On Wed, Feb 18, 2015 at 3:56 PM, wrote:
> On Wed, 18 Feb 2015, Holger Hoefling wrote:
>
>> Hi Luke,
>>
>> Ah - I see - thank you! This at least points me to a way on how to
>> "fix" this. I tried setting the srcref attribute to NULL, but
On Wed, 18 Feb 2015, Holger Hoefling wrote:
Hi Luke,
Ah - I see - thank you! This at least points me to a way on how to
"fix" this. I tried setting the srcref attribute to NULL, but the hash
value is still different and so is the serialization. So this looks
like it is one difference, but not a
Holger,
For me (see session info) using
digest(as.list(f))
gets around this problem.
~G
> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONET
Hi Luke,
Ah - I see - thank you! This at least points me to a way on how to
"fix" this. I tried setting the srcref attribute to NULL, but the hash
value is still different and so is the serialization. So this looks
like it is one difference, but not all of them
Even if all differences were identi
Add
attributes(testfun)
and you will see where the two functions differ.
luke
On Wed, 18 Feb 2015, Holger Hoefling wrote:
Hi,
I posted this question to the regular help list, but it seems to be
this is probably a question that is better addressed on r-devel. Sorry
for the double posting.
I
Hi,
I posted this question to the regular help list, but it seems to be
this is probably a question that is better addressed on r-devel. Sorry
for the double posting.
I am using hash-values to cache certain results in R. This caching
also depends on the hash-value of the function that is being ca
19 matches
Mail list logo
