Thanks everyone for helping me figure this out. Within terra::focalCpp
which handles the iteration over small subsets of the data there is a test
iteration that occurs which uses the data that is numbers 1-number of
elements in the window (for a 3x7 window that'd be 1-21). Since the
function I'm
On 15 December 2021 at 12:30, Robert J. Hijmans wrote:
| Dirk thanks very much for the help. And sorry, Alex, I misspoke. I meant to
| say that Rcpp will coerce a R "numeric" (vector) to an
| "Rcpp::IntegerVector" if you ask it to do so (and that is what happened in
| the context we were
Thanks Bill. I'm not sure how to set breakpoint on Windows (I found
resources for lldb or gdb which seem to be for Linux), but was able to get
a bit more insight with your Rf_error line and some print statements. For
some reason specifically on the first iteration xw is evaluating to 1:21
(the
To make this easier to debug, I added a check that the values in the x
given to C_make_glcm are within bounds:
for(int i=0; i < nr; ++i){
for(int j=0; j < nc; ++j){
int focal_val = x(i,j);
if (focal_val >= n_levels || focal_val < 0) { // sanity check
Thanks, I thought I was onto something there but I guess that wasn't the
issue (that only came up because when I made edits to my function to just
return the actual values as a check, I was converting them in an unsafe way
from int to double). I'm still confused on how the valgrind check Bill was
On 15 December 2021 at 11:22, Alex Ilich wrote:
| I actually think that the issue may be related to conversions between
| int/IntegerVectors and double/NumericVector/std::vector. I was
| talking with the terra package author to see if the focalCpp function can
| take an IntegerVector instead of a
I actually think that the issue may be related to conversions between
int/IntegerVectors and double/NumericVector/std::vector. I was
talking with the terra package author to see if the focalCpp function can
take an IntegerVector instead of a NumericVector/ /std::vector, as
it seemed initially to
Thanks for digging into this for me. If focal_val is 16, then this is an
out of bounds error as the matrix is 16x16 and the maximum index can be 15.
What I'm confused about is that focal_val comes from the data which has
been transformed to be restricted to integers in the range of 0-15 (0 -
In this example vgdb shows that valgrind's first complaint is at
(gdb) where 5
#0 0x1c1ada01 in C_make_glcm (x=..., n_levels=16, shift=...,
na_opt=...) at glcm_cpp_functions.cpp:73
#1 0x1c1b2238 in C_glcm_textures_helper2 (x=..., w2=...,
n_levels=16, shift=..., na_opt=..., ni=1,
Thanks, I hadn't noticed the --use-valgrind option to check.
I often run R under valgrind with the command line:
$ R --quiet --no-save --debugger=valgrind
--debugger-args="--track-origins=yes --vgdb=full --vgdb-error=0"
then in another window start a debugger process with
$ gdb
On 13 December 2021 at 09:15, Bill Dunlap wrote:
| I ran your example under valgrind on Linux (Ubuntu 20.04)
Excellent call, as usual! Thanks for doing that.
R actually makes is so easy to run with valgrind by calling
R CMD check --use-valgrind somePkg_1.2-3.tar.gz
that I started to add
I ran your example under valgrind on Linux (Ubuntu 20.04) and valgrind
found some memory misuse:
$ R --quiet --no-save --debugger=valgrind
--debugger-args="--track-origins=yes"
==1533== Memcheck, a memory error detector
==1533== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
On 13 December 2021 at 11:14, Alexander Ilich wrote:
| Hi, I'm upgrading one of my R packages to rely on the terra package instead
| of the raster package for the handling of spatial raster data. Previously
| when relying on the raster package I had to convert the data to a matrix
| and send it
Hi, I'm upgrading one of my R packages to rely on the terra package instead
of the raster package for the handling of spatial raster data. Previously
when relying on the raster package I had to convert the data to a matrix
and send it to C++ to loop through the cells manually, but with the new
14 matches
Mail list logo
