[R-pkg-devel] .OnLoad v .OnAttach

[Jonathan Godfrey]

Hello all,

An issue has been raised for my BrailleR package.   
https://github.com/ajrgodfrey/BrailleR/issues/97#issuecomment-1732136521

I do make use of an .OnLoad() function for various tasks, including creation of 
a folder to put stuff in. The user gets to choose if this is temporary or fixed 
if the session is interactive. (all in zzz.R

What risks do I face if any of this .OnLoad() are moved to .OnAttach()?

Thanks,
Jonathan




[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Recent changes to as.complex(NA_real_)

[Hervé Pagès]

On 9/22/23 16:55, Hervé Pagès wrote:

> The problem is that you have things that are **semantically** 
> different but look exactly the same:
>
> They look the same:
>
> > x
> [1] NA
> > y
> [1] NA
> > z
> [1] NA
>
> > is.na(x)
> [1] TRUE
> > is.na(y)
> [1] TRUE
> > is.na(z)
> [1] TRUE
>
> > str(x)
>  cplx NA
> > str(y)
>  num NA
>
oops, that was supposed to be:

 > str(y)
  cplx NA

but somehow I managed to copy/paste the wrong thing, sorry.

H.

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Recent changes to as.complex(NA_real_)

[Hervé Pagès]

The problem is that you have things that are **semantically** different 
but look exactly the same:

They look the same:

 > x
[1] NA
 > y
[1] NA
 > z
[1] NA

 > is.na(x)
[1] TRUE
 > is.na(y)
[1] TRUE
 > is.na(z)
[1] TRUE

 > str(x)
  cplx NA
 > str(y)
  num NA
 > str(z)
  cplx NA

but they are semantically different e.g.

 > Re(x)
[1] NA
 > Re(y)
[1] -0.5  # surprise!

 > Im(x)  # surprise!
[1] 2
 > Im(z)
[1] NA

so any expression involving Re() or Im() will produce different results 
on input that look the same on the surface.

You can address this either by normalizing the internal representation 
of complex NA to always be complex(r=NaN, i=NA_real_), like for 
NA_complex_, or by allowing the infinite variations that are currently 
allowed and at the same time making sure that both Re() and Im()  always 
return NA_real_ on a complex NA.

My point is that the behavior of complex NA should be predictable. Right 
now it's not. Once it's predictable (with Re() and Im() both returning 
NA_real_ regardless of internal representation), then it no longer 
matters what kind of complex NA is returned by as.complex(NA_real_), 
because they are no onger distinguishable.

H.

On 9/22/23 13:43, Duncan Murdoch wrote:
> Since the result of is.na(x) is the same on each of those, I don't see 
> a problem.  As long as that is consistent, I don't see a problem. You 
> shouldn't be using any other test for NA-ness.  You should never be 
> expecting identical() to treat different types as the same (e.g. 
> identical(NA, NA_real_) is FALSE, as it should be).  If you are using 
> a different test, that's user error.
>
> Duncan Murdoch
>
> On 22/09/2023 2:41 p.m., Hervé Pagès wrote:
>> We could also question the value of having an infinite number of NA
>> representations in the complex space. For example all these complex
>> values are displayed the same way (as NA), are considered NAs by
>> is.na(), but are not identical or semantically equivalent (from an Re()
>> or Im() point of view):
>>
>>       NA_real_ + 0i
>>
>>       complex(r=NA_real_, i=Inf)
>>
>>       complex(r=2, i=NA_real_)
>>
>>       complex(r=NaN, i=NA_real_)
>>
>> In other words, using a single representation for complex NA (i.e.
>> complex(r=NA_real_, i=NA_real_)) would avoid a lot of unnecessary
>> complications and surprises.
>>
>> Once you do that, whether as.complex(NA_real_) should return
>> complex(r=NA_real_, i=0) or complex(r=NA_real_, i=NA_real_) becomes a
>> moot point.
>>
>> Best,
>>
>> H.
>>
>> On 9/22/23 03:38, Martin Maechler wrote:
 Mikael Jagan
   on Thu, 21 Sep 2023 00:47:39 -0400 writes:
>>>   > Revisiting this thread from April:
>>>
>>> >https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
>>>
>>>   > where the decision (not yet backported) was made for
>>>   > as.complex(NA_real_) to give NA_complex_ instead of
>>>   > complex(r=NA_real_, i=0), to be consistent with
>>>   > help("as.complex") and as.complex(NA) and 
>>> as.complex(NA_integer_).
>>>
>>>   > Was any consideration given to the alternative?
>>>   > That is, to changing as.complex(NA) and 
>>> as.complex(NA_integer_) to
>>>   > give complex(r=NA_real_, i=0), consistent with
>>>   > as.complex(NA_real_), then amending help("as.complex")
>>>   > accordingly?
>>>
>>> Hmm, as, from R-core, mostly I was involved, I admit to say "no",
>>> to my knowledge the (above) alternative wasn't considered.
>>>
>>>     > The principle that
>>>     > Im(as.complex()) should be zero
>>>     > is quite fundamental, in my view, hence the "new" behaviour
>>>     > seems to really violate the principle of least surprise ...
>>>
>>> of course "least surprise"  is somewhat subjective.  Still,
>>> I clearly agree that the above would be one desirable property.
>>>
>>> I think that any solution will lead to *some* surprise for some
>>> cases, I think primarily because there are *many* different
>>> values z  for which  is.na(z)  is true,  and in any case
>>> NA_complex_  is only of the many.
>>>
>>> I also agree with Mikael that we should reconsider the issue
>>> that was raised by Davis Vaughan here ("on R-devel") last April.
>>>
>>>   > Another (but maybe weaker) argument is that
>>>   > double->complex coercions happen more often than
>>>   > logical->complex and integer->complex ones. Changing the
>>>   > behaviour of the more frequently performed coercion is
>>>   > more likely to affect code "out there".
>>>
>>>   > Yet another argument is that one expects
>>>
>>>   >  identical(as.complex(NA_real_), NA_real_ + (0+0i))
>>>
>>>   > to be TRUE, i.e., that coercing from double to complex is
>>>   > equivalent to adding a complex zero.  The new behaviour
>>>   > makes the above FALSE, since NA_real_ + (0+0i) gives
>>>   > complex(r=NA_real_, i=0).
>>>
>>> No!  --- To my own surprise (!) --- in current R-devel the above is 
>>> TRUE,
>>> and
>>>     NA_real_ + (0+0i)  , the same as

Re: [Rd] Recent changes to as.complex(NA_real_)

[Spencer Graves]

	  Perhaps I shouldn't comment without having read the entire thread, 
but I will:  I can envision situations where I might want, e.g., 2 from 
complex(r=2, i=NA_real_).



  Spencer Graves


On 9/22/23 3:43 PM, Duncan Murdoch wrote:
Since the result of is.na(x) is the same on each of those, I don't see a 
problem.  As long as that is consistent, I don't see a problem.  You 
shouldn't be using any other test for NA-ness.  You should never be 
expecting identical() to treat different types as the same (e.g. 
identical(NA, NA_real_) is FALSE, as it should be).  If you are using a 
different test, that's user error.


Duncan Murdoch

On 22/09/2023 2:41 p.m., Hervé Pagès wrote:

We could also question the value of having an infinite number of NA
representations in the complex space. For example all these complex
values are displayed the same way (as NA), are considered NAs by
is.na(), but are not identical or semantically equivalent (from an Re()
or Im() point of view):

      NA_real_ + 0i

      complex(r=NA_real_, i=Inf)

      complex(r=2, i=NA_real_)

      complex(r=NaN, i=NA_real_)

In other words, using a single representation for complex NA (i.e.
complex(r=NA_real_, i=NA_real_)) would avoid a lot of unnecessary
complications and surprises.

Once you do that, whether as.complex(NA_real_) should return
complex(r=NA_real_, i=0) or complex(r=NA_real_, i=NA_real_) becomes a
moot point.

Best,

H.

On 9/22/23 03:38, Martin Maechler wrote:

Mikael Jagan
  on Thu, 21 Sep 2023 00:47:39 -0400 writes:

  > Revisiting this thread from April:

  >https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html

  > where the decision (not yet backported) was made for
  > as.complex(NA_real_) to give NA_complex_ instead of
  > complex(r=NA_real_, i=0), to be consistent with
  > help("as.complex") and as.complex(NA) and 
as.complex(NA_integer_).


  > Was any consideration given to the alternative?
  > That is, to changing as.complex(NA) and 
as.complex(NA_integer_) to

  > give complex(r=NA_real_, i=0), consistent with
  > as.complex(NA_real_), then amending help("as.complex")
  > accordingly?

Hmm, as, from R-core, mostly I was involved, I admit to say "no",
to my knowledge the (above) alternative wasn't considered.

    > The principle that
    > Im(as.complex()) should be zero
    > is quite fundamental, in my view, hence the "new" behaviour
    > seems to really violate the principle of least surprise ...

of course "least surprise"  is somewhat subjective.  Still,
I clearly agree that the above would be one desirable property.

I think that any solution will lead to *some* surprise for some
cases, I think primarily because there are *many* different
values z  for which  is.na(z)  is true,  and in any case
NA_complex_  is only of the many.

I also agree with Mikael that we should reconsider the issue
that was raised by Davis Vaughan here ("on R-devel") last April.

  > Another (but maybe weaker) argument is that
  > double->complex coercions happen more often than
  > logical->complex and integer->complex ones.  Changing the
  > behaviour of the more frequently performed coercion is
  > more likely to affect code "out there".

  > Yet another argument is that one expects

  >  identical(as.complex(NA_real_), NA_real_ + (0+0i))

  > to be TRUE, i.e., that coercing from double to complex is
  > equivalent to adding a complex zero.  The new behaviour
  > makes the above FALSE, since NA_real_ + (0+0i) gives
  > complex(r=NA_real_, i=0).

No!  --- To my own surprise (!) --- in current R-devel the above is 
TRUE,

and
    NA_real_ + (0+0i)  , the same as
    NA_real_ + 0i  , really gives  complex(r=NA, i=NA) :

Using showC() from ?complex

    showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), 
Im(z)))


we see (in R-devel) quite consistently


showC(NA_real_ + 0i)

[1] (R = NA, I = NA)

showC(NA   + 0i)  # NA is 'logical'

[1] (R = NA, I = NA)
where as in R 4.3.1 and "R-patched" -- *in*consistently


showC(NA_real_ + 0i)

[1] (R = NA, I = 0)

showC(NA + 0i)

[1] (R = NA, I = NA)
 and honestly, I do not see *where* (and when) we changed
the underlying code (in arithmetic.c !?)  in R-devel to *also*
produce  NA_complex_  in such complex *arithmetic*


  > Having said that, one might also (but more naively) expect

  > identical(as.complex(as.double(NA_complex_)), NA_complex_)

  > to be TRUE.

as in current R-devel

  > Under my proposal it continues to be FALSE.

as in "R-release"

  > Well, I'd prefer if it gave FALSE with a warning
  > "imaginary parts discarded in coercion", but it seems that
  > as.double(complex(r=a, i=b)) never warns when either of
  > 'a' and 'b' is NA_real_ or NaN, even where "information"
  > {nonzero 'b'} is clearly lost ...

The question of *warning* here is related indeed, but I think
we should try to look at it only 

Re: [Rd] [External] On PRINTNAME() encoding, EncodeChar(), and being painted into a corner

[luke-tierney]

Thanks for looking into this!

On Mon, 18 Sep 2023, Ivan Krylov wrote:


Hello R-devel,

I have originally learned about this from the following GitHub issue:
. In short,
in various places of the R source code, symbol names are accessed using
translateChar(), EncodeChar(), and CHAR(), and it might help to unify
their use.

Currently, R is very careful to only create symbols with names in the
native encoding. I have verified this by tracing the ways a symbol can
be created (allocSExp) or have a name assigned (SET_PRINTNAME) using
static analysis (Coccinelle). While it's possible to create a symbol
with a name in an encoding different from the native encoding using
SET_PRINTNAME(symbol, mkCharCE(...)), neither R nor CRAN packages
invoke code like this for an arbitrary encoding; symbols are always
created using either install() or installTrChar(). (install("invalid
byte sequence") is, of course, still possible, but is a different
problem.)


SET_PRINTNAME is not in the API and not in the public header files so
this should not be an issue. It would probably be best to refactor
things so SET_PRINTNAME only exists in memory.c


This means that translateChar(PRINTNAME(...)) is currently unnecessary,
but it may be worth adding a check (opt-in, applicable only during R
CMD check, to avoid a performance hit?) to SET_PRINTNAME() to ensure
that only native-encoding (or ASCII) symbol names are used. I could also
suggest a patch for Writing R Extensions or R Internals to document this
assumption.

The following translateChar() doesn't hurt (it returns CHAR(x) right
away without allocating any memory), but it stands out against most
uses of CHAR(PRINTNAME(.)) and EncodeChar(PRINTNAME(.)):

--- src/main/subscript.c(revision 85160)
+++ src/main/subscript.c(working copy)
@@ -186,7 +186,7 @@
PROTECT(names);
for (i = 0; i < nx; i++)
if (streql(translateChar(STRING_ELT(names, i)),
-  translateChar(PRINTNAME(s {
+  CHAR(PRINTNAME(s {
indx = i;
break;
}

The following translateChar() can be safely replaced with EncodeChar(),
correctly printing funnily-named functions in tracemem() reports:

--- src/main/debug.c(revision 85160)
+++ src/main/debug.c(working copy)
@@ -203,7 +203,7 @@
&& TYPEOF(cptr->call) == LANGSXP) {
SEXP fun = CAR(cptr->call);
Rprintf("%s ",
-   TYPEOF(fun) == SYMSXP ? translateChar(PRINTNAME(fun)) :
+   TYPEOF(fun) == SYMSXP ? EncodeChar(PRINTNAME(fun)) : 
"");
}
}

tracemem(a <- 1:10)
`\r\v\t\n` <- function(x) x[1] <- 0
`\r\v\t\n`(a)
# Now correctly prints:
# tracemem[0x55fd11e61e00 -> 0x55fd1081d2a8]: \r\v\t\n
# tracemem[0x55fd1081d2a8 -> 0x55fd113277e8]: \r\v\t\n


Sounds good. I've made those two changes in the trunk in r85209.


What about EncodeChar(PRINTNAME(.))? This is the intended way to report
symbols in error messages. Without EncodeChar(),
.Internal(`\r\v\t\n`()) actually prints the newlines to standard output
as part of the error message instead of escaping them. Unfortunately,
EncodeChar() uses a statically-allocated buffer for its return value,
*and* the comments say that it's unsafe to use together with
errorcall(): errorcall_cpy() must be used instead. I think that's
overwriting the statically-allocated buffer before the format arguments
(which also contain the return value of EncodeChar()) are processed. In
particular, this means that EncodeChar() is unsafe to use with any kind
of warnings. The following Coccinelle script locates uses of
CHAR(PRINTNAME(.)) inside errors and warnings:
@@
expression x;
expression list arg1, arg2;
identifier fun =~ "(Rf_)?(error|warning)(call)?(_cpy)?";
@@
fun(
 arg1,
* CHAR(PRINTNAME(x)),
 arg2
)

Some of these, which already use errorcall(), are trivial to fix by
replacing CHAR() with EncodeChar() and upgrading errorcall() to
errorcall_cpy():


I think it would be best to modify errorcall so errorcall_cpy is not
necessary. As things are now it is just too easy to forget that
sometimes errorcall_cpy should be used (and this has lead to some bugs
recently).


--- src/main/names.c
+++ src/main/names.c
@@ -1367,7 +1367,7 @@ attribute_hidden SEXP do_internal(SEXP c
errorcall(call, _("invalid .Internal() argument"));
if (INTERNAL(fun) == R_NilValue)
-   errorcall(call, _("there is no .Internal function '%s'"),
+   errorcall_cpy(call, _("there is no .Internal function '%s'"),
- CHAR(PRINTNAME(fun)));
+ EncodeChar(PRINTNAME(fun)));

#ifdef CHECK_INTERNALS
if(R_Is_Running > 1 && getenv("_R_CHECK_INTERNALS2_")) {

--- src/main/eval.c
+++ src/main/eval.c
@@ -1161,7 +1161,7 @@ SEXP eval(SEXP e, SEXP rho)
const char *n = CHAR(PRINTNAME(e));
-   if(*n) errorcall(getLexicalCall(rho),
+

Re: [Rd] Recent changes to as.complex(NA_real_)

[Duncan Murdoch]

Since the result of is.na(x) is the same on each of those, I don't see a 
problem.  As long as that is consistent, I don't see a problem.  You 
shouldn't be using any other test for NA-ness.  You should never be 
expecting identical() to treat different types as the same (e.g. 
identical(NA, NA_real_) is FALSE, as it should be).  If you are using a 
different test, that's user error.


Duncan Murdoch

On 22/09/2023 2:41 p.m., Hervé Pagès wrote:

We could also question the value of having an infinite number of NA
representations in the complex space. For example all these complex
values are displayed the same way (as NA), are considered NAs by
is.na(), but are not identical or semantically equivalent (from an Re()
or Im() point of view):

      NA_real_ + 0i

      complex(r=NA_real_, i=Inf)

      complex(r=2, i=NA_real_)

      complex(r=NaN, i=NA_real_)

In other words, using a single representation for complex NA (i.e.
complex(r=NA_real_, i=NA_real_)) would avoid a lot of unnecessary
complications and surprises.

Once you do that, whether as.complex(NA_real_) should return
complex(r=NA_real_, i=0) or complex(r=NA_real_, i=NA_real_) becomes a
moot point.

Best,

H.

On 9/22/23 03:38, Martin Maechler wrote:

Mikael Jagan
  on Thu, 21 Sep 2023 00:47:39 -0400 writes:

  > Revisiting this thread from April:

  >https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html

  > where the decision (not yet backported) was made for
  > as.complex(NA_real_) to give NA_complex_ instead of
  > complex(r=NA_real_, i=0), to be consistent with
  > help("as.complex") and as.complex(NA) and as.complex(NA_integer_).

  > Was any consideration given to the alternative?
  > That is, to changing as.complex(NA) and as.complex(NA_integer_) to
  > give complex(r=NA_real_, i=0), consistent with
  > as.complex(NA_real_), then amending help("as.complex")
  > accordingly?

Hmm, as, from R-core, mostly I was involved, I admit to say "no",
to my knowledge the (above) alternative wasn't considered.

> The principle that
> Im(as.complex()) should be zero
> is quite fundamental, in my view, hence the "new" behaviour
> seems to really violate the principle of least surprise ...

of course "least surprise"  is somewhat subjective.  Still,
I clearly agree that the above would be one desirable property.

I think that any solution will lead to *some* surprise for some
cases, I think primarily because there are *many* different
values z  for which  is.na(z)  is true,  and in any case
NA_complex_  is only of the many.

I also agree with Mikael that we should reconsider the issue
that was raised by Davis Vaughan here ("on R-devel") last April.

  > Another (but maybe weaker) argument is that
  > double->complex coercions happen more often than
  > logical->complex and integer->complex ones.  Changing the
  > behaviour of the more frequently performed coercion is
  > more likely to affect code "out there".

  > Yet another argument is that one expects

  >  identical(as.complex(NA_real_), NA_real_ + (0+0i))

  > to be TRUE, i.e., that coercing from double to complex is
  > equivalent to adding a complex zero.  The new behaviour
  > makes the above FALSE, since NA_real_ + (0+0i) gives
  > complex(r=NA_real_, i=0).

No!  --- To my own surprise (!) --- in current R-devel the above is TRUE,
and
NA_real_ + (0+0i)  , the same as
NA_real_ + 0i  , really gives  complex(r=NA, i=NA) :

Using showC() from ?complex

showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))

we see (in R-devel) quite consistently


showC(NA_real_ + 0i)

[1] (R = NA, I = NA)

showC(NA   + 0i)  # NA is 'logical'

[1] (R = NA, I = NA)
where as in R 4.3.1 and "R-patched" -- *in*consistently


showC(NA_real_ + 0i)

[1] (R = NA, I = 0)

showC(NA + 0i)

[1] (R = NA, I = NA)
 and honestly, I do not see *where* (and when) we changed
the underlying code (in arithmetic.c !?)  in R-devel to *also*
produce  NA_complex_  in such complex *arithmetic*


  > Having said that, one might also (but more naively) expect

  > identical(as.complex(as.double(NA_complex_)), NA_complex_)

  > to be TRUE.

as in current R-devel

  > Under my proposal it continues to be FALSE.

as in "R-release"

  > Well, I'd prefer if it gave FALSE with a warning
  > "imaginary parts discarded in coercion", but it seems that
  > as.double(complex(r=a, i=b)) never warns when either of
  > 'a' and 'b' is NA_real_ or NaN, even where "information"
  > {nonzero 'b'} is clearly lost ...

The question of *warning* here is related indeed, but I think
we should try to look at it only *secondary* to your first
proposal.

  > Whatever decision is made about as.complex(NA_real_),
  > maybe these points should be weighed before it becomes part of
  > R-release ...

  > Mikael

Indeed.

Can we please get other 

Re: [Rd] Recent changes to as.complex(NA_real_)

[Hervé Pagès]

We could also question the value of having an infinite number of NA 
representations in the complex space. For example all these complex 
values are displayed the same way (as NA), are considered NAs by 
is.na(), but are not identical or semantically equivalent (from an Re() 
or Im() point of view):

     NA_real_ + 0i

     complex(r=NA_real_, i=Inf)

     complex(r=2, i=NA_real_)

     complex(r=NaN, i=NA_real_)

In other words, using a single representation for complex NA (i.e. 
complex(r=NA_real_, i=NA_real_)) would avoid a lot of unnecessary 
complications and surprises.

Once you do that, whether as.complex(NA_real_) should return 
complex(r=NA_real_, i=0) or complex(r=NA_real_, i=NA_real_) becomes a 
moot point.

Best,

H.

On 9/22/23 03:38, Martin Maechler wrote:
>> Mikael Jagan
>>  on Thu, 21 Sep 2023 00:47:39 -0400 writes:
>  > Revisiting this thread from April:
>
>  >https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
>
>  > where the decision (not yet backported) was made for
>  > as.complex(NA_real_) to give NA_complex_ instead of
>  > complex(r=NA_real_, i=0), to be consistent with
>  > help("as.complex") and as.complex(NA) and as.complex(NA_integer_).
>
>  > Was any consideration given to the alternative?
>  > That is, to changing as.complex(NA) and as.complex(NA_integer_) to
>  > give complex(r=NA_real_, i=0), consistent with
>  > as.complex(NA_real_), then amending help("as.complex")
>  > accordingly?
>
> Hmm, as, from R-core, mostly I was involved, I admit to say "no",
> to my knowledge the (above) alternative wasn't considered.
>
>> The principle that
>> Im(as.complex()) should be zero
>> is quite fundamental, in my view, hence the "new" behaviour
>> seems to really violate the principle of least surprise ...
>
> of course "least surprise"  is somewhat subjective.  Still,
> I clearly agree that the above would be one desirable property.
>
> I think that any solution will lead to *some* surprise for some
> cases, I think primarily because there are *many* different
> values z  for which  is.na(z)  is true,  and in any case
> NA_complex_  is only of the many.
>
> I also agree with Mikael that we should reconsider the issue
> that was raised by Davis Vaughan here ("on R-devel") last April.
>
>  > Another (but maybe weaker) argument is that
>  > double->complex coercions happen more often than
>  > logical->complex and integer->complex ones.  Changing the
>  > behaviour of the more frequently performed coercion is
>  > more likely to affect code "out there".
>
>  > Yet another argument is that one expects
>
>  >  identical(as.complex(NA_real_), NA_real_ + (0+0i))
>
>  > to be TRUE, i.e., that coercing from double to complex is
>  > equivalent to adding a complex zero.  The new behaviour
>  > makes the above FALSE, since NA_real_ + (0+0i) gives
>  > complex(r=NA_real_, i=0).
>
> No!  --- To my own surprise (!) --- in current R-devel the above is TRUE,
> and
>NA_real_ + (0+0i)  , the same as
>NA_real_ + 0i  , really gives  complex(r=NA, i=NA) :
>
> Using showC() from ?complex
>
>showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))
>
> we see (in R-devel) quite consistently
>
>> showC(NA_real_ + 0i)
> [1] (R = NA, I = NA)
>> showC(NA   + 0i)  # NA is 'logical'
> [1] (R = NA, I = NA)
> where as in R 4.3.1 and "R-patched" -- *in*consistently
>
>> showC(NA_real_ + 0i)
> [1] (R = NA, I = 0)
>> showC(NA + 0i)
> [1] (R = NA, I = NA)
>  and honestly, I do not see *where* (and when) we changed
> the underlying code (in arithmetic.c !?)  in R-devel to *also*
> produce  NA_complex_  in such complex *arithmetic*
>
>
>  > Having said that, one might also (but more naively) expect
>
>  > identical(as.complex(as.double(NA_complex_)), NA_complex_)
>
>  > to be TRUE.
>
> as in current R-devel
>
>  > Under my proposal it continues to be FALSE.
>
> as in "R-release"
>
>  > Well, I'd prefer if it gave FALSE with a warning
>  > "imaginary parts discarded in coercion", but it seems that
>  > as.double(complex(r=a, i=b)) never warns when either of
>  > 'a' and 'b' is NA_real_ or NaN, even where "information"
>  > {nonzero 'b'} is clearly lost ...
>
> The question of *warning* here is related indeed, but I think
> we should try to look at it only *secondary* to your first
> proposal.
>
>  > Whatever decision is made about as.complex(NA_real_),
>  > maybe these points should be weighed before it becomes part of
>  > R-release ...
>
>  > Mikael
>
> Indeed.
>
> Can we please get other opinions / ideas here?
>
> Thank you in advance for your thoughts!
> Martin
>
> ---
>
> PS:
>
>   Our *print()*ing  of complex NA's ("NA" here meaning NA or NaN)
>   is also unsatisfactory, e.g. in the case where all entries of a
>   vector are NA in the sense of is.na(.), but their
>   Re() and Im() are 

[Bioc-devel] Bioconductor 3.18 db0s, OrgDbs, and TxDbs now available

[Interdonato, Kayla via Bioc-devel]

Hello Bioconductor community,

The newest db0, OrgDb, and TxDb annotation packages for the upcoming 
Bioconductor 3.18 release are up and available for download in the devel 
version of Bioconductor.

The deadline for submitting contributed annotation packages will be Wednesday 
October 11th.

The new db0 packages are:

anopheles.db0_3.18.0.tar.gz
arabidopsis.db0_3.18.0.tar.gz
bovine.db0_3.18.0.tar.gz
canine.db0_3.18.0.tar.gz
chicken.db0_3.18.0.tar.gz
chimp.db0_3.18.0.tar.gz
ecoliK12.db0_3.18.0.tar.gz
ecoliSakai.db0_3.18.0.tar.gz
fly.db0_3.18.0.tar.gz
human.db0_3.18.0.tar.gz
malaria.db0_3.18.0.tar.gz
mouse.db0_3.18.0.tar.gz
pig.db0_3.18.0.tar.gz
rat.db0_3.18.0.tar.gz
rhesus.db0_3.18.0.tar.gz
worm.db0_3.18.0.tar.gz
xenopus.db0_3.18.0.tar.gz
yeast.db0_3.18.0.tar.gz
zebrafish.db0_3.18.0.tar.gz

The new OrgDb packages are:

GO.db_3.18.0.tar.gz
org.Ag.eg.db_3.18.0.tar.gz
org.At.tair.db_3.18.0.tar.gz
org.Bt.eg.db_3.18.0.tar.gz
org.Ce.eg.db_3.18.0.tar.gz
org.Cf.eg.db_3.18.0.tar.gz
org.Dm.eg.db_3.18.0.tar.gz
org.Dr.eg.db_3.18.0.tar.gz
org.EcK12.eg.db_3.18.0.tar.gz
org.EcSakai.eg.db_3.18.0.tar.gz
org.Gg.eg.db_3.18.0.tar.gz
org.Hs.eg.db_3.18.0.tar.gz
org.Mm.eg.db_3.18.0.tar.gz
org.Mmu.eg.db_3.18.0.tar.gz
org.Pt.eg.db_3.18.0.tar.gz
org.Rn.eg.db_3.18.0.tar.gz
org.Sc.eg.db_3.18.0.tar.gz
org.Ss.eg.db_3.18.0.tar.gz
org.Xl.eg.db_3.18.0.tar.gz
Orthology.eg.db_3.18.0.tar.gz
PFAM.db_3.18.0.tar.gz

The new TxDb packages are:

TxDb.Hsapiens.UCSC.hg38.knownGene_3.18.0.tar.gz
TxDb.Hsapiens.UCSC.hg38.refGene_3.18.0.tar.gz
TxDb.Mmusculus.UCSC.mm39.knownGene_3.18.0.tar.gz
TxDb.Mmusculus.UCSC.mm39.refGene_3.18.0.tar.gz

Thank you!

Kayla E. Interdonato, MS
Programmer/Analyst � Morgan Lab
Roswell Park Comprehensive Cancer Center
Department of Biostatistics & Bioinformatics
(716)845-1300 x4621


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Bioconductor project proposals for Outreachy internships by 9/29

[Jennifer Wokaty]

Bioconductor is participating in the Outreachy internship program for the 
December 2023 - March 2024 cohort. Outreachy's goal is to support people from 
groups underrepresented in the technology industry. Interns will work remotely 
with mentors from our community.


We are seeking mentors from the Bioconductor community to propose projects that 
Outreachy interns can work on during their internship. Projects must be open 
source and can include programming, research, design, event planning, UX, data 
science, and more. The deadline to submit projects is next week on Sept. 29, 
2023 at 4 pm UTC. Visit https://www.outreachy.org/communities/cfp/bioconductor/ 
to submit a project.


Mentors FAQ: 
https://www.outreachy.org/mentor/mentor-faq


Full details about the Outreachy program and the internship timeline can be 
found on the Call for Participation page on the Outreachy website: 
https://www.outreachy.org/communities/cfp/.


Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPH
Bioconductor Core Team

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] magpie package failing unit test

[Daoyu Duan]

Dear Bioconductor team,

I have received emails that my package "magpie" is failing the unit test
in devel, but I have not made any changes after the last release where the
unit test passed. I tried to investigate this issue but the unit test
passed on my local machines (MacOS and Windows) and was not able to
replicate the error. Are there any possible reasons for this to happen?
Thank you so much for any suggestions!

Best regards,

Daoyu

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Recent changes to as.complex(NA_real_)

[Mikael Jagan]

On 2023-09-22 6:38 am, Martin Maechler wrote:

Mikael Jagan
 on Thu, 21 Sep 2023 00:47:39 -0400 writes:


 > Revisiting this thread from April:

 >  https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html

 > where the decision (not yet backported) was made for
 > as.complex(NA_real_) to give NA_complex_ instead of
 > complex(r=NA_real_, i=0), to be consistent with
 > help("as.complex") and as.complex(NA) and as.complex(NA_integer_).

 > Was any consideration given to the alternative?
 > That is, to changing as.complex(NA) and as.complex(NA_integer_) to
 > give complex(r=NA_real_, i=0), consistent with
 > as.complex(NA_real_), then amending help("as.complex")
 > accordingly?

Hmm, as, from R-core, mostly I was involved, I admit to say "no",
to my knowledge the (above) alternative wasn't considered.

   > The principle that
   > Im(as.complex()) should be zero
   > is quite fundamental, in my view, hence the "new" behaviour
   > seems to really violate the principle of least surprise ...

of course "least surprise"  is somewhat subjective.  Still,
I clearly agree that the above would be one desirable property.

I think that any solution will lead to *some* surprise for some
cases, I think primarily because there are *many* different
values z  for which  is.na(z)  is true,  and in any case
NA_complex_  is only of the many.

I also agree with Mikael that we should reconsider the issue
that was raised by Davis Vaughan here ("on R-devel") last April.

 > Another (but maybe weaker) argument is that
 > double->complex coercions happen more often than
 > logical->complex and integer->complex ones.  Changing the
 > behaviour of the more frequently performed coercion is
 > more likely to affect code "out there".

 > Yet another argument is that one expects

 >  identical(as.complex(NA_real_), NA_real_ + (0+0i))

 > to be TRUE, i.e., that coercing from double to complex is
 > equivalent to adding a complex zero.  The new behaviour
 > makes the above FALSE, since NA_real_ + (0+0i) gives
 > complex(r=NA_real_, i=0).

No!  --- To my own surprise (!) --- in current R-devel the above is TRUE,
and
   NA_real_ + (0+0i)  , the same as
   NA_real_ + 0i  , really gives  complex(r=NA, i=NA) :



Thank you for the correction - indeed, as.complex(NA_real_) and
NA_real_ + (0+0i) are identical in both R-patched and R-devel,
both giving complex(r=NA_real_, i=0) in R-patched and both giving
NA_complex_ in R-devel.  I was hallucating, it seems ...


Using showC() from ?complex

   showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))

we see (in R-devel) quite consistently


showC(NA_real_ + 0i)

[1] (R = NA, I = NA)

showC(NA   + 0i)  # NA is 'logical'

[1] (R = NA, I = NA)




where as in R 4.3.1 and "R-patched" -- *in*consistently


showC(NA_real_ + 0i)

[1] (R = NA, I = 0)

showC(NA + 0i)

[1] (R = NA, I = NA)




 and honestly, I do not see *where* (and when) we changed
the underlying code (in arithmetic.c !?)  in R-devel to *also*
produce  NA_complex_  in such complex *arithmetic*



R_binary() in arithmetic.c has always coerced REALSXP->CPLXSXP when
encountering one of each.  Surely then the changes in coerce.c are the
cause and this arithmetic behaviour is just a (bad, IMO) side effect?



 > Having said that, one might also (but more naively) expect

 > identical(as.complex(as.double(NA_complex_)), NA_complex_)

 > to be TRUE.

as in current R-devel

 > Under my proposal it continues to be FALSE.

as in "R-release"

 > Well, I'd prefer if it gave FALSE with a warning
 > "imaginary parts discarded in coercion", but it seems that
 > as.double(complex(r=a, i=b)) never warns when either of
 > 'a' and 'b' is NA_real_ or NaN, even where "information"
 > {nonzero 'b'} is clearly lost ...

The question of *warning* here is related indeed, but I think
we should try to look at it only *secondary* to your first
proposal.

 > Whatever decision is made about as.complex(NA_real_),
 > maybe these points should be weighed before it becomes part of
 > R-release ...

 > Mikael

Indeed.

Can we please get other opinions / ideas here?



Thank you, Martin, for "reopening".

Mikael


Thank you in advance for your thoughts!
Martin

---

PS:

  Our *print()*ing  of complex NA's ("NA" here meaning NA or NaN)
  is also unsatisfactory, e.g. in the case where all entries of a
  vector are NA in the sense of is.na(.), but their
  Re() and Im() are not all NA:
  
   showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))

   z <- complex(, c(11, NA, NA), c(NA, 99, NA))
   z
   showC(z)

gives

   > z
   [1] NA NA NA
   > showC(z)
   [1] (R = 11, I = NA) (R = NA, I = 99) (R = NA, I = NA)

but that (printing of complex) *is* another issue,
in which we have the re-opened bugzilla PR#16752
 ==>   

Re: [R-pkg-devel] tinyfiledialogs - The bindings are ready, but I need help to make of package of it

[Paul Smith]

Hi Guillaume

As Ivan says there is a fair bit to packaging but not to much when you 
get used to it.


Since your email I've put a mostly untested package wrapping 
tingfiledialogs via Rcpp on github


https://github.com/waternumbers/tinyfiledialogR

It is far from fully tested but might help.

cheers

Paul

--
The information in this message and any attachments is l...{{dropped:9}}

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Recent changes to as.complex(NA_real_)

[Martin Maechler]

> Mikael Jagan 
> on Thu, 21 Sep 2023 00:47:39 -0400 writes:

> Revisiting this thread from April:

>  https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html

> where the decision (not yet backported) was made for
> as.complex(NA_real_) to give NA_complex_ instead of
> complex(r=NA_real_, i=0), to be consistent with
> help("as.complex") and as.complex(NA) and as.complex(NA_integer_).

> Was any consideration given to the alternative?  
> That is, to changing as.complex(NA) and as.complex(NA_integer_) to
> give complex(r=NA_real_, i=0), consistent with
> as.complex(NA_real_), then amending help("as.complex")
> accordingly?

Hmm, as, from R-core, mostly I was involved, I admit to say "no",
to my knowledge the (above) alternative wasn't considered.

  > The principle that
  > Im(as.complex()) should be zero
  > is quite fundamental, in my view, hence the "new" behaviour 
  > seems to really violate the principle of least surprise ...

of course "least surprise"  is somewhat subjective.  Still,
I clearly agree that the above would be one desirable property.

I think that any solution will lead to *some* surprise for some
cases, I think primarily because there are *many* different
values z  for which  is.na(z)  is true,  and in any case
NA_complex_  is only of the many.

I also agree with Mikael that we should reconsider the issue
that was raised by Davis Vaughan here ("on R-devel") last April.

> Another (but maybe weaker) argument is that
> double->complex coercions happen more often than
> logical->complex and integer->complex ones.  Changing the
> behaviour of the more frequently performed coercion is
> more likely to affect code "out there".

> Yet another argument is that one expects

>  identical(as.complex(NA_real_), NA_real_ + (0+0i))

> to be TRUE, i.e., that coercing from double to complex is
> equivalent to adding a complex zero.  The new behaviour
> makes the above FALSE, since NA_real_ + (0+0i) gives
> complex(r=NA_real_, i=0).

No!  --- To my own surprise (!) --- in current R-devel the above is TRUE, 
and
  NA_real_ + (0+0i)  , the same as
  NA_real_ + 0i  , really gives  complex(r=NA, i=NA) :

Using showC() from ?complex

  showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))

we see (in R-devel) quite consistently

> showC(NA_real_ + 0i)
[1] (R = NA, I = NA)
> showC(NA   + 0i)  # NA is 'logical'
[1] (R = NA, I = NA)
> 

where as in R 4.3.1 and "R-patched" -- *in*consistently

> showC(NA_real_ + 0i)
[1] (R = NA, I = 0)
> showC(NA + 0i)
[1] (R = NA, I = NA)
> 

 and honestly, I do not see *where* (and when) we changed
the underlying code (in arithmetic.c !?)  in R-devel to *also*
produce  NA_complex_  in such complex *arithmetic*


> Having said that, one might also (but more naively) expect

> identical(as.complex(as.double(NA_complex_)), NA_complex_)

> to be TRUE.  

as in current R-devel

> Under my proposal it continues to be FALSE.

as in "R-release"

> Well, I'd prefer if it gave FALSE with a warning
> "imaginary parts discarded in coercion", but it seems that
> as.double(complex(r=a, i=b)) never warns when either of
> 'a' and 'b' is NA_real_ or NaN, even where "information"
> {nonzero 'b'} is clearly lost ...

The question of *warning* here is related indeed, but I think
we should try to look at it only *secondary* to your first
proposal.

> Whatever decision is made about as.complex(NA_real_),
> maybe these points should be weighed before it becomes part of
> R-release ...

> Mikael

Indeed.

Can we please get other opinions / ideas here?

Thank you in advance for your thoughts!
Martin

--- 

PS: 

 Our *print()*ing  of complex NA's ("NA" here meaning NA or NaN)
 is also unsatisfactory, e.g. in the case where all entries of a
 vector are NA in the sense of is.na(.), but their
 Re() and Im() are not all NA:
 
  showC <- function(z) noquote(sprintf("(R = %g, I = %g)", Re(z), Im(z)))
  z <- complex(, c(11, NA, NA), c(NA, 99, NA))
  z
  showC(z)

gives

  > z
  [1] NA NA NA
  > showC(z)
  [1] (R = 11, I = NA) (R = NA, I = 99) (R = NA, I = NA)

but that (printing of complex) *is* another issue,
in which we have the re-opened bugzilla PR#16752
==>   https://bugs.r-project.org/show_bug.cgi?id=16752

on which we also worked during the R Sprint in Warwick three
weeks ago, and where I want to commit changes in any case {but
think we should change even a bit more than we got to during the
Sprint}.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] R interface to tinyfiledialog

[tinyfiledialogs]

I did my bindings using the easy .C interface
did you use the morecomplete .CALL ?

On 9/22/23 00:08, Paul Smith wrote:
> Hi,
>
> Following your email to the r-package-dev list I tidied up some 
> previous work I did with an R wrapper for the tinyfiledialog C code 
> into a package which can be found here
>
> https://github.com/waternumbers/tinyfiledialogR
>
> It is largely untested (except on my linux machine - KDE, openSUSE 
> tumbleweed) and not ready for CRAN but shows one way of interfacing to 
> the code.
>
> Feel free to fork or submit pull requests as you see fit.
>
> cheers
>
> Paul
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tinyfiledialogs - The bindings are ready, but I need help to make of package of it

[Brad Eck]

Dear Guillaume -

Here is a minimal example of an R package that uses C source:
https://github.com/bradleyjeck/fancyRpkg

As the timestamps show, I made this a few years ago, so some things might
not conform to the current version of Writing R Extensions.  But it should
get you started.

The motivation I had was to provide an R package that binds to a simulation
engine written in C.
That package is on CRAN and could be used as a more in depth example:
https://cran.r-project.org/package=epanet2toolkit

Hope this helps,

Brad



On Fri, Sep 22, 2023 at 6:33 AM  wrote:

> Hi,
>
> There are no dependencies and everything is considered/treated as UTF-8.
> On windows, I internally do all the conversions between UTF-8 and UTF-16.
> I also offer functions to convert between UTF-8 , UTF-16 and MBCS.
> I don't know what UCRT is, but tinyfiledialogs is compatible with all
> versions of windows from XP to 11,
> all the versions of mac since osx 10.2 and all the unix versions I have
> ever came accross.
>
>
> I was hoping to find a tldr version of the "how to write an extension".
> The source code is just one C file (+ header) and one R file for the
> interface.
> What files are supposed to be in my package ? the C file or the compiled
> shared libraries ?
> What else ? a documentation file ? is there a model to follow ?
>
> thanks for your help
>
> guillaume
>
>
>
> On 9/21/23 11:33, Ivan Krylov wrote:
> > Dear Guillaume Vareille,
> >
> > В Wed, 20 Sep 2023 12:30:53 +0200
> > tinyfiledial...@ysengrin.com  пишет:
> >
> >> I've been pointed to the documentation link on how to write a package,
> >> but it would really help if someone who knows what to do could direct
> >> me.
> > There's potentially a lot to tell. Converting the entire Writing R
> > Extensions [*] into e-mails is a poor use of one's time. Do you have
> > more specific questions? If you don't know where to start, try
> > utils::package.skeleton or the pkgKitten package (which aims to pass R
> > CMD check right from the start). There's also books like R Packages by
> > Hadley Wickham and Jennifer Bryan, but they mention a lot of techniques
> > and third-party dependencies that you don't have to use.
> >
> >>   # first load the included library (it could easily be compiled
> >> on the target machine)
> >>   dyn.load("tinyfiledialogsLinux64.so")
> > You will need to put your source files into the src/ subdirectory of
> > the package and arrange for them to get compiled (see WRE 1.1.5 and
> > 1.2.1). It's best to write a special entry point in order to let R know
> > about the functions you intend to call (see WRE 5.4).
> >
> > Does your code have third-party dependencies? If you'd like to put the
> > package on CRAN, you will need to bundle your own code with the package
> > (since it's probably not available yet in major GNU/Linux
> > distributions, macOS recipes and MXE) but set up a ./configure script
> > to locate the third-party dependencies while the package is being
> > installed:https://cran.r-project.org/web/packages/external_libs.html
> >
> >> result <- .C("tfd_openFileDialog",
> >>   charToRaw(aTitle),
> > In R, strings have encodings. A string can be stored in UTF-8, Latin-1,
> > the native locale encoding (which may include anything from
> > Windows-936 to KOI8-R) or even as arbitrary bytes, which admittedly
> > makes it less of a string (see ?Encoding).
> >
> > x1 <- `Encoding<-`('fran\xe7ais', 'latin1')
> > x2 <- `Encoding<-`('fran\xc3\xa7ais', 'UTF-8')
> > x1 == x2 # TRUE, they encode the same characters
> > identical(charToRaw(x1), charToRaw(x2)) # not even the same length
> >
> > Which encoding does tfd_openFileDialog() use for the file names and
> > paths? Does it work with UCRT on Windows in UTF-8 locale mode? (Can you
> > return a filename that is not representable in the ANSI codepage?) You
> > will probably need to convert the strings into a certain encoding before
> > passing them to tfd_openFileDialog(...) (e.g. enc2utf8(.)).
> >
> >> if ( result$lOpenFile == "NULL" ) return()
> > What happens if I create a file named NULL on my system and try to open
> > it?
> >
> > Good luck, and I hope that your effort results in a good R package!
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel