Duncan Murdoch wrote:
> I suspect that the attrib structure isn't really the problem, but I
> don't know what the problem is. X11() works fine under Xvfb on MacOSX,
> and rgl works fine when the Xvfb server is on Linux or Cygwin (with the
> identical line to invoke Xvfb as I was using on MacOS
Prof Brian Ripley wrote:
> I think the question is how are you accessing the parser? The only
> public interface is R_ParseVector, and that works like parse(text=):
Yes, I'm using R_ParseVector. PL/R basically takes the function's text
as stored in the Postgres system catalog table (prosrc fiel
I think the question is how are you accessing the parser? The only public
interface is R_ParseVector, and that works like parse(text=):
> parse(text="abc\ndef")
expression(abc, def)
attr(,"srcfile")
> parse(text="abc\r\ndef")
Error in parse(text = "abc\r\ndef") :
" syntax error, unexpected $und
Marc Schwartz wrote:
> Hi all,
>
> Came across this curious behavior in:
>
> R version 2.5.0 Patched (2007-06-05 r41831)
>
>
> A simplified example is:
>
>
>> all(c(NA, NA, NA) > NA, na.rm = TRUE)
>>
> [1] TRUE
>
>
> Is this expected by definition?
>
> If one reduces this to individual co
On Wed, 2007-06-20 at 09:48 -0700, Thomas Lumley wrote:
> On Wed, 20 Jun 2007, Marc Schwartz wrote:
> >
> > If my train of thought is correct, it seems to me that the behavior
> > above distills down to the comparison between logical(0) and NA, which
> > rather than returning NA, returns logical(0)
I've recently ported PL/R (R embedded in Postgres as a procedural
language) to work on Win32 -- thank you to all involved for making the
embedded interface common between *nix and Win32!
This of course means users are now creating PL/R functions using Win32
based editors, which are using \r\n f
On Wed, 20 Jun 2007, Marc Schwartz wrote:
>
> If my train of thought is correct, it seems to me that the behavior
> above distills down to the comparison between logical(0) and NA, which
> rather than returning NA, returns logical(0).
>
> This would seem appropriate, given that there is no actual c
Hi all,
Came across this curious behavior in:
R version 2.5.0 Patched (2007-06-05 r41831)
A simplified example is:
> all(c(NA, NA, NA) > NA, na.rm = TRUE)
[1] TRUE
Is this expected by definition?
If one reduces this to individual comparisons, such as :
> NA > NA
[1] NA
> all(NA > NA)
[1
[EMAIL PROTECTED] wrote:
> Full_Name: Kang Yousan
> Version: 2.5.0
> OS: Windows XP
> Submission from: (NULL) (211.137.211.67)
>
>
> There is a bug in function distancia() in package dprep. See the description
> below.
>
http://cran.r-project.org/doc/FAQ/R-FAQ.html#R-Bugs :
Finally, check caref
Full_Name: Kang Yousan
Version: 2.5.0
OS: Windows XP
Submission from: (NULL) (211.137.211.67)
There is a bug in function distancia() in package dprep. See the description
below.
> distancia
1 function (x, y)
2 {
3 if (class(y) == "matrix") {
4 distancia = drop(sqrt(colSums((x - t
10 matches
Mail list logo
