Re: [Rd] Question regarding .make_numeric_version with non-character input

[Hervé Pagès]

On 4/25/24 07:04, Kurt Hornik wrote:

...
> Sure, I'll look into adding something.  (Too late for 4.4.0, of course.)
>
> Best
> -k

Great. Thanks!

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] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Hervé Pagès writes:

> On 4/24/24 23:07, Kurt Hornik wrote:
>>> Hervé Pagès writes:
>>> Hi Kurt,
>>> Is it intended that numeric_version() returns an error by default on
>>> non-character input in R 4.4.0?
>> Dear Herve, yes, that's the intention.
>> 
>>> It seems that I can turn this into a warning by setting
>>> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
>>> seem to be able to find any of this mentioned in the NEWS file.
>> That's what I added for smoothing the transition: it will be removed
>> from the trunk shortly.

> Thanks for clarifying.  Could this be documented in the NEWS file? This 
> is a breaking change (it breaks a couple of Bioconductor packages) and 
> people are not going to set this environment variable if they are not 
> aware of it.

Sure, I'll look into adding something.  (Too late for 4.4.0, of course.)

Best
-k

> Thanks again,

> H.

>> 
>> Best
>> -k
>> 
>>> Thanks,
>>> H.
>>> On 4/1/24 05:28, Kurt Hornik wrote:
>>> Andrea Gilardi via R-devel writes:
>> 
>>> Thanks: should be fixed now in the trunk.
>> 
>>> Best
>>> -k
>>> Thank you very much Dirk for your kind words and for confirming the bug.
>>> Next week I will open a new issue on Bugzilla adding the related patch.
>> 
>>> Kind regards
>> 
>>> Andrea
>> 
>>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>> 
>>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>> | Dear all,
>>> |
>>> | I have a question regarding the R-devel version of 
>>> .make_numeric_version() function. As far as I can understand, the current 
>>> code 
>>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>>  runs the following steps in case of non-character input:
>>> |
>>> | 1. It creates a message named msg using gettextf.
>>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>>> the following condition
>>> |
>>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>>> "false")
>>> |
>>> | However, I don't understand the previous code since the output of 
>>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
>>> is just a boolean value and tolower() will just return "true" or "false". 
>>> Maybe the intended code is 
>>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>>> "false" ? Or am I missing something?
>> 
>>> Yes, agreed -- good catch.  In full, the code is (removing leading
>>> whitespace, and putting it back onto single lines)
>> 
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") 
>>> != "false"))
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>>> where msg is constant (but reflecting language settings via standard i18n)
>>> and as you not the parentheses appear wrong.  What was intended is likely
>> 
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>>> != "false")
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>>> If you use bugzilla before and have a handle, maybe file a bug report with
>>> this as patch athttps://bugs.r-project.org/
>> 
>>> Dirk
>>> __
>>> 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
>> 
>>> -- 
>>> Hervé Pagès
>>> Bioconductor Core Team
>>> hpages.on.git...@gmail.com

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

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> Hi Kurt,

> On 25 April 2024 at 08:07, Kurt Hornik wrote:
> | > Hervé Pagès writes:
> | 
> | > Hi Kurt,
> | > Is it intended that numeric_version() returns an error by default on
> | > non-character input in R 4.4.0? 
> | 
> | Dear Herve, yes, that's the intention.
> | 
> | > It seems that I can turn this into a warning by setting
> | > _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> | > seem to be able to find any of this mentioned in the NEWS file.
> | 
> | That's what I added for smoothing the transition: it will be removed
> | from the trunk shortly.

> I would actually be nice to have a more robust variant for non-CRAN
> versions. For example I just had to do a local hack to be able to use
> what the QuantLib 'rc' 1.34-rc reported (when I then used to R
> facilities to condition code and tests on whether I was dealing with
> code before or after an API transition).  So as a wishlist: could you
> envision an extension to package_version() casting that, say, removes
> all [a-zA-Z]+ first (if opted into) ?

Well, if I could turn back time and start again, I'd implement package
versions in the Debian way, and not numeric only.  As you know, the
current approach does not conveniently allow for handling binary
revisions or NMUs.

Currently, package_version extends numeric_version, but in principle
that could be changed: we would of course have to ensure that we go on
using numeric-only package versions for source packages so that older
versions of R can handle these.

One could in principle also enhance the 'strict' argument so that
e.g. strict = NA says drop all non-numeric non-sep parts, but it would
be better to first figure out whether it wouldn't be better to make
things work for non-numeric version components too :-)

Best
-k



> Dirk

> -- 
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Dirk Eddelbuettel]

Hi Kurt,

On 25 April 2024 at 08:07, Kurt Hornik wrote:
| > Hervé Pagès writes:
| 
| > Hi Kurt,
| > Is it intended that numeric_version() returns an error by default on
| > non-character input in R 4.4.0? 
| 
| Dear Herve, yes, that's the intention.
| 
| > It seems that I can turn this into a warning by setting
| > _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
| > seem to be able to find any of this mentioned in the NEWS file.
| 
| That's what I added for smoothing the transition: it will be removed
| from the trunk shortly.

I would actually be nice to have a more robust variant for non-CRAN
versions. For example I just had to do a local hack to be able to use what
the QuantLib 'rc' 1.34-rc reported (when I then used to R facilities to
condition code and tests on whether I was dealing with code before or after
an API transition).  So as a wishlist: could you envision an extension to
package_version() casting that, say, removes all [a-zA-Z]+ first (if opted
into) ?

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Hervé Pagès]

On 4/24/24 23:07, Kurt Hornik wrote:

>> Hervé Pagès writes:
>> Hi Kurt,
>> Is it intended that numeric_version() returns an error by default on
>> non-character input in R 4.4.0?
> Dear Herve, yes, that's the intention.
>
>> It seems that I can turn this into a warning by setting
>> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
>> seem to be able to find any of this mentioned in the NEWS file.
> That's what I added for smoothing the transition: it will be removed
> from the trunk shortly.

Thanks for clarifying.  Could this be documented in the NEWS file? This 
is a breaking change (it breaks a couple of Bioconductor packages) and 
people are not going to set this environment variable if they are not 
aware of it.

Thanks again,

H.

>
> Best
> -k
>
>> Thanks,
>> H.
>> On 4/1/24 05:28, Kurt Hornik wrote:
>>  Andrea Gilardi via R-devel writes:
>  
>>  Thanks: should be fixed now in the trunk.
>  
>>  Best
>>  -k
>>  Thank you very much Dirk for your kind words and for confirming the 
>> bug.
>>  Next week I will open a new issue on Bugzilla adding the related 
>> patch.
>  
>>  Kind regards
>  
>>  Andrea
>  
>>  On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>  
>>  On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>  | Dear all,
>>  |
>>  | I have a question regarding the R-devel version of 
>> .make_numeric_version() function. As far as I can understand, the current 
>> code 
>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>  runs the following steps in case of non-character input:
>>  |
>>  | 1. It creates a message named msg using gettextf.
>>  | 2. Such object is then passed to stop(msg) or warning(msg) 
>> according to the following condition
>>  |
>>  | 
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false")
>>  |
>>  | However, I don't understand the previous code since the 
>> output of Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false" is just a boolean value and tolower() will just return "true" or 
>> "false". Maybe the intended code is 
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>> "false" ? Or am I missing something?
>  
>>  Yes, agreed -- good catch.  In full, the code is (removing 
>> leading
>>  whitespace, and putting it back onto single lines)
>  
>>  msg <- gettextf("invalid non-character version specification 
>> 'x' (type: %s)", typeof(x))
>>  
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false"))
>>  stop(msg, domain = NA)
>>  else
>>  warning(msg, domain = NA, immediate. = TRUE)
>  
>>  where msg is constant (but reflecting language settings via 
>> standard i18n)
>>  and as you not the parentheses appear wrong.  What was intended 
>> is likely
>  
>>  msg <- gettextf("invalid non-character version specification 
>> 'x' (type: %s)", typeof(x))
>>  
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>> != "false")
>>  stop(msg, domain = NA)
>>  else
>>  warning(msg, domain = NA, immediate. = TRUE)
>  
>>  If you use bugzilla before and have a handle, maybe file a bug 
>> report with
>>  this as patch athttps://bugs.r-project.org/
>  
>>  Dirk
>>  __
>>  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
>  
>> -- 
>> Hervé Pagès
>> Bioconductor Core Team
>> hpages.on.git...@gmail.com

-- 
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] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Hervé Pagès writes:

> Hi Kurt,
> Is it intended that numeric_version() returns an error by default on
> non-character input in R 4.4.0? 

Dear Herve, yes, that's the intention.

> It seems that I can turn this into a warning by setting
> _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't
> seem to be able to find any of this mentioned in the NEWS file.

That's what I added for smoothing the transition: it will be removed
from the trunk shortly.

Best
-k

> Thanks,

> H.

> On 4/1/24 05:28, Kurt Hornik wrote:

> Andrea Gilardi via R-devel writes:

> Thanks: should be fixed now in the trunk.

> Best
> -k

> Thank you very much Dirk for your kind words and for confirming the 
> bug. 
> Next week I will open a new issue on Bugzilla adding the related 
> patch.

> Kind regards

> Andrea

> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:

> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
> | Dear all,
> |
> | I have a question regarding the R-devel version of 
> .make_numeric_version() function. As far as I can understand, the current 
> code 
> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>  runs the following steps in case of non-character input:
> |
> | 1. It creates a message named msg using gettextf.
> | 2. Such object is then passed to stop(msg) or warning(msg) 
> according to the following condition
> |
> | 
> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
> "false")
> |
> | However, I don't understand the previous code since the output 
> of Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
> is just a boolean value and tolower() will just return "true" or "false". 
> Maybe the intended code is 
> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
> "false" ? Or am I missing something?

> Yes, agreed -- good catch.  In full, the code is (removing leading
> whitespace, and putting it back onto single lines)

> msg <- gettextf("invalid non-character version specification 'x' 
> (type: %s)", typeof(x))
> 
> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
> "false"))
> stop(msg, domain = NA)
> else
> warning(msg, domain = NA, immediate. = TRUE)

> where msg is constant (but reflecting language settings via 
> standard i18n)
> and as you not the parentheses appear wrong.  What was intended 
> is likely

> msg <- gettextf("invalid non-character version specification 'x' 
> (type: %s)", typeof(x))
> 
> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
> "false")
> stop(msg, domain = NA)
> else
> warning(msg, domain = NA, immediate. = TRUE)

> If you use bugzilla before and have a handle, maybe file a bug 
> report with
> this as patch at https://bugs.r-project.org/

> Dirk

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

> -- 
> Hervé Pagès

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

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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Hervé Pagès]

Hi Kurt,

Is it intended that numeric_version() returns an error by default on 
non-character input in R 4.4.0? It seems that I can turn this into a 
warning by setting 
_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't seem 
to be able to find any of this mentioned in the NEWS file.

Thanks,

H.

On 4/1/24 05:28, Kurt Hornik wrote:
>> Andrea Gilardi via R-devel writes:
> Thanks: should be fixed now in the trunk.
>
> Best
> -k
>
>> Thank you very much Dirk for your kind words and for confirming the bug.
>> Next week I will open a new issue on Bugzilla adding the related patch.
>> Kind regards
>> Andrea
>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>> | Dear all,
>>> |
>>> | I have a question regarding the R-devel version of 
>>> .make_numeric_version() function. As far as I can understand, the current 
>>> code 
>>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>>  runs the following steps in case of non-character input:
>>> |
>>> | 1. It creates a message named msg using gettextf.
>>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>>> the following condition
>>> |
>>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>>> "false")
>>> |
>>> | However, I don't understand the previous code since the output of 
>>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
>>> is just a boolean value and tolower() will just return "true" or "false". 
>>> Maybe the intended code is 
>>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>>> "false" ? Or am I missing something?
>>>
>>> Yes, agreed -- good catch.  In full, the code is (removing leading
>>> whitespace, and putting it back onto single lines)
>>>
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") 
>>> != "false"))
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>>>
>>> where msg is constant (but reflecting language settings via standard i18n)
>>> and as you not the parentheses appear wrong.  What was intended is likely
>>>
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>>> != "false")
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>>>
>>> If you use bugzilla before and have a handle, maybe file a bug report with
>>> this as patch athttps://bugs.r-project.org/
>>>
>>> Dirk
>>>
>> __
>> 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

-- 
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] Question regarding .make_numeric_version with non-character input

[Kurt Hornik]

> Andrea Gilardi via R-devel writes:

Thanks: should be fixed now in the trunk.

Best
-k

> Thank you very much Dirk for your kind words and for confirming the bug. 
> Next week I will open a new issue on Bugzilla adding the related patch.

> Kind regards

> Andrea

> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>> | Dear all,
>> |
>> | I have a question regarding the R-devel version of .make_numeric_version() 
>> function. As far as I can understand, the current code 
>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>  runs the following steps in case of non-character input:
>> |
>> | 1. It creates a message named msg using gettextf.
>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>> the following condition
>> |
>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false")
>> |
>> | However, I don't understand the previous code since the output of 
>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" is 
>> just a boolean value and tolower() will just return "true" or "false". Maybe 
>> the intended code is 
>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>> "false" ? Or am I missing something?
>> 
>> Yes, agreed -- good catch.  In full, the code is (removing leading
>> whitespace, and putting it back onto single lines)
>> 
>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>> %s)", typeof(x))
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>> "false"))
>> stop(msg, domain = NA)
>> else
>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>> where msg is constant (but reflecting language settings via standard i18n)
>> and as you not the parentheses appear wrong.  What was intended is likely
>> 
>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>> %s)", typeof(x))
>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>> != "false")
>> stop(msg, domain = NA)
>> else
>> warning(msg, domain = NA, immediate. = TRUE)
>> 
>> If you use bugzilla before and have a handle, maybe file a bug report with
>> this as patch at https://bugs.r-project.org/
>> 
>> Dirk
>> 

> __
> 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] Question regarding .make_numeric_version with non-character input

[Andrea Gilardi via R-devel]

Thank you very much Dirk for your kind words and for confirming the bug. 
Next week I will open a new issue on Bugzilla adding the related patch.


Kind regards

Andrea

On 29/03/2024 20:14, Dirk Eddelbuettel wrote:

On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
| Dear all,
|
| I have a question regarding the R-devel version of .make_numeric_version() 
function. As far as I can understand, the current code 
(https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
 runs the following steps in case of non-character input:
|
| 1. It creates a message named msg using gettextf.
| 2. Such object is then passed to stop(msg) or warning(msg) according to the 
following condition
|
| tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
"false")
|
| However, I don't understand the previous code since the output of 
Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" is just a boolean value and tolower() will 
just return "true" or "false". Maybe the intended code is 
tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != "false" ? Or am I missing something?

Yes, agreed -- good catch.  In full, the code is (removing leading
whitespace, and putting it back onto single lines)

   msg <- gettextf("invalid non-character version specification 'x' (type: 
%s)", typeof(x))
   if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
"false"))
   stop(msg, domain = NA)
   else
   warning(msg, domain = NA, immediate. = TRUE)

where msg is constant (but reflecting language settings via standard i18n)
and as you not the parentheses appear wrong.  What was intended is likely

   msg <- gettextf("invalid non-character version specification 'x' (type: 
%s)", typeof(x))
   if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
"false")
   stop(msg, domain = NA)
   else
   warning(msg, domain = NA, immediate. = TRUE)

If you use bugzilla before and have a handle, maybe file a bug report with
this as patch at https://bugs.r-project.org/

Dirk



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

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Dirk Eddelbuettel]

On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
| Dear all,
| 
| I have a question regarding the R-devel version of .make_numeric_version() 
function. As far as I can understand, the current code 
(https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
 runs the following steps in case of non-character input:
| 
| 1. It creates a message named msg using gettextf.
| 2. Such object is then passed to stop(msg) or warning(msg) according to the 
following condition
| 
| tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
"false")
| 
| However, I don't understand the previous code since the output of 
Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" is 
just a boolean value and tolower() will just return "true" or "false". Maybe 
the intended code is 
tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
"false" ? Or am I missing something? 

Yes, agreed -- good catch.  In full, the code is (removing leading
whitespace, and putting it back onto single lines)

  msg <- gettextf("invalid non-character version specification 'x' (type: %s)", 
typeof(x))
  if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
"false"))
  stop(msg, domain = NA)
  else
  warning(msg, domain = NA, immediate. = TRUE)  

where msg is constant (but reflecting language settings via standard i18n)
and as you not the parentheses appear wrong.  What was intended is likely

  msg <- gettextf("invalid non-character version specification 'x' (type: %s)", 
typeof(x))
  if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
"false")
  stop(msg, domain = NA)
  else
  warning(msg, domain = NA, immediate. = TRUE)  

If you use bugzilla before and have a handle, maybe file a bug report with
this as patch at https://bugs.r-project.org/

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[Rd] Question regarding .make_numeric_version with non-character input

[Andrea Gilardi via R-devel]

Dear all,

I have a question regarding the R-devel version of .make_numeric_version() 
function. As far as I can understand, the current code 
(https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
 runs the following steps in case of non-character input:

1. It creates a message named msg using gettextf.
2. Such object is then passed to stop(msg) or warning(msg) according to the 
following condition

tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
"false")

However, I don't understand the previous code since the output of 
Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" is 
just a boolean value and tolower() will just return "true" or "false". Maybe 
the intended code is 
tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
"false" ? Or am I missing something? 

Thank you very much for your help
Kind regards

Andrea



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

Re: [Rd] question about an R idiom: eval()ing a quoted block

[peter dalgaard]

In the case of power.t.test, there is a situation where you want to create 4 
different functions with the same function body, in order to pass them to 
uniroot(). I think that at the time, it just seemed convenient to express that 
idea with a quote-eval (macro-like) construction, rather than figure out how to 
do it with functions. I suppose that it could have been done neatly enough 
along the lines of

g <- function(x1, x2, x3, x4)
{
  f <- function(x1, x2, x3, x4) {...body...}
  if (is.null(x1)
 x1 <- uniroot(function(x1) {target - f(x1, x2, x3, x4)}, )$root
  
}

This adds an extra layer of function call, but probably makes the byte compiler 
happier!

You might also use the ... argument to uniroot() as in

x1 <- uniroot(f, x2=x2, x3=x3, x4=x4, ..other args..)$root

but that gets a bit clunky.

-pd

> On 12 Jul 2023, at 00:01 , Ben Bolker  wrote:
> 
>  In a few places in the R source code, such as the $initialize element of 
> `family` objects, and in the body of power.t.test() (possibly other power.* 
> functions), sets of instructions that will need to be run later are 
> encapsulated by saving them as an expression and later applying eval(), 
> rather than as a function. This seems weird to me; the only reason I can 
> think of for doing it this way is to avoid having to pass back multiple 
> objects and assign them in the calling environment (since R doesn't have a 
> particularly nice form of Python's tuple-unpacking idiom).
> 
>  Am I missing something?
> 
> cheers
>   Ben
> 
> 
> https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52
> 
> https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
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] question about an R idiom: eval()ing a quoted block

[Duncan Murdoch]

On 11/07/2023 6:01 p.m., Ben Bolker wrote:

In a few places in the R source code, such as the $initialize element
of `family` objects, and in the body of power.t.test() (possibly other
power.* functions), sets of instructions that will need to be run later
are encapsulated by saving them as an expression and later applying
eval(), rather than as a function. This seems weird to me; the only
reason I can think of for doing it this way is to avoid having to pass
back multiple objects and assign them in the calling environment (since
R doesn't have a particularly nice form of Python's tuple-unpacking idiom).

Am I missing something?

   cheers
 Ben


https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52

https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171


Those examples are very old (the second is at least 20 years old).  It 
may be they were written by someone who was thinking in S rather than in 
R.


As far as I recall (but I might be wrong), S didn't have the same 
scoping rules for accessing and modifying local variables in a function 
from a nested function.


Duncan Murdoch

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

[Rd] question about an R idiom: eval()ing a quoted block

[Ben Bolker]

  In a few places in the R source code, such as the $initialize element 
of `family` objects, and in the body of power.t.test() (possibly other 
power.* functions), sets of instructions that will need to be run later 
are encapsulated by saving them as an expression and later applying 
eval(), rather than as a function. This seems weird to me; the only 
reason I can think of for doing it this way is to avoid having to pass 
back multiple objects and assign them in the calling environment (since 
R doesn't have a particularly nice form of Python's tuple-unpacking idiom).


  Am I missing something?

 cheers
   Ben


https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52

https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171

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

Re: [Rd] Question on non-blocking socket

[Simon Urbanek]

Ben,

yes, by definition - non-blocking means that reads won't block and always 
return immediately (the point of non-blocking). The loop below is terrible as 
it will cause 100% CPU usage while it's spinning. It seems that you want to 
block so why are you using non-blocking mode? select() effectively gets you 
back to blocking mode, because it does the "block" that read() would normally 
do in blocking mode. Moreover select() allows you to block for a specified time 
(the point of the timeout argument) so if you want to wait, you should set the 
timeout - you should never use a spin loop without timeouts. Also there are 
many other conditions you should be handling - there may be an error on the 
socket or EINTR (you should call R's interrupt handler) or EAGAIN (which you do 
implicitly, but you can't tell it from an actual error).

Sockets and I/O are quite complex matter - it's easy to get it wrong and create 
hard-to-detect bugs in you code unless you are an expert in it. It's one of the 
wheels you don't want to be reinventing.

Cheers,
Simon


> On Feb 18, 2023, at 3:00 AM, Ben Engbers  wrote:
> 
> Hi Tomas,
> 
> Apparently, inserting some kind of socketSelect() is essential when using 
> non-blocking sockets and a client/erve architecture. That is at least one 
> thing that I have learned ;-).
> 
> In C++, between sending and requesting, I inserted a call to this function:
> bool wait(int s) {
>  fd_set read_set;
>  struct timeval timeout {};
>  memset(, 0, sizeof(timeout));
>  bool done{};
>  while (!done ) {
>FD_ZERO(_set);
>FD_SET(s, _set);
>int rc = select(s + 1, _set, NULL, NULL, );
>done = (rc == 1) && FD_ISSET(s, _set);
>  };
>  return done;
> };
> 
> Inserting this call was essential in solving my problem.
> 
> Ben
> 
> Op 15-02-2023 om 17:17 schreef Tomas Kalibera:
>> In the example you are waiting only for a single byte. But if the response 
>> may be longer, one needs to take into account in the client that not all 
>> bytes of the response may be available right away. One would keep receiving 
>> the data in a loop, as they become available (e.g. socketSelect() would 
>> tell), keep appending them to a buffer, and keep looking for when they are 
>> complete.
>> Tomas
>>> Ben
> 
> __
> 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] Question on non-blocking socket

[Ben Engbers]

Hi Tomas,

Apparently, inserting some kind of socketSelect() is essential when 
using non-blocking sockets and a client/erve architecture. That is at 
least one thing that I have learned ;-).


In C++, between sending and requesting, I inserted a call to this function:
bool wait(int s) {
  fd_set read_set;
  struct timeval timeout {};
  memset(, 0, sizeof(timeout));
  bool done{};
  while (!done ) {
FD_ZERO(_set);
FD_SET(s, _set);
int rc = select(s + 1, _set, NULL, NULL, );
done = (rc == 1) && FD_ISSET(s, _set);
  };
  return done;
};

Inserting this call was essential in solving my problem.

Ben

Op 15-02-2023 om 17:17 schreef Tomas Kalibera:
In the example you are waiting only for a single byte. But if the 
response may be longer, one needs to take into account in the client 
that not all bytes of the response may be available right away. One 
would keep receiving the data in a loop, as they become available (e.g. 
socketSelect() would tell), keep appending them to a buffer, and keep 
looking for when they are complete.


Tomas

Ben


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

Re: [Rd] Question on non-blocking socket

[Charlie Gao via R-devel]

> Date: Wed, 15 Feb 2023 01:24:26 +0100
> From: Ben Engbers 
> To: r-devel@r-project.org
> Subject: [Rd] Question on non-blocking socket
> Message-ID: <68ce63b0-7e91-6372-6926-59f3fcfff...@be-logical.nl>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Hi,
> 
> December 27, 2021 I started a thread asking for help troubleshooting 
> non-blocking sockets.
> While developing the RBaseX client, I had issues with the authentication 
> process. It eventually turned out that a short break had to be inserted 
> in this process between sending the credentials to the server and 
> requesting the status. Tomas Kalibera put me on the right track by 
> drawing my attention to the 'socketSelect' function. I don't know 
> exactly the purpose of this function is (the function itself is 
> documented, but I can't find any information for which situations this 
> function should be called.) but it sufficed to call this function once 
> between sending and requesting.
> 
> I have two questions.
> The first is where I can find R documentation on proper use of 
> non-blocking sockets and on the proper use of the socketSelect function?
> 
> The second question is more focused on using non-blocking sockets in 
> general. Is it allowed to execute a read and a receive command 
> immediately after each other or must a short waiting loop be built in.
> I'm asking this because I'm running into the same problems in a C++ 
> project as I did with RBaseX.
> 
> Ben Engbers
> 

Hi Ben,

For an easier experience with sockets, you may wish to have a look at the 
`nanonext` package. This wraps 'NNG' and is generally used for messaging over 
its own protocols (req/rep, pub/sub etc.), although you can also use it for 
HTTP and websockets.

In any case, a low level stream interface allows connecting with arbitrary 
sockets. Using something like `s <- stream(dial = "tcp://0.0.0.0:")` 
substituting in the actual address. This would allow you greater flexibility in 
sending and receiving over the bytestream without worrying so much about order 
and timing as per your current experience.

For example, a common pattern this allows for is doing an async receive `r <- 
recv_aio(s)`  before sending a request `send(s, "some request")`, and then 
query the receive result afterwards at `r$data`.

I won't go into too much detail here, but as it is my own package, please feel 
free to reach out separately via email or github etc.

Thanks,

Charlie

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

Re: [Rd] Question on non-blocking socket

[Tomas Kalibera]

On 2/15/23 16:44, Ben Engbers wrote:

Hi

Op 15-02-2023 om 14:38 schreef Tomas Kalibera:

On 2/15/23 01:24, Ben Engbers wrote:

Hi,

December 27, 2021 I started a thread asking for help troubleshooting 
non-blocking sockets.

..


I have two questions.
The first is where I can find R documentation on proper use of 
non-blocking sockets and on the proper use of the socketSelect 
function?


In addition to the demos I sent to you in that 2021 thread on 
R-pkg-devel, you could also have a look at how it is used in R 
itself, in the parallel package, in snowSOCK.R, to set up the snow 
cluster in parallel. Some hints may be also found in the blog post 
https://blog.r-project.org/2020/03/17/socket-connections-update/. 
But, in principle, R API is just a thin layer on top of what the OS 
provides, so general literature and tutorials on sockets should help, 
there should be even textbooks used at CS universities in networking 
classes.

Thanks for the suggestions!

Basically select() can tell you when data is ready (on input), when 
the socket interface is able to accept more data (on output) or when 
there is an incoming connection. In practice, you should not need any 
delays to be inserted in your program to make it work - if that is 
needed, it means that is an error in it (a race condition). If the 
program is polling (checking in a loop whether something has already 
happened, and then sleeping for a short while), the duration of the 
sleep may indeed influence latency, but should not affect correctness 
- if it does, there is an error.


In RBaseX I first calculate an MD5 hash that is send to the server and 
then I check the status byte that is returned by the server.


writeBin(auth, private$conn)
socketSelect(list(conn))
Accepted <- readBin(conn, what = "raw", n = 1) == 0

Without the second line, 'Accepted' is always FALSE. With this line it 
is TRUE.


BaseX provides example API's in several languages. I've looked at 
several but indeed none uses any form of delay.
All API's follow the same pattern, calculate a MD5, send it to the 
server and check the status byte. So the server is not likely to 
enforce a delay. So there is nothing left but to look for that racing 
condition ;-(


Without knowing more details, this looks ok. If you have a non-blocking 
connection, and the server produces a response based on the client 
request, the client has to take into account that it takes the server 
some time to produce the response. Right, the sockets are full duplex 
and so could be the communication protocol, but in this case it 
apparently isn't, it is request/response.


Without the second line, there would be a race condition between the 
server sending a response and the client receiving it. With the second 
line, the client waits for the server before it starts receiving. In 
theory, one could be waiting for the response actively in a loop 
(polling), but socketSelect() is better. Both ways would resolve the 
race condition. Adding a single fixed-time wait, instead, would not 
remove the race condition, because one can never be sure that the server 
wouldn't take longer (apart from waiting too long most of the time).


In the example you are waiting only for a single byte. But if the 
response may be longer, one needs to take into account in the client 
that not all bytes of the response may be available right away. One 
would keep receiving the data in a loop, as they become available (e.g. 
socketSelect() would tell), keep appending them to a buffer, and keep 
looking for when they are complete.


Tomas



Ben


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

Re: [Rd] Question on non-blocking socket

[Ben Engbers]

Hi

Op 15-02-2023 om 14:38 schreef Tomas Kalibera:

On 2/15/23 01:24, Ben Engbers wrote:

Hi,

December 27, 2021 I started a thread asking for help troubleshooting 
non-blocking sockets.

..


I have two questions.
The first is where I can find R documentation on proper use of 
non-blocking sockets and on the proper use of the socketSelect function?


In addition to the demos I sent to you in that 2021 thread on 
R-pkg-devel, you could also have a look at how it is used in R itself, 
in the parallel package, in snowSOCK.R, to set up the snow cluster in 
parallel. Some hints may be also found in the blog post 
https://blog.r-project.org/2020/03/17/socket-connections-update/. But, 
in principle, R API is just a thin layer on top of what the OS provides, 
so general literature and tutorials on sockets should help, there should 
be even textbooks used at CS universities in networking classes.

Thanks for the suggestions!

Basically select() can tell you when data is ready (on input), when the 
socket interface is able to accept more data (on output) or when there 
is an incoming connection. In practice, you should not need any delays 
to be inserted in your program to make it work - if that is needed, it 
means that is an error in it (a race condition). If the program is 
polling (checking in a loop whether something has already happened, and 
then sleeping for a short while), the duration of the sleep may indeed 
influence latency, but should not affect correctness - if it does, there 
is an error.


In RBaseX I first calculate an MD5 hash that is send to the server and 
then I check the status byte that is returned by the server.


writeBin(auth, private$conn)
socketSelect(list(conn))
Accepted <- readBin(conn, what = "raw", n = 1) == 0

Without the second line, 'Accepted' is always FALSE. With this line it 
is TRUE.


BaseX provides example API's in several languages. I've looked at 
several but indeed none uses any form of delay.
All API's follow the same pattern, calculate a MD5, send it to the 
server and check the status byte. So the server is not likely to enforce 
a delay. So there is nothing left but to look for that racing condition ;-(


Ben

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

Re: [Rd] Question on non-blocking socket

[Ivan Krylov]

В Wed, 15 Feb 2023 01:24:26 +0100
Ben Engbers  пишет:

> where I can find R documentation on proper use of non-blocking
> sockets and on the proper use of the socketSelect function?

A useful guide to the Berkeley sockets API can be found at
. You'll have to translate between the C
idioms and the R idioms, but it's better than having no guide at all.
In particular, R spares you from having to figure out differently-sized
struct sockaddr objects by converting them to string representations of
the addresses (currently limited to IPv4).

-- 
Best regards,
Ivan

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

Re: [Rd] Question on non-blocking socket

[Tomas Kalibera]

On 2/15/23 01:24, Ben Engbers wrote:

Hi,

December 27, 2021 I started a thread asking for help troubleshooting 
non-blocking sockets.
While developing the RBaseX client, I had issues with the 
authentication process. It eventually turned out that a short break 
had to be inserted in this process between sending the credentials to 
the server and requesting the status. Tomas Kalibera put me on the 
right track by drawing my attention to the 'socketSelect' function. I 
don't know exactly the purpose of this function is (the function 
itself is documented, but I can't find any information for which 
situations this function should be called.) but it sufficed to call 
this function once between sending and requesting.


I have two questions.
The first is where I can find R documentation on proper use of 
non-blocking sockets and on the proper use of the socketSelect function?


In addition to the demos I sent to you in that 2021 thread on 
R-pkg-devel, you could also have a look at how it is used in R itself, 
in the parallel package, in snowSOCK.R, to set up the snow cluster in 
parallel. Some hints may be also found in the blog post 
https://blog.r-project.org/2020/03/17/socket-connections-update/. But, 
in principle, R API is just a thin layer on top of what the OS provides, 
so general literature and tutorials on sockets should help, there should 
be even textbooks used at CS universities in networking classes.


Basically select() can tell you when data is ready (on input), when the 
socket interface is able to accept more data (on output) or when there 
is an incoming connection. In practice, you should not need any delays 
to be inserted in your program to make it work - if that is needed, it 
means that is an error in it (a race condition). If the program is 
polling (checking in a loop whether something has already happened, and 
then sleeping for a short while), the duration of the sleep may indeed 
influence latency, but should not affect correctness - if it does, there 
is an error.


The second question is more focused on using non-blocking sockets in 
general. Is it allowed to execute a read and a receive command 
immediately after each other or must a short waiting loop be built in.
I'm asking this because I'm running into the same problems in a C++ 
project as I did with RBaseX.


No, in general there is no need to insert any delays between reads and 
writes, they can actually happen concurrently. But these are general 
networking questions, not the topic of this list.


Best
Tomas



Ben Engbers

__
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

[Rd] Question on non-blocking socket

[Ben Engbers]

Hi,

December 27, 2021 I started a thread asking for help troubleshooting 
non-blocking sockets.
While developing the RBaseX client, I had issues with the authentication 
process. It eventually turned out that a short break had to be inserted 
in this process between sending the credentials to the server and 
requesting the status. Tomas Kalibera put me on the right track by 
drawing my attention to the 'socketSelect' function. I don't know 
exactly the purpose of this function is (the function itself is 
documented, but I can't find any information for which situations this 
function should be called.) but it sufficed to call this function once 
between sending and requesting.


I have two questions.
The first is where I can find R documentation on proper use of 
non-blocking sockets and on the proper use of the socketSelect function?


The second question is more focused on using non-blocking sockets in 
general. Is it allowed to execute a read and a receive command 
immediately after each other or must a short waiting loop be built in.
I'm asking this because I'm running into the same problems in a C++ 
project as I did with RBaseX.


Ben Engbers

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

Re: [Rd] Question about grid.group compositing operators in cairo

[Paul Murrell]

Hi

This issue has expanded to include the behaviour of compositing 
operators in R graphics more generally.


For the record, the discussion is continuing here ...

https://github.com/pmur002/rgraphics-compositing

Paul

On 4/10/22 09:20, Paul Murrell wrote:


Interim update:  I have spoken with Thomas Lin Pedersen (cc'ed), the 
author/maintainer of 'ragg' and 'svglite', who is working on adding 
group support for those graphics devices and he has voted in support of 
the current Cairo implementation, so the needle has shifted towards 
Cairo at this stage.


I still want to do more tests on other devices to gather more evidence.

Paul

p.s.  Attached (if it makes it through the filters) is a manual 
modification of your original dsvg() example that has been changed so 
that it produces the Cairo result.  This is probably not exactly how you 
would want to implement the dsvg() solution, but it is at least a proof 
of concept that the Cairo result can be produced in SVG.


On 30/09/22 10:49, Paul Murrell wrote:

Hi

Some more thoughts ...

<1>
I said before that currently, dev->group() does this ...

[OVER] shape shape shape OP shape shape shape

... and one option would be an implicit group on 'src' and 'dst' like 
this ...


([OVER] shape shape shape) OP ([OVER] shape shape shape)

... but another approach could be just an implicit group on each 
shape, like this ...


[OVER] ([OVER] shape) ([OVER] shape) OP ([OVER] shape) ([OVER] shape)

That may be a better representation of what you are already doing with 
dsvg() ?  It may also better reflect what naturally occurs in some 
graphics systems.


<2>
Changing the Cairo implementation to work like that would I think 
produce the same result as your dsvg() for ...


grid.group(src, "in", dst)

... and it would make what constitutes more than one shape much less 
surprising ...


gList(rectGrob(), rectGrob())  ## multiple shapes (obviously)
rectGrob(width=1:2/2)  ## multiple shapes (less obvious)
rectGrob(gp=gpar(col=, fill=)) ## NOT multiple shapes (no surprise)

... and it should not break any pre-existing non-group behaviour.

<3>
One casualty from this third option would be that the following would 
no longer solve the overlapping fill and stroke problem ...


grid.group(overlapRect, "source")

... although the fact that that currently works is really a bit 
surprising AND that result could still be achieved by explicitly 
drawing separate shapes ...


grid.group(rectGrob(gp=gpar(col=rgb(1,0,0,.5), lwd=20, fill=NA)),
    "source",
    rectGrob(gp=gpar(col=NA, fill="green")))

<4>
I need to try some of this out and also check in with some other 
people who I think are working on implementing groups on different 
graphics devices.


<5>
In summary, don't go changing dsvg() too much just yet!

Paul

On 29/09/2022 1:30 pm, Paul Murrell wrote:

Hi

Would it work to explicitly record a filled-and-stroked shape as two 
separate elements (one only filled and one only stroked) ?


Then it should only be as hard to apply the active operator on both 
of those elements as it is to apply the active operator to more than 
one shape (?)


Paul

On 29/09/22 10:17, Panagiotis Skintzos wrote:

Thank you for the very thorough explanation Paul.

To answer your question on 11: The dsvg device, simply defines svg
elements with their attributes (rect with fill & stroke in my 
examples).

It does not do any internal image processing like cairo.

My concern is how to proceed with the implementation in dsvg.

If I leave it as it is now, they're will be cases where it will give
different results from cairo (and perhaps other devices that will
implement group compositing in similar way).

On the other hand It would be quite challenging in practice to simulate
the cairo implementation and apply first the fill and then the stroke
with the active operator, on the element itself.

Any suggestions? :-)

Panagiotis


On 28/9/22 02:56, Paul Murrell wrote:
 > Hi
 >
 > Thanks for the code (and for the previous attachments).
 >
 > Some thoughts so far (HTML version with images attached) ...
 >
 > <1>
 > As you have pointed out, the Cairo device draws a stroked-and-filled
 > shape with two separate drawing operations: the path is filled and
 > then the path is stroked.  I do not believe that there is any
 > alternative in Cairo graphics (apart from filling and stroking as an
 > isolated group and then drawing the group, which we will come 
back to).

 >
 > <2>
 > This fill-then-stroke approach is easy to demonstrate just with a 
thick

 > semitransparent border ...
 >
 > library(grid)
 > overlapRect <- rectGrob(width=.5, height=.5,
 >     gp=gpar(fill="green", lwd=20,
 >     col=rgb(1,0,0,.5)))
 > grid.newpage()
 > grid.draw(overlapRect)
 >
 > <3>
 > This fill-then-stroke approach is what happens on many (most?)
 > graphics devices, including, for example, the core windows() device,
 > the core quartz() device, the 

Re: [Rd] Question about grid.group compositing operators in cairo

[Paul Murrell]

Interim update:  I have spoken with Thomas Lin Pedersen (cc'ed), the 
author/maintainer of 'ragg' and 'svglite', who is working on adding 
group support for those graphics devices and he has voted in support of 
the current Cairo implementation, so the needle has shifted towards 
Cairo at this stage.


I still want to do more tests on other devices to gather more evidence.

Paul

p.s.  Attached (if it makes it through the filters) is a manual 
modification of your original dsvg() example that has been changed so 
that it produces the Cairo result.  This is probably not exactly how you 
would want to implement the dsvg() solution, but it is at least a proof 
of concept that the Cairo result can be produced in SVG.


On 30/09/22 10:49, Paul Murrell wrote:

Hi

Some more thoughts ...

<1>
I said before that currently, dev->group() does this ...

[OVER] shape shape shape OP shape shape shape

... and one option would be an implicit group on 'src' and 'dst' like 
this ...


([OVER] shape shape shape) OP ([OVER] shape shape shape)

... but another approach could be just an implicit group on each shape, 
like this ...


[OVER] ([OVER] shape) ([OVER] shape) OP ([OVER] shape) ([OVER] shape)

That may be a better representation of what you are already doing with 
dsvg() ?  It may also better reflect what naturally occurs in some 
graphics systems.


<2>
Changing the Cairo implementation to work like that would I think 
produce the same result as your dsvg() for ...


grid.group(src, "in", dst)

... and it would make what constitutes more than one shape much less 
surprising ...


gList(rectGrob(), rectGrob())  ## multiple shapes (obviously)
rectGrob(width=1:2/2)  ## multiple shapes (less obvious)
rectGrob(gp=gpar(col=, fill=)) ## NOT multiple shapes (no surprise)

... and it should not break any pre-existing non-group behaviour.

<3>
One casualty from this third option would be that the following would no 
longer solve the overlapping fill and stroke problem ...


grid.group(overlapRect, "source")

... although the fact that that currently works is really a bit 
surprising AND that result could still be achieved by explicitly drawing 
separate shapes ...


grid.group(rectGrob(gp=gpar(col=rgb(1,0,0,.5), lwd=20, fill=NA)),
    "source",
    rectGrob(gp=gpar(col=NA, fill="green")))

<4>
I need to try some of this out and also check in with some other people 
who I think are working on implementing groups on different graphics 
devices.


<5>
In summary, don't go changing dsvg() too much just yet!

Paul

On 29/09/2022 1:30 pm, Paul Murrell wrote:

Hi

Would it work to explicitly record a filled-and-stroked shape as two 
separate elements (one only filled and one only stroked) ?


Then it should only be as hard to apply the active operator on both of 
those elements as it is to apply the active operator to more than one 
shape (?)


Paul

On 29/09/22 10:17, Panagiotis Skintzos wrote:

Thank you for the very thorough explanation Paul.

To answer your question on 11: The dsvg device, simply defines svg
elements with their attributes (rect with fill & stroke in my examples).
It does not do any internal image processing like cairo.

My concern is how to proceed with the implementation in dsvg.

If I leave it as it is now, they're will be cases where it will give
different results from cairo (and perhaps other devices that will
implement group compositing in similar way).

On the other hand It would be quite challenging in practice to simulate
the cairo implementation and apply first the fill and then the stroke
with the active operator, on the element itself.

Any suggestions? :-)

Panagiotis


On 28/9/22 02:56, Paul Murrell wrote:
 > Hi
 >
 > Thanks for the code (and for the previous attachments).
 >
 > Some thoughts so far (HTML version with images attached) ...
 >
 > <1>
 > As you have pointed out, the Cairo device draws a stroked-and-filled
 > shape with two separate drawing operations: the path is filled and
 > then the path is stroked.  I do not believe that there is any
 > alternative in Cairo graphics (apart from filling and stroking as an
 > isolated group and then drawing the group, which we will come back 
to).

 >
 > <2>
 > This fill-then-stroke approach is easy to demonstrate just with a 
thick

 > semitransparent border ...
 >
 > library(grid)
 > overlapRect <- rectGrob(width=.5, height=.5,
 >     gp=gpar(fill="green", lwd=20,
 >     col=rgb(1,0,0,.5)))
 > grid.newpage()
 > grid.draw(overlapRect)
 >
 > <3>
 > This fill-then-stroke approach is what happens on many (most?)
 > graphics devices, including, for example, the core windows() device,
 > the core quartz() device, the 'ragg' devices, and 'ggiraph'.  The
 > latter is true because this is actually the defined behaviour for 
SVG ...

 >
 > https://www.w3.org/TR/SVG2/render.html#Elements 

 > 

Re: [Rd] Question about grid.group compositing operators in cairo

[Paul Murrell]

Hi

Some more thoughts ...

<1>
I said before that currently, dev->group() does this ...

[OVER] shape shape shape OP shape shape shape

... and one option would be an implicit group on 'src' and 'dst' like 
this ...


([OVER] shape shape shape) OP ([OVER] shape shape shape)

... but another approach could be just an implicit group on each shape, 
like this ...


[OVER] ([OVER] shape) ([OVER] shape) OP ([OVER] shape) ([OVER] shape)

That may be a better representation of what you are already doing with 
dsvg() ?  It may also better reflect what naturally occurs in some 
graphics systems.


<2>
Changing the Cairo implementation to work like that would I think 
produce the same result as your dsvg() for ...


grid.group(src, "in", dst)

... and it would make what constitutes more than one shape much less 
surprising ...


gList(rectGrob(), rectGrob())  ## multiple shapes (obviously)
rectGrob(width=1:2/2)  ## multiple shapes (less obvious)
rectGrob(gp=gpar(col=, fill=)) ## NOT multiple shapes (no surprise)

... and it should not break any pre-existing non-group behaviour.

<3>
One casualty from this third option would be that the following would no 
longer solve the overlapping fill and stroke problem ...


grid.group(overlapRect, "source")

... although the fact that that currently works is really a bit 
surprising AND that result could still be achieved by explicitly drawing 
separate shapes ...


grid.group(rectGrob(gp=gpar(col=rgb(1,0,0,.5), lwd=20, fill=NA)),
   "source",
   rectGrob(gp=gpar(col=NA, fill="green")))

<4>
I need to try some of this out and also check in with some other people 
who I think are working on implementing groups on different graphics 
devices.


<5>
In summary, don't go changing dsvg() too much just yet!

Paul

On 29/09/2022 1:30 pm, Paul Murrell wrote:

Hi

Would it work to explicitly record a filled-and-stroked shape as two 
separate elements (one only filled and one only stroked) ?


Then it should only be as hard to apply the active operator on both of 
those elements as it is to apply the active operator to more than one 
shape (?)


Paul

On 29/09/22 10:17, Panagiotis Skintzos wrote:

Thank you for the very thorough explanation Paul.

To answer your question on 11: The dsvg device, simply defines svg
elements with their attributes (rect with fill & stroke in my examples).
It does not do any internal image processing like cairo.

My concern is how to proceed with the implementation in dsvg.

If I leave it as it is now, they're will be cases where it will give
different results from cairo (and perhaps other devices that will
implement group compositing in similar way).

On the other hand It would be quite challenging in practice to simulate
the cairo implementation and apply first the fill and then the stroke
with the active operator, on the element itself.

Any suggestions? :-)

Panagiotis


On 28/9/22 02:56, Paul Murrell wrote:
 > Hi
 >
 > Thanks for the code (and for the previous attachments).
 >
 > Some thoughts so far (HTML version with images attached) ...
 >
 > <1>
 > As you have pointed out, the Cairo device draws a stroked-and-filled
 > shape with two separate drawing operations: the path is filled and
 > then the path is stroked.  I do not believe that there is any
 > alternative in Cairo graphics (apart from filling and stroking as an
 > isolated group and then drawing the group, which we will come back 
to).

 >
 > <2>
 > This fill-then-stroke approach is easy to demonstrate just with a 
thick

 > semitransparent border ...
 >
 > library(grid)
 > overlapRect <- rectGrob(width=.5, height=.5,
 >     gp=gpar(fill="green", lwd=20,
 >     col=rgb(1,0,0,.5)))
 > grid.newpage()
 > grid.draw(overlapRect)
 >
 > <3>
 > This fill-then-stroke approach is what happens on many (most?)
 > graphics devices, including, for example, the core windows() device,
 > the core quartz() device, the 'ragg' devices, and 'ggiraph'.  The
 > latter is true because this is actually the defined behaviour for 
SVG ...

 >
 > https://www.w3.org/TR/SVG2/render.html#Elements 

 > https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText 


 >
 > <4>
 > There are exceptions to the fill-then-stroke approach, including the
 > core pdf() device, but I think they are in the minority.  The PDF
 > language supports a "B" operator that only fills within the border (no
 > overlap between fill and border).  Demonstrating this is complicated
 > by the fact that not all PDF viewers support this correctly (e.g.,
 > evince and Firefox do not;  ghostscript and chrome do)!
 >
 > <5>
 > Forcing all R graphics devices to change the rendering of
 > filled-and-stroked shapes to match the PDF definition instead of
 > fill-then-stroke is unlikely to happen because it would impact a lot
 > of graphics devices, it would break existing 

Re: [Rd] Question about grid.group compositing operators in cairo

[Paul Murrell]

Hi

Would it work to explicitly record a filled-and-stroked shape as two 
separate elements (one only filled and one only stroked) ?


Then it should only be as hard to apply the active operator on both of 
those elements as it is to apply the active operator to more than one 
shape (?)


Paul

On 29/09/22 10:17, Panagiotis Skintzos wrote:

Thank you for the very thorough explanation Paul.

To answer your question on 11: The dsvg device, simply defines svg
elements with their attributes (rect with fill & stroke in my examples).
It does not do any internal image processing like cairo.

My concern is how to proceed with the implementation in dsvg.

If I leave it as it is now, they're will be cases where it will give
different results from cairo (and perhaps other devices that will
implement group compositing in similar way).

On the other hand It would be quite challenging in practice to simulate
the cairo implementation and apply first the fill and then the stroke
with the active operator, on the element itself.

Any suggestions? :-)

Panagiotis


On 28/9/22 02:56, Paul Murrell wrote:
 > Hi
 >
 > Thanks for the code (and for the previous attachments).
 >
 > Some thoughts so far (HTML version with images attached) ...
 >
 > <1>
 > As you have pointed out, the Cairo device draws a stroked-and-filled
 > shape with two separate drawing operations: the path is filled and
 > then the path is stroked.  I do not believe that there is any
 > alternative in Cairo graphics (apart from filling and stroking as an
 > isolated group and then drawing the group, which we will come back to).
 >
 > <2>
 > This fill-then-stroke approach is easy to demonstrate just with a thick
 > semitransparent border ...
 >
 > library(grid)
 > overlapRect <- rectGrob(width=.5, height=.5,
 >     gp=gpar(fill="green", lwd=20,
 >     col=rgb(1,0,0,.5)))
 > grid.newpage()
 > grid.draw(overlapRect)
 >
 > <3>
 > This fill-then-stroke approach is what happens on many (most?)
 > graphics devices, including, for example, the core windows() device,
 > the core quartz() device, the 'ragg' devices, and 'ggiraph'.  The
 > latter is true because this is actually the defined behaviour for SVG ...
 >
 > https://www.w3.org/TR/SVG2/render.html#Elements 

 > https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText 


 >
 > <4>
 > There are exceptions to the fill-then-stroke approach, including the
 > core pdf() device, but I think they are in the minority.  The PDF
 > language supports a "B" operator that only fills within the border (no
 > overlap between fill and border).  Demonstrating this is complicated
 > by the fact that not all PDF viewers support this correctly (e.g.,
 > evince and Firefox do not;  ghostscript and chrome do)!
 >
 > <5>
 > Forcing all R graphics devices to change the rendering of
 > filled-and-stroked shapes to match the PDF definition instead of
 > fill-then-stroke is unlikely to happen because it would impact a lot
 > of graphics devices, it would break existing behaviour, it may be
 > difficult/impossible for some devices, and it is not clear that it is
 > the best approach anyway.
 >
 > <6>
 > Finally getting back to your example, the fill-then-stroke approach
 > produces some interesting results when applying compositing operators
 > because the fill is drawn using the compositing operator to combine it
 > with previous drawing and then the stroke is drawn using the
 > compositing operator to combine it with *the result of combining the
 > fill with previous drawing*. The result makes sense in terms of how
 > the rendering works, but it probably fails the "principle of least
 > surprise".
 >
 > srcRect <- rectGrob(2/3, 1/3, width=.6, height=.6,
 >     gp=gpar(lwd = 5, fill=rgb(0, 0, 0.9, 0.4)))
 > dstRect <- rectGrob(1/3, 2/3, width=.6, height=.6,
 >     gp=gpar(lwd = 5, fill=rgb(0.7, 0, 0, 0.8)))
 > grid.newpage()
 > grid.group(srcRect, "in", dstRect)
 >
 > <7>
 > This issue is not entirely unanticipated because it can arise
 > slightly-less-unintentionally if we combine a 'src' and/or 'dst' that
 > draw more than one shape, like this ...
 >
 > src <- circleGrob(3:4/5, r=.2, gp=gpar(col=NA, fill=2))
 > dst <- circleGrob(1:2/5, r=.2, gp=gpar(col=NA, fill=3))
 > grid.newpage()
 > grid.group(src, "xor", dst)
 >
 > This was discussed in the Section "Compositing and blend modes" in the
 > original technical report about groups and compositing ...
 >
 > 
https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/groups/groups.html#userdetails 
 


 >
 >
 > <8>
 > A solution to the problem of drawing more than one shape (above) is to
 > take explicit control of how shapes are combined, *using explicit
 > groups* ...
 >
 > grid.newpage()
 > 

Re: [Rd] Question about grid.group compositing operators in cairo

[Panagiotis Skintzos]

Thank you for the very thorough explanation Paul.

To answer your question on 11: The dsvg device, simply defines svg 
elements with their attributes (rect with fill & stroke in my examples). 
It does not do any internal image processing like cairo.


My concern is how to proceed with the implementation in dsvg.

If I leave it as it is now, they're will be cases where it will give 
different results from cairo (and perhaps other devices that will 
implement group compositing in similar way).


On the other hand It would be quite challenging in practice to simulate 
the cairo implementation and apply first the fill and then the stroke 
with the active operator, on the element itself.


Any suggestions? :-)

Panagiotis


On 28/9/22 02:56, Paul Murrell wrote:

Hi

Thanks for the code (and for the previous attachments).

Some thoughts so far (HTML version with images attached) ...

<1>
As you have pointed out, the Cairo device draws a stroked-and-filled 
shape with two separate drawing operations: the path is filled and 
then the path is stroked.  I do not believe that there is any 
alternative in Cairo graphics (apart from filling and stroking as an 
isolated group and then drawing the group, which we will come back to).


<2>
This fill-then-stroke approach is easy to demonstrate just with a thick
semitransparent border ...

library(grid)
overlapRect <- rectGrob(width=.5, height=.5,
    gp=gpar(fill="green", lwd=20,
    col=rgb(1,0,0,.5)))
grid.newpage()
grid.draw(overlapRect)

<3>
This fill-then-stroke approach is what happens on many (most?) 
graphics devices, including, for example, the core windows() device, 
the core quartz() device, the 'ragg' devices, and 'ggiraph'.  The 
latter is true because this is actually the defined behaviour for SVG ...


https://www.w3.org/TR/SVG2/render.html#Elements
https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText

<4>
There are exceptions to the fill-then-stroke approach, including the 
core pdf() device, but I think they are in the minority.  The PDF 
language supports a "B" operator that only fills within the border (no 
overlap between fill and border).  Demonstrating this is complicated 
by the fact that not all PDF viewers support this correctly (e.g., 
evince and Firefox do not;  ghostscript and chrome do)!


<5>
Forcing all R graphics devices to change the rendering of 
filled-and-stroked shapes to match the PDF definition instead of 
fill-then-stroke is unlikely to happen because it would impact a lot 
of graphics devices, it would break existing behaviour, it may be 
difficult/impossible for some devices, and it is not clear that it is 
the best approach anyway.


<6>
Finally getting back to your example, the fill-then-stroke approach 
produces some interesting results when applying compositing operators 
because the fill is drawn using the compositing operator to combine it 
with previous drawing and then the stroke is drawn using the 
compositing operator to combine it with *the result of combining the 
fill with previous drawing*. The result makes sense in terms of how 
the rendering works, but it probably fails the "principle of least 
surprise".


srcRect <- rectGrob(2/3, 1/3, width=.6, height=.6,
    gp=gpar(lwd = 5, fill=rgb(0, 0, 0.9, 0.4)))
dstRect <- rectGrob(1/3, 2/3, width=.6, height=.6,
    gp=gpar(lwd = 5, fill=rgb(0.7, 0, 0, 0.8)))
grid.newpage()
grid.group(srcRect, "in", dstRect)

<7>
This issue is not entirely unanticipated because it can arise 
slightly-less-unintentionally if we combine a 'src' and/or 'dst' that 
draw more than one shape, like this ...


src <- circleGrob(3:4/5, r=.2, gp=gpar(col=NA, fill=2))
dst <- circleGrob(1:2/5, r=.2, gp=gpar(col=NA, fill=3))
grid.newpage()
grid.group(src, "xor", dst)

This was discussed in the Section "Compositing and blend modes" in the 
original technical report about groups and compositing ...


https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/groups/groups.html#userdetails 



<8>
A solution to the problem of drawing more than one shape (above) is to 
take explicit control of how shapes are combined, *using explicit 
groups* ...


grid.newpage()
grid.group(groupGrob(src), "xor", dst)

<9>
Explicit groups can be used to solve the problem of overlapping fill 
and stroke (here we specify that the rectangle border should be 
combined with the rectangle fill using the "source" operator) ...


grid.newpage()
grid.group(overlapRect, "source")

<10>
Explicit groups can also be used to get the result that we might have 
originally expected for the "in" operator example (here we isolate the 
'src' rectangle so that the border and the fill are combined together 
[using the default "over" operator] and then combined with the other 
rectangle using the "in" operator) ...


grid.newpage()
grid.group(groupGrob(srcRect), "in", dstRect)

<11>
A possible change would be to force an implicit group (with op=OVER) 
on 

Re: [Rd] Question about grid.group compositing operators in cairo

[Paul Murrell]

Hi

Thanks for the code (and for the previous attachments).

Some thoughts so far (HTML version with images attached) ...

<1>
As you have pointed out, the Cairo device draws a stroked-and-filled 
shape with two separate drawing operations:  the path is filled and then 
the path is stroked.  I do not believe that there is any alternative in 
Cairo graphics (apart from filling and stroking as an isolated group and 
then drawing the group, which we will come back to).


<2>
This fill-then-stroke approach is easy to demonstrate just with a thick
semitransparent border ...

library(grid)
overlapRect <- rectGrob(width=.5, height=.5,
gp=gpar(fill="green", lwd=20,
col=rgb(1,0,0,.5)))
grid.newpage()
grid.draw(overlapRect)

<3>
This fill-then-stroke approach is what happens on many (most?) graphics 
devices, including, for example, the core windows() device, the core 
quartz() device, the 'ragg' devices, and 'ggiraph'.  The latter is true 
because this is actually the defined behaviour for SVG ...


https://www.w3.org/TR/SVG2/render.html#Elements
https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText

<4>
There are exceptions to the fill-then-stroke approach, including the 
core pdf() device, but I think they are in the minority.  The PDF 
language supports a "B" operator that only fills within the border (no 
overlap between fill and border).  Demonstrating this is complicated by 
the fact that not all PDF viewers support this correctly (e.g., evince 
and Firefox do not;  ghostscript and chrome do)!


<5>
Forcing all R graphics devices to change the rendering of 
filled-and-stroked shapes to match the PDF definition instead of 
fill-then-stroke is unlikely to happen because it would impact a lot of 
graphics devices, it would break existing behaviour, it may be 
difficult/impossible for some devices, and it is not clear that it is 
the best approach anyway.


<6>
Finally getting back to your example, the fill-then-stroke approach 
produces some interesting results when applying compositing operators 
because the fill is drawn using the compositing operator to combine it 
with previous drawing and then the stroke is drawn using the compositing 
operator to combine it with *the result of combining the fill with 
previous drawing*.  The result makes sense in terms of how the rendering 
works, but it probably fails the "principle of least surprise".


srcRect <- rectGrob(2/3, 1/3, width=.6, height=.6,
gp=gpar(lwd = 5, fill=rgb(0, 0, 0.9, 0.4)))
dstRect <- rectGrob(1/3, 2/3, width=.6, height=.6,
gp=gpar(lwd = 5, fill=rgb(0.7, 0, 0, 0.8)))
grid.newpage()
grid.group(srcRect, "in", dstRect)

<7>
This issue is not entirely unanticipated because it can arise 
slightly-less-unintentionally if we combine a 'src' and/or 'dst' that 
draw more than one shape, like this ...


src <- circleGrob(3:4/5, r=.2, gp=gpar(col=NA, fill=2))
dst <- circleGrob(1:2/5, r=.2, gp=gpar(col=NA, fill=3))
grid.newpage()
grid.group(src, "xor", dst)

This was discussed in the Section "Compositing and blend modes" in the 
original technical report about groups and compositing ...


https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/groups/groups.html#userdetails

<8>
A solution to the problem of drawing more than one shape (above) is to 
take explicit control of how shapes are combined, *using explicit 
groups* ...


grid.newpage()
grid.group(groupGrob(src), "xor", dst)

<9>
Explicit groups can be used to solve the problem of overlapping fill and 
stroke (here we specify that the rectangle border should be combined 
with the rectangle fill using the "source" operator) ...


grid.newpage()
grid.group(overlapRect, "source")

<10>
Explicit groups can also be used to get the result that we might have 
originally expected for the "in" operator example (here we isolate the 
'src' rectangle so that the border and the fill are combined together 
[using the default "over" operator] and then combined with the other 
rectangle using the "in" operator) ...


grid.newpage()
grid.group(groupGrob(srcRect), "in", dstRect)

<11>
A possible change would be to force an implicit group (with op=OVER) on 
the 'src' and 'dst' in dev->group().  I believe this is effectively what 
you are doing with your dsvg() device (?).


Currently, dev->group() does this ...

[OVER] shape shape shape OP shape shape shape

... and an implicit group on 'src' and 'dst' would do this ...

([OVER] shape shape shape) OP ([OVER] shape shape shape)

An implicit (OVER) group would make it easier to combine multiple shapes 
with OVER (though only slightly) ...


grid.group(src, OP, dst)

... instead of ...

grid.group(groupGrob(src), OP, dst)

On the other hand, an implicit (OVER) group would make it harder to 
combine multiple shapes with an operator other than OVER (by quite a 
lot?) ...


grid.group(groupGrob(shape, OP, groupGrob(shape, OP, shape)), OP, dst)

... instead of ...

Re: [Rd] Question about grid.group compositing operators in cairo

[Panagiotis Skintzos]

Here is the code again in text:


src <- rectGrob(2/3, 1/3, width=.6, height=.6, gp=gpar(lwd = 5, 
fill=rgb(0, 0, 0.9, 0.4)))
dst <- rectGrob(1/3, 2/3, width=.6, height=.6, gp=gpar(lwd = 5, 
fill=rgb(0.7, 0, 0, 0.8)))


svg("cairo.in.svg", width = 5, height = 5)
grid.group(src, "in", dst)
dev.off()



On 27/9/22 04:44, Paul Murrell wrote:


Could you also please send me the SVG code that your device is 
generating for your example.  Thanks!


Paul

On 27/09/22 08:50, Paul Murrell wrote:

Hi

Thanks for the report.  It certainly sounds like I have done 
something stupid :)  For my debugging and testing could you please 
share the R code from your tests ?  Thanks!


Paul

On 26/09/22 10:27, Panagiotis Skintzos wrote:

Hello,

I'm trying to update ggiraph package in graphic engine v15 
(currently we support up to v14).


I've implemented the group operators and when I compare the outputs 
of ggiraph::dsvg with the outputs of svg/png, I noticed some weird 
results.


Specifically, some operators in cairo (in, out, dest.in, dest.atop) 
give strange output, when any source element in the group has a 
stroke color defined.


I attach three example images, where two stroked rectangles are used 
as source (right) and destination (left).


cairo.over.png shows the result of the over operator in cairo

cairo.in.png shows the result of the in operator in cairo

dsvg.in.png shows the result of the in operator in dsvg


You can see the difference between cairo.in.png and dsvg.in.png. I 
found out why I get different results:


In dsvg implementation there is one drawing operation: Draw the 
source element, as whole (fill and stroke) over the destination 
element (using feComposite filter)


In cairo implementation though there are two operations: Apply the 
fill on source and draw over the destination and then apply the 
stroke and draw over the result of the previous operation.


I'm not sure if this is intentional or not. Shouldn't the source 
element being drawn first as whole (fill and stroke with over 
operator) and then apply the group operator and draw it over the 
destination? It would seem more logical that way.



Thanks,

Panagiotis


__
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] Question about grid.group compositing operators in cairo

[Panagiotis Skintzos]

Hi, sure

I attach the test code and my svg.


You can also find my current work on ggiraph in the branch ge15 on github:

https://github.com/sigmapi/ggiraph/tree/ge15


Thanks,

Panagiotis


On 27/9/22 04:44, Paul Murrell wrote:


Could you also please send me the SVG code that your device is 
generating for your example.  Thanks!


Paul

On 27/09/22 08:50, Paul Murrell wrote:

Hi

Thanks for the report.  It certainly sounds like I have done 
something stupid :)  For my debugging and testing could you please 
share the R code from your tests ?  Thanks!


Paul

On 26/09/22 10:27, Panagiotis Skintzos wrote:

Hello,

I'm trying to update ggiraph package in graphic engine v15 
(currently we support up to v14).


I've implemented the group operators and when I compare the outputs 
of ggiraph::dsvg with the outputs of svg/png, I noticed some weird 
results.


Specifically, some operators in cairo (in, out, dest.in, dest.atop) 
give strange output, when any source element in the group has a 
stroke color defined.


I attach three example images, where two stroked rectangles are used 
as source (right) and destination (left).


cairo.over.png shows the result of the over operator in cairo

cairo.in.png shows the result of the in operator in cairo

dsvg.in.png shows the result of the in operator in dsvg


You can see the difference between cairo.in.png and dsvg.in.png. I 
found out why I get different results:


In dsvg implementation there is one drawing operation: Draw the 
source element, as whole (fill and stroke) over the destination 
element (using feComposite filter)


In cairo implementation though there are two operations: Apply the 
fill on source and draw over the destination and then apply the 
stroke and draw over the result of the previous operation.


I'm not sure if this is intentional or not. Shouldn't the source 
element being drawn first as whole (fill and stroke with over 
operator) and then apply the group operator and draw it over the 
destination? It would seem more logical that way.



Thanks,

Panagiotis


__
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] Question about grid.group compositing operators in cairo

[Paul Murrell]

Could you also please send me the SVG code that your device is 
generating for your example.  Thanks!


Paul

On 27/09/22 08:50, Paul Murrell wrote:

Hi

Thanks for the report.  It certainly sounds like I have done something 
stupid :)  For my debugging and testing could you please share the R 
code from your tests ?  Thanks!


Paul

On 26/09/22 10:27, Panagiotis Skintzos wrote:

Hello,

I'm trying to update ggiraph package in graphic engine v15 (currently 
we support up to v14).


I've implemented the group operators and when I compare the outputs of 
ggiraph::dsvg with the outputs of svg/png, I noticed some weird results.


Specifically, some operators in cairo (in, out, dest.in, dest.atop) 
give strange output, when any source element in the group has a stroke 
color defined.


I attach three example images, where two stroked rectangles are used 
as source (right) and destination (left).


cairo.over.png shows the result of the over operator in cairo

cairo.in.png shows the result of the in operator in cairo

dsvg.in.png shows the result of the in operator in dsvg


You can see the difference between cairo.in.png and dsvg.in.png. I 
found out why I get different results:


In dsvg implementation there is one drawing operation: Draw the source 
element, as whole (fill and stroke) over the destination element 
(using feComposite filter)


In cairo implementation though there are two operations: Apply the 
fill on source and draw over the destination and then apply the stroke 
and draw over the result of the previous operation.


I'm not sure if this is intentional or not. Shouldn't the source 
element being drawn first as whole (fill and stroke with over 
operator) and then apply the group operator and draw it over the 
destination? It would seem more logical that way.



Thanks,

Panagiotis


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





--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/

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

Re: [Rd] Question about grid.group compositing operators in cairo

[Paul Murrell]

Hi

Thanks for the report.  It certainly sounds like I have done something 
stupid :)  For my debugging and testing could you please share the R 
code from your tests ?  Thanks!


Paul

On 26/09/22 10:27, Panagiotis Skintzos wrote:

Hello,

I'm trying to update ggiraph package in graphic engine v15 (currently we 
support up to v14).


I've implemented the group operators and when I compare the outputs of 
ggiraph::dsvg with the outputs of svg/png, I noticed some weird results.


Specifically, some operators in cairo (in, out, dest.in, dest.atop) give 
strange output, when any source element in the group has a stroke color 
defined.


I attach three example images, where two stroked rectangles are used as 
source (right) and destination (left).


cairo.over.png shows the result of the over operator in cairo

cairo.in.png shows the result of the in operator in cairo

dsvg.in.png shows the result of the in operator in dsvg


You can see the difference between cairo.in.png and dsvg.in.png. I found 
out why I get different results:


In dsvg implementation there is one drawing operation: Draw the source 
element, as whole (fill and stroke) over the destination element (using 
feComposite filter)


In cairo implementation though there are two operations: Apply the fill 
on source and draw over the destination and then apply the stroke and 
draw over the result of the previous operation.


I'm not sure if this is intentional or not. Shouldn't the source element 
being drawn first as whole (fill and stroke with over operator) and then 
apply the group operator and draw it over the destination? It would seem 
more logical that way.



Thanks,

Panagiotis


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


--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/

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

[Rd] Question about grid.group compositing operators in cairo

[Panagiotis Skintzos]

Hello,

I'm trying to update ggiraph package in graphic engine v15 (currently we 
support up to v14).


I've implemented the group operators and when I compare the outputs of 
ggiraph::dsvg with the outputs of svg/png, I noticed some weird results.


Specifically, some operators in cairo (in, out, dest.in, dest.atop) give 
strange output, when any source element in the group has a stroke color 
defined.


I attach three example images, where two stroked rectangles are used as 
source (right) and destination (left).


cairo.over.png shows the result of the over operator in cairo

cairo.in.png shows the result of the in operator in cairo

dsvg.in.png shows the result of the in operator in dsvg


You can see the difference between cairo.in.png and dsvg.in.png. I found 
out why I get different results:


In dsvg implementation there is one drawing operation: Draw the source 
element, as whole (fill and stroke) over the destination element (using 
feComposite filter)


In cairo implementation though there are two operations: Apply the fill 
on source and draw over the destination and then apply the stroke and 
draw over the result of the previous operation.


I'm not sure if this is intentional or not. Shouldn't the source element 
being drawn first as whole (fill and stroke with over operator) and then 
apply the group operator and draw it over the destination? It would seem 
more logical that way.



Thanks,

Panagiotis

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

Re: [Rd] Question about the UCRT switch

[Tomas Kalibera]

On 12/9/21 3:30 PM, Therneau, Terry M., Ph.D. via R-devel wrote:

The connected blog has the statement  "Most authors will not have to do 
anything as the
number of CRAN packages that will need some attention is below 1%, but authors 
of packages
using native (C, C++ or Fortran) code should read the following lines."

My packages do use a lot of C, but I never use Windows.   My reading of "the 
following
lines" is that  I don't have to do anything.   Is this correct?


Well but your users might be using Windows, so as long as your package 
is on CRAN and you are maintaining it to support Windows, the blog might 
have useful information for you - for instance how to check whether you 
need to update your packages or not, but see below.


Specifically for your case, CRAN packages bdsmatrix, coxme, deming, 
noweb and survival are passing their checks with the new toolchain, as 
can be seen from the result pages such as


https://cran.r-project.org/web/checks/check_results_survival.html

They do not use any installation-time patches, as can be seen from

https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/r_packages/patches/CRAN/

So, you really don't have to do anything, as most package authors with 
native code who don't use Windows.


Best
Tomas



Terry T.




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

[Rd] Question about the UCRT switch

[Therneau, Terry M., Ph.D. via R-devel]

The connected blog has the statement  "Most authors will not have to do 
anything as the 
number of CRAN packages that will need some attention is below 1%, but authors 
of packages 
using native (C, C++ or Fortran) code should read the following lines."

My packages do use a lot of C, but I never use Windows.   My reading of "the 
following 
lines" is that  I don't have to do anything.   Is this correct?

Terry T.


-- 
Terry M Therneau, PhD
Department of Quantitative Health Sciences
Mayo Clinic
thern...@mayo.edu

"TERR-ree THUR-noh"


[[alternative HTML version deleted]]

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

Re: [Rd] Question about quantile fuzz and GPL license

[GILLIBERT, Andre]

Martin Maechler wrote:
> OTOH,  type=7 is the default, and I guess used in 99.9% of
> all uses of quantile, *and* does never use any fuzz 

Indeed. This also implies that this default should be well-thought when 
creating a new implementation of the quantile() procedure for a new programming 
language or library.
Most of the time, users use the default procedure, and do not report the 
procedure used in the statistical analysis reports, scientific or 
non-scientific articles produced.
The differences between all quantiles procedures are minor, unless they are 
used in crazy scenarios such as a sample size of 2, or with probs=0.001 for a 
sample of size 1000.
But, standardization of procedures is desirable for analysis reproducibility, 
as well as teaching (see https://doi.org/10.1080/10691898.2006.11910589 ).

Hyndman and Fan wanted that software package standardize their definition, but 
to no avail:
See https://robjhyndman.com/hyndsight/sample-quantiles-20-years-later/

In the absence of standard, my personal advice would be to use the same default 
as a popular statistical software, such as R or SAS.

R, Julia and NumPy (python) uses type 7 as default.
Microsoft Excel and LibreOffice Calc use type 7 as default (although Excel 
versions >= 2010 have new procedures).
SAS uses type 3 as default, unless prob=0.50
Stata uses type 2 or type 6, depending on the procedure 
(https://data.princeton.edu/stata/markdown/quantiles.htm)

-- 
Sincerely
André GILLIBERT

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

Re: [Rd] Question about quantile fuzz and GPL license

[Martin Maechler]

> GILLIBERT, Andre 
> on Tue, 14 Sep 2021 16:13:05 + writes:

> On 9/14/21 9:22 AM, Abel AOUN wrote:
>> However I don't get why epsilon is multiplied by 4 instead of simply 
using epsilon.
>> Is there someone who can explain this 4 ?

> .Machine$double.eps is the "precision" of floating point values for 
values close to 1.0 (between 0.5 and 2.0).

> Using fuzz = .Machine$double.eps would have no effect if nppm is greater 
than or equal to 2.
> Using fuzz = 4 * .Machine$double.eps can fix rounding errors for nppm < 
8; for greater nppm, it has no effect.

> Indeed:
> 2 + .Machine$double.eps == 2
> 8+ 4*.Machine$double.eps == 8

> Since nppm is approximatively equal to the quantile multiplied by the 
sample size, it can be much greater than 2 or 8.

hmm: not "quantile":
 it is approximatively equal to the *'prob'* multiplied by the sample size
 {the quantiles themselves can be on any scale anyway, but they
  don't matter yet fortunately in these parts of the calculations}

but you're right in the main point that they are
approx. proportional to  n.

> Maybe the rounding errors are only problematic for small nppm; or only 
that case is taken in account.

> Moreover, if rounding errors are cumulative, they can be much greater 
than the precision of the floating point value. I do not know how this constant 
was chosen and what the use-cases were.

I vaguely remember I've been wondering about this also (back at the time).

Experiential wisdom would tell us to take such  fuzz values as
*relative* to the magnitude of the values they are added to,
here 'nppm' (which is always >= 0, hence no need for  abs(.) as usually).

So, instead of

j <- floor(nppm + fuzz)
h <- nppm - j
if(any(sml <- abs(h) < fuzz, na.rm = TRUE)) h[sml] <- 0

it would be (something like)

j <- floor(nppm*(1 + fuzz))
h <- nppm - j
if(any(sml <- abs(h) < fuzz*nppm, na.rm = TRUE)) h[sml] <- 0

or rather we would define fuzz as
   nppm * (k * .Machine$double.eps) 
for a small k.

- - -

OTOH,  type=7 is the default, and I guess used in 99.9% of
all uses of quantile, *and* does never use any fuzz 

Martin

> --
> Sincerely
> Andre GILLIBERT


> [[alternative HTML version deleted]]

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

Re: [Rd] Question about quantile fuzz and GPL license

[GILLIBERT, Andre]

On 9/14/21 9:22 AM, Abel AOUN wrote:
> However I don't get why epsilon is multiplied by 4 instead of simply using 
> epsilon.
> Is there someone who can explain this 4 ?

.Machine$double.eps is the "precision" of floating point values for values 
close to 1.0 (between 0.5 and 2.0).

Using fuzz = .Machine$double.eps would have no effect if nppm is greater than 
or equal to 2.
Using fuzz = 4 * .Machine$double.eps can fix rounding errors for nppm < 8; for 
greater nppm, it has no effect.

Indeed:
2 + .Machine$double.eps == 2
8+ 4*.Machine$double.eps == 8

Since nppm is approximatively equal to the quantile multiplied by the sample 
size, it can be much greater than 2 or 8.

Maybe the rounding errors are only problematic for small nppm; or only that 
case is taken in account.

Moreover, if rounding errors are cumulative, they can be much greater than the 
precision of the floating point value. I do not know how this constant was 
chosen and what the use-cases were.

--
Sincerely
Andre GILLIBERT


[[alternative HTML version deleted]]

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

Re: [Rd] Question about quantile fuzz and GPL license

[Ben Bolker]

On 9/14/21 9:22 AM, Abel AOUN wrote:

Hello,

I'm currently working on Python numpy package to develop linear interpolation 
methods for quantiles.
Currently, numpy only support the type 7 of Hyndman & Fan and I did the 
implementation for the 8 other methods to do as much as R ::quantile.

As you may guess, I was inspired by R implementation as well as other sources, 
which lead to my questions:

About fuzz (see first reference below for the source code),
fuzz <- 4 * .Machine $ double.eps
I think I understand why the machine epsilon is used to correct some edge cases 
where the float comparisons would fail.
However I don't get why epsilon is multiplied by 4 instead of simply using 
epsilon.
Is there someone who can explain this 4 ?


No, but doing a bit of archaeology

https://github.com/wch/r-source/blame/trunk/src/library/stats/R/quantile.R

  give the commit message for these lines as "add (modified) version of 
quantile.default from Rob Hyndman (17 years ago)".  This commit was made 
by Brian Ripley.


  However, the code from Rob Hyndman here:

https://stat.ethz.ch/pipermail/r-devel/2004-July/030204.html

  does **not** have the lines with the fuzz.  So my guess would be that 
Brian Ripley is the author of that particular bit of code.


  I can't say, myself, what the logic behind 4 * .Machine$double.eps is ...




About licence,
Numpy is under license BSD and R is on GPL.
The only thing I really cherry picked and rewrote for numpy is the fuzz part.
I'm quite new to open source development. We are wondering if doing this breaks 
the license GPL and if I can credit the original authors.
Plus, I'm not quite sure this is the right place to ask this, if not, sorry for 
the noise.
The relevant discussion on numpy PR is here: [ 
https://github.com/numpy/numpy/pull/19857#discussion_r706019184 | 
https://github.com/numpy/numpy/pull/19857#discussion_r706019184 ]


Thank you for your time.

Regards,
Abel Aoun


References:
The source code for R::quantile (fuzz is at line 82) [ 
https://github.com/wch/r-source/blob/79298c499218846d14500255efd622b5021c10ec/src/library/stats/R/quantile.R
 | 
https://github.com/wch/r-source/blob/79298c499218846d14500255efd622b5021c10ec/src/library/stats/R/quantile.R
 ] [ https://github.com/numpy/numpy/pull/19857 ]
R doc for quantile : [ 
https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile | 
https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile ]
The ongoing PR on numpy: [ https://github.com/numpy/numpy/pull/19857 | 
https://github.com/numpy/numpy/pull/19857 ]



[[alternative HTML version deleted]]

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



--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics

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

[Rd] Question about quantile fuzz and GPL license

[Abel AOUN]

Hello, 

I'm currently working on Python numpy package to develop linear interpolation 
methods for quantiles. 
Currently, numpy only support the type 7 of Hyndman & Fan and I did the 
implementation for the 8 other methods to do as much as R ::quantile. 

As you may guess, I was inspired by R implementation as well as other sources, 
which lead to my questions: 

About fuzz (see first reference below for the source code), 
fuzz <- 4 * .Machine $ double.eps 
I think I understand why the machine epsilon is used to correct some edge cases 
where the float comparisons would fail. 
However I don't get why epsilon is multiplied by 4 instead of simply using 
epsilon. 
Is there someone who can explain this 4 ? 

About licence, 
Numpy is under license BSD and R is on GPL. 
The only thing I really cherry picked and rewrote for numpy is the fuzz part. 
I'm quite new to open source development. We are wondering if doing this breaks 
the license GPL and if I can credit the original authors. 
Plus, I'm not quite sure this is the right place to ask this, if not, sorry for 
the noise. 
The relevant discussion on numpy PR is here: [ 
https://github.com/numpy/numpy/pull/19857#discussion_r706019184 | 
https://github.com/numpy/numpy/pull/19857#discussion_r706019184 ] 


Thank you for your time. 

Regards, 
Abel Aoun 


References: 
The source code for R::quantile (fuzz is at line 82) [ 
https://github.com/wch/r-source/blob/79298c499218846d14500255efd622b5021c10ec/src/library/stats/R/quantile.R
 | 
https://github.com/wch/r-source/blob/79298c499218846d14500255efd622b5021c10ec/src/library/stats/R/quantile.R
 ] [ https://github.com/numpy/numpy/pull/19857 ] 
R doc for quantile : [ 
https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile | 
https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile ] 
The ongoing PR on numpy: [ https://github.com/numpy/numpy/pull/19857 | 
https://github.com/numpy/numpy/pull/19857 ] 



[[alternative HTML version deleted]]

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

Re: [Rd] Question about R developpment

[Morgan]

Thank you all for these explanations.
Kind regards,
Morgan

On 11 Jun 2017 02:47, "Duncan Murdoch"  wrote:

> On 10/06/2017 6:09 PM, Duncan Murdoch wrote:
>
>> On 10/06/2017 2:38 PM, Morgan wrote:
>>
>>> Hi,
>>>
>>> I had a question that might not seem obvious to me.
>>>
>>> I was wondering why there was no patnership between microsoft the R core
>>> team and eventually other developpers to improve R in one unified version
>>> instead of having different teams developping their own version of R.
>>>
>>
>> As far as I know, there's only one version of R currently being
>> developed.  Microsoft doesn't offer anything different; they just offer
>> a build of a slightly older version of base R, and a few packages that
>> are not in the base version.
>>
>
> Actually, I think my first sentence above is wrong.  Besides the base R
> that the core R team works on, there are a few other implementations of the
> language:  pqR, for instance.  But as others have said, the Microsoft
> product is simply a repackaging of the core R, so my second sentence is
> right.
>
> Duncan Murdoch
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] Question about R developpment

[Duncan Murdoch]

On 10/06/2017 6:09 PM, Duncan Murdoch wrote:

On 10/06/2017 2:38 PM, Morgan wrote:

Hi,

I had a question that might not seem obvious to me.

I was wondering why there was no patnership between microsoft the R core
team and eventually other developpers to improve R in one unified version
instead of having different teams developping their own version of R.


As far as I know, there's only one version of R currently being
developed.  Microsoft doesn't offer anything different; they just offer
a build of a slightly older version of base R, and a few packages that
are not in the base version.


Actually, I think my first sentence above is wrong.  Besides the base R 
that the core R team works on, there are a few other implementations of 
the language:  pqR, for instance.  But as others have said, the 
Microsoft product is simply a repackaging of the core R, so my second 
sentence is right.


Duncan Murdoch

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

Re: [Rd] Question about R developpment

[Andrie de Vries]

Martyn and Duncan are both correct. 

I am on the Microsoft team that creates and distributes Microsoft R Open
(MRO).  We make absolutely no changes to R at all, just some enchancements
in the distribution.  As already pointed out:
* We add the Intel MKL to replace the built-in BLAS. This is similar to
replacing the BLAS with OpenBLAS or Atlas - readily available for Linux
distributions of R
* We make some changes in the RProfile.site file, notably pointing to an
MRAN snapshot, in turn a timestamped mirror of CRAN
* We add some package, e.g. foreach and iterators - all of these packages
are on CRAN.

In Microsoft R Client and Microsoft R Server we go further:
* We add proprietary packages that add scalability and connectivity to SQL
Server, Hadoop and other big data platforms
* But, again, the underlying R code remains unchanged.

In addition, Microsoft provides bug fixes and other enhancements to R
itself.

Microsoft remains committed to supporting both the R Foundation and the R
Consortium.

I hope this helps.

Andrie

(Andrie de Vries, Senior Programme Manager, Microsoft)
(You can also contact me at mailto:adevr...@microsoft.com)

-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Martyn
Plummer
Sent: 10 June 2017 16:06
To: Duncan Murdoch <murdoch.dun...@gmail.com>; Morgan
<2005.mor...@gmail.com>; r-devel@r-project.org
Subject: Re: [Rd] Question about R developpment

I would describe MRO as a distribution of R, in the same way that Fedora,
Debian, SUSE etc are distributions of Linux. It is not fundamentally
different from the version of R that you can download from CRAN but the
binary builds offer some specific features:

1) The binary build is linked to the Intel Math Kernel Library (MKL) which
may increase the speed of some matrix operations
2) Packages are downloaded from MRAN, Microsoft's time-stamped copy of CRAN.
This can help with reproducibility of analyses that rely on CRAN packages.

As far as I know, all of the additional packages that are bundled with MRO
are freely distributable and also available from CRAN. As Roy points out,
both Microsoft and the R Foundation are partners in the R Consortium. So we
do talk to each other as well as other stakeholders who participate in the
Consortium.

Martyn

From: R-devel <r-devel-boun...@r-project.org> on behalf of Duncan Murdoch
<murdoch.dun...@gmail.com>
Sent: 11 June 2017 00:09
To: Morgan; r-devel@r-project.org
Subject: Re: [Rd] Question about R developpment

On 10/06/2017 2:38 PM, Morgan wrote:
> Hi,
>
> I had a question that might not seem obvious to me.
>
> I was wondering why there was no patnership between microsoft the R 
> core team and eventually other developpers to improve R in one unified 
> version instead of having different teams developping their own version of
R.

As far as I know, there's only one version of R currently being developed.
Microsoft doesn't offer anything different; they just offer a build of a
slightly older version of base R, and a few packages that are not in the
base version.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
---
This message and its attachments are strictly confidenti...{{dropped:8}}

__
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] Question about R developpment

[Martyn Plummer]

I would describe MRO as a distribution of R, in the same way that Fedora, 
Debian, SUSE etc are distributions of Linux. It is not fundamentally different 
from the version of R that you can download from CRAN but the binary builds 
offer some specific features:

1) The binary build is linked to the Intel Math Kernel Library (MKL) which may 
increase the speed of some matrix operations
2) Packages are downloaded from MRAN, Microsoft's time-stamped copy of CRAN. 
This can help with reproducibility of analyses that rely on CRAN packages.

As far as I know, all of the additional packages that are bundled with MRO are 
freely distributable and also available from CRAN. As Roy points out, both 
Microsoft and the R Foundation are partners in the R Consortium. So we do talk 
to each other as well as other stakeholders who participate in the Consortium.

Martyn

From: R-devel <r-devel-boun...@r-project.org> on behalf of Duncan Murdoch 
<murdoch.dun...@gmail.com>
Sent: 11 June 2017 00:09
To: Morgan; r-devel@r-project.org
Subject: Re: [Rd] Question about R developpment

On 10/06/2017 2:38 PM, Morgan wrote:
> Hi,
>
> I had a question that might not seem obvious to me.
>
> I was wondering why there was no patnership between microsoft the R core
> team and eventually other developpers to improve R in one unified version
> instead of having different teams developping their own version of R.

As far as I know, there's only one version of R currently being
developed.  Microsoft doesn't offer anything different; they just offer
a build of a slightly older version of base R, and a few packages that
are not in the base version.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
---
This message and its attachments are strictly confidenti...{{dropped:8}}

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

Re: [Rd] Question about R developpment

[Duncan Murdoch]

On 10/06/2017 2:38 PM, Morgan wrote:

Hi,

I had a question that might not seem obvious to me.

I was wondering why there was no patnership between microsoft the R core
team and eventually other developpers to improve R in one unified version
instead of having different teams developping their own version of R.


As far as I know, there's only one version of R currently being 
developed.  Microsoft doesn't offer anything different; they just offer 
a build of a slightly older version of base R, and a few packages that 
are not in the base version.


Duncan Murdoch

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

Re: [Rd] Question about R developpment

[Roy Mendelssohn - NOAA Federal]

https://www.r-consortium.org

-Roy

> On Jun 10, 2017, at 11:38 AM, Morgan <2005.mor...@gmail.com> wrote:
> 
> Hi,
> 
> I had a question that might not seem obvious to me.
> 
> I was wondering why there was no patnership between microsoft the R core
> team and eventually other developpers to improve R in one unified version
> instead of having different teams developping their own version of R.
> 
> Is it because they don't want to team up? Is it because you don't want? Any
> particular reasons? Different philosophies?
> 
> Thank you
> Kind regards
> Morgan
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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

[Rd] Question about R developpment

[Morgan]

Hi,

I had a question that might not seem obvious to me.

I was wondering why there was no patnership between microsoft the R core
team and eventually other developpers to improve R in one unified version
instead of having different teams developping their own version of R.

Is it because they don't want to team up? Is it because you don't want? Any
particular reasons? Different philosophies?

Thank you
Kind regards
Morgan

[[alternative HTML version deleted]]

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

[Rd] Question about CHARSXP and garbage collection

[Holger Hoefling]

Hi,

I had a technical question about CHARSXP and garbage collection and
couldn't find the answer in the R manual.

The question is this. Are CHARSXP garbage collected like any other object,
despite being part of the CHARSXP cache? i.e. is the cache being cleaned by
garbage collection regularly and therefore, when I am in C code, do I need
to protect a CHARSXP?

Thanks!

Holger

[[alternative HTML version deleted]]

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

Re: [Rd] Question about CHARSXP and garbage collection

[luke-tierney]

They are garbage collected so you do need to protect them in C code.

Best,

luke

On Sat, 13 Feb 2016, Holger Hoefling wrote:


Hi,

I had a technical question about CHARSXP and garbage collection and
couldn't find the answer in the R manual.

The question is this. Are CHARSXP garbage collected like any other object,
despite being part of the CHARSXP cache? i.e. is the cache being cleaned by
garbage collection regularly and therefore, when I am in C code, do I need
to protect a CHARSXP?

Thanks!

Holger

[[alternative HTML version deleted]]

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

Re: [Rd] Question about bug reporting, and the followup process

[Michael Felt]

On 2015-12-16 16:40, Duncan Murdoch wrote:
We generally ignore it, so your current practice is fine.  The problem 
is that none of the core developers use AIX, so it's unlikely anyone 
will be able to test and fix your problems.  You'll need to find an 
AIX expert, or fix them yourself.


Duncan Murdoch 

I have answered this twice, but still do not see it.

A) I am an AIX expert, not an R expert. I am willing to assist, 
longish-term for matters re: R on AIX.


B) If I fix something (e.g., the suggestions in the bug-reports, in 
particular for configure.ac related "stuff" - how do I submit a patch? 
(Did not find anything suitable in R-forge.)


C) Bug 16633 - https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16633 
is all platforms, not just AIX. And I am not attempting to fix it on my 
own, because there is an architectural element involved (namely, does 
the library, or libR own the symbol.


Thanks,
Michael

p.s. Duncan, maybe my previous replies were to you only - my mistake and 
please forgive the double emails.


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

Re: [Rd] Question about bug reporting, and the followup process

[Duncan Murdoch]

On 16/12/2015 12:31 AM, Michael Felt wrote:

Hi,

I sent in three bug-reports (maybe should have been 4, because the
second contains an "enhancement" as well as well as a bug).

I do not set "Importance", ever - or, is that the custom here?


We generally ignore it, so your current practice is fine.  The problem 
is that none of the core developers use AIX, so it's unlikely anyone 
will be able to test and fix your problems.  You'll need to find an AIX 
expert, or fix them yourself.


Duncan Murdoch



Regards,
Michael

p.s. - maybe related - is it best practice to add [Rd] in the subject
line, or is there a program doing that instead?

__
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

[Rd] Question about bug reporting, and the followup process

[Michael Felt]

Hi,

I sent in three bug-reports (maybe should have been 4, because the 
second contains an "enhancement" as well as well as a bug).


I do not set "Importance", ever - or, is that the custom here?

Regards,
Michael

p.s. - maybe related - is it best practice to add [Rd] in the subject 
line, or is there a program doing that instead?


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

[Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL)

[Kurt Schallitz]

Hello,

Can anyone tell me if there is a package which will allow me to write a
package in R, then publish the package using WebServices? The idea is that
I want to be able to pass a data set into R, have R perform the
calculations, then send the result back to either a .Net application or a
LIMS BASIC application.

So far I see many packages that allow R to consume WebServices, but I
haven't seen anything that allows you to publish a package as a WebService.
One company advertised a product for WebServices, but they are not using
the term in an industry standardized way - they are using it to mean, I
can publish my R results on the web and access them from the web. This is
NOT what we are looking for. We want to use true Web Services using SOAP
and WSDL.

Any help would be much appreciated.

-- 
Kurt Schallitz
Sr. Software Developer [LIMS]
FPPQI
Genentech
(650)-467-7304

[[alternative HTML version deleted]]

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

Re: [Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL)

[Dirk Eddelbuettel]

On 22 July 2014 at 07:21, Kurt Schallitz wrote:
| Can anyone tell me if there is a package which will allow me to write a
| package in R, then publish the package using WebServices? The idea is that
| I want to be able to pass a data set into R, have R perform the
| calculations, then send the result back to either a .Net application or a
| LIMS BASIC application.
| 
| So far I see many packages that allow R to consume WebServices, but I
| haven't seen anything that allows you to publish a package as a WebService.
| One company advertised a product for WebServices, but they are not using
| the term in an industry standardized way - they are using it to mean, I
| can publish my R results on the web and access them from the web. This is
| NOT what we are looking for. We want to use true Web Services using SOAP
| and WSDL.

You probably want to look into Jeroen's very capable OpenCPU project:

https://www.opencpu.org/

which does all that, and more, out of the box.

Just doing SOAP etc is a pretty old idea some folks played with a decade+
ago, and Duncan Temple-Lang had some packages in that area too. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL)

[Tobias Verbeke]

Hi Kurt, 

The R Service Bus was made to do this.

http://rsb.doc.openanalytics.eu/dev/
http://rsb.doc.openanalytics.eu/dev/wsdocs/index.html

Running in production at multiple big pharma companies since 2010.

Open source and freely available.

Best,
Tobias

- Original Message -
 From: Kurt Schallitz schallitz.k...@gene.com
 To: r-devel@r-project.org
 Sent: Tuesday, July 22, 2014 4:21:09 PM
 Subject: [Rd] Question: Publishing R/S objects with WebServices (SOAP/WSDL)
 
 Hello,
 
 Can anyone tell me if there is a package which will allow me to write a
 package in R, then publish the package using WebServices? The idea is that
 I want to be able to pass a data set into R, have R perform the
 calculations, then send the result back to either a .Net application or a
 LIMS BASIC application.
 
 So far I see many packages that allow R to consume WebServices, but I
 haven't seen anything that allows you to publish a package as a WebService.
 One company advertised a product for WebServices, but they are not using
 the term in an industry standardized way - they are using it to mean, I
 can publish my R results on the web and access them from the web. This is
 NOT what we are looking for. We want to use true Web Services using SOAP
 and WSDL.
 
 Any help would be much appreciated.
 
 --
 Kurt Schallitz
 Sr. Software Developer [LIMS]
 FPPQI
 Genentech
 (650)-467-7304
 
   [[alternative HTML version deleted]]
 
 __
 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] Question: Publishing R/S objects with WebServices (SOAP/WSDL)

[Geoff Jentry]

So far I see many packages that allow R to consume WebServices, but I
haven't seen anything that allows you to publish a package as a WebService.


If you haven't already, look at the RWebServices package from 
Bioconductor.


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

[Rd] Question on Code snippet semantics

[Mick Jordan]

I came across this code in library.R

package - as.character(substitute(package))

where package is the first argument to the library function.

I've been racking my brains to understand why this is not just an 
elaborate (and ineffcient) way to write:


package - package

E.g.

 package - as.character(substitute(package))
 package
[1] package


Thanks
Mick Jordan

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

Re: [Rd] Question on Code snippet semantics

[Marc Schwartz]

On Jul 21, 2014, at 10:07 AM, Mick Jordan mick.jor...@oracle.com wrote:

 I came across this code in library.R
 
 package - as.character(substitute(package))
 
 where package is the first argument to the library function.
 
 I've been racking my brains to understand why this is not just an elaborate 
 (and ineffcient) way to write:
 
 package - package
 
 E.g.
 
  package - as.character(substitute(package))
  package
 [1] package
 
 
 Thanks
 Mick Jordan


Frequently used in a function body, where the function author wants the 
argument to be passed as an object name, rather than a character vector, or 
perhaps both, as is the case with library() and require().

For example:

test - function(x) {as.character(substitute(x))}

# Quoted, passing MyPackage as a character vector
 test(MyPackage)
[1] MyPackage


# Not quoted, passing the object MyPackage
 test(MyPackage)
[1] MyPackage


In both cases, the argument passed as 'x' can then be used within the function 
as a character vector, rather than as the object itself.

Regards,

Marc Schwartz

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

Re: [Rd] Question on Code snippet semantics

[William Dunlap]

subsitute(expr), with only one argument, is only useful inside of a
function and then only when the expression, expr, involves an argument
to the function.  Then the unevaluated actual arguments to the
function are substituted into the [unevaluated] expression.

E.g.,
   f - function(x, y=stop(y is required), z=log(-1)) {
  substitute(y + z)
   }
   f(1)
   # stop(y is required) + log(-1)
   f(1,sqrt(-1),log(1:10))
   # sqrt(-1) + log(1:10)

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Jul 21, 2014 at 8:07 AM, Mick Jordan mick.jor...@oracle.com wrote:
 I came across this code in library.R

 package - as.character(substitute(package))

 where package is the first argument to the library function.

 I've been racking my brains to understand why this is not just an elaborate
 (and ineffcient) way to write:

 package - package

 E.g.

 package - as.character(substitute(package))
 package
 [1] package


 Thanks
 Mick Jordan

 __
 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

[Rd] Question about fifo behavior on Linux between versions 3.0.3 and 3.1.0

[James Smith]

Version 3.1.0 of R has imposed a very small data limit on writing to fifos on 
Linux. Consider the following R code (Assumes that ff is a fifo in the R 
process's current directory):

con - fifo(ff, a+b)
writeBin(raw(12501), con)

In R 3.0.3, this returns without error and the data is available on the fifo. 
In R 3.1.0, however, this returns the following error:

Error in writeBin(raw(12501), con) : too large a block specified

In investigating R's source, the difference seems to be in 
src/main/connections.c, in the function fifo_write() (around line 932). In R 
3.0.3, fifo_write() has these lines:

if ((double) size * (double) nitems  SSIZE_MAX)
error(_(too large a block specified));

R 3.1.0 has these lines changed to this:

if ((size * sizeof(wchar_t) * nitems)  5) {
  error(_(too large a block specified));
}

The change effectively places a limit of 12500 bytes on writes (since 
sizeof(wchar_t) == 4). Does anyone know why this change was made? I understand 
that fifos on Windows were implemented for R 3.1.0, but the code for fifos on 
Windows is in a separate part of connections.c that doesn't get compiled on 
Linux (i.e., the code given is Unix only). I also couldn't find any references 
to fifo behavior changes under Linux in any of R's documentation.

My platform is Fedora 20 (64-bit) and I have built and installed R from source.

Thank you for your time and consideration.

James O Smith
Harmonia Holdings Group, LLC

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

Re: [Rd] Question about fifo behavior on Linux between versions 3.0.3 and 3.1.0

[Prof Brian Ripley]

It _was_ part of the fifo for Windows patch.  As if does not seem to be 
needed for Windows, it has been reverted.



On 20/05/2014 16:02, James Smith wrote:

Version 3.1.0 of R has imposed a very small data limit on writing to fifos on Linux. 
Consider the following R code (Assumes that ff is a fifo in the R process's 
current directory):

con - fifo(ff, a+b)
writeBin(raw(12501), con)

In R 3.0.3, this returns without error and the data is available on the fifo. 
In R 3.1.0, however, this returns the following error:

Error in writeBin(raw(12501), con) : too large a block specified

In investigating R's source, the difference seems to be in 
src/main/connections.c, in the function fifo_write() (around line 932). In R 
3.0.3, fifo_write() has these lines:

 if ((double) size * (double) nitems  SSIZE_MAX)
error(_(too large a block specified));

R 3.1.0 has these lines changed to this:

 if ((size * sizeof(wchar_t) * nitems)  5) {
   error(_(too large a block specified));
 }

The change effectively places a limit of 12500 bytes on writes (since 
sizeof(wchar_t) == 4). Does anyone know why this change was made? I understand 
that fifos on Windows were implemented for R 3.1.0, but the code for fifos on 
Windows is in a separate part of connections.c that doesn't get compiled on 
Linux (i.e., the code given is Unix only). I also couldn't find any references 
to fifo behavior changes under Linux in any of R's documentation.

My platform is Fedora 20 (64-bit) and I have built and installed R from source.

Thank you for your time and consideration.

James O Smith
Harmonia Holdings Group, LLC

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

[Rd] question about code signing

[Ivan Zaigralin]

Greetings!

I maintain R SlackBuild for Slackware and derivatives, and it would make me
sleep easier if I could verify gpg signatures of the sources I refer to.
Is there any way to get the source signed with gpg, by any chance, preferably
in tarball form?



signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] question regarding lang2 command in C

[Romain François]

Hi, 

This is easy if the gender and age are already vectors of some sort of the same 
size. 

SEXP df = PROTECT(allocVector(VECSXP, 2)); 
SET_VECTOR_ELT(df,0,gender) ;
SET_VECTOR_ELT(df,1,age) ;
SEXP names = PROTECT(allocVector(STRSXP,2));
SET_STRING_ELT(names,0,mkChar(age))
SET_STRING_ELT(names,0,mkChar(gender))
setAttrib(df, R_NamesSymbol, names );
setAttrib(df, R_ClassSymbol, mkString(data.frame));
SEXP rn = PROTECT(allocVector(INTSXP,2)); 
INTEGER(rn)[0] = NA_INTEGER ;
INTEGER(rn)[1] = -length(gender);
setAttrib(df, R_RowNamesSymbol, rn) ;
UNPROTECT(3) ;
return df ;

If you really want to call back to R and make a call as you did before, you can 
do something like this: 

  SEXP call = PROTECT(lang4(install(data.frame), age, gender, 
ScalarLogical(FALSE))) ;
  SET_TAG(CDR(call), install(age)) ;
  SET_TAG(CDDR(call), install(gender)) ;
  SET_TAG(CDR(CDDR(call)), install(stringsAsFactors)) ;
  SEXP df = PROTECT(eval(call, R_GlobalEnv)) ;
  UNPROTECT(2) ;
  return df ;

Or you can use Rcpp: 

  DataFrame df = DataFrame::create(
_[age] = age, _[gender] = gender, _[stringsAsFactors] = FALSE
  ) ;

Romain

Le 3 avr. 2014 à 07:40, Sandip Nandi sanna...@umail.iu.edu a écrit :

 Hi ,
 
 I am asking too many questions , sorry for that .  I am creating a data
 frame in C itself , reading a table .
 
 The data frame calling code looks like this
 ==
 
 *PROTECT(dfm=lang2(install(data.frame),df));*
 *SEXP res = PROTECT(eval(dfm,R_GlobalEnv));*
 
 UNPROTECT(2);
 return res;
 ==
 
 It works fine , now the problem is I want to do the below one  from C
 itself  ( adding the *stringsAsFactors = FALSE* parameter)
 
 df - data.frame(gender, age, *stringsAsFactors = FALSE*);
 
 How can I do it from C , adding extra parameters. Anyone has pointer or any
 example . It will be great help. I find the arguments will always be in
 pair , i don't find any example.
 
 
 I try to see the source code ,not able to make it
 
 Thanks

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

[Rd] question regarding lang2 command in C

[Sandip Nandi]

Hi ,

I am asking too many questions , sorry for that .  I am creating a data
frame in C itself , reading a table .

The data frame calling code looks like this
==

*PROTECT(dfm=lang2(install(data.frame),df));*
*SEXP res = PROTECT(eval(dfm,R_GlobalEnv));*

UNPROTECT(2);
return res;
==

It works fine , now the problem is I want to do the below one  from C
itself  ( adding the *stringsAsFactors = FALSE* parameter)

df - data.frame(gender, age, *stringsAsFactors = FALSE*);

How can I do it from C , adding extra parameters. Anyone has pointer or any
example . It will be great help. I find the arguments will always be in
pair , i don't find any example.


I try to see the source code ,not able to make it

Thanks

[[alternative HTML version deleted]]

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

Re: [Rd] Question re: NA, NaNs in R

[Tim Hesterberg]

This isn't quite what you were asking, but might inform your choice.

R doesn't try to maintain the distinction between NA and NaN when
doing calculations, e.g.:
 NA + NaN
[1] NA
 NaN + NA
[1] NaN
So for the aggregate package, I didn't attempt to treat them differently.

The aggregate package is available at
http://www.timhesterberg.net/r-packages

Here is the inst/doc/missingValues.txt file from that package:

--
Copyright 2012 Google Inc. All Rights Reserved.
Author: Tim Hesterberg roc...@google.com
Distributed under GPL 2 or later.


Handling of missing values and not-a-numbers.


Here I'll note how this package handles missing values.
I do it the way R handles them, rather than the more strict way that S+ does.

First, for terminology,
  NaN = not-a-number, e.g. the result of 0/0
  NA  = missing value or true missing value, e.g. survey non-response
  xx  = I'll uses this for the union of those, or missing value of any kind.

For background, at the hardware level there is an IEEE standard that
specifies that certain bit patterns are NaN, and specifies that
operations involving an NaN result in another NaN.

That standard doesn't say anything about missing values, which are
important in statistics.

So what R and S+ do is to pick one of the bit patterns and declare
that to be a NA.  In other words, the NA bit pattern is a subset of
the NaN bit patterns.

At the user level, the reverse seems to hold.
You can assign either NA or NaN to an object.
But:
is.na(x) returns TRUE for both
is.nan(x) returns TRUE for NaN and FALSE for NA
Based on that, you'd think that NaN is a subset of NA.
To tell whether something is a true missing value do:
(is.na(x)  !is.nan(x))

The S+ convention is that any operation involving NA results in an NA;
otherwise any operation involving NaN results in NaN.

The R convention is that any operation involving xx results in an xx;
a missing value of any kind results in another missing value of any
kind.  R considers NA and NaN equivalent for testing purposes:
all.equal(NA_real_, NaN)
gives TRUE.

Some R functions follow the S+ convention, e.g. the Math2 functions
in src/main/arithmetic.c use this macro:
#define if_NA_Math2_set(y,a,b)  \
if  (ISNA (a) || ISNA (b)) y = NA_REAL; \
else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

Other R functions, like the basic arithmetic operations +-/*^,
do not (search for PLUSOP in src/main/arithmetic.c).
They just let the hardware do the calculations.
As a result, you can get odd results like
 is.nan(NA_real_ + NaN)
[1] FALSE
 is.nan(NaN + NA_real_)
[1] TRUE

The R help files help(is.na) and help(is.nan) suggest that
computations involving NA and NaN are indeterminate.

It is faster to use the R convention; most operations are just
handled by the hardware, without extra work.

In cases like sum(x, na.rm=TRUE), the help file specifies that both NA
and NaN are removed.




There is one NA but mulitple NaNs.

And please re-read 'man memcmp': your cast is wrong.

On 10/02/2014 06:52, Kevin Ushey wrote:
 Hi R-devel,

 I have a question about the differentiation between NA and NaN values
 as implemented in R. In arithmetic.c, we have

 int R_IsNA(double x)
 {
  if (isnan(x)) {
 ieee_double y;
 y.value = x;
 return (y.word[lw] == 1954);
  }
  return 0;
 }

 ieee_double is just used for type punning so we can check the final
 bits and see if they're equal to 1954; if they are, x is NA, if
 they're not, x is NaN (as defined for R_IsNaN).

 My question is -- I can see a substantial increase in speed (on my
 computer, in certain cases) if I replace this check with

 int R_IsNA(double x)
 {
  return memcmp(
  (char*)(x),
  (char*)(NA_REAL),
  sizeof(double)
  ) == 0;
 }

 IIUC, there is only one bit pattern used to encode R NA values, so
 this should be safe. But I would like to be sure:

 Is there any guarantee that the different functions in R would return
 NA as identical to the bit pattern defined for NA_REAL, for a given
 architecture? Similarly for NaN value(s) and R_NaN?

 My guess is that it is possible some functions used internally by R
 might encode NaN values differently; ie, setting the lower word to a
 value different than 1954 (hence being NaN, but potentially not
 identical to R_NaN), or perhaps this is architecture-dependent.
 However, NA should be one specific bit pattern (?). And, I wonder if
 there is any guarantee that the different functions used in R would
 return an NaN value as identical to R_NaN (which appears to be the
 'IEEE NaN')?

 (interested parties can see + run a simple benchmark from the gist at
 https://gist.github.com/kevinushey/8911432)

 Thanks,
 Kevin

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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor 

Re: [Rd] Question re: NA, NaNs in R

[Kevin Ushey]

Thanks Tim, this is exactly the explanation I was hoping to see. Much
appreciated!

On Mon, Feb 10, 2014 at 7:21 AM, Tim Hesterberg timhesterb...@gmail.com wrote:
 This isn't quite what you were asking, but might inform your choice.

 R doesn't try to maintain the distinction between NA and NaN when
 doing calculations, e.g.:
 NA + NaN
 [1] NA
 NaN + NA
 [1] NaN
 So for the aggregate package, I didn't attempt to treat them differently.

 The aggregate package is available at
 http://www.timhesterberg.net/r-packages

 Here is the inst/doc/missingValues.txt file from that package:

 --
 Copyright 2012 Google Inc. All Rights Reserved.
 Author: Tim Hesterberg roc...@google.com
 Distributed under GPL 2 or later.


 Handling of missing values and not-a-numbers.


 Here I'll note how this package handles missing values.
 I do it the way R handles them, rather than the more strict way that S+ does.

 First, for terminology,
   NaN = not-a-number, e.g. the result of 0/0
   NA  = missing value or true missing value, e.g. survey non-response
   xx  = I'll uses this for the union of those, or missing value of any kind.

 For background, at the hardware level there is an IEEE standard that
 specifies that certain bit patterns are NaN, and specifies that
 operations involving an NaN result in another NaN.

 That standard doesn't say anything about missing values, which are
 important in statistics.

 So what R and S+ do is to pick one of the bit patterns and declare
 that to be a NA.  In other words, the NA bit pattern is a subset of
 the NaN bit patterns.

 At the user level, the reverse seems to hold.
 You can assign either NA or NaN to an object.
 But:
 is.na(x) returns TRUE for both
 is.nan(x) returns TRUE for NaN and FALSE for NA
 Based on that, you'd think that NaN is a subset of NA.
 To tell whether something is a true missing value do:
 (is.na(x)  !is.nan(x))

 The S+ convention is that any operation involving NA results in an NA;
 otherwise any operation involving NaN results in NaN.

 The R convention is that any operation involving xx results in an xx;
 a missing value of any kind results in another missing value of any
 kind.  R considers NA and NaN equivalent for testing purposes:
 all.equal(NA_real_, NaN)
 gives TRUE.

 Some R functions follow the S+ convention, e.g. the Math2 functions
 in src/main/arithmetic.c use this macro:
 #define if_NA_Math2_set(y,a,b)  \
 if  (ISNA (a) || ISNA (b)) y = NA_REAL; \
 else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

 Other R functions, like the basic arithmetic operations +-/*^,
 do not (search for PLUSOP in src/main/arithmetic.c).
 They just let the hardware do the calculations.
 As a result, you can get odd results like
 is.nan(NA_real_ + NaN)
 [1] FALSE
 is.nan(NaN + NA_real_)
 [1] TRUE

 The R help files help(is.na) and help(is.nan) suggest that
 computations involving NA and NaN are indeterminate.

 It is faster to use the R convention; most operations are just
 handled by the hardware, without extra work.

 In cases like sum(x, na.rm=TRUE), the help file specifies that both NA
 and NaN are removed.




There is one NA but mulitple NaNs.

And please re-read 'man memcmp': your cast is wrong.

On 10/02/2014 06:52, Kevin Ushey wrote:
 Hi R-devel,

 I have a question about the differentiation between NA and NaN values
 as implemented in R. In arithmetic.c, we have

 int R_IsNA(double x)
 {
  if (isnan(x)) {
 ieee_double y;
 y.value = x;
 return (y.word[lw] == 1954);
  }
  return 0;
 }

 ieee_double is just used for type punning so we can check the final
 bits and see if they're equal to 1954; if they are, x is NA, if
 they're not, x is NaN (as defined for R_IsNaN).

 My question is -- I can see a substantial increase in speed (on my
 computer, in certain cases) if I replace this check with

 int R_IsNA(double x)
 {
  return memcmp(
  (char*)(x),
  (char*)(NA_REAL),
  sizeof(double)
  ) == 0;
 }

 IIUC, there is only one bit pattern used to encode R NA values, so
 this should be safe. But I would like to be sure:

 Is there any guarantee that the different functions in R would return
 NA as identical to the bit pattern defined for NA_REAL, for a given
 architecture? Similarly for NaN value(s) and R_NaN?

 My guess is that it is possible some functions used internally by R
 might encode NaN values differently; ie, setting the lower word to a
 value different than 1954 (hence being NaN, but potentially not
 identical to R_NaN), or perhaps this is architecture-dependent.
 However, NA should be one specific bit pattern (?). And, I wonder if
 there is any guarantee that the different functions used in R would
 return an NaN value as identical to R_NaN (which appears to be the
 'IEEE NaN')?

 (interested parties can see + run a simple benchmark from the gist at
 

Re: [Rd] Question re: NA, NaNs in R

[Duncan Murdoch]

On 10/02/2014 10:21 AM, Tim Hesterberg wrote:

This isn't quite what you were asking, but might inform your choice.

R doesn't try to maintain the distinction between NA and NaN when
doing calculations, e.g.:
 NA + NaN
[1] NA
 NaN + NA
[1] NaN
So for the aggregate package, I didn't attempt to treat them differently.


This looks like a bug to me.  In 32 bit 3.0.2 and R-patched I see

 NA + NaN
[1] NA
 NaN + NA
[1] NA

This seems more reasonable to me.  NA should propagate.  (I can see an 
argument for NaN for the answer here, as I can't think of any possible 
non-missing value that would give anything else when added to NaN, but 
the answer should not depend on the order of operands.)


However, I get the same as you in 64 bit 3.0.2.  All calculations I've 
shown are on 64 bit Windows 7.


Duncan Murdoch




The aggregate package is available at
http://www.timhesterberg.net/r-packages

Here is the inst/doc/missingValues.txt file from that package:

--
Copyright 2012 Google Inc. All Rights Reserved.
Author: Tim Hesterberg roc...@google.com
Distributed under GPL 2 or later.


Handling of missing values and not-a-numbers.


Here I'll note how this package handles missing values.
I do it the way R handles them, rather than the more strict way that S+ does.

First, for terminology,
   NaN = not-a-number, e.g. the result of 0/0
   NA  = missing value or true missing value, e.g. survey non-response
   xx  = I'll uses this for the union of those, or missing value of any kind.

For background, at the hardware level there is an IEEE standard that
specifies that certain bit patterns are NaN, and specifies that
operations involving an NaN result in another NaN.

That standard doesn't say anything about missing values, which are
important in statistics.

So what R and S+ do is to pick one of the bit patterns and declare
that to be a NA.  In other words, the NA bit pattern is a subset of
the NaN bit patterns.

At the user level, the reverse seems to hold.
You can assign either NA or NaN to an object.
But:
is.na(x) returns TRUE for both
is.nan(x) returns TRUE for NaN and FALSE for NA
Based on that, you'd think that NaN is a subset of NA.
To tell whether something is a true missing value do:
(is.na(x)  !is.nan(x))

The S+ convention is that any operation involving NA results in an NA;
otherwise any operation involving NaN results in NaN.

The R convention is that any operation involving xx results in an xx;
a missing value of any kind results in another missing value of any
kind.  R considers NA and NaN equivalent for testing purposes:
all.equal(NA_real_, NaN)
gives TRUE.

Some R functions follow the S+ convention, e.g. the Math2 functions
in src/main/arithmetic.c use this macro:
#define if_NA_Math2_set(y,a,b)  \
if  (ISNA (a) || ISNA (b)) y = NA_REAL; \
else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

Other R functions, like the basic arithmetic operations +-/*^,
do not (search for PLUSOP in src/main/arithmetic.c).
They just let the hardware do the calculations.
As a result, you can get odd results like
 is.nan(NA_real_ + NaN)
[1] FALSE
 is.nan(NaN + NA_real_)
[1] TRUE

The R help files help(is.na) and help(is.nan) suggest that
computations involving NA and NaN are indeterminate.

It is faster to use the R convention; most operations are just
handled by the hardware, without extra work.

In cases like sum(x, na.rm=TRUE), the help file specifies that both NA
and NaN are removed.




There is one NA but mulitple NaNs.

And please re-read 'man memcmp': your cast is wrong.

On 10/02/2014 06:52, Kevin Ushey wrote:
 Hi R-devel,

 I have a question about the differentiation between NA and NaN values
 as implemented in R. In arithmetic.c, we have

 int R_IsNA(double x)
 {
  if (isnan(x)) {
 ieee_double y;
 y.value = x;
 return (y.word[lw] == 1954);
  }
  return 0;
 }

 ieee_double is just used for type punning so we can check the final
 bits and see if they're equal to 1954; if they are, x is NA, if
 they're not, x is NaN (as defined for R_IsNaN).

 My question is -- I can see a substantial increase in speed (on my
 computer, in certain cases) if I replace this check with

 int R_IsNA(double x)
 {
  return memcmp(
  (char*)(x),
  (char*)(NA_REAL),
  sizeof(double)
  ) == 0;
 }

 IIUC, there is only one bit pattern used to encode R NA values, so
 this should be safe. But I would like to be sure:

 Is there any guarantee that the different functions in R would return
 NA as identical to the bit pattern defined for NA_REAL, for a given
 architecture? Similarly for NaN value(s) and R_NaN?

 My guess is that it is possible some functions used internally by R
 might encode NaN values differently; ie, setting the lower word to a
 value different than 1954 (hence being NaN, but potentially not
 identical to R_NaN), or perhaps this is architecture-dependent.
 

Re: [Rd] Question re: NA, NaNs in R

[Kevin Ushey]

Also, similarly, to clarify, should there be _one_ unique bit pattern
for R's NA_REAL, or two? Because I see (for a function hex that
produces the hex representation of a number):

 hex(NA_real_)
[1] 7FF007A2
 hex(NA_real_+1)
[1] 7FF807A2
 hex(NaN)
[1] 7FF8

This is with 64-bit R (on OS X Mavericks, R-devel r64910), as well. I
also noticed in a conversation of Arun (co-author of data.table) that:

On 32-bit R-2.15.3:

NA: 7ff807a2
NaN: 7ff8

On 64-bit version of R-2.15.3
NA: 7ff007a2
NaN: 7ff8

Notice that the initial bit pattern is 7ff0, rather than 7ff8, for
64-bit R. Is this intentional?

Thanks,
Kevin

(function follows:)

// assume size of double, unsigned long long is the same
SEXP hex(SEXP x) {

  // double is 8 bytes, each byte can be represented by 2 hex chars,
  // so need a str with 16+1 slots
  int n = sizeof(unsigned long long) * 2 + 1;

  unsigned long long *xx = (unsigned long long*) REAL(x);
  char buf[n];
  snprintf(buf, n, %016llX, *xx);
  SEXP output = PROTECT(allocVector(STRSXP, 1));
  SET_STRING_ELT(output, 0, mkChar(buf));
  UNPROTECT(1);
  return output;
}

On Mon, Feb 10, 2014 at 10:07 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 10/02/2014 10:21 AM, Tim Hesterberg wrote:

 This isn't quite what you were asking, but might inform your choice.

 R doesn't try to maintain the distinction between NA and NaN when
 doing calculations, e.g.:
  NA + NaN
 [1] NA
  NaN + NA
 [1] NaN
 So for the aggregate package, I didn't attempt to treat them differently.


 This looks like a bug to me.  In 32 bit 3.0.2 and R-patched I see


 NA + NaN
 [1] NA
 NaN + NA
 [1] NA

 This seems more reasonable to me.  NA should propagate.  (I can see an
 argument for NaN for the answer here, as I can't think of any possible
 non-missing value that would give anything else when added to NaN, but the
 answer should not depend on the order of operands.)

 However, I get the same as you in 64 bit 3.0.2.  All calculations I've shown
 are on 64 bit Windows 7.

 Duncan Murdoch




 The aggregate package is available at
 http://www.timhesterberg.net/r-packages

 Here is the inst/doc/missingValues.txt file from that package:

 --
 Copyright 2012 Google Inc. All Rights Reserved.
 Author: Tim Hesterberg roc...@google.com
 Distributed under GPL 2 or later.


 Handling of missing values and not-a-numbers.


 Here I'll note how this package handles missing values.
 I do it the way R handles them, rather than the more strict way that S+
 does.

 First, for terminology,
NaN = not-a-number, e.g. the result of 0/0
NA  = missing value or true missing value, e.g. survey non-response
xx  = I'll uses this for the union of those, or missing value of any
 kind.

 For background, at the hardware level there is an IEEE standard that
 specifies that certain bit patterns are NaN, and specifies that
 operations involving an NaN result in another NaN.

 That standard doesn't say anything about missing values, which are
 important in statistics.

 So what R and S+ do is to pick one of the bit patterns and declare
 that to be a NA.  In other words, the NA bit pattern is a subset of
 the NaN bit patterns.

 At the user level, the reverse seems to hold.
 You can assign either NA or NaN to an object.
 But:
 is.na(x) returns TRUE for both
 is.nan(x) returns TRUE for NaN and FALSE for NA
 Based on that, you'd think that NaN is a subset of NA.
 To tell whether something is a true missing value do:
 (is.na(x)  !is.nan(x))

 The S+ convention is that any operation involving NA results in an NA;
 otherwise any operation involving NaN results in NaN.

 The R convention is that any operation involving xx results in an xx;
 a missing value of any kind results in another missing value of any
 kind.  R considers NA and NaN equivalent for testing purposes:
 all.equal(NA_real_, NaN)
 gives TRUE.

 Some R functions follow the S+ convention, e.g. the Math2 functions
 in src/main/arithmetic.c use this macro:
 #define if_NA_Math2_set(y,a,b)  \
 if  (ISNA (a) || ISNA (b)) y = NA_REAL; \
 else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

 Other R functions, like the basic arithmetic operations +-/*^,
 do not (search for PLUSOP in src/main/arithmetic.c).
 They just let the hardware do the calculations.
 As a result, you can get odd results like
  is.nan(NA_real_ + NaN)
 [1] FALSE
  is.nan(NaN + NA_real_)
 [1] TRUE

 The R help files help(is.na) and help(is.nan) suggest that
 computations involving NA and NaN are indeterminate.

 It is faster to use the R convention; most operations are just
 handled by the hardware, without extra work.

 In cases like sum(x, na.rm=TRUE), the help file specifies that both NA
 and NaN are removed.




 There is one NA but mulitple NaNs.
 
 And please re-read 'man memcmp': your cast is wrong.
 
 On 10/02/2014 06:52, 

Re: [Rd] Question re: NA, NaNs in R

[Duncan Murdoch]

On 10/02/2014 1:43 PM, Kevin Ushey wrote:

Also, similarly, to clarify, should there be _one_ unique bit pattern
for R's NA_REAL, or two? Because I see (for a function hex that
produces the hex representation of a number):


I don't think the language definition defines bit patterns, it defines 
behaviour.  If both of those bit patterns behave correctly, then it's 
fine.  (I see the same patterns as you do in 64 bit R-patched, but only 
the 2nd in 32 bit R).


Now, perhaps we should define the bit pattern for NA_real_ to make the 
optimization you're looking into a bit easier; I don't know if that's 
trivial or hard.


Duncan Murdoch



 hex(NA_real_)
[1] 7FF007A2
 hex(NA_real_+1)
[1] 7FF807A2
 hex(NaN)
[1] 7FF8

This is with 64-bit R (on OS X Mavericks, R-devel r64910), as well. I
also noticed in a conversation of Arun (co-author of data.table) that:

On 32-bit R-2.15.3:

NA: 7ff807a2
NaN: 7ff8

On 64-bit version of R-2.15.3
NA: 7ff007a2
NaN: 7ff8

Notice that the initial bit pattern is 7ff0, rather than 7ff8, for
64-bit R. Is this intentional?

Thanks,
Kevin

(function follows:)

// assume size of double, unsigned long long is the same
SEXP hex(SEXP x) {

   // double is 8 bytes, each byte can be represented by 2 hex chars,
   // so need a str with 16+1 slots
   int n = sizeof(unsigned long long) * 2 + 1;

   unsigned long long *xx = (unsigned long long*) REAL(x);
   char buf[n];
   snprintf(buf, n, %016llX, *xx);
   SEXP output = PROTECT(allocVector(STRSXP, 1));
   SET_STRING_ELT(output, 0, mkChar(buf));
   UNPROTECT(1);
   return output;
}

On Mon, Feb 10, 2014 at 10:07 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 10/02/2014 10:21 AM, Tim Hesterberg wrote:

 This isn't quite what you were asking, but might inform your choice.

 R doesn't try to maintain the distinction between NA and NaN when
 doing calculations, e.g.:
  NA + NaN
 [1] NA
  NaN + NA
 [1] NaN
 So for the aggregate package, I didn't attempt to treat them differently.


 This looks like a bug to me.  In 32 bit 3.0.2 and R-patched I see


 NA + NaN
 [1] NA
 NaN + NA
 [1] NA

 This seems more reasonable to me.  NA should propagate.  (I can see an
 argument for NaN for the answer here, as I can't think of any possible
 non-missing value that would give anything else when added to NaN, but the
 answer should not depend on the order of operands.)

 However, I get the same as you in 64 bit 3.0.2.  All calculations I've shown
 are on 64 bit Windows 7.

 Duncan Murdoch




 The aggregate package is available at
 http://www.timhesterberg.net/r-packages

 Here is the inst/doc/missingValues.txt file from that package:

 --
 Copyright 2012 Google Inc. All Rights Reserved.
 Author: Tim Hesterberg roc...@google.com
 Distributed under GPL 2 or later.


 Handling of missing values and not-a-numbers.


 Here I'll note how this package handles missing values.
 I do it the way R handles them, rather than the more strict way that S+
 does.

 First, for terminology,
NaN = not-a-number, e.g. the result of 0/0
NA  = missing value or true missing value, e.g. survey non-response
xx  = I'll uses this for the union of those, or missing value of any
 kind.

 For background, at the hardware level there is an IEEE standard that
 specifies that certain bit patterns are NaN, and specifies that
 operations involving an NaN result in another NaN.

 That standard doesn't say anything about missing values, which are
 important in statistics.

 So what R and S+ do is to pick one of the bit patterns and declare
 that to be a NA.  In other words, the NA bit pattern is a subset of
 the NaN bit patterns.

 At the user level, the reverse seems to hold.
 You can assign either NA or NaN to an object.
 But:
 is.na(x) returns TRUE for both
 is.nan(x) returns TRUE for NaN and FALSE for NA
 Based on that, you'd think that NaN is a subset of NA.
 To tell whether something is a true missing value do:
 (is.na(x)  !is.nan(x))

 The S+ convention is that any operation involving NA results in an NA;
 otherwise any operation involving NaN results in NaN.

 The R convention is that any operation involving xx results in an xx;
 a missing value of any kind results in another missing value of any
 kind.  R considers NA and NaN equivalent for testing purposes:
 all.equal(NA_real_, NaN)
 gives TRUE.

 Some R functions follow the S+ convention, e.g. the Math2 functions
 in src/main/arithmetic.c use this macro:
 #define if_NA_Math2_set(y,a,b)  \
 if  (ISNA (a) || ISNA (b)) y = NA_REAL; \
 else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

 Other R functions, like the basic arithmetic operations +-/*^,
 do not (search for PLUSOP in src/main/arithmetic.c).
 They just let the hardware do the calculations.
 As a result, you can get odd results like
  is.nan(NA_real_ + NaN)
 [1] FALSE
  

Re: [Rd] Question re: NA, NaNs in R

[Duncan Murdoch]

On 10/02/2014 1:43 PM, Kevin Ushey wrote:

Also, similarly, to clarify, should there be _one_ unique bit pattern
for R's NA_REAL, or two? Because I see (for a function hex that
produces the hex representation of a number):

 hex(NA_real_)
[1] 7FF007A2
 hex(NA_real_+1)
[1] 7FF807A2
 hex(NaN)
[1] 7FF8

This is with 64-bit R (on OS X Mavericks, R-devel r64910), as well. I
also noticed in a conversation of Arun (co-author of data.table) that:


I've just taken a look at the IEEE Std 754-2008.  The encoding we use 
for NA is a signaling NaN.  The standard says that operations on 
signaling NaN values convert them to quiet NaN values, with the most 
significant bit of the mantissa set.  That's the difference between your 
first and second rows.


R doesn't do all this bit twiddling, it's done in hardware.  Perhaps we 
should have chosen a quiet NaN for NA from the beginning; they stay 
quiet when you do operations on them.  However, I think the choice of 
bit pattern was made before that behaviour was mandated, and a change 
now would be quite disruptive.


Similarly, the standard doesn't say which bit pattern propagates when 
you do binary operations on two NaNs.  That's why sometimes NA + NaN is 
NA, and sometimes NaN.


Duncan Murdoch





On 32-bit R-2.15.3:

NA: 7ff807a2
NaN: 7ff8

On 64-bit version of R-2.15.3
NA: 7ff007a2
NaN: 7ff8

Notice that the initial bit pattern is 7ff0, rather than 7ff8, for
64-bit R. Is this intentional?

Thanks,
Kevin

(function follows:)

// assume size of double, unsigned long long is the same
SEXP hex(SEXP x) {

   // double is 8 bytes, each byte can be represented by 2 hex chars,
   // so need a str with 16+1 slots
   int n = sizeof(unsigned long long) * 2 + 1;

   unsigned long long *xx = (unsigned long long*) REAL(x);
   char buf[n];
   snprintf(buf, n, %016llX, *xx);
   SEXP output = PROTECT(allocVector(STRSXP, 1));
   SET_STRING_ELT(output, 0, mkChar(buf));
   UNPROTECT(1);
   return output;
}

On Mon, Feb 10, 2014 at 10:07 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 10/02/2014 10:21 AM, Tim Hesterberg wrote:

 This isn't quite what you were asking, but might inform your choice.

 R doesn't try to maintain the distinction between NA and NaN when
 doing calculations, e.g.:
  NA + NaN
 [1] NA
  NaN + NA
 [1] NaN
 So for the aggregate package, I didn't attempt to treat them differently.


 This looks like a bug to me.  In 32 bit 3.0.2 and R-patched I see


 NA + NaN
 [1] NA
 NaN + NA
 [1] NA

 This seems more reasonable to me.  NA should propagate.  (I can see an
 argument for NaN for the answer here, as I can't think of any possible
 non-missing value that would give anything else when added to NaN, but the
 answer should not depend on the order of operands.)

 However, I get the same as you in 64 bit 3.0.2.  All calculations I've shown
 are on 64 bit Windows 7.

 Duncan Murdoch




 The aggregate package is available at
 http://www.timhesterberg.net/r-packages

 Here is the inst/doc/missingValues.txt file from that package:

 --
 Copyright 2012 Google Inc. All Rights Reserved.
 Author: Tim Hesterberg roc...@google.com
 Distributed under GPL 2 or later.


 Handling of missing values and not-a-numbers.


 Here I'll note how this package handles missing values.
 I do it the way R handles them, rather than the more strict way that S+
 does.

 First, for terminology,
NaN = not-a-number, e.g. the result of 0/0
NA  = missing value or true missing value, e.g. survey non-response
xx  = I'll uses this for the union of those, or missing value of any
 kind.

 For background, at the hardware level there is an IEEE standard that
 specifies that certain bit patterns are NaN, and specifies that
 operations involving an NaN result in another NaN.

 That standard doesn't say anything about missing values, which are
 important in statistics.

 So what R and S+ do is to pick one of the bit patterns and declare
 that to be a NA.  In other words, the NA bit pattern is a subset of
 the NaN bit patterns.

 At the user level, the reverse seems to hold.
 You can assign either NA or NaN to an object.
 But:
 is.na(x) returns TRUE for both
 is.nan(x) returns TRUE for NaN and FALSE for NA
 Based on that, you'd think that NaN is a subset of NA.
 To tell whether something is a true missing value do:
 (is.na(x)  !is.nan(x))

 The S+ convention is that any operation involving NA results in an NA;
 otherwise any operation involving NaN results in NaN.

 The R convention is that any operation involving xx results in an xx;
 a missing value of any kind results in another missing value of any
 kind.  R considers NA and NaN equivalent for testing purposes:
 all.equal(NA_real_, NaN)
 gives TRUE.

 Some R functions follow the S+ convention, e.g. the Math2 functions
 in src/main/arithmetic.c use this macro:
 #define 

Re: [Rd] Question re: NA, NaNs in R

[Rainer M Krug]

On 02/10/14, 19:07 , Duncan Murdoch wrote:
 On 10/02/2014 10:21 AM, Tim Hesterberg wrote:
 This isn't quite what you were asking, but might inform your choice.

 R doesn't try to maintain the distinction between NA and NaN when
 doing calculations, e.g.:
  NA + NaN
 [1] NA
  NaN + NA
 [1] NaN
 So for the aggregate package, I didn't attempt to treat them differently.
 
 This looks like a bug to me.  In 32 bit 3.0.2 and R-patched I see
 
 NA + NaN
 [1] NA
 NaN + NA
 [1] NA

But under 3.0.2 patched 64 bit on Maverick:

 version
   _
platform   x86_64-apple-darwin10.8.0
arch   x86_64
os darwin10.8.0
system x86_64, darwin10.8.0
status Patched
major  3
minor  0.2
year   2014
month  01
day07
svn rev64692
language   R
version.string R version 3.0.2 Patched (2014-01-07 r64692)
nickname   Frisbee Sailing
 NA+NaN
[1] NA
 NaN+NA
[1] NaN

 
 This seems more reasonable to me.  NA should propagate.  (I can see an
 argument for NaN for the answer here, as I can't think of any possible
 non-missing value that would give anything else when added to NaN, but
 the answer should not depend on the order of operands.)
 
 However, I get the same as you in 64 bit 3.0.2.  All calculations I've
 shown are on 64 bit Windows 7.
 
 Duncan Murdoch
 
 

 The aggregate package is available at
 http://www.timhesterberg.net/r-packages

 Here is the inst/doc/missingValues.txt file from that package:

 --
 Copyright 2012 Google Inc. All Rights Reserved.
 Author: Tim Hesterberg roc...@google.com
 Distributed under GPL 2 or later.


 Handling of missing values and not-a-numbers.


 Here I'll note how this package handles missing values.
 I do it the way R handles them, rather than the more strict way that
 S+ does.

 First, for terminology,
NaN = not-a-number, e.g. the result of 0/0
NA  = missing value or true missing value, e.g. survey
 non-response
xx  = I'll uses this for the union of those, or missing value of
 any kind.

 For background, at the hardware level there is an IEEE standard that
 specifies that certain bit patterns are NaN, and specifies that
 operations involving an NaN result in another NaN.

 That standard doesn't say anything about missing values, which are
 important in statistics.

 So what R and S+ do is to pick one of the bit patterns and declare
 that to be a NA.  In other words, the NA bit pattern is a subset of
 the NaN bit patterns.

 At the user level, the reverse seems to hold.
 You can assign either NA or NaN to an object.
 But:
 is.na(x) returns TRUE for both
 is.nan(x) returns TRUE for NaN and FALSE for NA
 Based on that, you'd think that NaN is a subset of NA.
 To tell whether something is a true missing value do:
 (is.na(x)  !is.nan(x))

 The S+ convention is that any operation involving NA results in an NA;
 otherwise any operation involving NaN results in NaN.

 The R convention is that any operation involving xx results in an xx;
 a missing value of any kind results in another missing value of any
 kind.  R considers NA and NaN equivalent for testing purposes:
 all.equal(NA_real_, NaN)
 gives TRUE.

 Some R functions follow the S+ convention, e.g. the Math2 functions
 in src/main/arithmetic.c use this macro:
 #define if_NA_Math2_set(y,a,b)\
 if  (ISNA (a) || ISNA (b)) y = NA_REAL;\
 else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

 Other R functions, like the basic arithmetic operations +-/*^,
 do not (search for PLUSOP in src/main/arithmetic.c).
 They just let the hardware do the calculations.
 As a result, you can get odd results like
  is.nan(NA_real_ + NaN)
 [1] FALSE
  is.nan(NaN + NA_real_)
 [1] TRUE

 The R help files help(is.na) and help(is.nan) suggest that
 computations involving NA and NaN are indeterminate.

 It is faster to use the R convention; most operations are just
 handled by the hardware, without extra work.

 In cases like sum(x, na.rm=TRUE), the help file specifies that both NA
 and NaN are removed.




 There is one NA but mulitple NaNs.
 
 And please re-read 'man memcmp': your cast is wrong.
 
 On 10/02/2014 06:52, Kevin Ushey wrote:
  Hi R-devel,
 
  I have a question about the differentiation between NA and NaN values
  as implemented in R. In arithmetic.c, we have
 
  int R_IsNA(double x)
  {
   if (isnan(x)) {
  ieee_double y;
  y.value = x;
  return (y.word[lw] == 1954);
   }
   return 0;
  }
 
  ieee_double is just used for type punning so we can check the final
  bits and see if they're equal to 1954; if they are, x is NA, if
  they're not, x is NaN (as defined for R_IsNaN).
 
  My question is -- I can see a substantial increase in speed (on my
  computer, in certain cases) if I replace this check with
 
  int R_IsNA(double x)
  {
   return memcmp(
   (char*)(x),
   (char*)(NA_REAL),
   sizeof(double)
   ) == 0;
  }
 

Re: [Rd] Question re: NA, NaNs in R

[Kevin Ushey]

Hi Duncan,

Thanks a ton -- I appreciate your taking the time to investigate this,
and especially even checking into the IEEE standard to clarify.

Cheers,
Kevin

On Mon, Feb 10, 2014 at 11:54 AM, Rainer M Krug rai...@krugs.de wrote:


 On 02/10/14, 19:07 , Duncan Murdoch wrote:
 On 10/02/2014 10:21 AM, Tim Hesterberg wrote:
 This isn't quite what you were asking, but might inform your choice.

 R doesn't try to maintain the distinction between NA and NaN when
 doing calculations, e.g.:
  NA + NaN
 [1] NA
  NaN + NA
 [1] NaN
 So for the aggregate package, I didn't attempt to treat them differently.

 This looks like a bug to me.  In 32 bit 3.0.2 and R-patched I see

 NA + NaN
 [1] NA
 NaN + NA
 [1] NA

 But under 3.0.2 patched 64 bit on Maverick:

 version
_
 platform   x86_64-apple-darwin10.8.0
 arch   x86_64
 os darwin10.8.0
 system x86_64, darwin10.8.0
 status Patched
 major  3
 minor  0.2
 year   2014
 month  01
 day07
 svn rev64692
 language   R
 version.string R version 3.0.2 Patched (2014-01-07 r64692)
 nickname   Frisbee Sailing
 NA+NaN
 [1] NA
 NaN+NA
 [1] NaN


 This seems more reasonable to me.  NA should propagate.  (I can see an
 argument for NaN for the answer here, as I can't think of any possible
 non-missing value that would give anything else when added to NaN, but
 the answer should not depend on the order of operands.)

 However, I get the same as you in 64 bit 3.0.2.  All calculations I've
 shown are on 64 bit Windows 7.

 Duncan Murdoch



 The aggregate package is available at
 http://www.timhesterberg.net/r-packages

 Here is the inst/doc/missingValues.txt file from that package:

 --
 Copyright 2012 Google Inc. All Rights Reserved.
 Author: Tim Hesterberg roc...@google.com
 Distributed under GPL 2 or later.


 Handling of missing values and not-a-numbers.


 Here I'll note how this package handles missing values.
 I do it the way R handles them, rather than the more strict way that
 S+ does.

 First, for terminology,
NaN = not-a-number, e.g. the result of 0/0
NA  = missing value or true missing value, e.g. survey
 non-response
xx  = I'll uses this for the union of those, or missing value of
 any kind.

 For background, at the hardware level there is an IEEE standard that
 specifies that certain bit patterns are NaN, and specifies that
 operations involving an NaN result in another NaN.

 That standard doesn't say anything about missing values, which are
 important in statistics.

 So what R and S+ do is to pick one of the bit patterns and declare
 that to be a NA.  In other words, the NA bit pattern is a subset of
 the NaN bit patterns.

 At the user level, the reverse seems to hold.
 You can assign either NA or NaN to an object.
 But:
 is.na(x) returns TRUE for both
 is.nan(x) returns TRUE for NaN and FALSE for NA
 Based on that, you'd think that NaN is a subset of NA.
 To tell whether something is a true missing value do:
 (is.na(x)  !is.nan(x))

 The S+ convention is that any operation involving NA results in an NA;
 otherwise any operation involving NaN results in NaN.

 The R convention is that any operation involving xx results in an xx;
 a missing value of any kind results in another missing value of any
 kind.  R considers NA and NaN equivalent for testing purposes:
 all.equal(NA_real_, NaN)
 gives TRUE.

 Some R functions follow the S+ convention, e.g. the Math2 functions
 in src/main/arithmetic.c use this macro:
 #define if_NA_Math2_set(y,a,b)\
 if  (ISNA (a) || ISNA (b)) y = NA_REAL;\
 else if (ISNAN(a) || ISNAN(b)) y = R_NaN;

 Other R functions, like the basic arithmetic operations +-/*^,
 do not (search for PLUSOP in src/main/arithmetic.c).
 They just let the hardware do the calculations.
 As a result, you can get odd results like
  is.nan(NA_real_ + NaN)
 [1] FALSE
  is.nan(NaN + NA_real_)
 [1] TRUE

 The R help files help(is.na) and help(is.nan) suggest that
 computations involving NA and NaN are indeterminate.

 It is faster to use the R convention; most operations are just
 handled by the hardware, without extra work.

 In cases like sum(x, na.rm=TRUE), the help file specifies that both NA
 and NaN are removed.




 There is one NA but mulitple NaNs.
 
 And please re-read 'man memcmp': your cast is wrong.
 
 On 10/02/2014 06:52, Kevin Ushey wrote:
  Hi R-devel,
 
  I have a question about the differentiation between NA and NaN values
  as implemented in R. In arithmetic.c, we have
 
  int R_IsNA(double x)
  {
   if (isnan(x)) {
  ieee_double y;
  y.value = x;
  return (y.word[lw] == 1954);
   }
   return 0;
  }
 
  ieee_double is just used for type punning so we can check the final
  bits and see if they're equal to 1954; if they are, x is NA, if
  they're not, x is NaN (as defined for R_IsNaN).
 
  My question is -- I can see 

[Rd] Question re: NA, NaNs in R

[Kevin Ushey]

Hi R-devel,

I have a question about the differentiation between NA and NaN values
as implemented in R. In arithmetic.c, we have

int R_IsNA(double x)
{
if (isnan(x)) {
ieee_double y;
y.value = x;
return (y.word[lw] == 1954);
}
return 0;
}

ieee_double is just used for type punning so we can check the final
bits and see if they're equal to 1954; if they are, x is NA, if
they're not, x is NaN (as defined for R_IsNaN).

My question is -- I can see a substantial increase in speed (on my
computer, in certain cases) if I replace this check with

int R_IsNA(double x)
{
return memcmp(
(char*)(x),
(char*)(NA_REAL),
sizeof(double)
) == 0;
}

IIUC, there is only one bit pattern used to encode R NA values, so
this should be safe. But I would like to be sure:

Is there any guarantee that the different functions in R would return
NA as identical to the bit pattern defined for NA_REAL, for a given
architecture? Similarly for NaN value(s) and R_NaN?

My guess is that it is possible some functions used internally by R
might encode NaN values differently; ie, setting the lower word to a
value different than 1954 (hence being NaN, but potentially not
identical to R_NaN), or perhaps this is architecture-dependent.
However, NA should be one specific bit pattern (?). And, I wonder if
there is any guarantee that the different functions used in R would
return an NaN value as identical to R_NaN (which appears to be the
'IEEE NaN')?

(interested parties can see + run a simple benchmark from the gist at
https://gist.github.com/kevinushey/8911432)

Thanks,
Kevin

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

Re: [Rd] Question re: NA, NaNs in R

[Prof Brian Ripley]

There is one NA but mulitple NaNs.

And please re-read 'man memcmp': your cast is wrong.

On 10/02/2014 06:52, Kevin Ushey wrote:

Hi R-devel,

I have a question about the differentiation between NA and NaN values
as implemented in R. In arithmetic.c, we have

int R_IsNA(double x)
{
 if (isnan(x)) {
ieee_double y;
y.value = x;
return (y.word[lw] == 1954);
 }
 return 0;
}

ieee_double is just used for type punning so we can check the final
bits and see if they're equal to 1954; if they are, x is NA, if
they're not, x is NaN (as defined for R_IsNaN).

My question is -- I can see a substantial increase in speed (on my
computer, in certain cases) if I replace this check with

int R_IsNA(double x)
{
 return memcmp(
 (char*)(x),
 (char*)(NA_REAL),
 sizeof(double)
 ) == 0;
}

IIUC, there is only one bit pattern used to encode R NA values, so
this should be safe. But I would like to be sure:

Is there any guarantee that the different functions in R would return
NA as identical to the bit pattern defined for NA_REAL, for a given
architecture? Similarly for NaN value(s) and R_NaN?

My guess is that it is possible some functions used internally by R
might encode NaN values differently; ie, setting the lower word to a
value different than 1954 (hence being NaN, but potentially not
identical to R_NaN), or perhaps this is architecture-dependent.
However, NA should be one specific bit pattern (?). And, I wonder if
there is any guarantee that the different functions used in R would
return an NaN value as identical to R_NaN (which appears to be the
'IEEE NaN')?

(interested parties can see + run a simple benchmark from the gist at
https://gist.github.com/kevinushey/8911432)

Thanks,
Kevin

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

[Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

I'm working on an update for my CRAN package spatial.tools and I noticed
a new warning when running R CMD CHECK --as-cran:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net'
Depends: includes the non-default packages:
  'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
  'doParallel' 'rgeos'
Adding so many packages to the search path is excessive
and importing selectively is preferable.

Is this a warning that would need to be fixed pre-CRAN (not really sure
how, since I need functions from all of those packages)?  Is there a way to
import only a single function from a package, if that function is a
dependency?

--j

-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

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

Re: [Rd] Question about selective importing of package functions...

[Duncan Murdoch]

On 13-10-20 4:43 PM, Jonathan Greenberg wrote:

I'm working on an update for my CRAN package spatial.tools and I noticed
a new warning when running R CMD CHECK --as-cran:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net'
Depends: includes the non-default packages:
   'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
   'doParallel' 'rgeos'
Adding so many packages to the search path is excessive
and importing selectively is preferable.

Is this a warning that would need to be fixed pre-CRAN (not really sure
how, since I need functions from all of those packages)?  Is there a way to
import only a single function from a package, if that function is a
dependency?


You really want to use imports.  Those are defined in the NAMESPACE 
file; you can import everything from a package if you want, but the best 
style is in fact to just import exactly what you need.  This is more 
robust than using Depends, and it doesn't add so much to the user's 
search path, so it's less likely to break something else (e.g. by 
putting a package on the path that masks some function the user already 
had there.)


Duncan Murdoch

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

Re: [Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

Duncan:

Thanks -- learning something new today -- quick follow-up, will using the
import statements in the NAMESPACE, when a user goes to install.packages(),
auto-install the dependent packages the same way Depends forces?

--j


On Sun, Oct 20, 2013 at 3:49 PM, Duncan Murdoch murdoch.dun...@gmail.comwrote:

 On 13-10-20 4:43 PM, Jonathan Greenberg wrote:

 I'm working on an update for my CRAN package spatial.tools and I noticed
 a new warning when running R CMD CHECK --as-cran:

 * checking CRAN incoming feasibility ... NOTE
 Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net'
 Depends: includes the non-default packages:
'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
'doParallel' 'rgeos'
 Adding so many packages to the search path is excessive
 and importing selectively is preferable.

 Is this a warning that would need to be fixed pre-CRAN (not really sure
 how, since I need functions from all of those packages)?  Is there a way
 to
 import only a single function from a package, if that function is a
 dependency?


 You really want to use imports.  Those are defined in the NAMESPACE file;
 you can import everything from a package if you want, but the best style is
 in fact to just import exactly what you need.  This is more robust than
 using Depends, and it doesn't add so much to the user's search path, so
 it's less likely to break something else (e.g. by putting a package on the
 path that masks some function the user already had there.)

 Duncan Murdoch




-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

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

Re: [Rd] Question about selective importing of package functions...

[Gabor Grothendieck]

On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 On 13-10-20 4:43 PM, Jonathan Greenberg wrote:

 I'm working on an update for my CRAN package spatial.tools and I noticed
 a new warning when running R CMD CHECK --as-cran:

 * checking CRAN incoming feasibility ... NOTE
 Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net'
 Depends: includes the non-default packages:
'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
'doParallel' 'rgeos'
 Adding so many packages to the search path is excessive
 and importing selectively is preferable.

 Is this a warning that would need to be fixed pre-CRAN (not really sure
 how, since I need functions from all of those packages)?  Is there a way
 to
 import only a single function from a package, if that function is a
 dependency?


 You really want to use imports.  Those are defined in the NAMESPACE file;
 you can import everything from a package if you want, but the best style is
 in fact to just import exactly what you need.  This is more robust than
 using Depends, and it doesn't add so much to the user's search path, so it's
 less likely to break something else (e.g. by putting a package on the path
 that masks some function the user already had there.)

That may answer the specific case of the poster but how does one
handle the case
where one wants the user to be able to access the functions in the
dependent package.

For example, sqldf depends on gsubfn which provides fn which is used
with sqldf to
perform substitutions in the SQL string.

library(sqldf)
tt - 3
fn$sqldf(select * from BOD where Time  $tt)

I don't want to ask the user to tediously issue a library(gsubfn) too since
fn is frequently needed and for literally years this has not been necessary.
Also I don't want to duplicate fn's code in sqldf since that makes the whole
thing less modular -- it would imply having to change fn in two places
if anything
in fn changed.

-- 
Statistics  Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

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

Re: [Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

One more follow-up -- will I now need to include a library() statement in
each function?

--j


On Sun, Oct 20, 2013 at 3:58 PM, Gabor Grothendieck ggrothendi...@gmail.com
 wrote:

 On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch
 murdoch.dun...@gmail.com wrote:
  On 13-10-20 4:43 PM, Jonathan Greenberg wrote:
 
  I'm working on an update for my CRAN package spatial.tools and I
 noticed
  a new warning when running R CMD CHECK --as-cran:
 
  * checking CRAN incoming feasibility ... NOTE
  Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net'
  Depends: includes the non-default packages:
 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
 'doParallel' 'rgeos'
  Adding so many packages to the search path is excessive
  and importing selectively is preferable.
 
  Is this a warning that would need to be fixed pre-CRAN (not really sure
  how, since I need functions from all of those packages)?  Is there a way
  to
  import only a single function from a package, if that function is a
  dependency?
 
 
  You really want to use imports.  Those are defined in the NAMESPACE file;
  you can import everything from a package if you want, but the best style
 is
  in fact to just import exactly what you need.  This is more robust than
  using Depends, and it doesn't add so much to the user's search path, so
 it's
  less likely to break something else (e.g. by putting a package on the
 path
  that masks some function the user already had there.)

 That may answer the specific case of the poster but how does one
 handle the case
 where one wants the user to be able to access the functions in the
 dependent package.

 For example, sqldf depends on gsubfn which provides fn which is used
 with sqldf to
 perform substitutions in the SQL string.

 library(sqldf)
 tt - 3
 fn$sqldf(select * from BOD where Time  $tt)

 I don't want to ask the user to tediously issue a library(gsubfn) too since
 fn is frequently needed and for literally years this has not been
 necessary.
 Also I don't want to duplicate fn's code in sqldf since that makes the
 whole
 thing less modular -- it would imply having to change fn in two places
 if anything
 in fn changed.

 --
 Statistics  Software Consulting
 GKX Group, GKX Associates Inc.
 tel: 1-877-GKX-GROUP
 email: ggrothendieck at gmail.com




-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

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

Re: [Rd] Question about selective importing of package functions...

[Dirk Eddelbuettel]

On 20 October 2013 at 16:20, Jonathan Greenberg wrote:
| One more follow-up -- will I now need to include a library() statement in
| each function?

No.

NAMESPACE entry, coupled with Imports: in DESCRIPTION.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

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

Re: [Rd] Question about selective importing of package functions...

[Jonathan Greenberg]

To be clear, if I used Depends: somepackage before, and switched over to
using Imports: somepackage, I'll need to mod my code that used to have a
call to, say, somefunction to now have somepackage::somefunction, correct?

--j


On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel e...@debian.org wrote:


 On 20 October 2013 at 16:20, Jonathan Greenberg wrote:
 | One more follow-up -- will I now need to include a library() statement in
 | each function?

 No.

 NAMESPACE entry, coupled with Imports: in DESCRIPTION.

 Dirk

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com




-- 
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

[[alternative HTML version deleted]]

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

Re: [Rd] Question about selective importing of package functions...

[Duncan Murdoch]

On 13-10-20 4:54 PM, Jonathan Greenberg wrote:

Duncan:

Thanks -- learning something new today -- quick follow-up, will using
the import statements in the NAMESPACE, when a user goes to
install.packages(), auto-install the dependent packages the same way
Depends forces?



You need to list the other packages in Imports instead of Depends; then 
the answer is yes.


Duncan Murdoch


--j


On Sun, Oct 20, 2013 at 3:49 PM, Duncan Murdoch
murdoch.dun...@gmail.com mailto:murdoch.dun...@gmail.com wrote:

On 13-10-20 4:43 PM, Jonathan Greenberg wrote:

I'm working on an update for my CRAN package spatial.tools and
I noticed
a new warning when running R CMD CHECK --as-cran:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jonathan Asher Greenberg
spatial-to...@estarcion.net mailto:spatial-to...@estarcion.net'
Depends: includes the non-default packages:
'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
'doParallel' 'rgeos'
Adding so many packages to the search path is excessive
and importing selectively is preferable.

Is this a warning that would need to be fixed pre-CRAN (not
really sure
how, since I need functions from all of those packages)?  Is
there a way to
import only a single function from a package, if that function is a
dependency?


You really want to use imports.  Those are defined in the NAMESPACE
file; you can import everything from a package if you want, but the
best style is in fact to just import exactly what you need.  This is
more robust than using Depends, and it doesn't add so much to the
user's search path, so it's less likely to break something else
(e.g. by putting a package on the path that masks some function the
user already had there.)

Duncan Murdoch




--
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL  61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/ http://www.geog.illinois.edu/%7Ejgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com mailto:jgrn...@hotmail.com,
Gchat: jgrn307, Skype: jgrn3007


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

Re: [Rd] Question about selective importing of package functions...

[Gabriel Becker]

Jonathan,

import/importFrom directives within the NAMESPACE places the symbol(s)
within your package's namespace. They are treated exactly the same as
(non-exported) symbols your code defines.

~G


On Sun, Oct 20, 2013 at 3:41 PM, Jonathan Greenberg j...@illinois.eduwrote:

 To be clear, if I used Depends: somepackage before, and switched over to
 using Imports: somepackage, I'll need to mod my code that used to have a
 call to, say, somefunction to now have somepackage::somefunction, correct?

 --j


 On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel e...@debian.org wrote:

 
  On 20 October 2013 at 16:20, Jonathan Greenberg wrote:
  | One more follow-up -- will I now need to include a library() statement
 in
  | each function?
 
  No.
 
  NAMESPACE entry, coupled with Imports: in DESCRIPTION.
 
  Dirk
 
  --
  Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
 



 --
 Jonathan A. Greenberg, PhD
 Assistant Professor
 Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
 Department of Geography and Geographic Information Science
 University of Illinois at Urbana-Champaign
 259 Computing Applications Building, MC-150
 605 East Springfield Avenue
 Champaign, IL  61820-6371
 Phone: 217-300-1924
 http://www.geog.illinois.edu/~jgrn/
 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007

 [[alternative HTML version deleted]]

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




-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

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

Re: [Rd] Question about selective importing of package functions...

[Duncan Murdoch]

On 13-10-20 6:41 PM, Jonathan Greenberg wrote:

To be clear, if I used Depends: somepackage before, and switched over to
using Imports: somepackage, I'll need to mod my code that used to have a
call to, say, somefunction to now have somepackage::somefunction, correct?


No.  You need to modify both the DESCRIPTION file as you say above, and 
the NAMESPACE file to say what to import.  Once you do that, those 
functions will appear to your own package functions without any prefix 
needed.


Duncan Murdoch



--j


On Sun, Oct 20, 2013 at 5:34 PM, Dirk Eddelbuettel e...@debian.org wrote:



On 20 October 2013 at 16:20, Jonathan Greenberg wrote:
| One more follow-up -- will I now need to include a library() statement in
| each function?

No.

NAMESPACE entry, coupled with Imports: in DESCRIPTION.

Dirk

--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com







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

Re: [Rd] Question about selective importing of package functions...

[Paul Gilbert]

On 13-10-20 04:58 PM, Gabor Grothendieck wrote:

On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:

On 13-10-20 4:43 PM, Jonathan Greenberg wrote:


I'm working on an update for my CRAN package spatial.tools and I noticed
a new warning when running R CMD CHECK --as-cran:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net'
Depends: includes the non-default packages:
'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
'doParallel' 'rgeos'
Adding so many packages to the search path is excessive
and importing selectively is preferable.

Is this a warning that would need to be fixed pre-CRAN (not really sure
how, since I need functions from all of those packages)?  Is there a way
to
import only a single function from a package, if that function is a
dependency?



You really want to use imports.  Those are defined in the NAMESPACE file;
you can import everything from a package if you want, but the best style is
in fact to just import exactly what you need.  This is more robust than
using Depends, and it doesn't add so much to the user's search path, so it's
less likely to break something else (e.g. by putting a package on the path
that masks some function the user already had there.)


That may answer the specific case of the poster but how does one
handle the case
where one wants the user to be able to access the functions in the
dependent package.


There are two answers to this, depending on how much of the dependent 
package you want to make available to the user. If you want most of that 
package to be available then this is the (only?) exception to the rule. 
From Writing R Extensions:


  Field ‘Depends’ should nowadays be used rarely, only for packages
  which are intended to be put on the search path to make their
  facilities available to the end user (and not to the package itself):
  for example it makes sense that a user of package latticeExtra would
   want the functions of package lattice made available.

If you really only want to make a couple of functions available then you 
can import and export the functions. Currently this has the unfortunate 
side effect that you need to document the functions, you cannot just 
re-direct to the documentation in the imported package, at least, I have 
not figured out how to do that.


Paul



For example, sqldf depends on gsubfn which provides fn which is used
with sqldf to
perform substitutions in the SQL string.

library(sqldf)
tt - 3
fn$sqldf(select * from BOD where Time  $tt)

I don't want to ask the user to tediously issue a library(gsubfn) too since
fn is frequently needed and for literally years this has not been necessary.
Also I don't want to duplicate fn's code in sqldf since that makes the whole
thing less modular -- it would imply having to change fn in two places
if anything
in fn changed.



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

[Rd] question about Makeconf and nvcc/CUDA

[Hodgess, Erin]

Dear R development:



I'm not sure if this is the appropriate list, but it's a start.



I would like to put together a package which contains a CUDA program on Windows 
7.  I believe that it has to do with the Makeconf file in the etc directory.



But when I just use the nvcc with the shared option, I can use the dyn.load 
command, but when I use the is.loaded function, it shows FALSE.







Here are the results of the check command:



c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize
R CMD check cudasize
* using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
* using R version 3.0.1 (2013-05-16)
* using platform: i386-w64-mingw32 (32-bit)
* using session charset: ISO8859-1
* checking for file 'cudasize/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'cudasize' version '1.0'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'cudasize' can be installed ... ERROR
Installation failed.
See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for details.

And the 00install.out file:

* installing *source* package 'cudasize' ...

** libs



*** arch - i386

cygwin warning:
  MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
  Preferred POSIX equivalent is: 
/cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
  CYGWIN environment variable option nodosfilewarning turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
cygwin warning:
  MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
  Preferred POSIX equivalent is: 
/cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
  CYGWIN environment variable option nodosfilewarning turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
make: `symbols.rds' is up to date.
ERROR: compilation failed for package 'cudasize'

* removing 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/cudasize'



I've been experimenting with the Makeconf file, but to no avail.



Does anyone have any suggestions, please?



Thanks,

Erin



[[alternative HTML version deleted]]

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

Re: [Rd] question about Makeconf and nvcc/CUDA

[Prof Brian Ripley]

On 18/07/2013 07:45, Hodgess, Erin wrote:

Dear R development:



I'm not sure if this is the appropriate list, but it's a start.



I would like to put together a package which contains a CUDA program on Windows 
7.  I believe that it has to do with the Makeconf file in the etc directory.


That message is just that you have not set up Rtools fully.  As it says,
set CYGWIN=nodosfilewarning in your environment.  See §D.3 in the 
R-admin manual, e.g. 
http://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-command-line-tools 
.


We can see nothing from what you supplied, as it was not a build in 
clean sources.







But when I just use the nvcc with the shared option, I can use the dyn.load 
command, but when I use the is.loaded function, it shows FALSE.







Here are the results of the check command:



c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize
R CMD check cudasize
* using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
* using R version 3.0.1 (2013-05-16)
* using platform: i386-w64-mingw32 (32-bit)
* using session charset: ISO8859-1
* checking for file 'cudasize/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'cudasize' version '1.0'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'cudasize' can be installed ... ERROR
Installation failed.
See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for details.

And the 00install.out file:

* installing *source* package 'cudasize' ...

** libs



*** arch - i386

cygwin warning:
   MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   Preferred POSIX equivalent is: 
/cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   CYGWIN environment variable option nodosfilewarning turns off this warning.
   Consult the user's guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
cygwin warning:
   MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   Preferred POSIX equivalent is: 
/cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   CYGWIN environment variable option nodosfilewarning turns off this warning.
   Consult the user's guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
make: `symbols.rds' is up to date.
ERROR: compilation failed for package 'cudasize'

* removing 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/cudasize'



I've been experimenting with the Makeconf file, but to no avail.



Does anyone have any suggestions, please?



Thanks,

Erin



[[alternative HTML version deleted]]

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] question about Makeconf and nvcc/CUDA

[Hodgess, Erin]

Now let's try again.  I set up the CYGWIN environment command as kindly 
suggested by Prof. Ripley.

Here are my next steps:

R CMD build cudasize
* checking for file 'cudasize/DESCRIPTION' ... OK
* preparing 'cudasize':
* checking DESCRIPTION meta-information ... OK
* cleaning src
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpOWOS4q/Rbuilda8820822194/cudasize/man/f1.Rd:33:
 unexpected '{'
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpOWOS4q/Rbuilda8820822194/cudasize/man/f1.Rd:37:
 unexpected '}'
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'cudasize_1.0.tar.gz'


c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize_1.0.tar.gz 
R CMD check cudasize_1.0.tar.gz 
* using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
* using R version 3.0.1 (2013-05-16)
* using platform: i386-w64-mingw32 (32-bit)
* using session charset: ISO8859-1
* checking for file 'cudasize/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'cudasize' version '1.0'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... WARNING
Subdirectory 'src' contains:
  cuda4.cu
These are unlikely file names for src files.
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'cudasize' can be installed ... ERROR
Installation failed.
See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for details.

And the 00install.out file is:
* installing *source* package 'cudasize' ...
** libs

*** arch - i386
ERROR: compilation failed for package 'cudasize'
* removing 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/cudasize'

So it doesn't seem that CUDA is  working here.  However, if I compile cuda4.cu 
from the command line, it works fine, as seen here:

nvcc -m32 --shared -o cuda4.dll cuda4.cu
 nvcc -m32 --shared -o cuda4.dll cuda4.cu
cuda4.cu
tmpxft_13d4_-5_cuda4.cudafe1.gpu
tmpxft_13d4_-10_cuda4.cudafe2.gpu
cuda4.cu
tmpxft_13d4_-5_cuda4.cudafe1.cpp
tmpxft_13d4_-15_cuda4.ii

So that is my situation.

This is Windows 7, R version 3.0.1
Thanks,
Erin


From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf 
of Prof Brian Ripley [rip...@stats.ox.ac.uk]
Sent: Thursday, July 18, 2013 2:44 AM
To: r-devel@r-project.org
Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

On 18/07/2013 07:45, Hodgess, Erin wrote:
 Dear R development:



 I'm not sure if this is the appropriate list, but it's a start.



 I would like to put together a package which contains a CUDA program on 
 Windows 7.  I believe that it has to do with the Makeconf file in the etc 
 directory.

That message is just that you have not set up Rtools fully.  As it says,
set CYGWIN=nodosfilewarning in your environment.  See §D.3 in the
R-admin manual, e.g.
http://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-command-line-tools
.

We can see nothing from what you supplied, as it was not a build in
clean sources.





 But when I just use the nvcc with the shared option, I can use the dyn.load 
 command, but when I use the is.loaded function, it shows FALSE.







 Here are the results of the check command:



 c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize
 R CMD check cudasize
 * using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
 * using R version 3.0.1 (2013-05-16)
 * using platform: i386-w64-mingw32 (32-bit)
 * using session charset: ISO8859-1
 * checking for file 'cudasize/DESCRIPTION' ... OK
 * checking extension type ... Package
 * this is package 'cudasize' version '1.0'
 * checking package namespace information ... OK
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking if there is a namespace ... OK
 * checking for executable files ... OK
 * checking for hidden files and directories ... OK
 * checking for portable file names ... OK
 * checking whether package 'cudasize' can be installed ... ERROR
 Installation failed.
 See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for 
 details.

 And the 00install.out file:

 * installing *source* package 'cudasize' ...

 ** libs



 *** arch - i386

 cygwin warning:
MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
Preferred POSIX equivalent is: 
 /cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
CYGWIN environment variable option nodosfilewarning turns off this 
 warning.
Consult the user's guide for more details about POSIX paths:
  http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
 cygwin warning:
MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
Preferred POSIX equivalent is: 
 /cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf

Re: [Rd] question about Makeconf and nvcc/CUDA

[Prof Brian Ripley]

You will need a src/Makevars.win to get a .cu file to compile.  It is 
not a known extension: see §1.1.4 of 'Writing R Extensions'


Most likely you need something like

cudasize.dll:
nvcc -m32 --shared -o $@ cuda4.cu

in Makevars.win.

Also, heed the advice about trying R CMD INSTALL before R CMD check.


On 18/07/2013 13:45, Hodgess, Erin wrote:

Now let's try again.  I set up the CYGWIN environment command as kindly 
suggested by Prof. Ripley.

Here are my next steps:

R CMD build cudasize
* checking for file 'cudasize/DESCRIPTION' ... OK
* preparing 'cudasize':
* checking DESCRIPTION meta-information ... OK
* cleaning src
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpOWOS4q/Rbuilda8820822194/cudasize/man/f1.Rd:33:
 unexpected '{'
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpOWOS4q/Rbuilda8820822194/cudasize/man/f1.Rd:37:
 unexpected '}'
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'cudasize_1.0.tar.gz'


c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize_1.0.tar.gz
R CMD check cudasize_1.0.tar.gz
* using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
* using R version 3.0.1 (2013-05-16)
* using platform: i386-w64-mingw32 (32-bit)
* using session charset: ISO8859-1
* checking for file 'cudasize/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'cudasize' version '1.0'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... WARNING
Subdirectory 'src' contains:
   cuda4.cu
These are unlikely file names for src files.
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'cudasize' can be installed ... ERROR
Installation failed.
See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for details.

And the 00install.out file is:
* installing *source* package 'cudasize' ...
** libs

*** arch - i386
ERROR: compilation failed for package 'cudasize'
* removing 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/cudasize'

So it doesn't seem that CUDA is  working here.  However, if I compile cuda4.cu 
from the command line, it works fine, as seen here:

nvcc -m32 --shared -o cuda4.dll cuda4.cu
  nvcc -m32 --shared -o cuda4.dll cuda4.cu
cuda4.cu
tmpxft_13d4_-5_cuda4.cudafe1.gpu
tmpxft_13d4_-10_cuda4.cudafe2.gpu
cuda4.cu
tmpxft_13d4_-5_cuda4.cudafe1.cpp
tmpxft_13d4_-15_cuda4.ii

So that is my situation.

This is Windows 7, R version 3.0.1
Thanks,
Erin


From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf 
of Prof Brian Ripley [rip...@stats.ox.ac.uk]
Sent: Thursday, July 18, 2013 2:44 AM
To: r-devel@r-project.org
Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

On 18/07/2013 07:45, Hodgess, Erin wrote:

Dear R development:



I'm not sure if this is the appropriate list, but it's a start.



I would like to put together a package which contains a CUDA program on Windows 
7.  I believe that it has to do with the Makeconf file in the etc directory.


That message is just that you have not set up Rtools fully.  As it says,
set CYGWIN=nodosfilewarning in your environment.  See §D.3 in the
R-admin manual, e.g.
http://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-command-line-tools
.

We can see nothing from what you supplied, as it was not a build in
clean sources.






But when I just use the nvcc with the shared option, I can use the dyn.load 
command, but when I use the is.loaded function, it shows FALSE.







Here are the results of the check command:



c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize
R CMD check cudasize
* using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
* using R version 3.0.1 (2013-05-16)
* using platform: i386-w64-mingw32 (32-bit)
* using session charset: ISO8859-1
* checking for file 'cudasize/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'cudasize' version '1.0'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking whether package 'cudasize' can be installed ... ERROR
Installation failed.
See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for details.

And the 00install.out file:

* installing *source* package 'cudasize' ...

** libs



*** arch - i386

cygwin warning:
MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
Preferred POSIX equivalent is: 
/cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
CYGWIN environment variable option nodosfilewarning turns off

Re: [Rd] question about Makeconf and nvcc/CUDA

[Duncan Temple Lang]

Hi Erin

 Glad you are making progress on this with Brian's help.

 I thought I would mention a different approach that might save you some
programming time and actually make the code more flexible at the same time.
Basically, in a high-level language like R, it is nice to keep the code
calling a GPU kernel also high-level rather than writing code in C/C++
to do the transfer of data to and from the CPU and GPU.

Simon's OpenCL package (on CRAN) and the new RCUDA package 
(www.omegahat.org/RCUDA)
allow us to load and invoke kernels directly from R.
These provide more flexibility for invoking GPU kernels from R than fixed C/C++ 
code.

RCUDA provides an interface to almost all of the CUDA API and so allows us to 
transfer
values from R to the GPU and back (in different ways), invoke kernels 
asynchronously, etc.
I haven't built the package on Windows yet, but may be able to get to that in 
the next
few days.

With a Windows binary of RCUDA (or OpenCL), you would be able to skip nvcc in 
your
package by  compiling the kernel code generically so that it contains code for 
GPUs
with different  capabilities (e.g. sm_20, sm_30, sm_35).

In the last few days, I have also managed to compile very simple R code
directly in R to PTX code that we can load and invoke using RCUDA.
The compilation uses the Rllvm and RLLVMCompile packages. So in the
future, I expect we will be able to compile simple R functions
to native and PTX code.

 D.

On 7/17/13 11:45 PM, Hodgess, Erin wrote:
 Dear R development:
 
 
 
 I'm not sure if this is the appropriate list, but it's a start.
 
 
 
 I would like to put together a package which contains a CUDA program on 
 Windows 7.  I believe that it has to do with the Makeconf file in the etc 
 directory.
 
 
 
 But when I just use the nvcc with the shared option, I can use the dyn.load 
 command, but when I use the is.loaded function, it shows FALSE.
 
 
 
 
 
 
 
 Here are the results of the check command:
 
 
 
 c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize
 R CMD check cudasize
 * using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
 * using R version 3.0.1 (2013-05-16)
 * using platform: i386-w64-mingw32 (32-bit)
 * using session charset: ISO8859-1
 * checking for file 'cudasize/DESCRIPTION' ... OK
 * checking extension type ... Package
 * this is package 'cudasize' version '1.0'
 * checking package namespace information ... OK
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking if there is a namespace ... OK
 * checking for executable files ... OK
 * checking for hidden files and directories ... OK
 * checking for portable file names ... OK
 * checking whether package 'cudasize' can be installed ... ERROR
 Installation failed.
 See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for 
 details.
 
 And the 00install.out file:
 
 * installing *source* package 'cudasize' ...
 
 ** libs
 
 
 
 *** arch - i386
 
 cygwin warning:
   MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   Preferred POSIX equivalent is: 
 /cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   CYGWIN environment variable option nodosfilewarning turns off this 
 warning.
   Consult the user's guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
 cygwin warning:
   MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   Preferred POSIX equivalent is: 
 /cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   CYGWIN environment variable option nodosfilewarning turns off this 
 warning.
   Consult the user's guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
 make: `symbols.rds' is up to date.
 ERROR: compilation failed for package 'cudasize'
 
 * removing 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/cudasize'
 
 
 
 I've been experimenting with the Makeconf file, but to no avail.
 
 
 
 Does anyone have any suggestions, please?
 
 
 
 Thanks,
 
 Erin
 
 
 
   [[alternative HTML version deleted]]
 
 __
 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] question about Makeconf and nvcc/CUDA

[Hodgess, Erin]

Hi again:

Here is another problem that I am having.  Hope this will be the last one.  I 
really want to see if I can put it together.  Sorry for belaboring the issue.

Well, here is my story:

c:\Program Files\R\R-3.0.1\bin\i386R CMD build cudasize
R CMD build cudasize
* checking for file 'cudasize/DESCRIPTION' ... OK
* preparing 'cudasize':
* checking DESCRIPTION meta-information ... OK
* cleaning src
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:33:
 unexpected '{'
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:37:
 unexpected '}'
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'cudasize_1.0.tar.gz'


c:\Program Files\R\R-3.0.1\bin\i386R CMD INSTALL --no-multiarch 
cudasize_1.0.tar.gz 
R CMD INSTALL --no-multiarch cudasize_1.0.tar.gz 
* installing to library 'c:/myRlib'
* installing *source* package 'cudasize' ...
** libs
nvcc -m32 --shared -o cuda4.dll cuda4.cu
cuda4.cu
tmpxft_12fc_-5_cuda4.cudafe1.gpu
tmpxft_12fc_-10_cuda4.cudafe2.gpu
cuda4.cu
tmpxft_12fc_-5_cuda4.cudafe1.cpp
tmpxft_12fc_-15_cuda4.ii
installing to c:/myRlib/cudasize/libs/i386
** R
** preparing package for lazy loading
** help
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:33:
 unexpected '{'
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:37:
 unexpected '}'
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:31:
 All text must be in a section
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:32:
 All text must be in a section
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:34:
 All text must be in a section
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:35:
 All text must be in a section
Warning: 
C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:36:
 All text must be in a section
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (cudasize)

c:\Program Files\R\R-3.0.1\bin\i386R --vanilla
R --vanilla

R version 3.0.1 (2013-05-16) -- Good Sport
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: i386-w64-mingw32/i386 (32-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

 library(cudasize)
library(cudasize)
 f1
f1
function (x) 
{
y - .Call(cuda4, as.character(x))
return(y)
}
environment: namespace:cudasize
 f1(2)
f1(2)
Error in .Call(cuda4, as.character(x)) : 
  cuda4 not resolved from current namespace (cudasize)
Calls: f1 - .Call
Execution halted

Here is the Makevars.win file

cuda4.dll:
nvcc -m32 --shared -o cuda4.dll cuda4.cu

And finally, the program itself:


#include stdio.h
#include cuda.h
 
// Kernel that executes on the CUDA device
__global__ void square_array(float *a, int N)
{
  int idx = blockIdx.x * blockDim.x + threadIdx.x;
  if (idxN) a[idx] = a[idx] * a[idx];
}
 
// main routine that executes on the host
void  stuff(int argc, char **argv)
{
  float *a_h, *a_d;  // Pointer to host  device arrays
  int N = atoi(argv[1]);
//  const int N = 10;   Number of elements in arrays
  size_t size = N * sizeof(float);
  a_h = (float *)malloc(size);// Allocate array on host
  cudaMalloc((void **) a_d, size);   // Allocate array on device
  // Initialize host array and copy it to CUDA device
  for (int i=0; iN; i++) a_h[i] = (float)i;
  cudaMemcpy(a_d, a_h, size, cudaMemcpyHostToDevice);
  // Do calculation on device:
  int block_size = 4;
  int n_blocks = N/block_size + (N%block_size == 0 ? 0:1);
  square_array  n_blocks, block_size  (a_d, N);
  // Retrieve result from device and store it in host array
  cudaMemcpy(a_h, a_d, sizeof(float)*N, cudaMemcpyDeviceToHost);
  // Print results
  for (int i=0; iN; i++) printf(%d %f\n, i, a_h[i]);
  // Cleanup
  free(a_h); cudaFree(a_d);
}

Any suggestions would be appreciated.

Thanks,
Erin


From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf 
of Duncan Temple Lang [dtemplel...@ucdavis.edu]
Sent: Thursday, July 18, 2013 9:16 AM
To: r-devel@r-project.org
Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

Hi Erin

 Glad you are making progress on this with Brian's help.

 I thought I would mention

Re: [Rd] question about Makeconf and nvcc/CUDA

[Duncan Temple Lang]

   for (int i=0; iN; i++) a_h[i] = (float)i;
   cudaMemcpy(a_d, a_h, size, cudaMemcpyHostToDevice);
   // Do calculation on device:
   int block_size = 4;
   int n_blocks = N/block_size + (N%block_size == 0 ? 0:1);
   square_array  n_blocks, block_size  (a_d, N);
   // Retrieve result from device and store it in host array
   cudaMemcpy(a_h, a_d, sizeof(float)*N, cudaMemcpyDeviceToHost);
   // Print results
   for (int i=0; iN; i++) printf(%d %f\n, i, a_h[i]);
   // Cleanup
   free(a_h); cudaFree(a_d);
 }
 
 Any suggestions would be appreciated.
 
 Thanks,
 Erin
 
 
 From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf 
 of Duncan Temple Lang [dtemplel...@ucdavis.edu]
 Sent: Thursday, July 18, 2013 9:16 AM
 To: r-devel@r-project.org
 Subject: Re: [Rd] question about Makeconf and nvcc/CUDA
 
 Hi Erin
 
  Glad you are making progress on this with Brian's help.
 
  I thought I would mention a different approach that might save you some
 programming time and actually make the code more flexible at the same time.
 Basically, in a high-level language like R, it is nice to keep the code
 calling a GPU kernel also high-level rather than writing code in C/C++
 to do the transfer of data to and from the CPU and GPU.
 
 Simon's OpenCL package (on CRAN) and the new RCUDA package 
 (www.omegahat.org/RCUDA)
 allow us to load and invoke kernels directly from R.
 These provide more flexibility for invoking GPU kernels from R than fixed 
 C/C++ code.
 
 RCUDA provides an interface to almost all of the CUDA API and so allows us to 
 transfer
 values from R to the GPU and back (in different ways), invoke kernels 
 asynchronously, etc.
 I haven't built the package on Windows yet, but may be able to get to that in 
 the next
 few days.
 
 With a Windows binary of RCUDA (or OpenCL), you would be able to skip nvcc in 
 your
 package by  compiling the kernel code generically so that it contains code 
 for GPUs
 with different  capabilities (e.g. sm_20, sm_30, sm_35).
 
 In the last few days, I have also managed to compile very simple R code
 directly in R to PTX code that we can load and invoke using RCUDA.
 The compilation uses the Rllvm and RLLVMCompile packages. So in the
 future, I expect we will be able to compile simple R functions
 to native and PTX code.
 
  D.
 
 On 7/17/13 11:45 PM, Hodgess, Erin wrote:
 Dear R development:



 I'm not sure if this is the appropriate list, but it's a start.



 I would like to put together a package which contains a CUDA program on 
 Windows 7.  I believe that it has to do with the Makeconf file in the etc 
 directory.



 But when I just use the nvcc with the shared option, I can use the dyn.load 
 command, but when I use the is.loaded function, it shows FALSE.







 Here are the results of the check command:



 c:\PROGRA~1\R\R-3.0.1\bin\i386R CMD check cudasize
 R CMD check cudasize
 * using log directory 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck'
 * using R version 3.0.1 (2013-05-16)
 * using platform: i386-w64-mingw32 (32-bit)
 * using session charset: ISO8859-1
 * checking for file 'cudasize/DESCRIPTION' ... OK
 * checking extension type ... Package
 * this is package 'cudasize' version '1.0'
 * checking package namespace information ... OK
 * checking package dependencies ... OK
 * checking if this is a source package ... OK
 * checking if there is a namespace ... OK
 * checking for executable files ... OK
 * checking for hidden files and directories ... OK
 * checking for portable file names ... OK
 * checking whether package 'cudasize' can be installed ... ERROR
 Installation failed.
 See 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/00install.out' for 
 details.

 And the 00install.out file:

 * installing *source* package 'cudasize' ...

 ** libs



 *** arch - i386

 cygwin warning:
   MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   Preferred POSIX equivalent is: 
 /cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   CYGWIN environment variable option nodosfilewarning turns off this 
 warning.
   Consult the user's guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
 cygwin warning:
   MS-DOS style path detected: c:/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   Preferred POSIX equivalent is: 
 /cygdrive/c/PROGRA~1/R/R-30~1.1/etc/i386/Makeconf
   CYGWIN environment variable option nodosfilewarning turns off this 
 warning.
   Consult the user's guide for more details about POSIX paths:
 http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
 make: `symbols.rds' is up to date.
 ERROR: compilation failed for package 'cudasize'

 * removing 'c:/PROGRA~1/R/R-3.0.1/bin/i386/cudasize.Rcheck/cudasize'



 I've been experimenting with the Makeconf file, but to no avail.



 Does anyone have any suggestions, please?



 Thanks,

 Erin



   [[alternative HTML version deleted]]

 __
 R

Re: [Rd] question about Makeconf and nvcc/CUDA

[Hodgess, Erin]

Hi again.

I put in the extern statement.

However, I'm not sure what you mean by changing the signature, please.  

I changed out the routine name from stuff to cuda4 in the cuda4.cu program.

Still getting:

 library(cudasize)
library(cudasize)

 

 .C(cuda4,as.character(5))
.C(cuda4,as.character(5))
Error in .C(cuda4, as.character(5)) : 
  C symbol name cuda4 not in load table
Execution halted

c:\Program Files\R\R-3.0.1\bin\i386

I still want to keep at it.

Thanks so much for all of your help!!!

Erin


From: Duncan Temple Lang [dtemplel...@ucdavis.edu]
Sent: Thursday, July 18, 2013 1:09 PM
To: Hodgess, Erin
Cc: r-devel@r-project.org
Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

Hi Erin

It appears that there is only one file in src that is compile, i.e. cuda4.cu.

That does not contain a routine named cuda4, which is what you are trying to 
invoke
via the .Call(cuda4) expression.

Instead, it contains two routines - one kernel square_array which runs
on the GPU, and the routine stuff.

To be able to call the stuff() routine from R, you would have to
a)  add
  extern C
before its definition/declaration so that its name is not mangled by nvcc

b)  change its signature so that it can be invoked via a .Call() or 
alternatively
a .C().

 I would create another routine that acts as an intermediate routine
called from R that then calls stuff().

This assumes that what you showed us of cuda4.cu is all there is in it.
   D.

On 7/18/13 11:01 AM, Hodgess, Erin wrote:
 Hi again:

 Here is another problem that I am having.  Hope this will be the last one.  I 
 really want to see if I can put it together.  Sorry for belaboring the issue.

 Well, here is my story:

 c:\Program Files\R\R-3.0.1\bin\i386R CMD build cudasize
 R CMD build cudasize
 * checking for file 'cudasize/DESCRIPTION' ... OK
 * preparing 'cudasize':
 * checking DESCRIPTION meta-information ... OK
 * cleaning src
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:33:
  unexpected '{'
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:37:
  unexpected '}'
 * checking for LF line-endings in source and make files
 * checking for empty or unneeded directories
 * building 'cudasize_1.0.tar.gz'


 c:\Program Files\R\R-3.0.1\bin\i386R CMD INSTALL --no-multiarch 
 cudasize_1.0.tar.gz
 R CMD INSTALL --no-multiarch cudasize_1.0.tar.gz
 * installing to library 'c:/myRlib'
 * installing *source* package 'cudasize' ...
 ** libs
 nvcc -m32 --shared -o cuda4.dll cuda4.cu
 cuda4.cu
 tmpxft_12fc_-5_cuda4.cudafe1.gpu
 tmpxft_12fc_-10_cuda4.cudafe2.gpu
 cuda4.cu
 tmpxft_12fc_-5_cuda4.cudafe1.cpp
 tmpxft_12fc_-15_cuda4.ii
 installing to c:/myRlib/cudasize/libs/i386
 ** R
 ** preparing package for lazy loading
 ** help
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:33:
  unexpected '{'
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:37:
  unexpected '}'
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:31:
  All text must be in a section
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:32:
  All text must be in a section
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:34:
  All text must be in a section
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:35:
  All text must be in a section
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpKSm696/R.INSTALL7fc517f4e58/cudasize/man/f1.Rd:36:
  All text must be in a section
 *** installing help indices
 ** building package indices
 ** testing if installed package can be loaded
 * DONE (cudasize)

 c:\Program Files\R\R-3.0.1\bin\i386R --vanilla
 R --vanilla

 R version 3.0.1 (2013-05-16) -- Good Sport
 Copyright (C) 2013 The R Foundation for Statistical Computing
 Platform: i386-w64-mingw32/i386 (32-bit)

 R is free software and comes with ABSOLUTELY NO WARRANTY.
 You are welcome to redistribute it under certain conditions.
 Type 'license()' or 'licence()' for distribution details.

 R is a collaborative project with many contributors.
 Type 'contributors()' for more information and
 'citation()' on how to cite R or R packages in publications.

 Type 'demo()' for some demos, 'help()' for on-line help, or
 'help.start()' for an HTML browser interface to help.
 Type 'q()' to quit R.

 library(cudasize)
 library(cudasize)
 f1
 f1
 function (x)
 {
 y - .Call(cuda4, as.character(x))
 return(y)
 }
 environment: namespace:cudasize
 f1(2)
 f1(2)
 Error in .Call(cuda4, as.character(x)) :
   cuda4 not resolved from current namespace (cudasize)
 Calls: f1 - .Call
 Execution halted

 Here is the Makevars.win file

 cuda4.dll:
   nvcc -m32 --shared -o

Re: [Rd] question about Makeconf and nvcc/CUDA

[Duncan Temple Lang]

Hi Erin

See the code below.

Basically, I have created a new routine that you will
call from R as

 .C(cuda4, 1L, 5)

where 1L is the number of arguments you are passing and 5 is the character 
vector of arguments.

We are using .C() here for simplicity. For other cases involving data, .Call() 
would be better.

That cuda4 routines is now not name-mangled, and has the correct parameter 
types and return type
to be called via the .C().
The good thing is this has nothing to do with CUDA, but just calling C++ 
routines from R.


This illustrates that there are complexities here with different devices, 
languages, etc.
This is one of the reasons a high-level interface to calling kernels is simpler 
and
more flexible.

The following R only code invokes the kernel on actual data we have in R (x).

# Put the square_array routine only in a file named, erinHodgess.cu
# add extern C before the square_array routine

  # generate the PTX code
f = nvcc(erinHodgess.cu)

  # load the PTX code
mod = loadModule(f)

  # Invoke the PTX code
x = rnorm(10)
ans = .gpu(mod$square_array, x, length(x), gridBy = x)

all.equal(x*x, ans)


  D.




#include stdio.h
#include cuda.h

// Kernel that executes on the CUDA device
extern C
__global__ void square_array(float *a, int N)
{
  int idx = blockIdx.x * blockDim.x + threadIdx.x;
  if (idxN) a[idx] = a[idx] * a[idx];
}

// main routine that executes on the host
void stuff(int argc, char **argv)
{
  float *a_h, *a_d;  // Pointer to host  device arrays
  int N = atoi(argv[1]);
//  const int N = 10;   Number of elements in arrays
  size_t size = N * sizeof(float);
  a_h = (float *)malloc(size);// Allocate array on host
  cudaMalloc((void **) a_d, size);   // Allocate array on device
  // Initialize host array and copy it to CUDA device
  for (int i=0; iN; i++) a_h[i] = (float)i;
  cudaMemcpy(a_d, a_h, size, cudaMemcpyHostToDevice);
  // Do calculation on device:
  int block_size = 4;
  int n_blocks = N/block_size + (N%block_size == 0 ? 0:1);
  square_array  n_blocks, block_size  (a_d, N);
  // Retrieve result from device and store it in host array
  cudaMemcpy(a_h, a_d, sizeof(float)*N, cudaMemcpyDeviceToHost);
  // Print results
  for (int i=0; iN; i++) printf(%d %f\n, i, a_h[i]);
  // Cleanup
  free(a_h); cudaFree(a_d);
}

extern C
void
cuda4(int *nels, char **els)
{
   stuff(*nels, els);
}


On 7/18/13 12:46 PM, Hodgess, Erin wrote:
 Hi again.
 
 I put in the extern statement.
 
 However, I'm not sure what you mean by changing the signature, please.  
 
 I changed out the routine name from stuff to cuda4 in the cuda4.cu 
 program.
 
 Still getting:
 
 library(cudasize)
 library(cudasize)
 

 
 .C(cuda4,as.character(5))
 .C(cuda4,as.character(5))
 Error in .C(cuda4, as.character(5)) : 
   C symbol name cuda4 not in load table
 Execution halted
 
 c:\Program Files\R\R-3.0.1\bin\i386
 
 I still want to keep at it.
 
 Thanks so much for all of your help!!!
 
 Erin
 
 
 From: Duncan Temple Lang [dtemplel...@ucdavis.edu]
 Sent: Thursday, July 18, 2013 1:09 PM
 To: Hodgess, Erin
 Cc: r-devel@r-project.org
 Subject: Re: [Rd] question about Makeconf and nvcc/CUDA
 
 Hi Erin
 
 It appears that there is only one file in src that is compile, i.e. cuda4.cu.
 
 That does not contain a routine named cuda4, which is what you are trying to 
 invoke
 via the .Call(cuda4) expression.
 
 Instead, it contains two routines - one kernel square_array which runs
 on the GPU, and the routine stuff.
 
 To be able to call the stuff() routine from R, you would have to
 a)  add
   extern C
 before its definition/declaration so that its name is not mangled by nvcc
 
 b)  change its signature so that it can be invoked via a .Call() or 
 alternatively
 a .C().
 
  I would create another routine that acts as an intermediate routine
 called from R that then calls stuff().
 
 This assumes that what you showed us of cuda4.cu is all there is in it.
D.
 
 On 7/18/13 11:01 AM, Hodgess, Erin wrote:
 Hi again:

 Here is another problem that I am having.  Hope this will be the last one.  
 I really want to see if I can put it together.  Sorry for belaboring the 
 issue.

 Well, here is my story:

 c:\Program Files\R\R-3.0.1\bin\i386R CMD build cudasize
 R CMD build cudasize
 * checking for file 'cudasize/DESCRIPTION' ... OK
 * preparing 'cudasize':
 * checking DESCRIPTION meta-information ... OK
 * cleaning src
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:33:
  unexpected '{'
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:37:
  unexpected '}'
 * checking for LF line-endings in source and make files
 * checking for empty or unneeded directories
 * building 'cudasize_1.0.tar.gz'


 c:\Program Files\R\R-3.0.1\bin\i386R CMD INSTALL --no-multiarch 
 cudasize_1.0.tar.gz
 R CMD INSTALL --no-multiarch cudasize_1.0.tar.gz
 * installing

Re: [Rd] question about Makeconf and nvcc/CUDA

[Hodgess, Erin]

Wow!

This is just amazing!

Thanks so much.  I didn't realize how intense this is.



From: Duncan Temple Lang [dtemplel...@ucdavis.edu]
Sent: Thursday, July 18, 2013 3:08 PM
To: Hodgess, Erin
Cc: r-devel@r-project.org
Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

Hi Erin

See the code below.

Basically, I have created a new routine that you will
call from R as

 .C(cuda4, 1L, 5)

where 1L is the number of arguments you are passing and 5 is the character 
vector of arguments.

We are using .C() here for simplicity. For other cases involving data, .Call() 
would be better.

That cuda4 routines is now not name-mangled, and has the correct parameter 
types and return type
to be called via the .C().
The good thing is this has nothing to do with CUDA, but just calling C++ 
routines from R.


This illustrates that there are complexities here with different devices, 
languages, etc.
This is one of the reasons a high-level interface to calling kernels is simpler 
and
more flexible.

The following R only code invokes the kernel on actual data we have in R (x).

# Put the square_array routine only in a file named, erinHodgess.cu
# add extern C before the square_array routine

  # generate the PTX code
f = nvcc(erinHodgess.cu)

  # load the PTX code
mod = loadModule(f)

  # Invoke the PTX code
x = rnorm(10)
ans = .gpu(mod$square_array, x, length(x), gridBy = x)

all.equal(x*x, ans)


  D.




#include stdio.h
#include cuda.h

// Kernel that executes on the CUDA device
extern C
__global__ void square_array(float *a, int N)
{
  int idx = blockIdx.x * blockDim.x + threadIdx.x;
  if (idxN) a[idx] = a[idx] * a[idx];
}

// main routine that executes on the host
void stuff(int argc, char **argv)
{
  float *a_h, *a_d;  // Pointer to host  device arrays
  int N = atoi(argv[1]);
//  const int N = 10;   Number of elements in arrays
  size_t size = N * sizeof(float);
  a_h = (float *)malloc(size);// Allocate array on host
  cudaMalloc((void **) a_d, size);   // Allocate array on device
  // Initialize host array and copy it to CUDA device
  for (int i=0; iN; i++) a_h[i] = (float)i;
  cudaMemcpy(a_d, a_h, size, cudaMemcpyHostToDevice);
  // Do calculation on device:
  int block_size = 4;
  int n_blocks = N/block_size + (N%block_size == 0 ? 0:1);
  square_array  n_blocks, block_size  (a_d, N);
  // Retrieve result from device and store it in host array
  cudaMemcpy(a_h, a_d, sizeof(float)*N, cudaMemcpyDeviceToHost);
  // Print results
  for (int i=0; iN; i++) printf(%d %f\n, i, a_h[i]);
  // Cleanup
  free(a_h); cudaFree(a_d);
}

extern C
void
cuda4(int *nels, char **els)
{
   stuff(*nels, els);
}


On 7/18/13 12:46 PM, Hodgess, Erin wrote:
 Hi again.

 I put in the extern statement.

 However, I'm not sure what you mean by changing the signature, please.

 I changed out the routine name from stuff to cuda4 in the cuda4.cu 
 program.

 Still getting:

 library(cudasize)
 library(cudasize)



 .C(cuda4,as.character(5))
 .C(cuda4,as.character(5))
 Error in .C(cuda4, as.character(5)) :
   C symbol name cuda4 not in load table
 Execution halted

 c:\Program Files\R\R-3.0.1\bin\i386

 I still want to keep at it.

 Thanks so much for all of your help!!!

 Erin

 
 From: Duncan Temple Lang [dtemplel...@ucdavis.edu]
 Sent: Thursday, July 18, 2013 1:09 PM
 To: Hodgess, Erin
 Cc: r-devel@r-project.org
 Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

 Hi Erin

 It appears that there is only one file in src that is compile, i.e. cuda4.cu.

 That does not contain a routine named cuda4, which is what you are trying to 
 invoke
 via the .Call(cuda4) expression.

 Instead, it contains two routines - one kernel square_array which runs
 on the GPU, and the routine stuff.

 To be able to call the stuff() routine from R, you would have to
 a)  add
   extern C
 before its definition/declaration so that its name is not mangled by nvcc

 b)  change its signature so that it can be invoked via a .Call() or 
 alternatively
 a .C().

  I would create another routine that acts as an intermediate routine
 called from R that then calls stuff().

 This assumes that what you showed us of cuda4.cu is all there is in it.
D.

 On 7/18/13 11:01 AM, Hodgess, Erin wrote:
 Hi again:

 Here is another problem that I am having.  Hope this will be the last one.  
 I really want to see if I can put it together.  Sorry for belaboring the 
 issue.

 Well, here is my story:

 c:\Program Files\R\R-3.0.1\bin\i386R CMD build cudasize
 R CMD build cudasize
 * checking for file 'cudasize/DESCRIPTION' ... OK
 * preparing 'cudasize':
 * checking DESCRIPTION meta-information ... OK
 * cleaning src
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:33:
  unexpected '{'
 Warning: 
 C:/Users/erin/AppData/Local/Temp/RtmpOKsfga/Rbuild22e066bf13fb/cudasize/man/f1.Rd:37:
  unexpected

Re: [Rd] question about Makeconf and nvcc/CUDA

[Hodgess, Erin]

 cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... WARNING
prepare_Rd: f1.Rd:33: unexpected '{'
prepare_Rd: f1.Rd:37: unexpected '}'
prepare_Rd: f1.Rd:31: All text must be in a section
prepare_Rd: f1.Rd:32: All text must be in a section
prepare_Rd: f1.Rd:34: All text must be in a section
prepare_Rd: f1.Rd:35: All text must be in a section
prepare_Rd: f1.Rd:36: All text must be in a section
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... OK
* checking examples ... ERROR
Running examples in 'cudasize-Ex.R' failed
The error most likely occurred in:

 ### Name: cudasize-package
 ### Title: test for cuda
 ### Aliases: cudasize-package cudasize
 ### Keywords: package
 
 ### ** Examples
 
 require(cudasize)
 z - .Call(cuda4,1L,5)
Error in .Call(cuda4, 1L, 5) : 
  C symbol name cuda4 not in load table
Execution halted

c:\Program Files\R\R-3.0.1\bin\i386

The updated cuda4.dll and symbols.rd files are in 
cudasize.Rcheck/00_pkg/cudasize/src

Yet again, any help truly appreciated.

Sincerely,
Erin




From: Duncan Temple Lang [dtemplel...@ucdavis.edu]
Sent: Thursday, July 18, 2013 3:08 PM
To: Hodgess, Erin
Cc: r-devel@r-project.org
Subject: Re: [Rd] question about Makeconf and nvcc/CUDA

Hi Erin

See the code below.

Basically, I have created a new routine that you will
call from R as

 .C(cuda4, 1L, 5)

where 1L is the number of arguments you are passing and 5 is the character 
vector of arguments.

We are using .C() here for simplicity. For other cases involving data, .Call() 
would be better.

That cuda4 routines is now not name-mangled, and has the correct parameter 
types and return type
to be called via the .C().
The good thing is this has nothing to do with CUDA, but just calling C++ 
routines from R.


This illustrates that there are complexities here with different devices, 
languages, etc.
This is one of the reasons a high-level interface to calling kernels is simpler 
and
more flexible.

The following R only code invokes the kernel on actual data we have in R (x).

# Put the square_array routine only in a file named, erinHodgess.cu
# add extern C before the square_array routine

  # generate the PTX code
f = nvcc(erinHodgess.cu)

  # load the PTX code
mod = loadModule(f)

  # Invoke the PTX code
x = rnorm(10)
ans = .gpu(mod$square_array, x, length(x), gridBy = x)

all.equal(x*x, ans)


  D.




#include stdio.h
#include cuda.h

// Kernel that executes on the CUDA device
extern C
__global__ void square_array(float *a, int N)
{
  int idx = blockIdx.x * blockDim.x + threadIdx.x;
  if (idxN) a[idx] = a[idx] * a[idx];
}

// main routine that executes on the host
void stuff(int argc, char **argv)
{
  float *a_h, *a_d;  // Pointer to host  device arrays
  int N = atoi(argv[1]);
//  const int N = 10;   Number of elements in arrays
  size_t size = N * sizeof(float);
  a_h = (float *)malloc(size);// Allocate array on host
  cudaMalloc((void **) a_d, size);   // Allocate array on device
  // Initialize host array and copy it to CUDA device
  for (int i=0; iN; i++) a_h[i] = (float)i;
  cudaMemcpy(a_d, a_h, size, cudaMemcpyHostToDevice);
  // Do calculation on device:
  int block_size = 4;
  int n_blocks = N/block_size + (N%block_size == 0 ? 0:1);
  square_array  n_blocks, block_size  (a_d, N);
  // Retrieve result from device and store it in host array
  cudaMemcpy(a_h, a_d, sizeof(float)*N, cudaMemcpyDeviceToHost);
  // Print results
  for (int i=0; iN; i++) printf(%d %f\n, i, a_h[i]);
  // Cleanup
  free(a_h); cudaFree(a_d);
}

extern C
void
cuda4(int *nels, char **els)
{
   stuff(*nels, els);
}


On 7/18/13 12:46 PM, Hodgess, Erin wrote:
 Hi again.

 I put in the extern statement.

 However, I'm not sure what you mean by changing the signature, please.

 I changed out the routine name from stuff to cuda4 in the cuda4.cu 
 program.

 Still getting:

 library(cudasize)
 library(cudasize)



 .C(cuda4,as.character(5))
 .C(cuda4,as.character(5))
 Error in .C(cuda4, as.character(5)) :
   C symbol name cuda4 not in load table
 Execution halted

 c:\Program Files\R\R-3.0.1\bin

Re: [Rd] Question about writing portable packages

[Gray]

Kevin Ushey: (12:10AM on Fri, Jun 07)

I think the key word here is _other_ packages. It's entirely okay to call
your package's own compiled code through the .Call interface (and the code
you write may link to other packages; the obvious example being Rcpp code
you write); however, it is not portable to use .Call to call compiled code
from another package directly. This is because package authors are not
required to maintain a consistent .Call interface to their compiled code;
rather, they just have to make sure the direct user-facing R exported
functions retain a stable interface over different versions (or, if
changed, are done so with prior warning etc.)


Also remember that, as long as you obey all of the licenses, you can
simply copy the source code that needs to be compiled into your own
package.  You'll obviously need to track development of the other
package (which you'll need to do anyway) but then you can be sure that
the calls you want to use work.

--
Gray Calhoun, Assistant Professor of Economics at Iowa State 
http://gray.clhn.co (web)


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

[Rd] Question about writing portable packages

[Guillermo.Vinue]

Dear R-devel list,

I am creating an R package that includes C++ code. I tried to install it
both in Linux and Windows and it worked. I load the C code via the
NAMESPACE file using useDynLib.

Now I am revising once again whether everything is ready before
submitting the package to CRAN and I have read in
http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages
that “It is not portable to call compiled code in R or other packages
via .Internal, .C, .Fortran, .Call or .External, since such interfaces
are subject to change without notice and will probably result in your
code terminating the R process”.

However, the R function of my package that calls the C++ code uses the
Call function. 

Does it mean that I cannot submit my package to CRAN because the
portability is not guaranteed?. Then, how could I to call C++ code so
that my package were portable?.

I hope you can clarify my doubts. I have seen the collection of prior
postings to the list, but I have not found a specifical answer to my doubts .

Thank you very much in advance.

Best regards,

Guillermo

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

Re: [Rd] Question about writing portable packages

[Gabriel Becker]

Guillermo,

That phrase is referring to using .Call in your package to call a C
function that shipped with a DIFFERENT package or is part of R itself
(defined in the R source code).

As long as you are only calling C functions you define in the C++ code that
ships with your package you are fine.

~G


On Thu, Jun 6, 2013 at 6:54 AM, guillermo.vi...@uv.es wrote:

 Dear R-devel list,

 I am creating an R package that includes C++ code. I tried to install it
 both in Linux and Windows and it worked. I load the C code via the
 NAMESPACE file using useDynLib.

 Now I am revising once again whether everything is ready before
 submitting the package to CRAN and I have read in
 http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages
 that “It is not portable to call compiled code in R or other packages
 via .Internal, .C, .Fortran, .Call or .External, since such interfaces
 are subject to change without notice and will probably result in your
 code terminating the R process”.

 However, the R function of my package that calls the C++ code uses the
 Call function.

 Does it mean that I cannot submit my package to CRAN because the
 portability is not guaranteed?. Then, how could I to call C++ code so
 that my package were portable?.

 I hope you can clarify my doubts. I have seen the collection of prior
 postings to the list, but I have not found a specifical answer to my
 doubts .

 Thank you very much in advance.

 Best regards,

 Guillermo

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




-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

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

Re: [Rd] Question about writing portable packages

[Guillermo.Vinue]

Dear Kevin, Berwin and Gabriel,

Thank you very much for your detailed and clear answers. 

According to your comments, in a few days I will submit my package to CRAN.

I would also like to take this opportunity to thank all the R-devel list
for being a wonderful place to discuss and clarify doubts about R.

Best wishes,

Guillermo

 Guillermo,
 
 That phrase is referring to using .Call in your package to call a C
 function that shipped with a DIFFERENT package or is part of R itself
 (defined in the R source code).
 
 As long as you are only calling C functions you define in the C++ code
that
 ships with your package you are fine.
 
 ~G
 
 
 On Thu, Jun 6, 2013 at 6:54 AM, guillermo.vi...@uv.es wrote:
 
  Dear R-devel list,
 
  I am creating an R package that includes C++ code. I tried to install it
  both in Linux and Windows and it worked. I load the C code via the
  NAMESPACE file using useDynLib.
 
  Now I am revising once again whether everything is ready before
  submitting the package to CRAN and I have read in
 
http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages
  that “It is not portable to call compiled code in R or other packages
  via .Internal, .C, .Fortran, .Call or .External, since such interfaces
  are subject to change without notice and will probably result in your
  code terminating the R process”.
 
  However, the R function of my package that calls the C++ code uses the
  Call function.
 
  Does it mean that I cannot submit my package to CRAN because the
  portability is not guaranteed?. Then, how could I to call C++ code so
  that my package were portable?.
 
  I hope you can clarify my doubts. I have seen the collection of prior
  postings to the list, but I have not found a specifical answer to my
  doubts .
 
  Thank you very much in advance.
 
  Best regards,
 
  Guillermo
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 
 
 
 
 -- 
 Gabriel Becker
 Graduate Student
 Statistics Department
 University of California, Davis
 

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