[Rd] mistake in Italian translation
Hi all.
I'm not sure I should send this here, but the link to the Italian
Traslation Team is dead here:
http://developer.r-project.org/TranslationTeams.html
I've found an annoying mistake in the italian traslation of a base
error message:
##
> d <- data.frame(a=1)
> d$a <- 1:2
Errore in `$<-.data.frame`(`*tmp*`, "a", value = 1:2) :
dati sostitutivi con %righe, i dati ne hanno 1
##
This is a little cryptic message for the final user, if compared with this:
##
> Sys.setlocale('LC_MESSAGES','C')
[1] "C"
> d$a <- 1:2
Error in `$<-.data.frame`(`*tmp*`, "a", value = 1:2) :
replacement has 2 rows, data has 1
##
Find attached the proposed patch against revision 43697.
Bests,
Antonio.
--
Antonio, Fabio Di Narzo
Ph.D. student at
Department of Statistical Sciences
University of Bologna, Italy
diff --git a/src/library/base/po/R-it.po b/src/library/base/po/R-it.po
index d7c77a9..0b9a6d7 100644
--- a/src/library/base/po/R-it.po
+++ b/src/library/base/po/R-it.po
@@ -316,7 +316,7 @@ msgid "duplicate subscripts for columns"
msgstr "indici doppi nelle colonne"
msgid "replacement has %d rows, data has %d"
-msgstr "dati sostitutivi con %righe, i dati ne hanno %d"
+msgstr "dati sostitutivi con %d righe, i dati ne hanno %d"
msgid "replacement has %d items, need %d"
msgstr "il sostituto ha %d elementi, ne servono %d"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] APARCH?
I have made the same notification.
In the case of Asymmetric power ARCH (APARCH), garchFit and garchOxFit commands
give remarkably different results. Instead of that with normal garch model, the
results are exactly same. So, there must be some mistake in the garchFit
commands.
Best regards,
Allan Pe
Researcher
> Date: Wed, 12 Dec 2007 18:07:34 +0200
> From: [EMAIL PROTECTED]
> To: r-devel@r-project.org
> Subject: [Rd] APARCH
>
>
> Hi,
>
> Could somebody say if it is possible to compute APARCH-models with garchFit
> commands.
>
> I have earlier used aaa (garchOxFit) and now I try to use bbb (look below)
>
> aaa <-
> garchOxFit(formula.mean=~arma(1,0),formula.var=~aparch(1,1),series=nyk,cond.dist=c('gaussian'))
>
>
> bbb <- garchFit(formula=~arma(1,0)+aparch(1,1),data=nyk)
>
> aaa works well, but I need other characteristics of garchFit and, therefore it
> would be important to know what's wrong with my bbb command (the value of
> delta
> is fixed to 2 and I get totally different coefficients than with aaa).
>
> How should I write bbb to get similar answer than with aaa?
>
> Thanks a lot,
>
> Veikko
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
_
Joululahjaksi joukko uusia ja ilmaisia Windows Live palveluja!
http://get.live.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wrong length of POSIXt vectors (PR#10507)
On 15/12/2007 5:17 PM, Martin Maechler wrote:
>> "TP" == Tony Plate <[EMAIL PROTECTED]>
>> on Fri, 14 Dec 2007 13:58:30 -0700 writes:
>
> TP> Duncan Murdoch wrote:
> >> On 12/13/2007 1:59 PM, Tony Plate wrote:
> >>> Duncan Murdoch wrote:
> On 12/11/2007 6:20 AM, [EMAIL PROTECTED] wrote:
> > Full_Name: Petr Simecek
> > Version: 2.5.1, 2.6.1
> > OS: Windows XP
> > Submission from: (NULL) (195.113.231.2)
> >
> >
> > Several times I have experienced that a length of a POSIXt vector
> > has not been
> > computed right.
> >
> > Example:
> >
> > tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31
> > ), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L
> > ), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L, 12L, 12L),
> > mday = c(13L, 13L, 13L, 13L, 13L, 13L, 13L, NA, 13L, 13L, 13L), mon
> > = c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L,
> > 105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday =
> > c(1L, 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L, 163L,
> > 163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L,
> > 1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec", "min",
> > "hour", "mday", "mon", "year", "wday", "yday", "isdst"
> > ), class = c("POSIXt", "POSIXlt"))
> >
> > print(tv)
> > # print 11 time points (right)
> >
> > length(tv)
> > # returns 9 (wrong)
>
> tv is a list of length 9. The answer is right, your expectation is
> wrong.
> > I have tried that on several computers with/without switching to
> > English
> > locales, i.e. Sys.setlocale("LC_TIME", "en"). I have searched a
> > help pages but I
> > cannot imagine how that could be OK.
>
> See this in ?POSIXt:
>
> Class '"POSIXlt"' is a named list of vectors...
>
> You could define your own length measurement as
>
> length.POSIXlt <- function(x) length(x$sec)
>
> and you'll get the answer you expect, but be aware that length.XXX
> methods are quite rare, and you may surprise some of your users.
>
> >>>
> >>> On the other hand, isn't the fact that length() currently always
> >>> returns 9 for POSIXlt objects likely to be a surprise to many users
> >>> of POSIXlt?
> >>>
> >>> The back of "The New S Language" says "Easy-to-use facilities allow
> >>> you to organize, store and retrieve all sorts of data. ... S
> >>> functions and data organization make applications easy to write."
> >>>
> >>> Now, POSIXlt has methods for c() and vector subsetting "[" (and many
> >>> other vector-manipulation methods - see methods(class="POSIXlt")).
> >>> Hence, from the point of view of intending to supply "easy-to-use
> >>> facilities ... [for] all sorts of data", isn't it a little
> >>> incongruous that length() is not also provided -- as 3 functions (any
> >>> others?) comprise a core set of vector-manipulation functions?
> >>>
> >>> Would it make sense to have an informal prescription (e.g., in
> >>> R-exts) that a class that implements a vector-like object and
> >>> provides at least of one of functions 'c', '[' and 'length' should
> >>> provide all three? It would also be easy to describe a test-suite
> >>> that should be included in the 'test' directory of a package
> >>> implementing such a class, that had some tests of the basic
> >>> vector-manipulation functionality, such as:
> >>>
> >>> > # at this point, x0, x1, x3, & x10 should exist, as vectors of the
> >>> > # class being tested, of length 0, 1, 3, and 10, and they should
> >>> > # contain no duplicate elements
> >>> > length(x0)
> >>> [1] 1
> >>> > length(c(x0, x1))
> >>> [1] 2
> >>> > length(c(x1,x10))
> >>> [1] 11
> >>> > all(x3 == x3[seq(len=length(x3))])
> >>> [1] TRUE
> >>> > all(x3 == c(x3[1], x3[2], x3[3]))
> >>> [1] TRUE
> >>> > length(c(x3[2], x10[5:7]))
> >>> [1] 4
> >>> >
> >>>
> >>> It would also be possible to describe a larger set of vector
> >>> manipulation functions that should be implemented together, including
> >>> e.g., 'rep', 'unique', 'duplicated', '==', 'sort', '[<-', 'is.na',
> >>> head, tail ... (many of which are provided for POSIXlt).
> >>>
> >>> Or is there some good reason that length() cannot be provided (while
> >>> 'c' and '[' can) for some vector-like classes such as "POSIXlt"?
> >>
> >> What you say sounds good in general, but the devil is in the details.
> >> Changing the meaning of length(x)
Re: [Rd] mistake in Italian translation
I think we no longer have an active Italian translation team. I'll make
the change you suggest.
On Sun, 16 Dec 2007, Antonio, Fabio Di Narzo wrote:
> Hi all.
> I'm not sure I should send this here, but the link to the Italian
> Traslation Team is dead here:
> http://developer.r-project.org/TranslationTeams.html
>
> I've found an annoying mistake in the italian traslation of a base
> error message:
> ##
>> d <- data.frame(a=1)
>> d$a <- 1:2
> Errore in `$<-.data.frame`(`*tmp*`, "a", value = 1:2) :
> dati sostitutivi con %righe, i dati ne hanno 1
> ##
>
> This is a little cryptic message for the final user, if compared with this:
> ##
>> Sys.setlocale('LC_MESSAGES','C')
> [1] "C"
>> d$a <- 1:2
> Error in `$<-.data.frame`(`*tmp*`, "a", value = 1:2) :
> replacement has 2 rows, data has 1
> ##
>
> Find attached the proposed patch against revision 43697.
>
> Bests,
> Antonio.
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] mistake in Italian translation
I'll try to revise the translations for 2.7.0
And Antonio is right, that link is broken. Will fix.
stefano
On 17/dic/07, at 03:01, Prof Brian Ripley wrote:
> I think we no longer have an active Italian translation team. I'll
> make
> the change you suggest.
>
> On Sun, 16 Dec 2007, Antonio, Fabio Di Narzo wrote:
>
>> Hi all.
>> I'm not sure I should send this here, but the link to the Italian
>> Traslation Team is dead here:
>> http://developer.r-project.org/TranslationTeams.html
>>
>> I've found an annoying mistake in the italian traslation of a base
>> error message:
>> ##
>>> d <- data.frame(a=1)
>>> d$a <- 1:2
>> Errore in `$<-.data.frame`(`*tmp*`, "a", value = 1:2) :
>> dati sostitutivi con %righe, i dati ne hanno 1
>> ##
>>
>> This is a little cryptic message for the final user, if compared
>> with this:
>> ##
>>> Sys.setlocale('LC_MESSAGES','C')
>> [1] "C"
>>> d$a <- 1:2
>> Error in `$<-.data.frame`(`*tmp*`, "a", value = 1:2) :
>> replacement has 2 rows, data has 1
>> ##
>>
>> Find attached the proposed patch against revision 43697.
>>
>> Bests,
>> Antonio.
>>
>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] guidelines for consistency of vector functions
Moving on from the discussion of the fact that length(x)==9 for any
POSIXlt object x (which seems diabolically confusing, given that 'c' and
'[' are defined for POSIXlt and have the vector-like behavior one would
expect), what about having some guidelines for coding and documentation
of vector-like classes?
(1) a vector-like class should implement functions in groups:
level 1: 'c', '[', 'length'
level 2: 'x[i] <- value', 'rep', 'unique', 'duplicated'
level 3: 'head', 'tail', 'sort'
NA group: 'is.na' 'x[i] <- NA' 'is.na(x) <- TRUE'
character coercion: 'as.character', 'as..character'
names group: 'names()' 'names()<-'
[should '==', 'all.equal' be included anywhere]
If any member of a group is implemented, then it is considered good
style to implement the others.
(2) conformance or deviation from this guideline should be documented on
the help page for the class.
These could go in a section of R-ext, and a function that automatically
checks conformance could also be supplied as part of R. A rough version
of such a function is attached.
This would have the following benefits:
(1) developers would have guidelines and tools to help them write
classes that behave in a way that users expect
(2) users would know better what to expect, both in general, and in
specific cases where developers followed the documentation guidelines.
(3) observance of the guidelines would be an indicator of software
quality (no evidence of any attention to the guidelines would be a sign
that the code was more of an experiment than a piece of software that
was carefully engineered for widespread use.)
All of the above is a rough draft that could be discussed further (e.g.,
should '[.<-' go in level 1 or level 2?) if there was any interest in
pursuing this suggestion.
Comments?
-- Tony Plate
PS:
Here's a few examples of running an automatic vector-functionality
tester on some vector-like classes in R ("basic"="level 1",
"extra"="level 2", and "bonus"="level 3" functions) (this might be hard
to read if line wrapping happens -- I've attached text files):
> source("testVectorFunctionality.R")
> library(chron)
> if (exists("length.POSIXlt")) remove(list="length.POSIXlt")
>
> ### 'character' passes the functionality tests
> res <- testVectorFunctionality(CLASS="character", verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### 'numeric' passes the functionality tests
> res <- testVectorFunctionality(CLASS="numeric", verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### 'integer' passes the functionality tests
> res <- testVectorFunctionality(CLASS="integer", verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### 'Date' passes the functionality tests
> res <- testVectorFunctionality(from.numeric=function(i)
as.Date("2001/01/01") + i, verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### chron 'times' passes the basic, but not the extra functionality tests
> res <- testVectorFunctionality(from.numeric=function(i)
chron(times=i), verbose=FALSE)
Failed 0 of 17 basic tests, 12 of 17 extra tests, and 0 of 0 bonus tests
> res <- testVectorFunctionality(from.numeric=function(i)
chron(times=i), verbose=TRUE)
Testing basic vector functionality for class 'times'
Testing extra vector functionality for class 'times'
Failed consistency check: unique(xa) == xa
Failed consistency check: unique(xb) == xb
Failed consistency check: unique(x0) == x0
Failed consistency check: unique(x1) == x1
Failed consistency check: unique(xA) == xA[!duplicated(xA)]
Failed consistency check: rep(x1, 3) == c(x1, x1, x1)
Failed consistency check: rep(xa, 3) == c(xa, xa, xa)
Failed consistency check: rep(xb, 2) == c(xb, xb)
Failed consistency check: rep(x1, 0) == x1[0]
Failed consistency check: rep(xa, each = 3) == xa[rep(seq(len =
xa.len), each = 3)]
Failed consistency check: rep(xb, each = 2) == xb[rep(seq(len =
xb.len), each = 2)]
Failed consistency check: rep(xa, length.out = xa.len + 1) == c(xa,
xa[1])
In 17 basic consistency tests on 'times', had the following outcomes: ok:17
'ok' tests (17) involved: '[':4, c:9, length:9
In 17 extra consistency tests on 'times', had the following outcomes:
failure:12, ok:5
'failure' tests (12) involved: duplicated:1, rep:7, unique:5
'ok' tests (5) involved: duplicated:5
Did not perform any bonus consistency tests on 'times'
>
> ### chron 'dates' does not pass the basic functionality tests
> res <- testVectorFunctionality(from.numeric=function(i) chron(i),
verbose=FALSE)
Failed 6 of 17 basic tests, 0 of 0 extra tests, and 0 of 0 bonus tests
> res <- testVectorFunctionality(from.numeric=function(i) chron(i),
verbose=TRUE)
Testing basic vector functionality for class ['dates', 'times']
Failed consistency check: c(x1) == x1
Failed consistency check: c(x1, x0) == x1
Failed consistency check: c(x0, x1) == x1
Failed cons
Re: [Rd] Wrong length of POSIXt vectors (PR#10507)
Duncan Murdoch wrote:
> On 15/12/2007 5:17 PM, Martin Maechler wrote:
>>> "TP" == Tony Plate <[EMAIL PROTECTED]>
>>> on Fri, 14 Dec 2007 13:58:30 -0700 writes:
>> TP> Duncan Murdoch wrote:
>> >> On 12/13/2007 1:59 PM, Tony Plate wrote:
>> >>> Duncan Murdoch wrote:
>> On 12/11/2007 6:20 AM, [EMAIL PROTECTED] wrote:
>> > Full_Name: Petr Simecek
>> > Version: 2.5.1, 2.6.1
>> > OS: Windows XP
>> > Submission from: (NULL) (195.113.231.2)
>> >
>> >
>> > Several times I have experienced that a length of a POSIXt vector
>> > has not been
>> > computed right.
>> >
>> > Example:
>> >
>> > tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31
>> > ), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L
>> > ), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L, 12L, 12L),
>> > mday = c(13L, 13L, 13L, 13L, 13L, 13L, 13L, NA, 13L, 13L, 13L),
>> mon
>> > = c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L,
>> > 105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday =
>> > c(1L, 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L,
>> 163L,
>> > 163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L,
>> > 1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec",
>> "min",
>> > "hour", "mday", "mon", "year", "wday", "yday", "isdst"
>> > ), class = c("POSIXt", "POSIXlt"))
>> >
>> > print(tv)
>> > # print 11 time points (right)
>> >
>> > length(tv)
>> > # returns 9 (wrong)
>>
>> tv is a list of length 9. The answer is right, your expectation is
>> wrong.
>> > I have tried that on several computers with/without switching to
>> > English
>> > locales, i.e. Sys.setlocale("LC_TIME", "en"). I have searched a
>> > help pages but I
>> > cannot imagine how that could be OK.
>>
>> See this in ?POSIXt:
>>
>> Class '"POSIXlt"' is a named list of vectors...
>>
>> You could define your own length measurement as
>>
>> length.POSIXlt <- function(x) length(x$sec)
>>
>> and you'll get the answer you expect, but be aware that length.XXX
>> methods are quite rare, and you may surprise some of your users.
>>
>> >>>
>> >>> On the other hand, isn't the fact that length() currently always
>> >>> returns 9 for POSIXlt objects likely to be a surprise to many users
>> >>> of POSIXlt?
>> >>>
>> >>> The back of "The New S Language" says "Easy-to-use facilities allow
>> >>> you to organize, store and retrieve all sorts of data. ... S
>> >>> functions and data organization make applications easy to write."
>> >>>
>> >>> Now, POSIXlt has methods for c() and vector subsetting "[" (and many
>> >>> other vector-manipulation methods - see methods(class="POSIXlt")).
>> >>> Hence, from the point of view of intending to supply "easy-to-use
>> >>> facilities ... [for] all sorts of data", isn't it a little
>> >>> incongruous that length() is not also provided -- as 3 functions
>> (any
>> >>> others?) comprise a core set of vector-manipulation functions?
>> >>>
>> >>> Would it make sense to have an informal prescription (e.g., in
>> >>> R-exts) that a class that implements a vector-like object and
>> >>> provides at least of one of functions 'c', '[' and 'length' should
>> >>> provide all three? It would also be easy to describe a test-suite
>> >>> that should be included in the 'test' directory of a package
>> >>> implementing such a class, that had some tests of the basic
>> >>> vector-manipulation functionality, such as:
>> >>>
>> >>> > # at this point, x0, x1, x3, & x10 should exist, as vectors of the
>> >>> > # class being tested, of length 0, 1, 3, and 10, and they should
>> >>> > # contain no duplicate elements
>> >>> > length(x0)
>> >>> [1] 1
>> >>> > length(c(x0, x1))
>> >>> [1] 2
>> >>> > length(c(x1,x10))
>> >>> [1] 11
>> >>> > all(x3 == x3[seq(len=length(x3))])
>> >>> [1] TRUE
>> >>> > all(x3 == c(x3[1], x3[2], x3[3]))
>> >>> [1] TRUE
>> >>> > length(c(x3[2], x10[5:7]))
>> >>> [1] 4
>> >>> >
>> >>>
>> >>> It would also be possible to describe a larger set of vector
>> >>> manipulation functions that should be implemented together,
>> including
>> >>> e.g., 'rep', 'unique', 'duplicated', '==', 'sort', '[<-', 'is.na',
>> >>> head, tail ... (many of which are provided for POSIXlt).
>> >>>
>> >>> Or is there some good reason that length() cannot be provided (while
>> >>> 'c' and '[' can) for some vector-like classes such as
Re: [Rd] Defaults for postscript()
I think you should change anything you want to change, on the assumption that most users are setting things by themselves, anyway. Now may be the time to change anything that you (and those kind enough to reply to your post) would like to see changed. For an example, I really like the ratio of font size to default plot size that I see in windows on my OSX machine, and would love it if pdf (which I use instead of postscript), produced similar geometry. I find pdf() produces a sort of "spaced out" appearance, with large fonts and lots of spacing, and that's great for giving lectures, but for papers I always set the page width to 10 inches or more, simply to get a higher ratio of data to labels. -- View this message in context: http://www.nabble.com/Defaults-for-postscript%28%29-tp14188096p14366644.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
