Simon,
Very likely butchered my initial problem explanation. The issue is that I
make a call to a library, something like:
SEXP my_fun() {
...
CB = MyCallback("XYZ"); /* this contains callback functions that in turn
use R */
externalLibCall(CB); /* infinite loop that won't return as it is
ca
On May 23, 2012, at 12:40 PM, Jeffrey Ryan wrote:
> Simon,
>
> Thanks for the clarifying example. I fear my current set up fails the
> test for 'no R calls',
Well, but in that case you already have interrupt points so I'm not sure what
is the problem? I thought the whole point is that you hav
I use svUnit, too.
I put a kind of standard skeleton into my packages that has a
packagename.unittest () function that will run all svUnit tests (if
svUnit is available). This function returns NA if svUnit is not
available, invisible (TRUE) if all tests are passed and stops
otherwise. Which will
Simon,
Thanks for the clarifying example. I fear my current set up fails the
test for 'no R calls', so I think I am stuck on the ugly variant for my
current challenge, but I will be able to use this in other places.
Thanks again,
Jeff
On 5/22/12 4:45 PM, "Simon Urbanek" wrote:
>Jeff,
>
>On Ma
I'm not persuaded at this point that we want to support use of the
lazy loading infrastructure outside the core as we might want to
change it in the future. But the principle that promises are an
internal implementation detail that should be as invisible at possible
at the user level suggest that
OK, I switched to r-devel.
I'm caching the random seed by saving and lazy loading .Random.seed,
so I think it should always be valid (except that it becomes a promise
which is essentially an integer vector).
The complete process is as follows:
set.seed(1) # R generates .Random.seed now
tools:::
To fix myself: the stupid solution I suggested won't work as 'scale.' need not
be TRUE or FALSE, but it can be a vector of scales. The following looks like
being able to handle this, but is not transparent nor elegant:
sc <- if (isTRUE(scale.)) attr(x, "scaled:scale") else scale.
I trust you fi
On 12-05-23 4:37 AM, Matthew Dowle wrote:
Hi,
I've read ?is.unsorted and searched. Have found a few items but nothing
close, yet. Is the following expected?
is.unsorted(data.frame(1:2))
[1] FALSE
is.unsorted(data.frame(2:1))
[1] FALSE
is.unsorted(data.frame(1:2,3:4))
[1] TRUE
is.unsorte
Hello folks,
it may be regarded as a user error to scale() your data prior to prcomp()
instead of using its 'scale.' argument. However, it is a user thing that may
happen and sounds a legitimate thing to do, but in that case predict() with
'newdata' can give wrong results:
x <- scale(USArrests
>> is.unsorted(data.frame(1:2))
> [1] FALSE
>> is.unsorted(data.frame(2:1))
> [1] FALSE
>> is.unsorted(data.frame(1:2,3:4))
> [1] TRUE
>> is.unsorted(data.frame(2:1,4:3))
> [1] TRUE
>
> IIUC, is.unsorted is intended for atomic vectors only (description of x in
> ?is.unsorted). Indeed the C source (
Dear colleagues,
I'm currently trying to improve my R package (PairedData) devoted to the
analysis (and plotting) of paired data. For basic statistics teaching purposes,
I would like to give a list of the most interesting datasets including paired
data available in R packages (BSDA, HistData...)
Hi,
I've read ?is.unsorted and searched. Have found a few items but nothing
close, yet. Is the following expected?
> is.unsorted(data.frame(1:2))
[1] FALSE
> is.unsorted(data.frame(2:1))
[1] FALSE
> is.unsorted(data.frame(1:2,3:4))
[1] TRUE
> is.unsorted(data.frame(2:1,4:3))
[1] TRUE
IIUC, is.u
12 matches
Mail list logo
