[Rd] failure in `setClass' examples
Hello,
Below is what I got running the examples from `setClass'. Could somebody
please help explain why the last `setIs' call is returning the warning and
whether this is expected?
R> setClass("track",
+ representation(x="numeric", y="numeric"))
[1] "track"
R> setClass("trackCurve",
+ representation("track", smooth = "numeric"))
[1] "trackCurve"
R> setClass("trackMultiCurve",
+ representation(x="numeric", y="matrix", smooth="matrix"),
+ prototype = list(x=numeric(), y=matrix(0,0,0),
+smooth= matrix(0,0,0)))
[1] "trackMultiCurve"
R> try(setIs("trackMultiCurve", "trackCurve",
+ test = function(obj) {ncol(slot(obj, "y")) == 1}))
Warning message:
there is no automatic definition for as(object, "trackCurve") <- value when
object has class "trackMultiCurve" and no 'replace' argument was supplied;
replacement will be an error in: makeExtends(class1, class2, coerce, test,
replace, by, classDef1 = classDef,
R> setIs("trackMultiCurve", "trackCurve",
+test = function(obj) {ncol(slot(obj, "y")) == 1},
+coerce = function(obj) {
+ new("trackCurve",
+ x = slot(obj, "x"),
+ y = as.numeric(slot(obj,"y")),
+ smooth = as.numeric(slot(obj, "smooth")))
+})
Warning message:
there is no automatic definition for as(object, "trackCurve") <- value when
object has class "trackMultiCurve" and no 'replace' argument was supplied;
replacement will be an error in: makeExtends(class1, class2, coerce, test,
replace, by, classDef1 = classDef,
R> version
_
platform i486-pc-linux-gnu
arch i486
os linux-gnu
system i486, linux-gnu
status
major2
minor2.0
year 2005
month10
day 06
svn rev 35749
language R
Thanks in advance,
--
Sebastian P. Luque
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] failure in `setClass' examples
John Chambers <[EMAIL PROTECTED]> wrote: > There's nothing bad happening, and we should remove the setIs() example > from the setClass() documentation. > If you run example(setIs), you will see a slightly different version of > the same call to setIs(), but one that does not generate the warning > (because it includes the argument replace= to setIs()). Comparing the > two calls and looking at the documentation for setIs should explain > where the warning comes from. But in any case, nothing to worry about. Thank you, things are much clearer after reading the setIs() documentation. Cheers, -- Sebastian P. Luque __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] chron vs. POSIX
Hi, One of the big decisions when writing code is how to handle dates and times. Gabor Grothendieck provided an excellent overview of the issue in his R News 4/1 (2004) article, and many users and developers are probably using it as a guide. The proposed guideline is to use the simplest class required; as Gabor put it "use Date if possible, otherwise use chron, and otherwise use POSIX". This seems to me a very efficient strategy, judging from my own experiences and those of others users. All but the simplest calculations with POSIX objects demand great care, due to time zone and and daylight savings considerations. Therefore, I've always chosen chron for relatively complex projects, where I don't need to deal with time zones or daylight savings problems. The ease with which objects can be switched from numeric to chron representations is a major advantage IMHO¹. If Gabor's recommendations are to be followed, wouldn't it make sense to include chron in base R? Given that flexibility for handling time variables is so fundamental, the addition of chron to base R would provide users everything they need to work with time, without the need to rely on an external package. What do others think? + *Footnotes* + ¹ This is possible with POSIX classes too by using the structure() function, but a post by Brian Ripley to the effect that it may not be practical in the long term further convinced me of this. -- Sebastian P. Luque Department of Biology Memorial University of Newfoundland [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: On 14 July 2006 at 14:38, Sebastian Luque wrote: | If Gabor's recommendations are to be followed, wouldn't it make sense to | include chron in base R? Given that flexibility for handling time Future historians will provide a fuller account of the extended debates, but my reading of these discussions here over the last few years leaves me with the impression that Gabor is arguing for chron in a manner that is simultaneously informed, polite, persistent and yet ... utterly isolated. Date and POSIXt have served me well over the last few years. They are maintained and being extended [ 1 ]. Chron, to the best of my knowledge, is dead code so I'd bet against it appearing in core R any time soon. Regards, Dirk [ 1 ] I had some pleasant exchanges with Brian Ripley where I was able to suggest a few extension relative to the new millisecond granularity in POSIXt and its interfaces. -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
[Sorry for my previous empty post]
Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> On 14 July 2006 at 14:38, Sebastian Luque wrote:
> | If Gabor's recommendations are to be followed, wouldn't it make sense
> | to include chron in base R? Given that flexibility for handling time
> Future historians will provide a fuller account of the extended debates,
> but my reading of these discussions here over the last few years leaves
> me with the impression that Gabor is arguing for chron in a manner that
> is simultaneously informed, polite, persistent and yet ... utterly
> isolated.
> Date and POSIXt have served me well over the last few years. They are
> maintained and being extended [ 1 ]. Chron, to the best of my knowledge,
> is dead code so I'd bet against it appearing in core R any time soon.
That is not true, as Gabor pointed out. At any rate, I can't understand
why there's only a choice between a dates-only class and another one
including every detail of time in R base. As mentioned in Gabor's R News
article, the latter requires the user to pay attention to time zones and
daylight savings details that are completely irrelevant in some cases.
The drawbacks of using POSIX classes, in cases where TZ and DS are
irrelevant, can be quite serious when writing relatively complex code¹.
[...]
Cheers,
+ *Footnotes* +
¹ In addition to the list in the R News article, there's also issues with
TZ attribute being lost after operations such as 'sapply' with POSIX
objects. Spotting that problem, and how to recover your POSIX object
after that is not as simple as doing chron('sapply return value').
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
