Re: [Rd] rbind has confusing result for custom sub-class (possible bug?)

2019-05-27 Thread Joshua Ulrich 
Follow-up (inline) on my comment about a potential issue in `[<-.Date`.

On Mon, May 27, 2019 at 9:31 AM Michael Chirico
 wrote:
>
> Yes, thanks for following up on thread here. And thanks again for clearing 
> things up, your email was a finger snap of clarity on the whole issue.
>
> I'll add that actually it was data.table's code at fault on the storage 
> conversion -- note that if you use an arbitrary sub-class 'foo' with no 
> methods defined, it'll stay integer.
>
> That's because [<- calls as.Date and then as.Date.IDate, and that method 
> (ours) has as.numeric(); earlier I had recognized that if we commented that 
> line, the issue was "fixed" but I still wasn't understanding the root cause.
>
> My last curiosity on this issue will be in my follow-up thread.
>
> Mike C
>
> On Mon, May 27, 2019, 10:25 PM Joshua Ulrich  wrote:
>>
>> On Sun, May 26, 2019 at 6:47 AM Joshua Ulrich  
>> wrote:
>> >
>> > On Sun, May 26, 2019 at 4:06 AM Michael Chirico
>> >  wrote:
>> > >
>> > > Have finally managed to come up with a fix after checking out sys.calls()
>> > > from within the as.Date.IDate debugger, which shows something like:
>> > >
>> > > [[1]] rbind(DF, DF)
>> > > [[2]] rbind(deparse.level, ...)
>> > > [[3]] `[<-`(`*tmp*`, ri, value = 18042L)
>> > > [[4]] `[<-.Date`(`*tmp*`, ri, value = 18042L)
>> > > [[5]] as.Date(value)
>> > > [[6]] as.Date.IDate(value)
>> > >
>> > > I'm not sure why [<- is called, I guess the implementation is to assign 
>> > > to
>> > > the output block by block? Anyway, we didn't have a [<- method. And
>> > > [<-.Date looks like:
>> > >
>> > > value <- unclass(as.Date(value)) # <- converts to double
>> > > .Date(NextMethod(.Generic), oldClass(x)) # <- restores 'IDate' class
>> > >
>> > > So we can fix our bug by defining a [<- class; the question that I still
>> > > don't see answered in documentation or source code is, why/where is [<-
>> > > called, exactly?
>> > >
>> > Your rbind(DF, DF) call dispatches to base::rbind.data.frame().  The
>> > `[<-` call is this line:
>> > value[[jj]][ri] <- if (is.factor(xij)) as.vector(xij) else xij
>> >
>> > That's where the storage.mode changes from integer to double.
>> >
>> > debug: value[[jj]][ri] <- if (is.factor(xij)) as.vector(xij) else xij
>> > Browse[2]>
>> > debug: xij
>> > Browse[2]> storage.mode(xij)
>> > [1] "integer"
>> > Browse[2]> value[[jj]][ri]
>> > [1] "2019-05-26"
>> > Browse[2]> storage.mode(value[[jj]][ri])
>> > [1] "integer"
>> > Browse[2]>
>> > debug: if (!is.null(nm <- names(xij))) names(value[[jj]])[ri] <- nm
>> > Browse[2]> storage.mode(value[[jj]][ri])
>> > [1] "double"
>> >
>> To be clear, I don't think this is a bug in rbind() or
>> rbind.data.frame().  The confusion is that rbind.data.frame() calls
>> `[<-` for each column of the data.frame, and there is no `[<-.IDate`
>> method.  So the parent class method is dispatched, which converts the
>> storage mode to double.
>>
>> Someone may argue that this is an issue with `[<-.Date`, and that it
>> shouldn't convert the storage.mode from integer to double.

I don't think this is an issue.  The storage mode isn't converted if
the replacement is the same storage mode.  For example:

R> x <- .Date(1:5)
R> storage.mode(x)
[1] "integer"
R> x[1L] <- .Date(0L)
R> storage.mode(x)
[1] "integer"
R> x[1L] <- .Date(0)
R> storage.mode(x)
[1] "double"

>> >
>> > > Mike C
>> > >
>> > > On Sun, May 26, 2019 at 1:16 PM Michael Chirico 
>> > > 
>> > > wrote:
>> > >
>> > > > Debugging this issue:
>> > > >
>> > > > https://github.com/Rdatatable/data.table/issues/2008
>> > > >
>> > > > We have custom class 'IDate' which inherits from 'Date' (it just forces
>> > > > integer storage for efficiency, hence, I).
>> > > >
>> > > > The concatenation done by rbind, however, breaks this and returns a 
>> > > > double:
>> > > >
>> > > > library(data.table)
>> > > > DF = data.frame(date = as.IDate(Sys.Date()))
>> > > > storage.mode(rbind(DF, DF)$date)
>> > > > # [1] "double"
>> > > >
>> > > > This is specific to base::rbind (data.table's rbind returns an integer 
>> > > > as
>> > > > expected); in ?rbind we see:
>> > > >
>> > > > The method dispatching is not done via UseMethod(), but by C-internal
>> > > > dispatching. Therefore there is no need for, e.g., rbind.default.
>> > > > The dispatch algorithm is described in the source file
>> > > > (‘.../src/main/bind.c’) as
>> > > > 1. For each argument we get the list of possible class memberships from
>> > > > the class attribute.
>> > > > 2. *We inspect each class in turn to see if there is an applicable
>> > > > method.*
>> > > > 3. If we find an applicable method we make sure that it is identical to
>> > > > any method determined for prior arguments. If it is identical, we 
>> > > > proceed,
>> > > > otherwise we immediately drop through to the default code.
>> > > >
>> > > > It's not clear what #2 means -- an applicable method *for what*? 
>> > > > Glancing
>> > > > at the source code would suggest it's looking for rbind.IDate:
>> > > >
>> > > >

Re: [Rd] rbind has confusing result for custom sub-class (possible bug?)

2019-05-27 Thread Michael Chirico 
Yes, thanks for following up on thread here. And thanks again for clearing
things up, your email was a finger snap of clarity on the whole issue.

I'll add that actually it was data.table's code at fault on the storage
conversion -- note that if you use an arbitrary sub-class 'foo' with no
methods defined, it'll stay integer.

That's because [<- calls as.Date and then as.Date.IDate, and that method
(ours) has as.numeric(); earlier I had recognized that if we commented that
line, the issue was "fixed" but I still wasn't understanding the root cause.

My last curiosity on this issue will be in my follow-up thread.

Mike C

On Mon, May 27, 2019, 10:25 PM Joshua Ulrich 
wrote:

> On Sun, May 26, 2019 at 6:47 AM Joshua Ulrich 
> wrote:
> >
> > On Sun, May 26, 2019 at 4:06 AM Michael Chirico
> >  wrote:
> > >
> > > Have finally managed to come up with a fix after checking out
> sys.calls()
> > > from within the as.Date.IDate debugger, which shows something like:
> > >
> > > [[1]] rbind(DF, DF)
> > > [[2]] rbind(deparse.level, ...)
> > > [[3]] `[<-`(`*tmp*`, ri, value = 18042L)
> > > [[4]] `[<-.Date`(`*tmp*`, ri, value = 18042L)
> > > [[5]] as.Date(value)
> > > [[6]] as.Date.IDate(value)
> > >
> > > I'm not sure why [<- is called, I guess the implementation is to
> assign to
> > > the output block by block? Anyway, we didn't have a [<- method. And
> > > [<-.Date looks like:
> > >
> > > value <- unclass(as.Date(value)) # <- converts to double
> > > .Date(NextMethod(.Generic), oldClass(x)) # <- restores 'IDate' class
> > >
> > > So we can fix our bug by defining a [<- class; the question that I
> still
> > > don't see answered in documentation or source code is, why/where is [<-
> > > called, exactly?
> > >
> > Your rbind(DF, DF) call dispatches to base::rbind.data.frame().  The
> > `[<-` call is this line:
> > value[[jj]][ri] <- if (is.factor(xij)) as.vector(xij) else xij
> >
> > That's where the storage.mode changes from integer to double.
> >
> > debug: value[[jj]][ri] <- if (is.factor(xij)) as.vector(xij) else xij
> > Browse[2]>
> > debug: xij
> > Browse[2]> storage.mode(xij)
> > [1] "integer"
> > Browse[2]> value[[jj]][ri]
> > [1] "2019-05-26"
> > Browse[2]> storage.mode(value[[jj]][ri])
> > [1] "integer"
> > Browse[2]>
> > debug: if (!is.null(nm <- names(xij))) names(value[[jj]])[ri] <- nm
> > Browse[2]> storage.mode(value[[jj]][ri])
> > [1] "double"
> >
> To be clear, I don't think this is a bug in rbind() or
> rbind.data.frame().  The confusion is that rbind.data.frame() calls
> `[<-` for each column of the data.frame, and there is no `[<-.IDate`
> method.  So the parent class method is dispatched, which converts the
> storage mode to double.
>
> Someone may argue that this is an issue with `[<-.Date`, and that it
> shouldn't convert the storage.mode from integer to double.
> >
> > > Mike C
> > >
> > > On Sun, May 26, 2019 at 1:16 PM Michael Chirico <
> michaelchiri...@gmail.com>
> > > wrote:
> > >
> > > > Debugging this issue:
> > > >
> > > > https://github.com/Rdatatable/data.table/issues/2008
> > > >
> > > > We have custom class 'IDate' which inherits from 'Date' (it just
> forces
> > > > integer storage for efficiency, hence, I).
> > > >
> > > > The concatenation done by rbind, however, breaks this and returns a
> double:
> > > >
> > > > library(data.table)
> > > > DF = data.frame(date = as.IDate(Sys.Date()))
> > > > storage.mode(rbind(DF, DF)$date)
> > > > # [1] "double"
> > > >
> > > > This is specific to base::rbind (data.table's rbind returns an
> integer as
> > > > expected); in ?rbind we see:
> > > >
> > > > The method dispatching is not done via UseMethod(), but by C-internal
> > > > dispatching. Therefore there is no need for, e.g., rbind.default.
> > > > The dispatch algorithm is described in the source file
> > > > (‘.../src/main/bind.c’) as
> > > > 1. For each argument we get the list of possible class memberships
> from
> > > > the class attribute.
> > > > 2. *We inspect each class in turn to see if there is an applicable
> > > > method.*
> > > > 3. If we find an applicable method we make sure that it is identical
> to
> > > > any method determined for prior arguments. If it is identical, we
> proceed,
> > > > otherwise we immediately drop through to the default code.
> > > >
> > > > It's not clear what #2 means -- an applicable method *for what*?
> Glancing
> > > > at the source code would suggest it's looking for rbind.IDate:
> > > >
> > > >
> https://github.com/wch/r-source/blob/trunk/src/main/bind.c#L1051-L1063
> > > >
> > > > const char *generic = ((PRIMVAL(op) == 1) ? "cbind" : "rbind"); //
> should
> > > > be rbind here
> > > > const char *s = translateChar(STRING_ELT(classlist, i)); //
> iterating over
> > > > the classes, should get to IDate first
> > > > sprintf(buf, "%s.%s", generic, s); // should be rbind.IDate
> > > >
> > > > but adding this method (or even exporting it) is no help [ simply
> defining
> > > > rbind.IDate = function(...) as.IDate(NextMethod()) ]
> > > >
> > > >

Re: [Rd] rbind has confusing result for custom sub-class (possible bug?)

2019-05-27 Thread Joshua Ulrich 
On Sun, May 26, 2019 at 6:47 AM Joshua Ulrich  wrote:
>
> On Sun, May 26, 2019 at 4:06 AM Michael Chirico
>  wrote:
> >
> > Have finally managed to come up with a fix after checking out sys.calls()
> > from within the as.Date.IDate debugger, which shows something like:
> >
> > [[1]] rbind(DF, DF)
> > [[2]] rbind(deparse.level, ...)
> > [[3]] `[<-`(`*tmp*`, ri, value = 18042L)
> > [[4]] `[<-.Date`(`*tmp*`, ri, value = 18042L)
> > [[5]] as.Date(value)
> > [[6]] as.Date.IDate(value)
> >
> > I'm not sure why [<- is called, I guess the implementation is to assign to
> > the output block by block? Anyway, we didn't have a [<- method. And
> > [<-.Date looks like:
> >
> > value <- unclass(as.Date(value)) # <- converts to double
> > .Date(NextMethod(.Generic), oldClass(x)) # <- restores 'IDate' class
> >
> > So we can fix our bug by defining a [<- class; the question that I still
> > don't see answered in documentation or source code is, why/where is [<-
> > called, exactly?
> >
> Your rbind(DF, DF) call dispatches to base::rbind.data.frame().  The
> `[<-` call is this line:
> value[[jj]][ri] <- if (is.factor(xij)) as.vector(xij) else xij
>
> That's where the storage.mode changes from integer to double.
>
> debug: value[[jj]][ri] <- if (is.factor(xij)) as.vector(xij) else xij
> Browse[2]>
> debug: xij
> Browse[2]> storage.mode(xij)
> [1] "integer"
> Browse[2]> value[[jj]][ri]
> [1] "2019-05-26"
> Browse[2]> storage.mode(value[[jj]][ri])
> [1] "integer"
> Browse[2]>
> debug: if (!is.null(nm <- names(xij))) names(value[[jj]])[ri] <- nm
> Browse[2]> storage.mode(value[[jj]][ri])
> [1] "double"
>
To be clear, I don't think this is a bug in rbind() or
rbind.data.frame().  The confusion is that rbind.data.frame() calls
`[<-` for each column of the data.frame, and there is no `[<-.IDate`
method.  So the parent class method is dispatched, which converts the
storage mode to double.

Someone may argue that this is an issue with `[<-.Date`, and that it
shouldn't convert the storage.mode from integer to double.
>
> > Mike C
> >
> > On Sun, May 26, 2019 at 1:16 PM Michael Chirico 
> > wrote:
> >
> > > Debugging this issue:
> > >
> > > https://github.com/Rdatatable/data.table/issues/2008
> > >
> > > We have custom class 'IDate' which inherits from 'Date' (it just forces
> > > integer storage for efficiency, hence, I).
> > >
> > > The concatenation done by rbind, however, breaks this and returns a 
> > > double:
> > >
> > > library(data.table)
> > > DF = data.frame(date = as.IDate(Sys.Date()))
> > > storage.mode(rbind(DF, DF)$date)
> > > # [1] "double"
> > >
> > > This is specific to base::rbind (data.table's rbind returns an integer as
> > > expected); in ?rbind we see:
> > >
> > > The method dispatching is not done via UseMethod(), but by C-internal
> > > dispatching. Therefore there is no need for, e.g., rbind.default.
> > > The dispatch algorithm is described in the source file
> > > (‘.../src/main/bind.c’) as
> > > 1. For each argument we get the list of possible class memberships from
> > > the class attribute.
> > > 2. *We inspect each class in turn to see if there is an applicable
> > > method.*
> > > 3. If we find an applicable method we make sure that it is identical to
> > > any method determined for prior arguments. If it is identical, we proceed,
> > > otherwise we immediately drop through to the default code.
> > >
> > > It's not clear what #2 means -- an applicable method *for what*? Glancing
> > > at the source code would suggest it's looking for rbind.IDate:
> > >
> > > https://github.com/wch/r-source/blob/trunk/src/main/bind.c#L1051-L1063
> > >
> > > const char *generic = ((PRIMVAL(op) == 1) ? "cbind" : "rbind"); // should
> > > be rbind here
> > > const char *s = translateChar(STRING_ELT(classlist, i)); // iterating over
> > > the classes, should get to IDate first
> > > sprintf(buf, "%s.%s", generic, s); // should be rbind.IDate
> > >
> > > but adding this method (or even exporting it) is no help [ simply defining
> > > rbind.IDate = function(...) as.IDate(NextMethod()) ]
> > >
> > > Lastly, it appears that as.Date.IDate is called, which is causing the type
> > > conversion:
> > >
> > > debug(data.table:::as.Date.IDate)
> > > rbind(DF, DF) # launches debugger
> > > x
> > > # [1] "2019-05-26" <-- singleton, so apparently applied to DF$date, not
> > > c(DF$date, DF$date)
> > > undebug(data.table:::as.Date.IDate)
> > >
> > > I can't really wrap my head around why as.Date is being called here, and
> > > even allowing that, why the end result is still the original class [
> > > class(rbind(DF, DF)$date) == c('IDate', 'Date') ]
> > >
> > > So, I'm beginning to think this might be a bug. Am I missing something?
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
> R/Finance

Re: [Rd] bug in rbind?

2019-05-27 Thread Martin Maechler 
With thanks to Krzysztof Banas (and Joshua Ulrich),

Almost 2.5 years ago, there's been a bug report that never made
it to  https://bugs.r-project.org/  and has been forgotten
... until I've stumbled over this again.

I've found an easy fix (and improved readability also by adding
comments) and committed the fix to R-devel rev 76612 , planned
to be ported to   R 3.6.0 patched   a bit later.

Thank you once more!
Martin

--
Martin Maechler
ETH Zurich  and  R Core Team


> Joshua Ulrich 
> on Sat, 21 Jan 2017 11:58:18 -0600 writes:

> I'm not sure whether or not this is a bug, but I did isolate the line
> where the error is thrown:
> src/library/base/R/dataframe.R:1395.
> 
https://github.com/wch/r-source/blob/01374c3c367fa12f555fd354f735a6e16e5bd98e/src/library/base/R/dataframe.R#L1395

> The error is thrown because the line attempts to set a subset of the
> rownames to NULL, which fails.

R> options(error = recover)
R> rbind(dfm.names, dfm)
> Error in rownames(value[[jj]])[ri] <- rownames(xij) :
> replacement has length zero

> Enter a frame number, or 0 to exit

> 1: rbind(dfm.names, dfm)
> 2: rbind(deparse.level, ...)

> Selection: 2
> Called from: top level
> Browse[1]> rownames(value[[jj]])
> [1] "a" "b" "c" NA  NA  NA
> Browse[1]> rownames(xij)
> NULL
> Browse[1]> ri
> [1] 4 5 6
> Browse[1]> rownames(value[[jj]])[ri]
> [1] NA NA NA


> On Mon, Jan 16, 2017 at 7:50 PM, Krzysztof Banas  
wrote:
>> I suspect there may be a bug in base::rbind.data.frame
>> 
>> Below there is minimal example of the problem:
>> 
>> m <- matrix (1:12, 3)
>> dfm <- data.frame (c = 1 : 3, m = I (m))
>> str (dfm)
>> 
>> m.names <- m
>> rownames (m.names) <- letters [1:3]
>> dfm.names <- data.frame (c = 1 : 3, m = I (m.names))
>> str (dfm.names)
>> 
>> rbind (m, m.names)
>> rbind (m.names, m)
>> rbind (dfm, dfm.names)
>> 
>> #not working
>> rbind (dfm.names, dfm)
>> 
>> Error in rbind(deparse.level, ...) : replacement has length zero
>> 
>> rbind (dfm, dfm.names)$m
>> 
>> 
>> [,1] [,2] [,3] [,4]
>> 
>> 147   10
>> 
>> 258   11
>> 
>> 369   12
>> 
>> a   147   10
>> 
>> b   258   11
>> 
>> c   369   12
>> 
>> 
>> 
>> 
>> 
>> Important: This email is confidential and may be privileged. If you are 
not the intended recipient, please delete it and notify us immediately; you 
should not copy or use it for any purpose, nor disclose its contents to any 
other person. Thank you.
>> 
>> [[alternative HTML version deleted]]
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



> -- 
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
> R/Finance 2016 | www.rinfinance.com

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

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

Re: [Rd] [R] Increasing number of observations worsen the regression model

2019-05-27 Thread peter dalgaard 
Yes, it is important that it only happens with certan BLAS, so probably not 
really an R issue. 
However, there has been some concern over the C/Fortran interfaces lately, so 
if you could narrow it down to a specific BLAS routine, it could prove useful 
for the developers.

One fairly easy thing to do would be to find the breakdown point. I speculate 
that it could be at 16384 (=2^14) and that some sort of endianness or integer 
width declaration is the cause. (It would in turn suggest that MKL is using 
16-bit integers somehow, which doesn't really seem credible, but you never 
know.)

I'm moving this to the r-devel list. It certainly is not for r-help.

-pd

> On 27 May 2019, at 10:47 , Ivan Krylov  wrote:
> 
> On Sat, 25 May 2019 14:38:07 +0200
> Raffa  wrote:
> 
>> I have tried to ask for example in CrossValidated 
>> 
>>  
>> but the code works for them. Any help?
> 
> In the comments you note that the problem went away after you replaced
> Intel MKL with OpenBLAS. This is important.
> 
> The code that fits linear models in R is somewhat complex[*]; if
> you want to get to the bottom of the problem, you may have to take
> parts of it and feed them differently-sized linear regression problems
> until you narrow it down to a specific set of calls to BLAS or LAPACK
> functions which Intel MKL provides.
> 
> One option would be to ask at Intel MKL forums[**].
> 
> -- 
> Best regards,
> Ivan
> 
> [*]
> https://madrury.github.io/jekyll/update/statistics/2016/07/20/lm-in-R.html
> 
> [**] https://software.intel.com/en-us/forums/intel-math-kernel-library/
> 
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

-- 
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

Re: [Rd] writing Unicode text to the Windows clipboard

2019-05-27 Thread Martin Maechler 
> Jennifer Bryan 
> on Thu, 23 May 2019 00:03:05 -0400 writes:

> Hello, I'm interested in moving text from and to the
> clipboard that cannot necessarily be represented in the
> native encoding. So, really, this is about Windows.

> I can successfully read from the clipboard by specifying
> the format that corresponds to unicode text.

>> From R >=2.7.0, it seems you should also be able to write
>> unicode text
> to the Windows clipboard.

> 
https://github.com/wch/r-source/blob/5a156a0865362bb8381dcd69ac335f5174a4f60c/src/gnuwin32/CHANGES0#L535-L536

> However, in my hands, this does not seem to be true. I can
> make it work with this change:

> diff --git a/src/library/utils/src/windows/util.c
> b/src/library/utils/src/windows/util.c
> index 373049495dd..fc3dc39e3a7 100644
> --- a/src/library/utils/src/windows/util.c
> +++ b/src/library/utils/src/windows/util.c
> @@ -318,7 +318,7 @@ SEXP writeClipboard(SEXP text, SEXP sformat)
>   warning(_("unable to open the clipboard"));
>   GlobalFree(hglb);
>   } else {
> - success = SetClipboardData(CF_TEXT, hglb) != 0;
> + success = SetClipboardData(format, hglb) != 0;
>   if(!success) {
>   warning(_("unable to write to the clipboard"));
>   GlobalFree(hglb);
> 
> Example:
> 
> "≧" is "GREATER-THAN OVER EQUAL TO", which is unicode , has
> UTF-16LE bytes 67 22, and is not representable in latin1.
> 
> I copy ≧ to the Windows clipboard and attempt a round trip. I see:
> 
> x <- readClipboard(format = 13, raw = TRUE) # 13 <--> "Unicode text"
> #> [1] 67 22 00 00
> writeClipboard(x, format = 13L)
> readClipboard(format = 13, raw = TRUE)
> #> [1] 67 00 22 00 00 00 00 00
> 
> and, literally, pasting yields: g"
> 
> If I build r-devel with the patch, the same process yields
> 
> x <- readClipboard(format = 13, raw = TRUE)
> #> [1] 67 22 00 00
> writeClipboard(x, format = 13)
> readClipboard(format = 13, raw = TRUE)
> #> [1] 67 22 00 00
> 
> and pasting returns the original input: ≧
> 
> Passing the `format` to SetClipboardData() instead of hard-wiring
> "CF_TEXT" brings behaviour in line with the docs.
> 
> -- Jenny
> 
>   [[alternative HTML version deleted]]

Thank you, Jenny -- and Jeroen for confirmation!

I've now found the time to read up a bit on this, notably ?writeClipboard
and the underlying source code,
and just from that reading I'd agree that the change seems a
clear improvement and does what indeed the documentation had
suggested all along.

I'll commit the change to R-devel .. and plan to port it to 'R
3.6.0 patched' in a few days.

Martin

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

Re: [Rd] "if" function in pure R?

2019-05-27 Thread Stepan 

Hello Alexandre,

there are two sides of your question it seems to me:

- there is no possibility to extend the R parser with new syntax. The R 
parser knows to internally "rewrite"(*) things such as


if (a>b) print(1) else print(2)

into

`if`(a>b, print(1), print(2))

The parser has a fixed set of functions that get some special treatment 
like this.


- there is possibility to implement control flow constructs thanks to 
the lazy evaluation of arguments. An example of such function is ifelse 
from base.


Best,
Stepan

(*) "rewrite" is illustrative, the exact internal working of this is not 
important for this discussion



On 27/05/2019 08:16, Alexandre Courtiol wrote:

Thanks a lot Jiefei,

I had thought of defining a binary operator (inspired by pipes) or simply
using an additional condition in the if() calls [e.g. if(foo & fn(bar))
doSomeThing; with fn(bar) returning a logical], but both are workaround
that I do not find as elegant as a proper control-flow construct.

Thus two questions remain:
- is it possible to create a control-flow construct in pure R?
- if yes, how?

Anyone with more insights?
Thanks

On Mon, 27 May 2019 at 04:27, King Jiefei  wrote:


Hi Alexandre,

I'm not an R expert so this is only my personal thought:

I don't think you can achieve what you want exactly. A possible solution
would be defining a binary operator %*%, where you can replace the asterisk
with any function name you want. The function %*% is special since it has
two arguments, left operand and right operand respectively. You then
can call the `substitute` function to get its function arguments in an
expression format and proceed to do what you want. Here is an example to
show the idea.

*Code:*

`%myOperator%` <- function(x, y) {
   x = substitute(x)
   y = substitute(y)
   return(list(x, y))
}


myIf(i == 1, arg1) %myOperator% {
   doSomeThing
}


*Results:*

[[1]]
myIf(i == 1, arg1)

[[2]]
{
 doSomeThing
}

I hope that helps.

Best,
Jiefei

On Sun, May 26, 2019 at 4:45 AM Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:


Hi all,

Could anyone refer to me to a good source to learn how to program a simple
control-flow construct* in R, or provide me with a simple example?

Control-flow constructs are programmed as primitives, but I would like to
be able to do that (if possible) in pure R.

The general context is that those functions are a mystery to me. The
motivating example is that I would like to create a function that behave
similarly to base::`if` with an extra argument to the function (e.g. to
include an error rate on the condition).

Many thanks,

Alex

* control-flow constructs are functions such as if, for, while... that
allow for call of the form fn(x) expr to work (see ?Control).

--
Alexandre Courtiol

https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_alexandrecourtiol_home=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=neKFCw86thQe2E2-61NAgpDMw4cC7oD_tUTTzraOkQM=S7ovivpWoG4APCzcwxdRGsn_Rr4FYxNrxmayP5prMhQ=LOGFMQPijyvAAyk5wcsWQkM6HjyrNqd9bJTkHhi_4YA=

*"Science is the belief in the ignorance of experts"*, R. Feynman

 [[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=neKFCw86thQe2E2-61NAgpDMw4cC7oD_tUTTzraOkQM=S7ovivpWoG4APCzcwxdRGsn_Rr4FYxNrxmayP5prMhQ=sAVfqnOeGqyqLFdvykN3nfGgEwxOCo7oq3slMwEWKi8=







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

Re: [Rd] Give update.formula() an option not to simplify or reorder the result -- request for comments

2019-05-27 Thread Thomas Mailund 
With a bit of meta programming that manipulates expressions, I don’t think this 
would be difficult to implement in a package. Well, as difficult as it is to 
implement a CAS, but not harder. I wrote some code for symbolic differentiation 
— I don’t remember where I put it — and that was easy. But that is because 
differentiation is just a handful of rules and then the chain rule. I don’t 
have the skills for handling more complex symbolic manipulation, but anyone who 
could add it to the language could also easily add it as a package, I think.

Whether in a standard package or not, I have no preference whatsoever.

Cheers
Thomas



On 25 May 2019 at 00.59.44, Abby Spurdle 
(spurdl...@gmail.com) wrote:

> Martin Maechler has asked me to send this to R-devel for discussion
> after I submitted it as an enhancement request (
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17563).

I think R needs to provide more support for CAS-style symbolic computation.
That is, support by either the R language itself or the standard packages,
or both.
(And certainly not by interfacing with another interpreted language).

Obviously, I don't speak for R Core.
However, this is how I would like to see R move in the future.
...improved symbolic and symbolic-numeric computation...

I think any changes to formula objects or their methods, should be
congruent with these symbolic improvements.

[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

Re: [Rd] coerce SEXP type to C++ matrix class and back

2019-05-27 Thread kklot 


perhaps you don't need this anymore but now after extract the dimension m, n,
we can simply generate arma matrix as
mat an_arma_mat(REAL(RA), m, n);
similarly you can convert RB to an arma matrix pointer, operate on it then
return directly RB to R.


I am testing a simple C++ function that takes a double matrix as
argument and which uses routines provided by the C++ Armadillo
package. I am aware of the nice capabilities of Rcpp and RcppArmadillo
which helps simplifying a lot and that I have already successfully
tested. However, I had a hard time trying to figure out how the
coercion from a REALSPX matrix to an arma::mat = arma::Mat
matrix (double matrix in Armadillo) is done. In this particular case,
because of the simplicity of my function, I would like to use base R
only.



--
Sent from: http://r.789695.n4.nabble.com/R-devel-f909078.html

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

Re: [Rd] Possible bug when finding shared libraries during staged installation

2019-05-27 Thread Tomas Kalibera 
Fixed in R-devel and R-patched.

Best,
Tomas

On 5/24/19 6:56 PM, Kara Woo wrote:
> Yes, that's the same result that I see as well.
>
> If you still want the formal report I can create one if someone adds 
> me to bugzilla, but it sounds like that may not be necessary. Thanks 
> for looking into this!
>
> On Fri, May 24, 2019 at 5:58 AM Tomas Kalibera 
> mailto:tomas.kalib...@gmail.com>> wrote:
>
> On 5/24/19 2:52 PM, Martin Maechler wrote:
> >> Kara Woo
> >>      on Thu, 23 May 2019 14:24:26 -0700 writes:
> >      > Hi all,
> >      > With the new staged installation, it seems that R CMD
> INSTALL sometimes
> >      > fails on macOS due to these lines [1] when sapply()
> returns a list. The
> >      > x13binary package has an example [2], reproducible with
> the following steps:
> >
> >      > $ git clone g...@github.com:x13org/x13binary.git && cd
> x13binary
> >      > $ git checkout 663ad7122
> >      > $ R CMD INSTALL .
> >
> >      > (We've also run into it in an internal package, but it's
> easier to
> >      > reproduce with x13binary)
> >
> >      > In this case the file command returns multiple results
> for one of the
> >      > dynamic libraries, so are_shared looks like this:
> >
> >      >> are_shared
> >      >
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib`
> >      > [1] TRUE TRUE TRUE
> >
> >      >
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libgfortran.3.dylib`
> >      > [1] TRUE
> >
> >      >
> $`/Users/Kara/projects/forks/x13binary/inst//lib/libquadmath.0.dylib`
> >      > [1] TRUE
> >
> > Thank you, Kara.
> >
> > Just for curiosity, what does
> >
> >   file
> /Users/Kara/projects/forks/x13binary/inst//lib/libgcc_s.1.dylib
> >
> > produce on your Mac?
>
> I can reproduce, it is something like
>
> /usr/lib/libgcc_s.1.dylib: Mach-O universal binary with 2
> architectures:
> [x86_64:Mach-O 64-bit dynamically linked shared library x86_64]
> [i386:Mach-O dynamically linked shared library i386]
> /usr/lib/libgcc_s.1.dylib (for architecture x86_64):    Mach-O 64-bit
> dynamically linked shared library x86_64
> /usr/lib/libgcc_s.1.dylib (for architecture i386):    Mach-O
> dynamically
> linked shared library i386
>
> Thanks for the report, I will fix.
>
> Tomas
>
> >
> >      > slibs[are_shared] then fails with invalid subscript type
> 'list'.
> >
> > yes, "of course".
> >
> >      > I believe this may be a bug and I have included a patch
> that uses any() and
> >      > vapply() to ensure that only one value is returned for
> each library and the
> >      > result is an atomic vector. This is my first time
> submitting a bug report
> >      > or patch here; I'm happy to make any changes if needed.
> >
> > Your patch was not attached with MIME type   text/plain and so
> > was filtered out by the mailing list software.
> > OTOH, I could relatively easily guess how to fix the bug,
> > notably when seeing the above "file ...dylib" result.
> >
> > What we *meant* to say in https://www.r-project.org/bugs.html
> > is that in such a situation
> > 1) you send your finding / suspicion / diagnosis
> >     to the R-devel mailing list,  in order to get confirmation etc
> >     if what you see is a bug;
> > 2) then ideally, you'd do a formal bug report at
> > https://bugs.r-project.org/
> >       (for which you need to get an "account" there to be created
> >        once only by a bugzilla admin, typically an R core member).
> >
> > In this case, that (2) may not be necessary, but you may want
> > that anyway (and let some of us know).
> >
> >      > Thanks for considering,
> >      > Kara
> >
> > Thank *you* indeed for the report,
> > Martin
> >
> >      > [1]
> >      >
> 
> https://github.com/wch/r-source/blob/3fe2bb01e9ec1b268803a437c308742775c2442d/src/library/tools/R/install.R#L594-L597
> >      > [2] https://github.com/x13org/x13binary/issues/46
> >
> >      > R version 3.6.0 Patched (2019-05-22 r76579)
> >      > Platform: x86_64-apple-darwin15.6.0 (64-bit)
> >      > Running under: macOS Mojave 10.14.4
> >
> > --
> > Martin Maechler
> > ETH Zurich  and  R Core Team
> >
> > __
> > R-devel@r-project.org  mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


[[alternative HTML version deleted]]

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

Re: [Rd] "if" function in pure R?

2019-05-27 Thread Alexandre Courtiol 
Thanks a lot Jiefei,

I had thought of defining a binary operator (inspired by pipes) or simply
using an additional condition in the if() calls [e.g. if(foo & fn(bar))
doSomeThing; with fn(bar) returning a logical], but both are workaround
that I do not find as elegant as a proper control-flow construct.

Thus two questions remain:
- is it possible to create a control-flow construct in pure R?
- if yes, how?

Anyone with more insights?
Thanks

On Mon, 27 May 2019 at 04:27, King Jiefei  wrote:

> Hi Alexandre,
>
> I'm not an R expert so this is only my personal thought:
>
> I don't think you can achieve what you want exactly. A possible solution
> would be defining a binary operator %*%, where you can replace the asterisk
> with any function name you want. The function %*% is special since it has
> two arguments, left operand and right operand respectively. You then
> can call the `substitute` function to get its function arguments in an
> expression format and proceed to do what you want. Here is an example to
> show the idea.
>
> *Code:*
>
> `%myOperator%` <- function(x, y) {
>   x = substitute(x)
>   y = substitute(y)
>   return(list(x, y))
> }
>
>
> myIf(i == 1, arg1) %myOperator% {
>   doSomeThing
> }
>
>
> *Results:*
>
> [[1]]
> myIf(i == 1, arg1)
>
> [[2]]
> {
> doSomeThing
> }
>
> I hope that helps.
>
> Best,
> Jiefei
>
> On Sun, May 26, 2019 at 4:45 AM Alexandre Courtiol <
> alexandre.court...@gmail.com> wrote:
>
>> Hi all,
>>
>> Could anyone refer to me to a good source to learn how to program a simple
>> control-flow construct* in R, or provide me with a simple example?
>>
>> Control-flow constructs are programmed as primitives, but I would like to
>> be able to do that (if possible) in pure R.
>>
>> The general context is that those functions are a mystery to me. The
>> motivating example is that I would like to create a function that behave
>> similarly to base::`if` with an extra argument to the function (e.g. to
>> include an error rate on the condition).
>>
>> Many thanks,
>>
>> Alex
>>
>> * control-flow constructs are functions such as if, for, while... that
>> allow for call of the form fn(x) expr to work (see ?Control).
>>
>> --
>> Alexandre Courtiol
>>
>> http://sites.google.com/site/alexandrecourtiol/home
>>
>> *"Science is the belief in the ignorance of experts"*, R. Feynman
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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