On Tue, 6 Nov 2007, [EMAIL PROTECTED] wrote:
> Unfortunately I think it would break too much existing code. tapply()
> is an old function and many people have gotten used to the way it works
> now.
It is also not necessarily desirable: FUN(numeric(0)) might be an error.
For example:
> Z <- data
What OS was that compiler built for? This happened when you had a
version of gcc built for the wrong version of the OS, as gcc captures
system headers. (There's a warning about that in the R-admin manual.)
The 'report to' message is autogenerated by autoconf.
SunStudio 11 is a recent version
Unfortunately I think it would break too much existing code. tapply()
is an old function and many people have gotten used to the way it works
now.
This is not to suggest there could not be another argument added at the
end to indicate that you want the new behaviour, though. e.g.
tapply <- fun
Dear R-developers,
when tapply() is invoked on factors that have empty levels, it returns
NA. This behaviour is in accord with the tapply documentation, and is
reasonable in many cases. However, when FUN is sum, it would also
seem reasonable to return 0 instead of NA, because "the sum of an
empt
This just information of my experience installing R on SunOS 5.9
today, not a request for help.
(in case anyone cares, and if not, I apologize for the distraction)
I am building R 2.6.0 (patched; svn revision 43319, 2007-11-01) and
encountered the problem described below.
I believe the problem
On 05/11/2007 3:48 PM, Liaw, Andy wrote:
> Hello everyone,
>
> I'm trying to update the locfit package so that it passes package check
> in R 2.6.0. However, the check seems to think some of the functions
> with dot in the names are S3 methods (thus warns about the format of the
> \usage{} part)
Hello everyone,
I'm trying to update the locfit package so that it passes package check
in R 2.6.0. However, the check seems to think some of the functions
with dot in the names are S3 methods (thus warns about the format of the
\usage{} part) when they are not. Can anyone recommend a workaround
On Mon, 5 Nov 2007, Fabian Scheipl wrote:
> Wouldn't it make programming more error-resistant if vectors were
> initialized with missing data, instad of zeroes or ""?
Lots of code relies on this. It's common programming practice (and not
just in R/S).
> That way, if you assign values to a vect
Wouldn't it make programming more error-resistant if vectors were
initialized with missing data, instad of zeroes or ""?
That way, if you assign values to a vector elementwise and you miss some
elements
(because their indices were not selected or because the assignment didn't
work out, see below f
On Mon, 5 Nov 2007, "Jens Oehlschlägel" wrote:
Dear all,
I have defined a generic as.ff(x, ...) and a method as.ff.function(x, ...)
which converts a standard R function x into a chunked version operating on
large ff objects. Everything works fine, but when registering
S3method("as.ff",functi
On 11/5/2007 7:41 AM, Jens Oehlschlägel wrote:
> Dear all,
>
> I have defined a generic as.ff(x, ...) and a method as.ff.function(x, ...)
> which converts a standard R function x into a chunked version operating on
> large ff objects. Everything works fine, but when registering
>
> S3method("a
Dear all,
I have defined a generic as.ff(x, ...) and a method as.ff.function(x, ...)
which converts a standard R function x into a chunked version operating on
large ff objects. Everything works fine, but when registering
S3method("as.ff",function)
in NAMESPACE, the installation fails with so
12 matches
Mail list logo
