[Rd] [R] Calculation of cross-correlation in ccf

2014-11-04 Thread Sami Toppinen 

Dear All,

I am studying some process measurement time series in R and trying to identify 
time delays using cross-correlation function ccf. The results have however been 
bit confusing. I found a couple of years old message about this issue but 
unfortunately wasn't able to find it again for a reference.

For example, an obvious time shift is observed between the measurements y1 and 
y2 when the following test data is plotted:

x <- 1:121
y1 <- c(328.27, 328.27, 328.27, 328.27, 328.21, 328.14, 328.14, 328.01,
 328.07, 328.01, 327.87, 328.01, 328.07, 328.27, 328.27, 328.54, 328.61,
 328.74, 328.88, 329.01, 329.01, 329.21, 329.28, 329.35, 329.35, 329.42,
 329.35, 329.28, 329.28, 329.15, 329.08, 329.08, 328.95, 328.95, 328.95,
 328.95, 329.01, 329.15, 329.21, 329.28, 329.55, 329.62, 329.75, 329.82,
 329.89, 330.09, 330.09, 330.29, 330.29, 330.36, 330.42, 330.29, 330.15,
 330.22, 330.09, 329.95, 329.82, 329.75, 329.62, 329.55, 329.48, 329.55,
 329.68, 329.75, 329.82, 329.89, 330.09, 330.09, 330.15, 330.22, 330.42,
 330.42, 330.42, 330.36, 330.42, 330.22, 330.15, 330.09, 329.89, 329.75,
 329.55, 329.35, 329.35, 329.42, 329.48, 329.55, 329.75, 329.75, 329.82,
 330.09, 330.15, 330.42, 330.42, 330.62, 330.69, 330.69, 330.83, 330.83,
 330.76, 330.62, 330.62, 330.56, 330.42, 330.42, 330.29, 330.29, 330.29,
 330.29, 330.22, 330.49, 330.56, 330.62, 330.76, 331.03, 330.96, 331.16,
 331.23, 331.50, 331.63, 332.03, 332.03)
y2 <- c(329.68, 329.75, 329.82, 329.95, 330.02, 330.15, 330.22, 330.36,
 330.22, 330.29, 330.29, 330.29, 330.29, 330.15, 330.22, 330.22, 330.15,
 330.15, 330.15, 330.15, 330.15, 330.29, 330.49, 330.49, 330.62, 330.89,
 331.03, 331.09, 331.16, 331.30, 331.30, 331.36, 331.43, 331.43, 331.43,
 331.36, 331.36, 331.36, 331.36, 331.23, 331.23, 331.16, 331.16, 331.23,
 331.30, 331.23, 331.36, 331.56, 331.70, 331.83, 331.97, 331.97, 332.10,
 332.30, 332.44, 332.44, 332.51, 332.51, 332.57, 332.57, 332.51, 332.37,
 332.24, 332.24, 332.10, 331.97, 331.97, 331.90, 331.83, 331.97, 331.97,
 331.97, 332.03, 332.24, 332.30, 332.30, 332.37, 332.57, 332.57, 332.57,
 332.57, 332.57, 332.51, 332.37, 332.30, 332.17, 331.97, 331.83, 331.70,
 331.70, 331.63, 331.63, 331.70, 331.83, 331.90, 332.10, 332.24, 332.30,
 332.44, 332.57, 332.71, 332.84, 332.77, 332.91, 332.84, 332.84, 332.91,
 332.84, 332.77, 332.77, 332.64, 332.64, 332.57, 332.57, 332.57, 332.57,
 332.57, 332.71, 332.98, 333.24, 333.58)
matplot(cbind(y1, y2))

However, the cross-correlation function surprisingly gives the maximum 
correlation 0.83 at zero lag:

ccf(y1, y2)

Plotting of variables against each other with zero lag

plot(y1, y2)

shows that the correlation is not that good. Instead, a very nice correlation 
is obtained with a plot with shifted variables:

plot(y1[1:113], y2[1:113 + 8])

As a comparison I defined my own cross correlation function:

cross.cor <- function(x, y, k)
{
 n <- length(x) - abs(k)
 if (k >= 0)
   cor(x[1:n + k], y[1:n])
 else
   cor(x[1:n], y[1:n - k])
}

The new function cross.cor gives maximum correlation of 0.99 at lag -8, and the 
shape of the correlation function is very different from the one obtained with 
ccf (both methods give same value at zero lag):

plot(-15:15, sapply(-15:15, function(lag) cross.cor(y1, y2, lag)),
 ylim = c(0.3, 1))
points(-15:15, ccf(y1, y2, 15, plot = FALSE)$acf, col = "red")

In order to understand the reason for the differences, I looked at the program 
codes of ccf function. When the variables are compared with a nonzero lag, some 
the data points must be left out from the tails of the time series. It appears 
to me that ccf calculates (partly in R code, partly in C code) first the means 
and the standard deviations using the whole data, and then uses those values as 
constants in further calculations. The time series are truncated only in the 
summations for covariances.

That approach naturally speeds up the computations, but is it really correct? 
Is the approach used in ccf somehow statistically more correct? I suppose the 
strong increasing trend in my test data emphasizes this issue (leaving data 
points out from one end has big impact on the average).

Best regards,
Sami Toppinen
sami.toppi...@kolumbus.fi

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

[Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread kaveh 

Dear all,

I'm working on a project that links to the BH package
(http://cran.r-project.org/web/packages/BH/index.html).

My packages doesn't call entry points which might terminate R nor
write to stdout/stderr instead of to the console.

However, it seems some of the codes in the BH package
might. At any rate, when I include some boost headers such as
boost/math/distributions/ through BH, I get the following warnings
 when  submitting to the win-builder page:


  Found '_ZSt4cerr', possibly from 'std::cerr' (C++)

  Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)

  Found '_ZSt4cerr', possibly from 'std::cerr' (C++)

  Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)


 Furthermore, these warnings disappear when remove the boost
 headers and replace the call to boost functions by constants.

Looking at the CRAN-check diagnostics of some other packages that link to
BH, I do not see similar warnings, so I suppose it is possible to fix 
this issue.

Looking at their source code, it is not clear to me how these authors have
managed to do this, but this might be because I'm not that familiar with
boost to begin with. Can someone point me to some solution to this problem?

Thanks in advance,

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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread Dirk Eddelbuettel 

On 4 November 2014 at 14:37, kaveh wrote:
| Dear all,
| 
| I'm working on a project that links to the BH package
| (http://cran.r-project.org/web/packages/BH/index.html).
| 
| My packages doesn't call entry points which might terminate R nor
| write to stdout/stderr instead of to the console.
| 
| However, it seems some of the codes in the BH package
| might. At any rate, when I include some boost headers such as
| boost/math/distributions/ through BH, I get the following warnings
|   when  submitting to the win-builder page:
| 
| 
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| 
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| 
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| 
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| 
| 
|   Furthermore, these warnings disappear when remove the boost
|   headers and replace the call to boost functions by constants.
| 
| Looking at the CRAN-check diagnostics of some other packages that link to
| BH, I do not see similar warnings, so I suppose it is possible to fix 
| this issue.
| Looking at their source code, it is not clear to me how these authors have
| managed to do this, but this might be because I'm not that familiar with
| boost to begin with. Can someone point me to some solution to this problem?

Briefly:

i) Your subject line is wrong.  You do not "link" to BH, you use it to
include headers at compile time. That may seem like a small difference, but
it is not. You generally want to avoid linking as much as you can, if only
for cross-OS portability,

ii) This the R-devel list for R question. You have a package question. You
are generally advised to contact __the package authors__ and/or the package
mailing list. And yes, BH has one in

http://lists.r-forge.r-project.org/pipermail/boostheaders-devel/

though I grant you that it is not as well advertised as it should be. I just
opened a ticket at https://github.com/eddelbuettel/bh/issues/3 to remind
myself to improve that.

iii) As for your problem, only you and some careful bisections can help you
there as we do not have your sources.  I too have packages including BH
headers, but they do not pull in abort() or other things the CRAN gatekeepers
prohibit us from deploying.

Dirk
aka your friendly neighborhood BH maintainer

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

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

[Rd] Volunteers for Google Code-in mentor & co-admin/admin

2014-11-04 Thread Gaurav Sehrawat 
Hello everyone ,

I would like to bring everyone's attention to this thread :
https://groups.google.com/forum/#!topic/gsoc-r/dtYY_5NBvyc .

R-project has been participating for Google Summer of Code since long time
. This R-project is planning for Google Code-in ,to introduce school kids
about the r-language .

If anyone is available to volunteer for the same , that would be great .

More about code-in is here :
http://www.google-melange.com/gci/homepage/google/gci2014

Thanks

Cheers

[[alternative HTML version deleted]]

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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread Romain François 

> Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel  a écrit :
> 
> 
> On 4 November 2014 at 14:37, kaveh wrote:
> | Dear all,
> | 
> | I'm working on a project that links to the BH package
> | (http://cran.r-project.org/web/packages/BH/index.html).
> | 
> | My packages doesn't call entry points which might terminate R nor
> | write to stdout/stderr instead of to the console.
> | 
> | However, it seems some of the codes in the BH package
> | might. At any rate, when I include some boost headers such as
> | boost/math/distributions/ through BH, I get the following warnings
> |   when  submitting to the win-builder page:
> | 
> | 
> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> | 
> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> | 
> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
> | 
> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)

You’re kind of out of luck. These functions are both:
 - used by the boost headers
 - forbidden by R, well at least forbidden by CRAN

> |   Furthermore, these warnings disappear when remove the boost
> |   headers and replace the call to boost functions by constants.
> | 
> | Looking at the CRAN-check diagnostics of some other packages that link to
> | BH, I do not see similar warnings, so I suppose it is possible to fix 
> | this issue.
> | Looking at their source code, it is not clear to me how these authors have
> | managed to do this, but this might be because I'm not that familiar with
> | boost to begin with. Can someone point me to some solution to this problem?
> 
> Briefly:
> 
> i) Your subject line is wrong.  You do not "link" to BH, you use it to
> include headers at compile time. That may seem like a small difference, but
> it is not. You generally want to avoid linking as much as you can, if only
> for cross-OS portability,

How would you not expect someone to be confused when « not linking to » BH 
requires the use of the `LinkingTo: BH` in the DESCRIPTION file. 

> ii) This the R-devel list for R question. You have a package question. You
> are generally advised to contact __the package authors__ and/or the package
> mailing list. And yes, BH has one in
> 
>http://lists.r-forge.r-project.org/pipermail/boostheaders-devel/
> 
> though I grant you that it is not as well advertised as it should be. I just
> opened a ticket at https://github.com/eddelbuettel/bh/issues/3 to remind
> myself to improve that.
> 
> iii) As for your problem, only you and some careful bisections can help you
> there as we do not have your sources.  I too have packages including BH
> headers, but they do not pull in abort() or other things the CRAN gatekeepers
> prohibit us from deploying.
> 
> Dirk
> aka your friendly neighborhood BH maintainer
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> 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] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread kaveh 

Dear Romain,



/You’re kind of out of luck. These functions are both:
  - used by the boost headers
  - forbidden by R, well at least forbidden by CRAN
/

//

Thanks for conforming my earlier fears. Since I only use
this header and would like my package to eventually be
on CRAN, I was thinking of bypassing BH and just putting
these headers in the /inst directory and modifying them
to remove the offending calls. I was wondering what your
view on this is. Or perhaps there is a simpler alternative?

Thanks in advance,



On 2014-11-04 21:46, Romain François wrote:
>> Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel  a écrit :
>>
>>
>> On 4 November 2014 at 14:37, kaveh wrote:
>> | Dear all,
>> |
>> | I'm working on a project that links to the BH package
>> | (http://cran.r-project.org/web/packages/BH/index.html).
>> |
>> | My packages doesn't call entry points which might terminate R nor
>> | write to stdout/stderr instead of to the console.
>> |
>> | However, it seems some of the codes in the BH package
>> | might. At any rate, when I include some boost headers such as
>> | boost/math/distributions/ through BH, I get the following warnings
>> |   when  submitting to the win-builder page:
>> |
>> |
>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
>> |
>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>> |
>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
>> |
>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
> You’re kind of out of luck. These functions are both:
>   - used by the boost headers
>   - forbidden by R, well at least forbidden by CRAN
>


[[alternative HTML version deleted]]

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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread Romain François 

> Le 4 nov. 2014 à 21:52, kaveh  a écrit :
> 
> 
> Dear Romain, 
> 
> 
> 
> You’re kind of out of luck. These functions are both:
>  - used by the boost headers
>  - forbidden by R, well at least forbidden by CRAN
> 
> 
> Thanks for conforming my earlier fears. Since I only use 
> this header and would like my package to eventually be 
> on CRAN, I was thinking of bypassing BH and just putting 
> these headers in the /inst directory and modifying them 
> to remove the offending calls. I was wondering what your 
> view on this is. Or perhaps there is a simpler alternative?
> 
> Thanks in advance, 

If you go through the hoops of modifying these headers to fulfill R’s 
requirements, I’m sure it would be of interest to others if you contribute 
these back to BH. 

The danger obviously is that this gets out of sync with boost, which would 
create work for merging your changes to new boost files from the future. 

Some parts of boost (e.g. uBlas) have macros to control whether or not 
std::cerr is used at all. 
https://github.com/eddelbuettel/bh/blob/cb1427c27dc068c8328fd1d2f4b1b8a8da1957c2/inst/include/boost/numeric/ublas/exception.hpp#L215
 


But I don’t think this is of any relevance to the files you want to use. 

Romain

> On 2014-11-04 21:46, Romain François wrote:
>>> Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel  
>>>  a écrit :
>>> 
>>> 
>>> On 4 November 2014 at 14:37, kaveh wrote:
>>> | Dear all,
>>> | 
>>> | I'm working on a project that links to the BH package
>>> | (http://cran.r-project.org/web/packages/BH/index.html 
>>> ).
>>> | 
>>> | My packages doesn't call entry points which might terminate R nor
>>> | write to stdout/stderr instead of to the console.
>>> | 
>>> | However, it seems some of the codes in the BH package
>>> | might. At any rate, when I include some boost headers such as
>>> | boost/math/distributions/ through BH, I get the following warnings
>>> |   when  submitting to the win-builder page:
>>> | 
>>> | 
>>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
>>> | 
>>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>>> | 
>>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
>>> | 
>>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>> You’re kind of out of luck. These functions are both:
>>  - used by the boost headers
>>  - forbidden by R, well at least forbidden by CRAN
>> 
> 


[[alternative HTML version deleted]]

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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread kaveh 
Dear Romain,


Thanks for all these info,


I will ponder this versus using
some of the alternatives in the R sources


Best regards,

On 2014-11-04 22:01, Romain François wrote:
>
>> Le 4 nov. 2014 à 21:52, kaveh > > a écrit :
>>
>>
>> Dear Romain,
>>
>>
>>
>> /You’re kind of out of luck. These functions are both:
>>   - used by the boost headers
>>   - forbidden by R, well at least forbidden by CRAN
>> /
>>
>> //
>>
>> Thanks for conforming my earlier fears. Since I only use
>> this header and would like my package to eventually be
>> on CRAN, I was thinking of bypassing BH and just putting
>> these headers in the /inst directory and modifying them
>> to remove the offending calls. I was wondering what your
>> view on this is. Or perhaps there is a simpler alternative?
>>
>> Thanks in advance,
>
> If you go through the hoops of modifying these headers to fulfill R’s 
> requirements, I’m sure it would be of interest to others if you 
> contribute these back to BH.
>
> The danger obviously is that this gets out of sync with boost, which 
> would create work for merging your changes to new boost files from the 
> future.
>
> Some parts of boost (e.g. uBlas) have macros to control whether or not 
> std::cerr is used at all. 
> https://github.com/eddelbuettel/bh/blob/cb1427c27dc068c8328fd1d2f4b1b8a8da1957c2/inst/include/boost/numeric/ublas/exception.hpp#L215
>
> But I don’t think this is of any relevance to the files you want to use.
>
> Romain
>
>> On 2014-11-04 21:46, Romain François wrote:
 Le 4 nov. 2014 à 15:42, Dirk Eddelbuettel  a écrit :


 On 4 November 2014 at 14:37, kaveh wrote:
 | Dear all,
 |
 | I'm working on a project that links to the BH package
 | (http://cran.r-project.org/web/packages/BH/index.html).
 |
 | My packages doesn't call entry points which might terminate R nor
 | write to stdout/stderr instead of to the console.
 |
 | However, it seems some of the codes in the BH package
 | might. At any rate, when I include some boost headers such as
 | boost/math/distributions/ through BH, I get the following warnings
 |   when  submitting to the win-builder page:
 |
 |
 |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
 |
 |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
 |
 |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
 |
 |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>>> You’re kind of out of luck. These functions are both:
>>>   - used by the boost headers
>>>   - forbidden by R, well at least forbidden by CRAN
>>>
>>
>


[[alternative HTML version deleted]]

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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread Hadley Wickham 
>> | However, it seems some of the codes in the BH package
>> | might. At any rate, when I include some boost headers such as
>> | boost/math/distributions/ through BH, I get the following warnings
>> |   when  submitting to the win-builder page:
>> |
>> |
>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
>> |
>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>> |
>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
>> |
>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
>
> You’re kind of out of luck. These functions are both:
>  - used by the boost headers
>  - forbidden by R, well at least forbidden by CRAN

Mybe - I had this note in RSQLite, and CRAN seemed ok with my explanation:

* checking compiled code ... NOTE
  File 
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
Found ‘___stderrp’, possibly from ‘stderr’ (C)
  Object: ‘sqlite-all.o’

  This is in C code from the embedded SQLite database.


Hadley

-- 
http://had.co.nz/

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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread kaveh 

Dear Hadley,

Thank you for this information, maybe the CRAN gods
will look favourably on this case too,


Best regards,

On 2014-11-04 23:32, Hadley Wickham wrote:

| However, it seems some of the codes in the BH package
| might. At any rate, when I include some boost headers such as
| boost/math/distributions/ through BH, I get the following warnings
|   when  submitting to the win-builder page:
|
|
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
|
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
|
|Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
|
|Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)

You’re kind of out of luck. These functions are both:
  - used by the boost headers
  - forbidden by R, well at least forbidden by CRAN

Mybe - I had this note in RSQLite, and CRAN seemed ok with my explanation:

* checking compiled code ... NOTE
   File 
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
 Found ‘___stderrp’, possibly from ‘stderr’ (C)
   Object: ‘sqlite-all.o’

   This is in C code from the embedded SQLite database.


Hadley



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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread Dirk Eddelbuettel 

Gentlemen,

On 4 November 2014 at 23:36, kaveh wrote:
| Dear Hadley,
| 
| Thank you for this information, maybe the CRAN gods
| will look favourably on this case too,

You seemed to have missed a point my earlier email tried to stress: Inclusion
of BH does not lead to the warning.  

All this depends on WHICH headers are included, and the OP will need to sort
this out by modifying his code.

Dirk
 
| Best regards,
| 
| On 2014-11-04 23:32, Hadley Wickham wrote:
| >>> | However, it seems some of the codes in the BH package
| >>> | might. At any rate, when I include some boost headers such as
| >>> | boost/math/distributions/ through BH, I get the following warnings
| >>> |   when  submitting to the win-builder page:
| >>> |
| >>> |
| >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >>> |
| >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >> You’re kind of out of luck. These functions are both:
| >>   - used by the boost headers
| >>   - forbidden by R, well at least forbidden by CRAN
| > Mybe - I had this note in RSQLite, and CRAN seemed ok with my 
explanation:
| >
| > * checking compiled code ... NOTE
| >File 
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
| >  Found ‘___stderrp’, possibly from ‘stderr’ (C)
| >Object: ‘sqlite-all.o’
| >
| >This is in C code from the embedded SQLite database.
| >
| >
| > Hadley
| >
| 

-- 
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] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread kaveh 

Sire,

The header that is included is

boost/math/distributions/

If I remove it and replace the calls
to its members by plain constants,
the warning disappear (I just tried
this again on http://win-builder.r-project.org/).

This leads me to the suspicion that
the header is causing the error message.

I will post a simpler source code,
tomorrow on this list.

Best regards,


On 2014-11-04 23:52, Dirk Eddelbuettel wrote:

Gentlemen,

On 4 November 2014 at 23:36, kaveh wrote:
| Dear Hadley,
|
| Thank you for this information, maybe the CRAN gods
| will look favourably on this case too,

You seemed to have missed a point my earlier email tried to stress: Inclusion
of BH does not lead to the warning.

All this depends on WHICH headers are included, and the OP will need to sort
this out by modifying his code.

Dirk
  
| Best regards,

|
| On 2014-11-04 23:32, Hadley Wickham wrote:
| >>> | However, it seems some of the codes in the BH package
| >>> | might. At any rate, when I include some boost headers such as
| >>> | boost/math/distributions/ through BH, I get the following warnings
| >>> |   when  submitting to the win-builder page:
| >>> |
| >>> |
| >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >>> |
| >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >> You’re kind of out of luck. These functions are both:
| >>   - used by the boost headers
| >>   - forbidden by R, well at least forbidden by CRAN
| > Mybe - I had this note in RSQLite, and CRAN seemed ok with my 
explanation:
| >
| > * checking compiled code ... NOTE
| >File 
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
| >  Found ‘___stderrp’, possibly from ‘stderr’ (C)
| >Object: ‘sqlite-all.o’
| >
| >This is in C code from the embedded SQLite database.
| >
| >
| > Hadley
| >
|



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

Re: [Rd] Linking to the BH package introduces CRAN warnings

2014-11-04 Thread kaveh 

Dear all,


the simple code in below, when send to the
win-builder returns the following (and no other)
warning:


* checking compiled code ... WARNING
File 'quicky/libs/i386/quicky.dll':
  Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
Object: 'quicky.o'
  Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
Object: 'quicky.o'
File 'quicky/libs/x64/quicky.dll':
  Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
Object: 'quicky.o'
  Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
Object: 'quicky.o'

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor the C RNG.

See 'Writing portable packages' in the 'Writing R Extensions' manual.


Here is the source:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 

using namespace std;
using namespace Eigen;
using Eigen::MatrixXd;
using Eigen::VectorXd;
using Eigen::VectorXi;
using Eigen::RowVectorXd;


using boost::math::chi_squared;
using boost::math::quantile;
using boost::math::complement;
using boost::math::normal_distribution;
using namespace boost::math::policies;

typedef policy<
  promote_double
  > my_policy_norm;
typedef policy<
  promote_double
  > my_policy_chi2;

typedef boost::math::normal_distribution my_norm;
typedef boost::math::chi_squared_distribution 
my_chi2;



VectorXd GetQs(const VectorXd& x){
const int n=x.size();
double mytol=1e-8;
double the_max=x.maxCoeff();
double the_min=x.minCoeff();
double the_rag=(the_max-the_min);
if(the_ragfor(int i=0;iy(i)=sqrt(quantile(complement(my_chi2(1.0),x(i;

return(y);
}
extern "C"{
void quicky(int* rn,double* xi,double* yi){
const int n=*rn;
VectorXd x=Map(xi,n);
Map(yi,n)=GetQs(x);
}
}


So I guess, I should fill a bug report with the
BH maintainer?

Best regards,


On 2014-11-04 23:52, Dirk Eddelbuettel wrote:

Gentlemen,

On 4 November 2014 at 23:36, kaveh wrote:
| Dear Hadley,
|
| Thank you for this information, maybe the CRAN gods
| will look favourably on this case too,

You seemed to have missed a point my earlier email tried to stress: Inclusion
of BH does not lead to the warning.

All this depends on WHICH headers are included, and the OP will need to sort
this out by modifying his code.

Dirk
  
| Best regards,

|
| On 2014-11-04 23:32, Hadley Wickham wrote:
| >>> | However, it seems some of the codes in the BH package
| >>> | might. At any rate, when I include some boost headers such as
| >>> | boost/math/distributions/ through BH, I get the following warnings
| >>> |   when  submitting to the win-builder page:
| >>> |
| >>> |
| >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >>> |
| >>> |Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >> You’re kind of out of luck. These functions are both:
| >>   - used by the boost headers
| >>   - forbidden by R, well at least forbidden by CRAN
| > Mybe - I had this note in RSQLite, and CRAN seemed ok with my 
explanation:
| >
| > * checking compiled code ... NOTE
| >File 
‘/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so’:
| >  Found ‘___stderrp’, possibly from ‘stderr’ (C)
| >Object: ‘sqlite-all.o’
| >
| >This is in C code from the embedded SQLite database.
| >
| >
| > Hadley
| >
|



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

[Rd] r-release, r-oldrel

2014-11-04 Thread Gábor Csárdi 
Hi All,

quick question. How does one know which R versions r-release and
r-oldrel correspond to? Is there a prefered way to determine this
programmatically?

So far I could only find messy ways, like parsing the HTML of the
homepage, or (for r-release) checking the latest R-x-x-x tag in the
SVN. The SVN is actually not bad, but how about r-oldrel? Is that
always the previous release? Or the previous minor?

Thanks, Best,
Gabor

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