1. This is not a bug (as you seem to realize), so it should not be sent to
r-bugs.
2. You seem to want the drop=FALSE argument to [], as in FAQ 7.5
-thomas
On Wed, 13 Aug 2008 [EMAIL PROTECTED] wrote:
Good Day,
I can understand that after indexing a single column in a matrix, R will
1. This is not a bug (as you seem to realize), so it should not be sent to
r-bugs.
2. You seem to want the drop=FALSE argument to [], as in FAQ 7.5
-thomas
On Wed, 13 Aug 2008 [EMAIL PROTECTED] wrote:
> Good Day,
> I can understand that after indexing a single column in a matrix, R wi
I'm looking for advice on manipulating parameters that
are going to be passed through to another function.
Specifically, I am working on my version of "mle",
which is a wrapper for optim (among other optimizers).
I would prefer not to replicate the entire argument
list of optim(), so I'm usi
On Wed, Aug 13, 2008 at 6:56 AM, Laurent Gautier <[EMAIL PROTECTED]> wrote:
> There is a chance that further changes in the handling of plotting
> devices event appear;
> I think that there is an ongoing effort to bring new features for R-2.8.
>
> What about bumping that to r-devel ? (Sorry if you
If I understand it correctly, one way would be to define a function to
specify the default options/arguments in the required order.
For example,
> mle.options <- function(method = "BFGS", lower = 0, upper = Inf,
hessian=FALSE)
+ list(method=method, lower=lower, upper=upper, hessian=hessian)
> mle
Ben Bolker wrote:
I'm looking for advice on manipulating parameters that
are going to be passed through to another function.
Specifically, I am working on my version of "mle",
which is a wrapper for optim (among other optimizers).
I would prefer not to replicate the entire argument
list of
On Wed, 13 Aug 2008, Tony Plate wrote:
Ben Bolker wrote:
I'm looking for advice on manipulating parameters that
are going to be passed through to another function.
Specifically, I am working on my version of "mle",
which is a wrapper for optim (among other optimizers).
I would prefer not
A while ago I decided to simply download and install every package on CRAN
(disk space is cheap these days...). In the process, I kept loose track of
which packages generated one or more 'compilation errors' during the install
process (machine runs 64-bit Fedora 8, gcc 4.1 etc. etc). Most of the er
You should report package problems to the package maintainer (see the R
posting guide and FAQ). *But* it seems you are just replicating what the
CRAN daily checks on x86_64 Debian Linux do, and I repeat those checks
most weeks on Fedora 8 (including twice already this week as we test the
near-
Tony Plate wrote:
here's my two cents:
- require names on parameters, rather than order
- construct calls and use eval() rather than do.call() (then you can
manipulate list(...) without the ugh factor of do.call() -- though is
do.call() any different to eval() in R? -- I know in S-PLUS that the
Hi,
You are completely right, the problem was not about what R_alloc
returned but my use of the fill_array32. Now it works fine, but the
block generation is longer due to a conversion to double after using
fill_array32. I must underline the fact that I do not yet use sse2
support.
Thank
11 matches
Mail list logo
