[Rd] checking Rd cross-references ... WARNING
Dear all I am getting this strange error when checking my package. Would you have an idea what causes it? Thank you Liviu * checking Rd cross-references ... WARNING Error in .find.package(package, lib.loc) : there is no package called 'KernSmooth' Calls: -> lapply -> FUN -> .find.package Execution halted > sessionInfo () R version 2.10.0 (2009-10-26) x86_64-pc-linux-gnu locale: [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] datasets grid splines graphics stats utils grDevices tcltk methods base other attached packages: [1] fortunes_1.3-6 RcmdrPlugin.HH_1.1-25HH_2.1-32 leaps_2.9 [5] multcomp_1.1-2 mvtnorm_0.9-8lattice_0.17-26 RcmdrPlugin.sos_0.1-0 [9] tcltk2_1.1-1 RcmdrPlugin.Export_0.3-0 Hmisc_3.7-0 survival_2.35-7 [13] xtable_1.5-6 Rcmdr_1.5-4 car_1.2-16 relimp_1.0-1 [17] sos_1.2-4brew_1.0-3 hints_1.0.1-1 loaded via a namespace (and not attached): [1] cluster_1.12.1 -- Do you know how to read? http://www.alienetworks.com/srtest.cfm Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking Rd cross-references ... WARNING
Liviu Andronic wrote: Dear all I am getting this strange error when checking my package. Would you have an idea what causes it? Thank you Liviu * checking Rd cross-references ... WARNING Error in .find.package(package, lib.loc) : there is no package called 'KernSmooth' Calls: -> lapply -> FUN -> .find.package Execution halted sessionInfo () R version 2.10.0 (2009-10-26) Do you get the same message in 2.10.1? Duncan Murdoch x86_64-pc-linux-gnu locale: [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_GB.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] datasets grid splines graphics stats utils grDevices tcltk methods base other attached packages: [1] fortunes_1.3-6 RcmdrPlugin.HH_1.1-25HH_2.1-32 leaps_2.9 [5] multcomp_1.1-2 mvtnorm_0.9-8lattice_0.17-26 RcmdrPlugin.sos_0.1-0 [9] tcltk2_1.1-1 RcmdrPlugin.Export_0.3-0 Hmisc_3.7-0 survival_2.35-7 [13] xtable_1.5-6 Rcmdr_1.5-4 car_1.2-16 relimp_1.0-1 [17] sos_1.2-4brew_1.0-3 hints_1.0.1-1 loaded via a namespace (and not attached): [1] cluster_1.12.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal for new axis.Date/axis.POSIXct
Hi R-devel.
I've noticed a couple of quirks in the current time/date axis
functions (axis.Date, axis.POSIXct, and the equivalents in lattice).
Looking at the code, it seems like a fairly ad-hoc approach, often
using pretty() on components of the time. This is not always ideal -
for example a one-hour interval gets cut into 10-minute chunks rather
than the more natural 15-minute chunks (since pretty() doesn't know
about the minutes in an hour, etc). Generally the number of tick marks
produced varies a lot, and there are a couple of strange cases: try
plot(0:1 ~ as.POSIXct(paste(2002:2003,"-02-01",sep="")))
So, I've written a function prettyDate() that attempts to act like
pretty(), but with dates and times. Like pretty, it takes arguments
'n' and 'min.n' which specify the desired and minimum number of ticks,
respectively.
http://pastie.org/751640
By the way, also listed there is an extension of trunc.POSIXt with
extra units "weeks", "months", "years", "decades", "centuries".
Following is a test of prettyDate() for axis labelling, drawn for a
sequence of different time intervals.
source("http://pastie.org/751640.txt";)
steps <-
list("10 secs",
"1 min", "5 mins", "10 mins", "15 mins", "30 mins",
"1 hour", "3 hours", "6 hours", "12 hours",
"1 DSTday", "1 week", "2 weeks",
"1 month", "3 months", "6 months",
"1 year", "2 years", "5 years", "10 years",
"20 years", "50 years", "100 years")
names(steps) <- paste("span =", unlist(steps))
from <- as.POSIXct("2002-02-02 02:02")
devAskNewPage(TRUE)
lapply(steps, function(s) {
times <- seq(from, by = s, length = 2)
plot(0:1 ~ times, yaxt = "n", ylab = "")
x <- mean(par("usr")[1:2])
text(x, 0.5, paste("span:", s), cex = 2)
text(x, 0.33, paste(format(times), collapse="\n"))
text(x, 0.05, "current axis.POSIXct")
text(x, 0.95, "proposed new prettyDate axis")
## draw new proposed axis function at top of plot
timelim <- par("usr")[1:2]
mostattributes(timelim) <- attributes(from)
axis(side = 3, at = prettyDate(timelim),
labels = prettyDate(timelim, do.format=TRUE))
})
devAskNewPage(FALSE)
Is it appropriate / desirable for this to be incorporated into R?
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking Rd cross-references ... WARNING
Hello On 12/21/09, Duncan Murdoch wrote: > > R version 2.10.0 (2009-10-26) > > Do you get the same message in 2.10.1? > I no longer get the warning after I installed r-recommended and r-cran-kernsmooth, without upgrading to 2.10.1. Perhaps this is a Debian specific issue. Regards Liviu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] a little bug for the function 'sprintf' (PR#14161)
Dear R-ers,
I am a gratuate student from South China University of Technology. I fond
the function 'sprintf' in R2.10.1 have a little bug(?):
When you type in the example codes:
> sprintf("%s is %f feet tall\n", "Sven", 7.1)
and R returns:
[1] "Sven is 7.10 feet tall\n"
this is very different from the 'sprintf' function in C/C++, for in C/C++,
the format string "\n" usually represents a new line, but here, just
the plain text "\n"!
Is it a bug, or a deliberate design?
Thanks for your attention!
Best wishes!
Yours sincerely,
Baoli Qin
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cut.POSIXt problem with breaks= "quarter" (PR#14162)
Full_Name: Qing Xia
Version: 2.10.0
OS: Windows XP
Submission from: (NULL) (213.71.23.233)
I find, when I use "cut" function to cut date-time objects based on breaks =
"quarter", there exists a problem. It means, if the date-time has "-MM-30"
or "-MM-31", then "cut" runs not correctly, it gives wrong levels. Detail
can be found in the following R-Output:
1. correct Output levels, if there is no date-time "-MM-30" or "-MM-31"
> x<- as.Date(c("2009-03-21","2009-03-24"))
> cut(x, breaks= "quarter")
[1] 2009-01-01 2009-01-01
Levels: 2009-01-01
2. wrong Output levels, if there exists date-time "-MM-30" or "-MM-31"
> x<- as.Date(c("2009-03-21","2009-03-30"))
> cut(x, breaks= "quarter")
[1] 2009-01-01 2009-01-01
Levels: 2009-01-01 2009-04-01
> x<- as.Date(c("2009-03-21","2009-03-31"))
> cut(x, breaks= "quarter")
[1] 2009-01-01 2009-01-01
Levels: 2009-01-01 2009-04-01
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a little bug for the function 'sprintf' (PR#14161)
baoli...@gmail.com wrote:
Dear R-ers,
I am a gratuate student from South China University of Technology. I fond
the function 'sprintf' in R2.10.1 have a little bug(?):
When you type in the example codes:
sprintf("%s is %f feet tall\n", "Sven", 7.1)
and R returns:
[1] "Sven is 7.10 feet tall\n"
this is very different from the 'sprintf' function in C/C++, for in C/C++,
the format string "\n" usually represents a new line, but here, just
the plain text "\n"!
No, this is exactly the same as in C/C++. If you compare the result of
sprintf to "Sven is 7.10 feet tall\n" with strcmp() in C, they will
compare equal.
> s <- sprintf("%s is %f feet tall\n", "Sven", 7.1)
> s
[1] "Sven is 7.10 feet tall\n"
> nchar(s)
[1] 27
> substr(s,27,27)
[1] "\n"
The thing that is confusing you is that strings are DISPLAYED using the
same escape-character mechanisms as used for input. Compare
> cat(s)
Sven is 7.10 feet tall
>
Is it a bug, or a deliberate design?
Design, not bug (and please don't file as bug when you are in doubt.)
Thanks for your attention!
Best wishes!
Yours sincerely,
Baoli Qin
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cut.POSIXt problem with breaks= "quarter" (PR#14162)
as.yearqtr in the zoo package could be used as a workaround until cut is fixed.
> as.yearqtr(as.Date(c("2009-03-21","2009-03-31")))
[1] "2009 Q1" "2009 Q1"
> as.Date(as.yearqtr(as.Date(c("2009-03-21","2009-03-31"
[1] "2009-01-01" "2009-01-01"
On Mon, Dec 21, 2009 at 7:45 AM, wrote:
> Full_Name: Qing Xia
> Version: 2.10.0
> OS: Windows XP
> Submission from: (NULL) (213.71.23.233)
>
>
> I find, when I use "cut" function to cut date-time objects based on breaks =
> "quarter", there exists a problem. It means, if the date-time has "-MM-30"
> or "-MM-31", then "cut" runs not correctly, it gives wrong levels. Detail
> can be found in the following R-Output:
>
> 1. correct Output levels, if there is no date-time "-MM-30" or
> "-MM-31"
>
>> x<- as.Date(c("2009-03-21","2009-03-24"))
>> cut(x, breaks= "quarter")
> [1] 2009-01-01 2009-01-01
> Levels: 2009-01-01
>
>
> 2. wrong Output levels, if there exists date-time "-MM-30" or "-MM-31"
>
>> x<- as.Date(c("2009-03-21","2009-03-30"))
>> cut(x, breaks= "quarter")
> [1] 2009-01-01 2009-01-01
> Levels: 2009-01-01 2009-04-01
>
>
>> x<- as.Date(c("2009-03-21","2009-03-31"))
>> cut(x, breaks= "quarter")
> [1] 2009-01-01 2009-01-01
> Levels: 2009-01-01 2009-04-01
>
> __
> 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] a little bug for the function 'sprintf' (PR#14161)
> When you type in the example codes:
>
> > sprintf("%s is %f feet tall\n", "Sven", 7.1)
>
> and R returns:
>
> [1] "Sven is 7.10 feet tall\n"
>
> this is very different from the 'sprintf' function in C/C++, for in C/C++,
> the format string "\n" usually represents a new line, but here, just
> the plain text "\n"!
The function sprintf() produces a string, which is then printed
using R formatting. You probably expected the following.
> cat(sprintf("%s is %f feet tall\n", "Sven", 7.1))
Sven is 7.10 feet tall
Compare also
> s <- sprintf("%s is %f feet tall\n", "Sven", 7.1)
> cat(s)
Sven is 7.10 feet tall
> print(s)
[1] "Sven is 7.10 feet tall\n"
>
PS.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a little bug for the function 'sprintf' (PR#14161)
On 21-Dec-09 17:36:12, Peter Dalgaard wrote:
> baoli...@gmail.com wrote:
>> Dear R-ers,
>> I am a gratuate student from South China University of Technology.
>> I fond the function 'sprintf' in R2.10.1 have a little bug(?):
>>
>> When you type in the example codes:
>>
>>> sprintf("%s is %f feet tall\n", "Sven", 7.1)
>>
>> and R returns:
>>
>> [1] "Sven is 7.10 feet tall\n"
>>
>> this is very different from the 'sprintf' function in C/C++,
>> for in C/C++, the format string "\n" usually represents a new line,
>> but here, just the plain text "\n"!
>
> No, this is exactly the same as in C/C++. If you compare the result
> of sprintf to "Sven is 7.10 feet tall\n" with strcmp() in C,
> they will compare equal.
>
> > s <- sprintf("%s is %f feet tall\n", "Sven", 7.1)
> > s
> [1] "Sven is 7.10 feet tall\n"
> > nchar(s)
> [1] 27
> > substr(s,27,27)
> [1] "\n"
>
> The thing that is confusing you is that strings are DISPLAYED
> using the same escape-character mechanisms as used for input.
> Compare
>
> > cat(s)
> Sven is 7.10 feet tall
> >
>
>>
>> Is it a bug, or a deliberate design?
>
> Design, not bug (and please don't file as bug when you are in doubt.)
And another confusion is that the C/C++ function sprintf() indeed
creates a string AND ASSIGNS IT TO A NAMED VARIABLE, according to
the syntax
int sprintf(char *str, const char *format, ...);
as in
char *X ;
sprintf(X,"%s is %f feet tall\n", "Sven", 7.1) ;
as a result of which the string X will have the value
"Sven is 7.10 feet tall\n"
R's sprintf does not provide for the parameter "Char *str", here X,
and so RETURNS the string as the value of the function.
This is NOT TO BE CONFUSED with the behaviour of the C/C++ functions
printf() and fprintf(), both of which create the string and then
send it to either stdout or to a file:
int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);
Therefore, if you programmed
printf("%s is %f feet tall\n", "Sven", 7.1) ;
you would see on-screen (stdout) the string
"Sven is 7.10 feet tall"
(followed by a line-break due to the "\n"), while
mystream = fopen("myoutput.txt",a) ;
fprintf(mystream, "%s is %f feet tall\n", "Sven", 7.1) ;
would append
"Sven is 7.10 feet tall"
(followed by a line-break) to myoutput.txt
Hoping this helps!
Ted.
E-Mail: (Ted Harding)
Fax-to-email: +44 (0)870 094 0861
Date: 21-Dec-09 Time: 18:14:57
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a little bug for the function 'sprintf' (PR#14161)
> The thing that is confusing you is that strings are DISPLAYED using the same > escape-character mechanisms as used for input. Compare > >> cat(s) > Sven is 7.10 feet tall See also: http://en.wikipedia.org/wiki/The_Treachery_of_Images http://www.youtube.com/watch?v=sShMA85pv8M Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
