This is an automated message.
I apologize for the inconvenience, but I need your help in fighting
spam. I'm using a program called Qurb which automatically maintains
a list of approved senders for me. Messages from approved senders go
directly to my Inbox. Messages from addresses that Qurb hasn't
R does not contain a function interp.surface!
This is from package 'fields', and according to the FAQ only the
maintainer is allowed to send bug reports on a contributed package to
R-bugs.
I am closing this report: please contact the maintainer (and do read the
FAQ).
On Wed, 23 Mar 2005 [EMAIL
On Wed, 23 Mar 2005, Pedro Ribeiro de Andrade Neto wrote:
Let me tell an example.
I found the bayesSurv package in CRAN. It has some .cpp and .h files, and
doesn't have a makefile. I did the following steps:
1. compile the package (R CMD INSTALL)
2. write something in /src/List.cpp (only add an emp
On Wed, 23 Mar 2005 22:16:30 +0100 (CET), [EMAIL PROTECTED]
wrote :
>R version: 2.001
>OS: Windows XP SP2
>
>When I use the interp.surface() function, on occasion I have encountered
>the following error message:
>
>Error in interp.surface(a, loc) : subscript out of bounds
>
>Since it is somewhat
Let me tell an example.
I found the bayesSurv package in CRAN. It has some .cpp and .h files, and
doesn't have a makefile. I did the following steps:
1. compile the package (R CMD INSTALL)
2. write something in /src/List.cpp (only add an empty line)
3. recompile package (INSTALL)
it works, OK.
R version: 2.001
OS: Windows XP SP2
When I use the interp.surface() function, on occasion I have encountered
the following error message:
Error in interp.surface(a, loc) : subscript out of bounds
Since it is somewhat dependent on the data set, I cannot say exactly in
which cases these occur, b
I just tested this problem on a Windows 2000 Pro P4-Xeon system. I tried
this in patched 2.0.1 (2005-2-28) and 2.1.0-alpha (2005-3-23) with both
generic BLAS and precompiled ATLAS BLAS dll (downloaded from CRAN windows
binaries). In all 4 combinations I get
> d<-matrix(NaN,3,3)
> f<-solve(d
On Wed, 23 Mar 2005, Simon Urbanek wrote:
On Mar 22, 2005, at 6:19 PM, Bill Northcott wrote:
On 23/03/2005, at 12:55 AM, Simon Urbanek wrote:
You may prefer the error, but it is not in the sprit of robust arithmetic.
ie
> d<-matrix(NaN,3,3)
> f<-solve(d)
Error in solve.default(d) : Lapack routine
On Mar 22, 2005, at 6:19 PM, Bill Northcott wrote:
On 23/03/2005, at 12:55 AM, Simon Urbanek wrote:
You may prefer the error, but it is not in the sprit of robust
arithmetic. ie
> d<-matrix(NaN,3,3)
> f<-solve(d)
Error in solve.default(d) : Lapack routine dgesv: system is exactly
singular
> f
E
On 23/mar/05, at 09:04, Martin Maechler wrote:
"Bill" == Bill Northcott <[EMAIL PROTECTED]>
on Wed, 23 Mar 2005 10:19:22 +1100 writes:
Bill> On 23/03/2005, at 12:55 AM, Simon Urbanek wrote:
As I see it, the MacOS X behaviour is not IEEE-754 compliant.
I had a quick look at the IEEE web site
On Wed, 23 Mar 2005, Pedro Ribeiro de Andrade Neto wrote:
> On Wed, 23 Mar 2005, Prof Brian Ripley wrote:
>
> > On Wed, 23 Mar 2005, Pedro Ribeiro de Andrade Neto wrote:
> >
> > > I am developing a package with a lot of C++ code, and I have a question
> > > about R CMD COMPILE. As I can see, when
On Wed, 23 Mar 2005, Pedro Ribeiro de Andrade Neto wrote:
On Wed, 23 Mar 2005, Prof Brian Ripley wrote:
On Wed, 23 Mar 2005, Pedro Ribeiro de Andrade Neto wrote:
I am developing a package with a lot of C++ code, and I have a question
about R CMD COMPILE. As I can see, when the package's Makefile ca
On Wed, 23 Mar 2005, Prof Brian Ripley wrote:
> On Wed, 23 Mar 2005, Pedro Ribeiro de Andrade Neto wrote:
>
> > I am developing a package with a lot of C++ code, and I have a question
> > about R CMD COMPILE. As I can see, when the package's Makefile calls
> >
> > R CMD COMPILE foo.cpp
>
> Why do
On Wed, 23 Mar 2005, Brian D Ripley wrote:
The first is as designed: zero-length initial matches are ignored in the C
code. (Don't ask me why it was designed that way.)
The second is not reproducible in the current sources, so is probably
already fixed by the fix to PR#7742.
I've found a better so
On 23/03/2005, at 7:04 PM, Martin Maechler wrote:
I pretty much entirely agree with your points, Bill, and would
tend to declare that this Apple library is ``broken''
for building a correctly running R.
Thanks for that.
Let me ask one question I've been wondering about now for a
while:
Did you ru
The first is as designed: zero-length initial matches are ignored in the C
code. (Don't ask me why it was designed that way.)
The second is not reproducible in the current sources, so is probably
already fixed by the fix to PR#7742.
On Wed, 23 Mar 2005, Gabor Grothendieck wrote:
> stat.math.e
stat.math.ethz.ch> writes:
:
: > "David" == David Forrest maplepark.com>
: > on Tue, 22 Mar 2005 15:02:20 -0600 (CST) writes:
:
: David> According to help(sub), the ^ should match the
: David> zero-length string at the beginning of a string:
:
: yes, indeed.
:
: Davi
On Wed, 23 Mar 2005 [EMAIL PROTECTED] wrote:
1) In your cases, the integer 'x' argument is auto-coerced to
character, however that fails as soon as 'perl = TRUE' is used.
> sub('^','v_', 1:3, perl=TRUE)
Error in sub.perl(pattern, replacement, x, ignore.case) :
invalid argument
{one can
> "Bill" == Bill Northcott <[EMAIL PROTECTED]>
> on Wed, 23 Mar 2005 10:19:22 +1100 writes:
Bill> On 23/03/2005, at 12:55 AM, Simon Urbanek wrote:
>>> As I see it, the MacOS X behaviour is not IEEE-754 compliant.
>>>
>>> I had a quick look at the IEEE web site and it s
> "David" == David Forrest <[EMAIL PROTECTED]>
> on Tue, 22 Mar 2005 15:02:20 -0600 (CST) writes:
David> According to help(sub), the ^ should match the
David> zero-length string at the beginning of a string:
yes, indeed.
David> sub('^','var',1:3) # "1" "2" "3"
David>
20 matches
Mail list logo
