In building R 2.6.2 from source for Mac OS X 2.5.1 (with
i686-apple-darwin9-gcc-4.0.1), 'make check' fails. The failure is in
reg-plot.R, and occurs because Mac OS X's 'tr' command (invoked by Rdiff
to strip carriage returns) regards the dagger sign in reg-plot.ps as an
illegal byte sequence.
On 17/02/2008 8:35 AM, [EMAIL PROTECTED] wrote:
In building R 2.6.2 from source for Mac OS X 2.5.1 (with
i686-apple-darwin9-gcc-4.0.1), 'make check' fails. The failure is in
reg-plot.R, and occurs because Mac OS X's 'tr' command (invoked by Rdiff
to strip carriage returns) regards the dagger
Please do as we ask in both the FAQ and posting guide and check the
current working copy of R, which does this differently.
On Sun, 17 Feb 2008, [EMAIL PROTECTED] wrote:
In building R 2.6.2 from source for Mac OS X 2.5.1 (with
i686-apple-darwin9-gcc-4.0.1), 'make check' fails. The failure is
Hi,
I'm just wondering does anyone know of a good site that would assist me in
creating a spam filter through R? It is for a college project. I have
searched the net but cannot find anything of relevance. Any help would be
greatly appreciated
Regards,
--
View this message in context:
On 17 February 2008 at 06:35, hoogeebear wrote:
| I'm just wondering does anyone know of a good site that would assist me in
| creating a spam filter through R? It is for a college project. I have
| searched the net but cannot find anything of relevance. Any help would be
| greatly
I'd like to have two packages with S4 classes with the same name but
different implementation. To that end I create a package tmpA with
setClass(A,
representation=representation(
x=numeric),
sealed=TRUE)
setClass(B,
representation=representation(
OK. Good point.
Note that that article was written 4 years ago
when R was at version 1.9 and POSIXt did not fully support
subseconds. At that time, POSIXct could represent subseconds
internally but it was not used as POSIXlt did not yet support it
and that and the associated digits.sec option
Hi Gabo,
FAQ 7.31 does not apply to this. numeric in R is 64bit which is large eno=
ugh to handle this.
I
figured out the cause is that Sys.time() gives millisecond value while
b-as.POSIXct(format(a,tz=3DGMT)) cuts off that part.=20
Then of course a-b is not 5 hours!
Do it again with
Yea I thought that would be the story behind it. Thanks.
Date: Sun, 17 Feb 2008 16:15:27 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Rd] Arithmetic bug? (found when use POSIXct) (PR#10776)
CC: [EMAIL PROTECTED]
OK. Good point.
Note that that article was written
