[Rd] Help: Where can I find the code for 'C_Cdqrls'?
Dear all, Iâm not sure if it is O.K. to ask this question here. But where can I find the code for the function âC_Cdqrlsâ which is called by the R function âlsfitâ. Thank you all. Sorry for being naïve if so. Ziqiang Zhao 2013-04-23 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Line breaks in rd files
How can I add a new line in an rd file f.e between references? Knut __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] httpd error with and help_type = 'html', package = NULL
Having loaded a package that masks an object from another package, calling
help(conflictedname, help_type = 'html')
instead of producing a page giving the choices of help page available
The page produced is
Error in httpd("/library/NULL/help/nobs", NULL, NULL, c(48, 6f, 73, 74, :
replacement has length zero
This example is reproduced using
library(gdata)
help(nobs, help_type = 'html')
sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] gdata_2.12.0.2
loaded via a namespace (and not attached):
[1] gtools_2.7.1 tools_3.0.0
There are no issues when using help_type = 'pdf' or help_type = 'text'
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Line breaks in rd files
On 23.04.2013 11:34, Knut Krueger wrote: How can I add a new line in an rd file f.e between references? Keep a blank line between references. Uwe Ligges Knut __ 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] Help: Where can I find the code for 'C_Cdqrls'?
On 23.04.2013 09:35, 赵自强 wrote:
Dear all,
I’m not sure if it is O.K. to ask this question here.
But where can I find the code for the function ‘C_Cdqrls’
which is called by the R function ‘lsfit‘.
Look into the R sources:
grepping for dqrls shows the following relevant files:
./src/appl/dqrls.f: subroutine
dqrls(x,n,p,y,ny,tol,b,rsd,qty,k,jpvt,qraux,work)
./src/include/R_ext/Applic.h:void F77_NAME(dqrls)(double *x, int *n, int
*p, double *y, int *ny,
./src/library/stats/src/init.c:CALLDEF(Cdqrls, 3),
./src/library/stats/src/lm.c:z <- .Fortran("dqrls",
./src/library/stats/src/lm.c:SEXP Cdqrls(SEXP x, SEXP y, SEXP tol)
./src/library/stats/src/lm.c:F77_CALL(dqrls)(REAL(qr), &n, &p,
REAL(y), &ny, &rtol,
./src/library/stats/src/statsR.h:SEXP Cdqrls(SEXP x, SEXP y, SEXP tol);
Best,
Uwe Ligges
Thank you all.
Sorry for being naïve if so.
Ziqiang Zhao
2013-04-23
[[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] Help: Where can I find the code for 'C_Cdqrls'?
First, it is not a function. It is an R object in the stats namespace and you can look at it like any other object: > stats:::C_Cdqrls $name [1] "Cdqrls" $address attr(,"class") [1] "RegisteredNativeSymbol" $dll DLL name: stats Filename: /Users/ripley/R/R-devel/library/stats/libs/stats.so Dynamic lookup: FALSE $numParameters [1] 3 attr(,"class") [1] "CallRoutine" "NativeSymbolInfo" That tells you it is invoking a C function called Cdqrls: you can search from that in the sources for package stats. In fact it is in src/library/stats/src/lm.c . You would know to look in the stats namespace since you found this in a function from that namespace. Generally R's own code uses the convention of object C_foo for C entry point foo and F_bar for Fortran entry point bar (but there are exceptions, more so in R < 3.0.0). On 23/04/2013 08:35, 赵自强 wrote: Dear all, I’m not sure if it is O.K. to ask this question here. But where can I find the code for the function ‘C_Cdqrls’ which is called by the R function ‘lsfit‘. Thank you all. Sorry for being naïve if so. Ziqiang Zhao 2013-04-23 [[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] httpd error with and help_type = 'html', package = NULL
Is this not PR#15282? No one has got to it yet.
On 23/04/2013 07:32, Michael Nelson wrote:
Having loaded a package that masks an object from another package, calling
help(conflictedname, help_type = 'html')
instead of producing a page giving the choices of help page available
The page produced is
Error in httpd("/library/NULL/help/nobs", NULL, NULL, c(48, 6f, 73, 74, :
replacement has length zero
This example is reproduced using
library(gdata)
help(nobs, help_type = 'html')
sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] gdata_2.12.0.2
loaded via a namespace (and not attached):
[1] gtools_2.7.1 tools_3.0.0
There are no issues when using help_type = 'pdf' or help_type = 'text'
Michael
__
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] parallel::mclapply does not return try-error objects with mc.preschedule=TRUE
On 11/04/2013 12:43, Karl Forner wrote: Hello, Consider this: 1) library(parallel) res <- mclapply(1:2, stop) #Warning message: #In mclapply(1:2, stop) : # all scheduled cores encountered errors in user code is(res[[1]], 'try-error') #[1] FALSE 2) library(parallel) res <- mclapply(1:2, stop, mc.preschedule=FALSE) #Warning message: #In mclapply(1:2, stop, mc.preschedule = FALSE) : # 2 function calls resulted in an error is(res[[1]], 'try-error') #[1] TRUE The documentation states that: 'Each forked process runs its job inside try(..., silent = TRUE) so if errors occur they will be stored as class "try-error" objects in the return value and a warning will be given.' Is this a bug ? Not in parallel. Something else has changed, and I am about to commit a different version that still works as documented. Thanks Karl sessionInfo() R version 2.15.3 (2013-03-01) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] parallel stats graphics grDevices utils datasets methods [8] base loaded via a namespace (and not attached): [1] tools_2.15.3 __ 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] Line breaks in rd files
On 23/04/2013 5:34 AM, Knut Krueger wrote: How can I add a new line in an rd file f.e between references? As Uwe said, for a reference list a blank line between references is probably best: in most reference styles, each reference is its own paragraph. For other uses \cr will insert a break. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignettes: problems with PDF compaction
On 4/22/2013 5:51 PM, Uwe Ligges wrote:
But this doesn't do anything, not even changing the timestamp on the
file, because the file size doesn't change enough.
Either you changed it or not, there is no "not enough".
I meant that the code in tools::compact compares the sizes of the old
and new files and only replaces the old file if the change in size is
"sufficient":
if (new/old < 0.9 && new < old - 1) {
file.copy(tf, p, overwrite = TRUE)
}
At any rate, with R_GSCMD now fixed (Thx: Henrik), tools::compactPDF,
with gs_quality="ebook",
still does not reduce the size of my HE-examples.pdf file.
I tried the same on my Ubuntu system (R 2.15.2 also), and there I get
> tools::compactPDF("HE-examples.pdf", gs_quality="ebook")
compacted 'HE-examples.pdf' from 739Kb to 366Kb
So, I can now copy the compacted file back to my development tree
on Windows; however, as I understand things, vignettes are re-built
by R CMD build and --compact-vignettes=gs+qpdf has no effect.
So my Ubuntu-compacted file will be overwritten.
It's somewhat maddening to have to spend so much time to save ~373Kb
in order to avoid a CRAN warning.
--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele StreetWeb: http://www.datavis.ca
Toronto, ONT M3J 1P3 CANADA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Verbose output from R CMD check
I've been developing a package called foobar for a couple of years now. It has evolved through various versions, but has always contained compiled C code. Recently, R CMD check has started generating the following message [START QUOTE] R CMD check foobar_1.7.5.tar.gz * using log directory ‘/home/david/foobar/package/foobar.Rcheck’ * using R version 2.15.2 (2012-10-26) * using platform: x86_64-unknown-linux-gnu (64-bit) * using session charset: UTF-8 * checking for file ‘foobar/DESCRIPTION’ ... OK [LOTS OF '...OK' CHECK REPORTS REMOVED FOR BREVITY] * checking compiled code ... NOTE File ‘/home/david/foobar/package/foobar.Rcheck/foobar/libs/foobar.so’: Found ‘putchar’, possibly from ‘putchar’ (C) Object: ‘foobar.o’ Found ‘puts’, possibly from ‘printf’ (C), ‘puts’ (C) Object: ‘foobar.o’ Compiled code should not call functions which might terminate R nor write to stdout/stderr instead of to the console. See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual. * checking examples ... OK * checking PDF version of manual ... OK NOTE: There was 1 note. See ‘/home/david/foobar/package/foobar.Rcheck/00check.log’ for details. [END QUOTE] This message is recent, but appears even when I re-compile and check old versions of the package which previously passed the check without any such warning messages. My understanding is that since R 2.15.0 R CMD check has undergone numerous modifications, and as a result it is now identifying a "problem" that wasn't being identified previously. I'm currently running R 2.15.2. Identifying the source of the message is a non-trivial problem because there are a large number of calls to printf and fprintf etc in several thousands of lines of code spread over many different *.c files. So my question... is there a way to obtain a more verbose output that could point me to the lines of code that generate the message? Without this information debugging is rendered unnecessarily hard, time consuming and frustrating. many thanks David -- David Pleydell, INRA, UMR-1351 CMAEE, Domaine Duclos, Prise D'eau, 97122 Petit Bourg, Guadeloupe dpleyd...@antilles.inra.fr pleyd...@cirad.fr Tel +33 5 90 25 54 42 Fax +33 5 90 94 03 96 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parallel::mclapply does not return try-error objects with mc.preschedule=TRUE
> >> Is this a bug ? >> > > Not in parallel. Something else has changed, and I am about to commit a > different version that still works as documented. > > Thanks for replying. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Verbose output from R CMD check
On Apr 23, 2013, at 10:51 AM, dpleydell wrote: > I've been developing a package called foobar for a couple of years now. It > has evolved through various versions, but has always contained compiled C > code. Recently, R CMD check has started generating the following message > > [START QUOTE] > > R CMD check foobar_1.7.5.tar.gz > * using log directory ‘/home/david/foobar/package/foobar.Rcheck’ > * using R version 2.15.2 (2012-10-26) > * using platform: x86_64-unknown-linux-gnu (64-bit) > * using session charset: UTF-8 > * checking for file ‘foobar/DESCRIPTION’ ... OK > [LOTS OF '...OK' CHECK REPORTS REMOVED FOR BREVITY] > * checking compiled code ... NOTE > File ‘/home/david/foobar/package/foobar.Rcheck/foobar/libs/foobar.so’: > Found ‘putchar’, possibly from ‘putchar’ (C) >Object: ‘foobar.o’ > Found ‘puts’, possibly from ‘printf’ (C), ‘puts’ (C) >Object: ‘foobar.o’ > > Compiled code should not call functions which might terminate R nor write to > stdout/stderr instead of to the console. > > See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual. > * checking examples ... OK > * checking PDF version of manual ... OK > > NOTE: There was 1 note. > See ‘/home/david/foobar/package/foobar.Rcheck/00check.log’ for details. > > [END QUOTE] > > This message is recent, but appears even when I re-compile and check old > versions of the package which previously passed the check without any such > warning messages. > > My understanding is that since R 2.15.0 R CMD check has undergone numerous > modifications, and as a result it is now identifying a "problem" that wasn't > being identified previously. I'm currently running R 2.15.2. > > Identifying the source of the message is a non-trivial problem because there > are a large number of calls to printf and fprintf etc in several thousands of > lines of code spread over many different *.c files. > There should be none, so apparently you have broken the rules quite a lot ;). This is not a new rule, R just got better at identifying the transgressions. Number of lines in your code is quite irrelevant - that's why there is grep and the search function in editors. > So my question... is there a way to obtain a more verbose output that could > point me to the lines of code that generate the message? Without this > information debugging is rendered unnecessarily hard, time consuming and > frustrating. > It's not "unnecessarily hard" - it fact it's much easier to find this out from the sources than the compiled code which is how R has to identify it which makes it impossible to track the source (because it could have been from a static library, for example). Cheers, Simon > many thanks > David > > > -- > David Pleydell, > INRA, > UMR-1351 CMAEE, > Domaine Duclos, > Prise D'eau, > 97122 Petit Bourg, > Guadeloupe > dpleyd...@antilles.inra.fr > pleyd...@cirad.fr > Tel +33 5 90 25 54 42 > Fax +33 5 90 94 03 96 > > __ > 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] Verbose output from R CMD check
Many thanks Simon for your response
>> Identifying the source of the message is a non-trivial problem because there
>> are a large number of calls to printf and fprintf etc in several thousands
>> of lines of code spread over many different *.c files.
>>
> There should be none, so apparently you have broken the rules quite a lot ;).
> This is not a new rule, R just got better at identifying the transgressions.
> Number of lines in your code is quite irrelevant - that's why there is grep
> and the search function in editors.
Well, that wouldn't be the first time I've broken rules ;0)
But, how bad could the consequences of my misbehaviour be here? Are we
talking about crashing R or just messing the output a little?
In Writing R Extensions (current on-line version) the worst they say
about printf is
[QUOTE]
The most useful function for printing from a C routine compiled into R
is |Rprintf|. This is used in exactly the same way as |printf|, but is
guaranteed to write to R's output (which might be a GUI console rather
than a file, and can be re-directed by |sink|).
[UNQUOTE]
and both printf and fprintf are used in section 8.2.2 in the rtest.c
example. Also, the manual does not say explicitly what fprintf should be
replaced with.
Come to think of it... my package performs MCMC and uses fprintf to
write samples to an output file. I have noticed that once in each nth
blue-moon (for large n) a single line of output has been dropped or
scrambled. More frequently, the updates of the output file seem to lag
behind the progress of the algorithm's principal loop - for example,
file size becomes non-zero much later than I expect. I never understood
this behaviour or saw how to rectify it. Perhaps replacing fprintf with
something else could "guarantee" the end of this undesirable behaviour?
Great!
Is there a "safe" way to re-write the following?
fprintf(fMCMCout, "%d %e %e ", iteration, posteriorLoglik, parameter);
if (numberRandomEffects > 1) {
for (k=0; k < numberRandomEffects; k++) {
fprintf(fMCMCout, "%e ", randomEffects[k]);
}
fprintf(fMCMCout,"\n");
This is really a question of 2 parts
1) what is the best replacement of fprintf in the above?
and
2) Writing R Extensions says "It is wise to write complete lines
(including the |"\n"|) before returning to R.", so is it legal to defer
\n as in the example above?
many thanks
David
--
David Pleydell,
INRA,
UMR-1351 CMAEE,
Domaine Duclos,
Prise D'eau,
97122 Petit Bourg,
Guadeloupe
dpleyd...@antilles.inra.fr
pleyd...@cirad.fr
Tel +33 5 90 25 54 42
Fax +33 5 90 94 03 96
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.name and namespaces
'as.name' doesn't recognize a name with
its namespace extension as a name:
> as.name("lm")
lm
> as.name("stats::lm")
`stats::lm`
> as.name("stats:::lm")
`stats:::lm`
Is there a reason why it shouldn't?
Pat
--
Patrick Burns
pbu...@pburns.seanet.com
twitter: @burnsstat @portfolioprobe
http://www.portfolioprobe.com/blog
http://www.burns-stat.com
(home of:
'Impatient R'
'The R Inferno'
'Tao Te Programming')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.name and namespaces
On Apr 23, 2013, at 19:23 , Patrick Burns wrote:
> 'as.name' doesn't recognize a name with
> its namespace extension as a name:
>
> > as.name("lm")
> lm
> > as.name("stats::lm")
> `stats::lm`
> > as.name("stats:::lm")
> `stats:::lm`
>
>
> Is there a reason why it shouldn't?
Any reason why it should? :: and ::: are operators. foo$bar is not the same as
`foo$bar` either.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
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] httpd error with and help_type = 'html', package = NULL
On 23/04/2013 9:07 AM, Prof Brian Ripley wrote:
Is this not PR#15282? No one has got to it yet.
Fixed now in R-devel; just testing R-patched.
Duncan Murdoch
On 23/04/2013 07:32, Michael Nelson wrote:
> Having loaded a package that masks an object from another package, calling
>
>
> help(conflictedname, help_type = 'html')
>
>
> instead of producing a page giving the choices of help page available
>
> The page produced is
>
> Error in httpd("/library/NULL/help/nobs", NULL, NULL, c(48, 6f, 73, 74, :
>replacement has length zero
>
>
> This example is reproduced using
>
> library(gdata)
> help(nobs, help_type = 'html')
>
>
>
> sessionInfo()
> R version 3.0.0 (2013-04-03)
> Platform: i386-w64-mingw32/i386 (32-bit)
>
> locale:
> [1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] gdata_2.12.0.2
>
> loaded via a namespace (and not attached):
> [1] gtools_2.7.1 tools_3.0.0
>
>
> There are no issues when using help_type = 'pdf' or help_type = 'text'
>
>
> Michael
>
> __
> 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] as.name and namespaces
Okay, that's a good reason why it shouldn't.
Why it should is that I want to substitute
the first element of a call to be a function
including the namespace.
Pat
On 23/04/2013 18:32, peter dalgaard wrote:
On Apr 23, 2013, at 19:23 , Patrick Burns wrote:
'as.name' doesn't recognize a name with
its namespace extension as a name:
as.name("lm")
lm
as.name("stats::lm")
`stats::lm`
as.name("stats:::lm")
`stats:::lm`
Is there a reason why it shouldn't?
Any reason why it should? :: and ::: are operators. foo$bar is not the same as
`foo$bar` either.
--
Patrick Burns
pbu...@pburns.seanet.com
twitter: @burnsstat @portfolioprobe
http://www.portfolioprobe.com/blog
http://www.burns-stat.com
(home of:
'Impatient R'
'The R Inferno'
'Tao Te Programming')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.name and namespaces
On Apr 23, 2013, at 21:51 , Patrick Burns wrote:
> Okay, that's a good reason why it shouldn't.
>
> Why it should is that I want to substitute
> the first element of a call to be a function
> including the namespace.
Offhand, I'd say that it shouldn't be a problem, but do you have a more
concrete example?
-pd
>
> Pat
>
>
> On 23/04/2013 18:32, peter dalgaard wrote:
>>
>> On Apr 23, 2013, at 19:23 , Patrick Burns wrote:
>>
>>> 'as.name' doesn't recognize a name with
>>> its namespace extension as a name:
>>>
as.name("lm")
>>> lm
as.name("stats::lm")
>>> `stats::lm`
as.name("stats:::lm")
>>> `stats:::lm`
>>>
>>>
>>> Is there a reason why it shouldn't?
>>
>> Any reason why it should? :: and ::: are operators. foo$bar is not the same
>> as `foo$bar` either.
>>
>
> --
> Patrick Burns
> pbu...@pburns.seanet.com
> twitter: @burnsstat @portfolioprobe
> http://www.portfolioprobe.com/blog
> http://www.burns-stat.com
> (home of:
> 'Impatient R'
> 'The R Inferno'
> 'Tao Te Programming')
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
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] as.name and namespaces
On 13-04-23 3:51 PM, Patrick Burns wrote:
Okay, that's a good reason why it shouldn't.
Why it should is that I want to substitute
the first element of a call to be a function
including the namespace.
Three ways:
1. Assign the function from the namespace locally, then call the local one.
2. Import the function in your NAMESPACE (if you know the name in advance).
3. Construct an expression involving ::, and substitute that in.
For example:
substitute(foo(x), list(foo=quote(baz::bar)))
Duncan Murdoch
Pat
On 23/04/2013 18:32, peter dalgaard wrote:
On Apr 23, 2013, at 19:23 , Patrick Burns wrote:
'as.name' doesn't recognize a name with
its namespace extension as a name:
as.name("lm")
lm
as.name("stats::lm")
`stats::lm`
as.name("stats:::lm")
`stats:::lm`
Is there a reason why it shouldn't?
Any reason why it should? :: and ::: are operators. foo$bar is not the same as
`foo$bar` either.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] about the 'length' arg of vector()
Hi,
In the man page for vector():
length: A non-negative integer specifying the desired length. Double
values will be coerced to integer: supplying an argument of
length other than one is an error.
Since long vectors are supported, it doesn't seem to be true anymore
that "double values will be coerced to integer":
> bigraw <- vector("raw", 3e9)
> length(bigraw)
[1] 3e+09
> storage.mode(length(bigraw))
[1] "double"
At least not always...
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Verbose output from R CMD check
On Apr 23, 2013, at 12:43 PM, dpleydell wrote:
> Many thanks Simon for your response
>>> Identifying the source of the message is a non-trivial problem because
>>> there are a large number of calls to printf and fprintf etc in several
>>> thousands of lines of code spread over many different *.c files.
>>>
>>>
>> There should be none, so apparently you have broken the rules quite a lot
>> ;). This is not a new rule, R just got better at identifying the
>> transgressions. Number of lines in your code is quite irrelevant - that's
>> why there is grep and the search function in editors.
>>
>
> Well, that wouldn't be the first time I've broken rules ;0)
>
> But, how bad could the consequences of my misbehaviour be here? Are we
> talking about crashing R or just messing the output a little?
>
We're not talking life and death here ;) - yes, frustrated users because of
messed up output is the main danger here. Also the behavior changes by GUI and
platform, so throw in inconsistency charge as well.
To be precise, there are two issues: a) the output on stdout/stderr is not
necessarily visible (e.g. the Windows GUI discards it) and it is separate from
the console (e.g. sink() doesn't work on it). More importantly b) it messes up
the use of R in streaming, i.e. uses where you are processing input on stdin
and streaming output on stdout -- it will break the output. This is most
frustrating because the user has no way to control this behavior other than
deleting the offending package.
> In Writing R Extensions (current on-line version) the worst they say about
> printf is
>
> [QUOTE]
> The most useful function for printing from a C routine compiled into R is
> Rprintf. This is used in exactly the same way as printf, but is guaranteed to
> write to R's output (which might be a GUI console rather than a file, and can
> be re-directed by sink).
> [UNQUOTE]
>
> and both printf and fprintf are used in section 8.2.2 in the rtest.c example.
> Also, the manual does not say explicitly what fprintf should be replaced with.
>
fprintf() is ok as long as you don't use it with stdout/stderr. You can use it
for files, no problem there.
> Come to think of it... my package performs MCMC and uses fprintf to write
> samples to an output file. I have noticed that once in each nth blue-moon
> (for large n) a single line of output has been dropped or scrambled. More
> frequently, the updates of the output file seem to lag behind the progress of
> the algorithm's principal loop - for example, file size becomes non-zero much
> later than I expect.
Typically, I/O is buffered, so the file is not necessarily updated after you
use fprintf(). By default, it will get updated only after the output buffer has
been filled. You can use fflush() to flush the output buffer to disk
immediately (alternatively you can mark the stream as unbuffered).
> I never understood this behaviour or saw how to rectify it. Perhaps replacing
> fprintf with something else could "guarantee" the end of this undesirable
> behaviour? Great!
>
> Is there a "safe" way to re-write the following?
>
> fprintf(fMCMCout, "%d %e %e ", iteration, posteriorLoglik, parameter);
> if (numberRandomEffects > 1) {
> for (k=0; k < numberRandomEffects; k++) {
> fprintf(fMCMCout, "%e ", randomEffects[k]);
> }
> fprintf(fMCMCout,"\n");
>
> This is really a question of 2 parts
> 1) what is the best replacement of fprintf in the above?
If MCMCout is a file, the above is fine.
> and
> 2) Writing R Extensions says "It is wise to write complete lines (including
> the "\n") before returning to R.", so is it legal to defer \n as in the
> example above?
>
Yes, sure.
Cheers,
Simon
> many thanks
> David
>
>
>
>
>
> --
> David Pleydell,
> INRA,
> UMR-1351 CMAEE,
> Domaine Duclos,
> Prise D'eau,
> 97122 Petit Bourg,
> Guadeloupe
>
> dpleyd...@antilles.inra.fr
> pleyd...@cirad.fr
>
> Tel +33 5 90 25 54 42
> Fax +33 5 90 94 03 96
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is.vector(as.vector(x, m), m) not always TRUE
In the man page for as.vector() (same as man page for vector()):
Writers of methods for ‘as.vector’ need to take care to follow the
conventions of the default method. In particular
• Argument ‘mode’ can be ‘"any"’, any of the atomic modes,
‘"list"’, ‘"expression"’, ‘"symbol"’, ‘"pairlist"’ or one of
the aliases ‘"double"’ and ‘"name"’.
• The return value should be of the appropriate mode. For
‘mode = "any"’ this means an atomic vector or list.
• Attributes should be treated appropriately: in particular
when the result is an atomic vector there should be no
attributes, not even names.
• ‘is.vector(as.vector(x, m), m)’ should be true for any mode
‘m’, including the default ‘"any"’.
But:
> is.vector(as.vector("a", "name"), "name")
[1] FALSE
Mmmh, the default method itself doesn't seem to follow its own
conventions :-/
Cheers,
H.
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with S3 method dispatch and NAMESPACE
I have updated the rms package to extensively use NAMESPACE. I cannot get certain S3 methods to dispatch. For example I have in NAMESPACE S3method(anova, rms) S3method(latex, anova.rms) anova.rms produces an object of class "anova.rms" and there is a latex.anova.rms function in rms. But when I do latex(anova(fit)) I get an invocation of latex.default. I have tried using "anova.rms" and `anova.rms` in S3method() to no avail. Any help appreciated. I'm using R 2.15.3 Frank - Frank Harrell Department of Biostatistics, Vanderbilt University -- View this message in context: http://r.789695.n4.nabble.com/Problem-with-S3-method-dispatch-and-NAMESPACE-tp4665179.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] multiple issues with is.unsorted()
Hi,
In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0 or 1 are
sorted: the result will be ‘NA’ for objects of length 2 or more
except for atomic vectors and objects with a class (where the ‘>=’
or ‘>’ method is used to compare ‘x[i]’ with ‘x[i-1]’ for ‘i’ in
‘2:length(x)’).
This contains many incorrect statements:
> length(NA)
[1] 1
> is.unsorted(NA)
[1] NA
> length(list(NA))
[1] 1
> is.unsorted(list(NA))
[1] NA
=> Contradicts "all objects of length 0 or 1 are sorted".
> is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type 'raw' in
'isUnsorted'
=> Doesn't agree with the doc (unless "except for atomic vectors"
means "it might fail for atomic vectors").
> setClass("A", representation(aa="integer"))
> a <- new("A", aa=4:1)
> length(a)
[1] 1
> is.unsorted(a)
[1] FALSE
Warning message:
In is.na(x) : is.na() applied to non-(list or vector) of type 'S4'
=> Ok, but it's arguable the warning is useful/justified from a user
point of view. The warning *seems* to suggest that defining an
"is.na" method for my objects is required for is.unsorted() to
work properly but the doc doesn't make this clear.
Anyway, let's define one, so the warning goes away:
> setMethod("is.na", "A", function(x) is.na(x@aa))
[1] "is.na"
Let's define a "length" method:
> setMethod("length", "A", function(x) length(x@aa))
[1] "length"
> length(a)
[1] 4
> is.unsorted(a)
[1] FALSE
=> Is this correct? Hard to know. The doc is not clear about what
should happen for objects of length 2 or more and with a class
but with no ">=" or ">" methods.
Let's define "[", ">=", and ">":
> setMethod("[", "A", function(x, i, j, ..., drop=TRUE) new("A",
aa=x@aa[i]))
[1] "["
> rev(a)
An object of class "A"
Slot "aa":
[1] 1 2 3 4
> setMethod(">=", c("A", "A"), function(e1, e2) {e1@aa >= e2@aa})
[1] ">="
> a >= a[3]
[1] TRUE TRUE TRUE FALSE
> setMethod(">", c("A", "A"), function(e1, e2) {e1@aa > e2@aa})
[1] ">"
> a > a[3]
[1] TRUE TRUE FALSE FALSE
> is.unsorted(a)
[1] FALSE
> is.unsorted(rev(a))
[1] FALSE
Still not working as expected. So what's required exactly for making
is.unsorted() work on an object "with a class"?
BTW, is.unsorted() would be *much* faster, at least on atomic vectors,
without those calls to is.na(). The C code could check for NAs, without
having to do this as a first pass on the full vector like it is the
case with the current implementation. If the vector if unsorted, the
C code is typically able to bail out early so the speed-up will
typically be 1x or more if the vector as millions of elements.
Thanks,
H.
> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.0.0
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.vector(as.vector(x, m), m) not always TRUE
On Apr 24, 2013, at 01:48 , Hervé Pagès wrote:
> In the man page for as.vector() (same as man page for vector()):
>
> Writers of methods for ‘as.vector’ need to take care to follow the
> conventions of the default method. In particular
>
>• Argument ‘mode’ can be ‘"any"’, any of the atomic modes,
> ‘"list"’, ‘"expression"’, ‘"symbol"’, ‘"pairlist"’ or one of
> the aliases ‘"double"’ and ‘"name"’.
>
>• The return value should be of the appropriate mode. For
> ‘mode = "any"’ this means an atomic vector or list.
>
>• Attributes should be treated appropriately: in particular
> when the result is an atomic vector there should be no
> attributes, not even names.
>
>• ‘is.vector(as.vector(x, m), m)’ should be true for any mode
> ‘m’, including the default ‘"any"’.
>
> But:
>
> > is.vector(as.vector("a", "name"), "name")
> [1] FALSE
>
> Mmmh, the default method itself doesn't seem to follow its own
> conventions :-/
>
Looks like there should be a straightforward fix, since
> is.vector(as.vector("a", "name"), "symbol")
[1] TRUE
so it is just a matter of implementing "name" as synomyous with "symbol".
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
