Displaying 20 results from an estimated 4000 matches similar to: "Frames in compiled functions"
2016 Nov 11
0
Frames in compiled functions
It looks like the byte compiler is optimizing local() to an
immediately-invoked function, instead of using eval() and substitute(). I
don't know if that's exactly how it's implemented internally, but that's
what it looks like here:
compiler::enableJIT(0)
fun <- function(x) {
local(sys.calls())
}
fun(1)
## [[1]]
## fun(1)
##
## [[2]]
## local(sys.calls())
##
## [[3]]
##
2017 Apr 26
4
byte-compiler bug
Hi,
I'm running into a case where byte-compilation changes
the semantic of a function. This is with R 3.4.0:
foo <- function(x) { TRUE && x }
foo(c(a=FALSE))
# [1] FALSE # OK
foo(c(a=TRUE))
# [1] TRUE # OK
foo(c(a=FALSE))
# a # ????
# FALSE
The 3rd call returned a result that it different from the 1st
call!
After
2016 Nov 27
1
Changes in error reporting in r-devel
On 27 November 2016 at 13:20, Duncan Murdoch wrote:
| On 27/11/2016 11:34 AM, brodie gaslam via R-devel wrote:
| > Minor issue, but the following changed as of R3.3.2 from:
| >
| > > a <- function() b()
| > > a()
| > Error in a() : could not find function "b"
| >
| > To (at least in R Under development (unstable) (2016-11-20 r71670)):
| >
|
2016 Nov 27
3
Changes in error reporting in r-devel
Minor issue, but the following changed as of R3.3.2 from:
> a <- function() b()
> a()
Error in a() : could not find function "b"
To (at least in R Under development (unstable) (2016-11-20 r71670)):
Error in b() : could not find function "b"
Notice the "Error in **b**() :" part. The original error message seems more correct to me, although
2018 Sep 25
1
Fwd: Bug report: cbind with numeric and raw gives incorrect result
Thanks Brodie, that's some nice detective work.
If someone wanted to grant me access to Bugzilla, I'll be happy to post the
bug and patch there (with your permission Brodie?) and help this bug get
fixed.
Mike.
On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <brodie.gaslam at yahoo.com>
wrote:
>
>
> For what it's worth the following patch fixes that particular problem
2012 Apr 12
2
enableJIT(2) causes major slow-up in rpart
Hello,
Due to exploration of the JIT capabilities offered through the {compiler}
package, I came by the fact that using enableJIT(2) can *slow* the rpart
function (from the {rpart} package) by a magnitude of about 10 times.
Here is an example code to run:
library(rpart)
require(compiler)
enableJIT(0) # just making sure that JIT is off # We could also use
enableJIT(1) and it would be fine
fo
2020 Mar 05
3
findInterval Documentation Suggestion
I've found over time that R documentation that comes off as terse at
first blush is usually revealed to be precise, concise, and complete
on close reading.? I'm sure this is also true of `?findInterval`, but
for whatever reason my brain simply refuses to extract meaning from it.
Part of the problem may be that we interact with the function via a
compressed form of the bounds of the
2019 Jul 14
2
[External] Mitigating Stalls Caused by Call Deparse on Error
Luke, thanks for considering the issue.? I would like to
try to separate the problem into two parts, as I _think_
your comments address primarily part 2 below:
1. How can we avoid significant and possibly crippling
?? stalls on error with these non-standard calls.
2. What is the best way to view these non-standard calls.
I agree that issue 2. requires further thought and
discussion under a
2020 May 20
2
Precision of function mean,bug?
> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard <pdalgd at gmail.com> wrote:
>
> Expected, see FAQ 7.31.
>
> You just can't trust == on FP operations. Notice also
Additionally, since you're implementing a "mean" function you are testing
against R's mean, you might want to consider that R uses a two-pass
calculation[1] to reduce floating
2018 Sep 24
3
Fwd: Bug report: cbind with numeric and raw gives incorrect result
Hi there,
using cbind with a numeric and raw argument produces an incorrect result.
I've posted some details below,
kind regards,
Mike.
e.g.
> cbind(0, as.raw(0))
[,1] [,2]
[1,] 0 6.950136e-310
A longer example shows that the result is not a rounding error, is not
consistent, and repeated applications get different results.
> cbind(0, as.raw(1:10))
2020 Mar 06
1
findInterval Documentation Suggestion
> On Friday, March 6, 2020, 8:56:54 AM EST, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
> Note that the? * -> LaTex -> PDF rendered version looks a bitnicer.
Ah yes, that does indeed look quite a bit nicer.
> I wrote the function and that help page originally.
And thank you for doing so. It is a wonderful function.
(0 sarcasm here).
> For that reason,
2018 Mar 29
2
Possible `substr` bug in UTF-8 Corner Case
I think there is a memory bug in `substr` that is triggered by a UTF-8 corner case: an incomplete UTF-8 byte sequence at the end of a string.? With a valgrind level 2 instrumented build of R-devel I get:
> string <- "abc\xEE"??? # \xEE indicates the start of a 3 byte UTF-8 sequence
> Encoding(string) <- "UTF-8"
> substr(string, 1, 10)
==15375== Invalid read of
2019 Jul 16
1
[External] Mitigating Stalls Caused by Call Deparse on Error
We also have a few other suggestions and wishes about backtrace
storage and display on the one hand, and display of constructed calls
on the other hand. Perhaps it would be better to open a different
wishlist item for traceback() to keep the discussions focused?
FWIW I think deparsing backtraces lazily is a great idea. Displaying 1
line per call by default in interactive sessions, while being
2020 Jan 07
3
Another wish (?) for R 4.0.0: print(*, width = <n>)
One of the things I often wish R would work with:
When calling print() explicitly --- as I do not so rarely, e.g.,
specifying digits = <nd> ---
it sometimes seems awkward that from the printing options() ,
one can specify 'digits' and it has default digits = NULL which is
documented to be equivalent to digits = getOption("digits"),
but one cannot specify 'width'
2019 Mar 31
3
stopifnot
Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version.
options(error = expression(NULL))
library(compiler)
enableJIT(0)
f <- function(x) for (i in 1) {x; eval(expression(i))}
f(is.numeric(y))
# Error: object 'y' not found
fc <- cmpfun(f)
fc(is.numeric(y))
# Error: object 'y' not found
2020 May 15
4
edit() doubles backslashes when keep.source=TRUE
> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel <edd at debian.org> wrote:
> On 15 May 2020 at 15:41, Martin Maechler wrote:
> | <whining>
> |
> |??? Why does nobody anymore? help R development by working with
> |??? "R-devel", or at least then the alpha, beta and the "RC"
> |??? (Release Candidate) versions that we release daily
2020 May 27
1
R-ints context documentation
In 1.4 Contexts[1], should the following:
> Note that whilst calls to closures and builtins set a context,
> those to special internal functions never do.
Be something like:
> Note that whilst calls to closures always set a context,
> those to builtins only set a context under profiling
> or if they are of the foreign variety (e.g `.C` and similar),
> and those to special
2020 Jun 22
4
R 4.0.2 is released
The build system rolled up R-4.0.2.tar.gz (codename "Taking Off Again") this morning.
The list below details the changes in this release.
You can get the source code from
http://cran.r-project.org/src/base/R-4/R-4.0.2.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
2020 Jun 01
1
eval and Calling Frames
I ran into an interesting issue with `evalq` (and also
`eval(quote(...))`):
???? f <- function() {
?????? list(
???????? sys.parent(1),
???????? evalq(sys.parent(1)),
???????? evalq((function() sys.parent(2))()),? # add an anon fun layer
???????? evalq((function() sys.parent(1))())
?????? )
???? }
???? res <- f()
???? str(res)
???? ## List of 4
???? ##? $ : int 0???????? # sys.parent(1)
2017 Oct 27
1
Slow down using the compiler
Dear All,
In R 3.4.2 (Linux), the compiler seems to have regressed:
$ R --vanilla
g = function() {
N = 1e7; ans = numeric(N)
system.time({for (j in 1:N) ans[j] = 1})
}
g()
# user system elapsed
# 4.272 0.000 4.272
g1 = compiler::cmpfun(g)
g1()
# user system elapsed
# 4.232 0.004 4.235
Running the above code in Windows 3.3.1, g() takes the same time, but g1()
takes around 0.5