[Rd] Inconsistency in treating NaN-results?
This question is more out of curiosity than a complaint or suggestion, but I'm just wondering. The behavior of R on calculations that result in NaN seems a bit inconsistent. # this is expected: > 0/0 [1] NaN # but this gives a warning > sin(Inf) [1] NaN Warning message: In sin(Inf) : NaNs produced # and this again does not > exp(NaN) [1] NaN Conceptually, I like to think that R computes over the real line augmented with NaN, Inf, -Inf, NaN, and NA (which is technically also NaN). As far as I know, this set is closed under R's arithmetic operations and mathematical functions (following the IEEE standard on double precision). If that's the case, the result sin(Inf)=NaN seems normal to me and a warning is unnecessary. So why the choice to have warning on sin(Inf), but not on 0/0 or exp(Nan)? Is it just historical or am I missing a reasoning or some standard? Best, Mark > sessionInfo() R version 3.2.2 (2015-08-14) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.3 LTS locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=nl_NL.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=nl_NL.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=nl_NL.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=nl_NL.UTF-8 LC_IDENTIFICATION=C [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compile question
On 2015-11-23 23:43, peter dalgaard wrote:
On 23 Nov 2015, at 22:30 , aixtools wrote:
./configure --enable-maintainer-mode ...
Two things here
- possibly irrelevant, but I'd avoid building in the source directory. (mkdir
../BUILD ; cd ../BUILD; ../R/configure)
- don't turn on mantainer mode. You are not a maintainer, and if you want to
play at being one, I think you need extra tools.
I think I may need the extra tools. Besides autoconf and automake (plus
gnu m4) - what other tools are needed?
I am not able to generate a good configure (yet).
root@x072:[/data/prj/cran/R-devel]autoconf
configure.ac:254: error: possibly undefined macro: AM_CONDITIONAL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:655: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:727: error: possibly undefined macro: AC_CHECK_LIBM
configure.ac:1982: error: possibly undefined macro: AM_LANGINFO_CODESET
configure.ac:2639: error: possibly undefined macro: AM_NLS
configure.ac:2643: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION
configure.ac:2644: error: possibly undefined macro: AM_GNU_GETTEXT
What I changed...
root@x072:[/data/prj/cran]diff -u R-devel_2015-11-26/configure.ac
R-devel/configure.ac
--- R-devel_2015-11-26/configure.ac 2015-10-18 16:02:55.0 +
+++ R-devel/configure.ac2015-11-26 13:29:28.0 +
@@ -1300,12 +1300,14 @@
##ADD: A symbol of memcpy,memset is exported in libR by expall.
##ADD: However, for example, symbol in libc of memcpy is
__memmove,__memmove64.
##ADD: This black magic puts lc before lR and pockets this.
+ ## MAMF: This black magic is no longer working, it seems - getting
duplicate symbol errors now.
if test "x${OBJECT_MODE}" = "x64"; then
- main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x1
${wl}-bpD:0x11000 -lc"
+ main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x1
${wl}-bpD:0x11000"
else
- main_ldflags="${wl}-brtl ${wl}-bexpall -lc"
+ main_ldflags="${wl}-brtl ${wl}-bexpall"
fi
- shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry -lc"
+ ## MAMF: This black magic is clearly not working, removed from
main_ldflags to be consistent
+ shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry"
SHLIB_LIBADD="\$(LIBM)"
shlib_cxxldflags="${shlib_ldflags}"
if test "${GCC}" = yes; then
This removes most of the Duplicate symbol messages, although there are
still several coming from -lR being included
during the build of the shared libraries (.so files).
Another group of Duplicate symbols is coming from the -lm flag being too
early in the command syntax (autoconf library discovery, so more
difficult to "move", or "remove".
And I expect the logf() failure is from a program that was dynamically
linked but the symbol was ignored (as unref/unknown) for some reason.
I'll continue looking for that.
Regards,
Michael
p.s. is libR still exporting a libc defined symbol? Or is this just very
old text?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Custom C finalizers for .Call
We do have a mechanism in the base C code for ensuring that cleanup
code is run on longjmps; we wouldn't want to expose that in the API in
its current form, but could make a wrapper around it available -- I'll
make a note to look into it. But as Simon describes there are good
options available for packages now.
Best,
luke
On Wed, 25 Nov 2015, Simon Urbanek wrote:
Jeroen,
I agree that it may be useful to have some kind of "finally"-like
infrastructure. However, in the use cases you list there are already ways to do that -
the same way that R_alloc uses. First, you don't need to call UNPROTECT - the whole point
is that the protection stack is automatically popped in case of an abnormal termination.
That is precisely how memory leaks are prevented - as long as you play by the rules it
will be released for you. The check for UNPROTECTs at the end of .Call is explicitly
there so catch bugs in *normal* termination. So no memory leaks there.
The real case where users may create leaks is if you allocate memory that you
don't tell R about. As long as you associate a finalizer with any non-R memory
you allocate, there will be no memory leaks -that is how you are supposed to
write R packages with external allocations. So the only difference to your
example is that you don't register a finalizer with the *function* but rather
with the *allocation* you make. That also seems IMHO less error prone.
So to take your example, the way would typically write that code safely is
something like
typedef struct {
xmlNodePtr *node;
EVP_PKEY_CTX *ctx;
} my_context_t;
// define how to dispose of all things you care about correctly
static void context_fin(SEXP what) {
my_context_t *c = (my_context_t*) EXTPTR_PTR(what);
if (!c) return;
if (c->ctx) EVP_PKEY_CTX_free(c->ctx);
if (c->node) xmlFreeNode(c->node);
}
[...]
// allocate the context and tell R to manage its protection and finalization
// (you could write a macro to make this one-liner)
my_context_t* c = (my_context_t*) R_Calloc(1, my_context_t);
SEXP res = PROTECT(R_MakeExternalPtr(c, R_NilValue, R_NilValue));
R_RegisterCFinalizer(res, context_fin);
// do all work here ... you safely abort at any point without memory leaks
c->node = xmlNewNode(...);
c->ctx = EVP_PKEY_CTX_new(...);
[...]
The point of using a finalizer is that no matter what happens the memory is
always released. The structure with all allocations is protected until you
unprotect it or there is any interrupt/error. Since all regular R rules apply,
you can also assign it someplace to make the protection dependent on any other
object you care about. This is often useful because you don't need to PROTECT
things left and right, but instead you can just have one object that holds
references to random things you care about.
Of course, you could write a wrapper for the above with some syntactic sugar to achieve
the same - essentially limiting the finalizer to be just a function call on the reference
that you create. It may be a bit of overkill since you may end up creating objects for
every allocation, but certainly doable. I would argue that in most cases you already tend
to have a structure for the things you allocate so the "normal" approach is
typically more clear and readable than inlining calls with side-effects, but that may be
a matter of taste.
Cheers,
Simon
On Nov 23, 2015, at 6:10 PM, Jeroen Ooms wrote:
WRE explains that R_alloc() can be used to allocate memory which
automatically gets released by R at the end of a .C, .Call or
.External, even in the case of an error or interruption. This is a
really great feature to prevent memory leaks. I was wondering if there
is a way to extend this mechanism to allow for automatically running
UNPROTECT and custom finalizers at the end of a .Call as well.
Currently it is all to easy for package authors to introduce a memory
leak or stack imbalance by calling Rf_error() or
R_CheckUserInterrupt() in a way that skips over the usual cleanup
steps. This holds especially for packages interfacing C libraries
(libcurl, libxml2, openssl, etc) which require xx_new() and xx_free()
functions to allocate/free various types of objects, handles and
contexts. Therefore we cannot use R_alloc() and we need to manually
clean up when returning, which is tricky for irregular exits.
Moreover package authors might benefit from an alternative of
allocVector() which automatically protects the SEXP until the .Call is
done. Perhaps I don't fully appreciate the complexity of the garbage
collector, but one could imagine a variant of PROTECT() which
automatically keeps a counter 'n' for the number of allocated objects
and makes R run UNPROTECT(n) when .Call exists, along with releasing
the R_alloc() memory. Yes, there are cases where it is useful to have
manual control over what can be collected earlier during the .Call
procedure, but these are rare. A lot of C code in packages might
become safer and cleaner if authors would have an option to
Re: [Rd] compile question
If you do want to play with maintainer-mode, first check out
https://developer.r-project.org/R-build-prerelease
it is what is done in the nightly builds on OSX. (Actually Mavericks. The
comment is old.)
-pd
On 26 Nov 2015, at 14:38 , Michael Felt wrote:
> On 2015-11-23 23:43, peter dalgaard wrote:
>>> On 23 Nov 2015, at 22:30 , aixtools wrote:
>>>
./configure --enable-maintainer-mode ...
>> Two things here
>>
>> - possibly irrelevant, but I'd avoid building in the source directory.
>> (mkdir ../BUILD ; cd ../BUILD; ../R/configure)
>>
>> - don't turn on mantainer mode. You are not a maintainer, and if you want to
>> play at being one, I think you need extra tools.
>>
> I think I may need the extra tools. Besides autoconf and automake (plus gnu
> m4) - what other tools are needed?
>
> I am not able to generate a good configure (yet).
>
> root@x072:[/data/prj/cran/R-devel]autoconf
> configure.ac:254: error: possibly undefined macro: AM_CONDITIONAL
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
> configure.ac:655: error: possibly undefined macro: AC_DISABLE_STATIC
> configure.ac:727: error: possibly undefined macro: AC_CHECK_LIBM
> configure.ac:1982: error: possibly undefined macro: AM_LANGINFO_CODESET
> configure.ac:2639: error: possibly undefined macro: AM_NLS
> configure.ac:2643: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION
> configure.ac:2644: error: possibly undefined macro: AM_GNU_GETTEXT
>
> What I changed...
>
> root@x072:[/data/prj/cran]diff -u R-devel_2015-11-26/configure.ac
> R-devel/configure.ac
> --- R-devel_2015-11-26/configure.ac 2015-10-18 16:02:55.0 +
> +++ R-devel/configure.ac2015-11-26 13:29:28.0 +
> @@ -1300,12 +1300,14 @@
> ##ADD: A symbol of memcpy,memset is exported in libR by expall.
> ##ADD: However, for example, symbol in libc of memcpy is
> __memmove,__memmove64.
> ##ADD: This black magic puts lc before lR and pockets this.
> + ## MAMF: This black magic is no longer working, it seems - getting
> duplicate symbol errors now.
> if test "x${OBJECT_MODE}" = "x64"; then
> - main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x1
> ${wl}-bpD:0x11000 -lc"
> + main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x1
> ${wl}-bpD:0x11000"
> else
> - main_ldflags="${wl}-brtl ${wl}-bexpall -lc"
> + main_ldflags="${wl}-brtl ${wl}-bexpall"
> fi
> - shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry -lc"
> + ## MAMF: This black magic is clearly not working, removed from
> main_ldflags to be consistent
> + shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry"
> SHLIB_LIBADD="\$(LIBM)"
> shlib_cxxldflags="${shlib_ldflags}"
> if test "${GCC}" = yes; then
>
> This removes most of the Duplicate symbol messages, although there are still
> several coming from -lR being included
> during the build of the shared libraries (.so files).
>
> Another group of Duplicate symbols is coming from the -lm flag being too
> early in the command syntax (autoconf library discovery, so more difficult to
> "move", or "remove".
>
> And I expect the logf() failure is from a program that was dynamically linked
> but the symbol was ignored (as unref/unknown) for some reason. I'll continue
> looking for that.
>
> Regards,
> Michael
>
> p.s. is libR still exporting a libc defined symbol? Or is this just very old
> text?
>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
