Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> I just updated my copy of Cygwin to the latest version, and now Windows
> builds are failing on that machine. The only parts of the R toolset I
> changed were the Cygwin dlls. I haven't tracked down exactly what the
> problem is, and probably won't b
On 10/25/2006 11:02 PM, Gabor Grothendieck wrote:
> On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
>>> Suppose we have a function such as the following
>>>
>>> F <- function(f, x) f(x)+1
>>>
>>> which runs function f and then transforms it
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 19:16 -0700, Deepayan Sarkar wrote:
> > On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > > > Suppose we have a function such as the following
> >
On Wed, 2006-10-25 at 19:16 -0700, Deepayan Sarkar wrote:
> On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > > Suppose we have a function such as the following
> > >
> > > F <- function(f, x) f(x)+1
> > >
> > > which runs fun
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding func
On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding function which
On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
> Suppose we have a function such as the following
>
> F <- function(f, x) f(x)+1
>
> which runs function f and then transforms it. I would like the
> corresponding function which works the same except that
> unlike F returns an invisible result i
I'm observing the following on different platforms:
> parse(text='"\\x7F"')
expression("\177")
> parse(text='"\\x80"')
Error: invalid multibyte string
...
> parse(text='"\\xFF"')
Error: invalid multibyte string
However,
cat("\x7F\n\x80\n...\xFF\n")
works. Using R --vanilla.
SYSTEMS GIVING THE
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding func
Okay ... I'll try to attach that patch once more ... (does this list
only accept certain exertions for attachments? I used '.patch', but it
must have been filtered off, so I'll try '.patch.txt' now ...)
+mt
Index: R/src/library/base/man/character.Rd
==
Also, Splus 7 has a different behaviour from R:
> sapply(v, is.na)
a b c
F T T
> sapply(as.character(v), is.na)
[1] F F F
> as.character(v)
[1] "\"NA\"" "NA" "NA"
In R, it remains logical: if it isn't in character mode, then
as.character always turns NA's into "NA"'s. If that behaviour is no
On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> Suppose we have a function such as the following
>
> F <- function(f, x) f(x)+1
>
> which runs function f and then transforms it. I would like the
> corresponding function which works the same except that
> unlike F returns an invisi
Suppose we have a function such as the following
F <- function(f, x) f(x)+1
which runs function f and then transforms it. I would like the
corresponding function which works the same except that
unlike F returns an invisible result if and only if f does.
Is there some way of determining whether
Seth Falcon <[EMAIL PROTECTED]> writes:
> Hi all,
>
> In some circumstances, as.character applied to a list converts real
> NA's into the string "NA". Propagation of NAs is something R does
> very well and unless there are good reasons for losing the NA, it
> would improve the consistency w.r.t.
Hi ALL,
To fit proportional hazard Cox Model with counting
process style of input data R and S-plus implement
"(TStart,Tstop] algorithm" (agfit3.c) which uses
"smart subsets" of sorted events time. Are there any
accessible publications where the idea of this
algorithm was represented ?
Thank yo
Hi all,
In some circumstances, as.character applied to a list converts real
NA's into the string "NA". Propagation of NAs is something R does
very well and unless there are good reasons for losing the NA, it
would improve the consistency w.r.t. NA handling for as.character to
behave differently.
Some of the packages needed to be newer, as you indicated. Thanks.
--On Wednesday, October 25, 2006 7:49 PM +0200 Roger Bivand
<[EMAIL PROTECTED]> wrote:
> On Wed, 25 Oct 2006 [EMAIL PROTECTED] wrote:
>
>> Full_Name: Larry Layne
>> Version: 2.4.0
>> OS: MS Windows 2000
>> Submission from: (NULL)
On Wed, 25 Oct 2006 [EMAIL PROTECTED] wrote:
> Full_Name: Larry Layne
> Version: 2.4.0
> OS: MS Windows 2000
> Submission from: (NULL) (129.24.91.249)
>
>
> All of the following libraries loaded just fine in version 2.3.1:
Not a bug. For sp in particular, please simply re-install the contribute
Thanks for your reply, as an example it appears to have difficulty linking
to even ostream library of the standard C++, as shown below:
/home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference
to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc'
Classifier.o: In functi
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Thanks.
>
> However, that still leaves these questions:
>
> 1. I assume the changes to the internal representation of rownames is
> behind this but should not dput continue to work exactly the same as
> it used to work??? I would think that the
Dear Tom,
It has worked for me out-of-the box in at least two times, one a while ago
with R-2.2-something and recently with R-2.4.0. In both cases, I was running
Debian (with a mix of testing and unstable) on x86. I never had to do
anything, just run the script and at least in one case I did cr
Full_Name: Larry Layne
Version: 2.4.0
OS: MS Windows 2000
Submission from: (NULL) (129.24.91.249)
All of the following libraries loaded just fine in version 2.3.1:
> utils:::menuInstallLocal()
package 'tripack' successfully unpacked and MD5 sums checked
updating HTML package descriptions
> libra
You can do it like this:
> as.missing <- force
> g <- function(x = as.missing()) missing(x)
> g(3)
[1] FALSE
> g()
[1] TRUE
On 10/24/06, Paul Gilbert <[EMAIL PROTECTED]> wrote:
> (I'm not sure if this is a request for a feature, or another instance
> where a feature has eluded me for many years.)
Hi everyone,
I am trying to cross-compile a package I wrote using the Yan and Rossini
tutorial "Building Microsoft Windows versions of R and R packages using
Intel Linux". I have got reasonably far with this but when doing the
linking using the line:
i586-mingw32-g++ -shared -s -o mylibr
Peter Dalgaard wrote:
>"Charles C. Berry" <[EMAIL PROTECTED]> writes:
>
>
>
>>On Tue, 24 Oct 2006, Duncan Murdoch wrote:
>>
>>
>
>
>
>>>with no defaults. However, this little demo illustrates the point, I think:
>>>
>>>
>>>
g <- function(gnodef, gdef=1) {
>>>
Thanks.
However, that still leaves these questions:
1. I assume the changes to the internal representation of rownames is
behind this but should not dput continue to work exactly the same as
it used to work??? I would think that the internal representation aspect
would be just that -- internal a
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Is this not supposed to work?
>
> > dput(BOD, file = "/BOD.R")
> > source("/BOD.R")
> Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> row names must be 'character' or 'integer', not 'double'
>
> > dput(iris, file = "/iris.
Is this not supposed to work?
> dput(BOD, file = "/BOD.R")
> source("/BOD.R")
Error in attributes(.Data) <- c(attributes(.Data), attrib) :
row names must be 'character' or 'integer', not 'double'
> dput(iris, file = "/iris.R")
> source("/iris.R")
Error in attributes(.Data) <- c(attributes
I just updated my copy of Cygwin to the latest version, and now Windows
builds are failing on that machine. The only parts of the R toolset I
changed were the Cygwin dlls. I haven't tracked down exactly what the
problem is, and probably won't be able to do so for a few days.
So if you're a Wi
This is indeed unfortunate, but expecting Chinese speakers (20% of the
world's population) to write in Latin-1 was also unfortunate.
What I had (and still have) some hope of doing is being able to mark
character strings as UTF-8, probably via a flag bit on the CHARSXP. Then
output routines co
30 matches
Mail list logo
