Re: [R-pkg-devel] R package development using GPU based on R package OpenCL

2022-10-11 Thread Martin Morgan
I�m not particularly experienced with this but wrote a �proof-of-concept� 
skeleton of a package at https://github.com/mtmorgan/ocl . The basics are


  *   Import OpenCL in the DESCRIPTION file
  *   Write OpenCL scripts in inst/ (dnorm implemented in OpenCL)
  *   Use the helper function in R/ocl.R to source the code
  *   Provide a user-friendly interface as in R/examples.R (dnorm_ocl)

Martin

From: R-package-devel  on behalf of 
Quirin Stier 
Date: Tuesday, October 11, 2022 at 10:46 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] R package development using GPU based on R package OpenCL
Dear members,

I have difficulties packing my OpenCL functions together as a complete R
package. I did not find any exemplary R package building upon the R
OpenCL Package. Currently I can only run the OpenCL functions as was
presented by the OpenCL examples of the OpenCL package itself. So,
assuming I have working OpenCL files, how can I create the MakeVars (or
whatever necessity needs to be done), in order to create a fully
functional R package?

Best regards,

Quirin

__
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


[R-pkg-devel] R package development using GPU based on R package OpenCL

2022-10-11 Thread Quirin Stier

Dear members,

I have difficulties packing my OpenCL functions together as a complete R
package. I did not find any exemplary R package building upon the R
OpenCL Package. Currently I can only run the OpenCL functions as was
presented by the OpenCL examples of the OpenCL package itself. So,
assuming I have working OpenCL files, how can I create the MakeVars (or
whatever necessity needs to be done), in order to create a fully
functional R package?

Best regards,

Quirin

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


Re: [R-pkg-devel] Identify Original Column Names of Model Matrix

2022-10-11 Thread Ivan Krylov
On Mon, 10 Oct 2022 08:00:04 +
Dario Strbenac  wrote:

> It requires input data to be in one-hot encoding, which is created by
> Matrix::sparse.model.matrix. For further analysis, such as variable
> importance, is there a way to identify which original feature each
> column of a sparse.model.matrix result was derived from?

?Matrix::sparse.model.matrix seems to recommend
MatrixModel::model.Matrix for this reason. The latter function returns
an object with additional slots `assign` and `contrasts`, which should
make it possible to recover the original columns.

-- 
Best regards,
Ivan

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


Re: [R-pkg-devel] Issue handling datetimes: possible differences between computers

2022-10-11 Thread Martin Maechler
> Ben Bolker 
> on Mon, 10 Oct 2022 16:59:35 -0400 writes:

> Right now as.POSIXlt.Date() is just
> function (x, ...)
> .Internal(Date2POSIXlt(x))

It has been quite a bit different in R-devel  for a little
while.  NEWS entries  (there are more already, and more coming
on the wide topic)

* The as.POSIXlt() and as.POSIXct() default
  methods now do obey their tz argument, also in this case.

* as.POSIXlt() now does apply a tz (timezone) argument, as
  does as.POSIXct(); partly suggested by Roland Fuss on the R-devel
  mailing list.

and indeed it would have been good had you used (and read) the
R-devel mailing list  which is much more appropriate on the
topic of *changing* base R behavior.




> How expensive would it be to throw a warning when '...' is provided by 
> the user/discarded ??

> Alternately, perhaps the documentation could be amended, although I'm 
> not quite sure what to suggest. (The sentence Liam refers to, "Dates 
> without times are treated as being at midnight UTC." is correct but 
> terse ...)


> On 2022-10-10 4:50 p.m., Alexandre Courtiol wrote:
>> Hi Simon,
>> 
>> Thanks for the clarification.
>> 
>> From a naive developer point of view, we were initially baffled that the
>> generic as.POSIXlt() does very different things on a character and on a
>> Date input:
>> 
>> as.POSIXlt(as.character(foo), "Europe/Berlin")
>> [1] "1992-09-27 CEST"
>> 
>> as.POSIXlt(foo, "Europe/Berlin")
>> [1] "1992-09-27 UTC"
>> 
>> Based on what you said, it does make sense: it is only when creating the
>> date/time that we want to include the time zone and that only happens 
when
>> we don't already work on a previously created date.
>> That is your subtle but spot-on distinction between "parsing" and
>> "changing" the time zone.
>> 
>> Yet, we do find it dangerous that as.POSIXlt.Date() accepts a time zone 
but
>> does nothing of it, especially when the help file starts with:
>> 
>> Usage
>> as.POSIXlt(x, tz = "", ...)
>> 
>> The behaviour is documented, as Liam reported it, but still, we will 
almost
>> certainly not be the last one tripping on this (without even adding the
>> additional issue of as.POSIXct() behaving differently across OS).
>> 
>> Thanks again,
>> 
>> Alex & Liam
>> 
>> 
>> 
>> 
>> On Mon, 10 Oct 2022 at 22:13, Simon Urbanek 
>> wrote:
>> 
>>> Liam,
>>> 
>>> I think I have failed to convey my main point in the last e-mail - which
>>> was that you want to parse the date/time in the timezone that you care
>>> about so in your example that would be
>>> 
 foo <- as.Date(33874, origin = "1899-12-30")
 foo
>>> [1] "1992-09-27"
 as.POSIXlt(as.character(foo), "Europe/Berlin")
>>> [1] "1992-09-27 CEST"
>>> 
>>> I was explicitly saying that you do NOT want to simply change the time
>>> zone on POSIXlt objects as that won't work for reasons I explained - 
see my
>>> last e-mail.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> 
 On 11/10/2022, at 6:31 AM, Liam Bailey 
>>> wrote:
 
 Hi all,
 
 Thanks Simon for the detailed response, that helps us understand a lot
>>> better what’s going on! However, with your response in mind, we still
>>> encounter some behaviour that we did not expect.
 
 I’ve included another minimum reproducible example below to expand on
>>> the situation. In this example, `foo` is a Date object that we generate
>>> from a numeric input. Following your advice, `bar` is then a POSIXlt 
object
>>> where we now explicitly define timezone using argument tz. However, even
>>> though we are explicit about the timezone the POSIXlt that is generated 
is
>>> always in UTC. This then leads to the issues outlined by Alexandre 
above,
>>> which we now understand are caused by DST.
 
 ``` r
 #Generate date from numeric
 #Not possible to specify tz at this point
 foo <- as.Date(33874, origin = "1899-12-30")
 dput(foo)
 #> structure(8305, class = "Date")
 
 #Convert to POSIXlt specifying UTC timezone
 bar <- as.POSIXlt(foo, tz = "UTC")
 dput(bar)
 #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
 #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =
>>> c("POSIXlt",
 #> "POSIXt"), tzone = "UTC")
 
 #Convert to POSIXlt specifying Europe/Berlin.
 #Time zone is still UTC
 bar <- as.POSIXlt(foo, tz = "Europe/Berlin")
 dput(bar)
 #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
 #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =
>>> c("POSIXlt",
 #>