Duncan Murdoch wrote:
On 22/03/2009 4:50 PM, Romain Francois wrote:
Romain Francois wrote:
Peter Dalgaard wrote:
Duncan Murdoch wrote:
On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote:
It happens in the token function in gram.c:
   c = SkipSpace();
   if (c == '#') c = SkipComm
Hi,
I have extensive programming experience (Winodws, Unix, scripting, compiled
languages, you name it) but new to R.
I found that it is quite hard to interpret the results returned by all.equal
(base). The main problem is that when attributes are compared, they are sorted
in attr.all.equal b
Full_Name: Wacek Kusnierczyk
Version: 2.10.0 r48181
OS: Ubuntu 8.04 Linux 32bit
Submission from: (NULL) (129.241.199.135)
there seems to be something wrong with r's regexing. consider the following
example:
gregexpr('a*|b', 'ab')
# positions: 1 2
# lengths: 1 1
gsub('a*|b', '.'
somewhat related to a previous discussion [1] on how 'names<-' would
sometimes modify its argument in place, and sometimes produce a modified
copy without changing the original, here's another example of how it
becomes visible to the user when r makes or doesn't make a copy of an
object:
x = N
> "WK" == Wacek Kusnierczyk
> on Mon, 23 Mar 2009 09:52:19 +0100 writes:
WK> somewhat related to a previous discussion [1] on how 'names<-' would
WK> sometimes modify its argument in place, and sometimes produce a modified
WK> copy without changing the original, here's ano
Martin Maechler wrote:
>> "WK" == Wacek Kusnierczyk
>>
>>
> WK> somewhat related to a previous discussion [1] on how 'names<-' would
> WK> sometimes modify its argument in place, and sometimes produce a
> modified
> WK> copy without changing the original, here
On 23/03/2009 3:10 AM, Romain Francois wrote:
Duncan Murdoch wrote:
However, it might make sense for you to have your own parser, based on
the grammar in R's parser, but handling white space differently.
Certainly it would make sense to do that before making changes to the
base R one.
> "WK" == Wacek Kusnierczyk
> on Mon, 23 Mar 2009 10:56:37 +0100 writes:
WK> Martin Maechler wrote:
>>> "WK" == Wacek Kusnierczyk
>>>
>>>
WK> somewhat related to a previous discussion [1] on how 'names<-' would
WK> sometimes modify its argument i
Martin Maechler wrote:
>
> [.. omitted part no longer relevant ]
>
> WK> however, the following has a different pattern:
> >>
> WK> x = NULL
> WK> dput(x)
> WK> # NULL
> WK> names(x) = character(0)
> WK> # error: attempt to set an attribute on NULL
> >>
> "WK" == Wacek Kusnierczyk
> on Mon, 23 Mar 2009 16:11:04 +0100 writes:
WK> Martin Maechler wrote:
>>
>> [.. omitted part no longer relevant ]
>>
WK> however, the following has a different pattern:
>> >>
WK> x = NULL
WK> dput(x)
WK>
Martin Maechler wrote:
>
> >> more verbously, all NULL objects in R are identical, or as the
> >> help page says, there's only ``*The* NULL Object'' in R,
> >> i.e., NULL cannot get any attributes.
> >>
>
> WK> yes, but that's not the issue. the issue is that names(x)<- seems
In the Installer for R.8.1 for Mac OSX Tiger or higher, the
description of the GNU Fortran package in the customize option writes
Fortran as "Fotran." Just a minor error, but should be fixed if
revisited.
-Bonner Reed
Yale Univ.
__
R-devel@r-proj
Hi the list,
I am using matplot with the option lend="butt", but only the first line
(the black) is printed correctly :
> matplot(matrix(1:9,3),type="c",lwd=10,lty=1,lend="butt")
Is it a bug ?
I am using R2.8.1 under windows XP pack3.
Christophe
It looks to be a bug. Here is the code and notice that ... is passed to
plot (which plots the first series) but not to lines (which plots the rest):
if (!add) {
ii <- ii[-1]
plot(x[, 1], y[, 1], type = type[1], xlab = xlab, ylab = ylab,
xlim = xlim, ylim = ylim, lt
Full_Name: Christophe Genolini
Version: 2.8.1, but also 2.9
OS: Windows XP
Submission from: (NULL) (82.225.59.146)
I am using matplot with the option lend="butt", but only the first line (the
black) is printed correctly :
> matplot(matrix(1:9,3),type="c",lwd=10,lty=1,lend="butt")
Gabor Grothen
Full_Name: Christophe Genolini
Version: 2.8.1
OS: Windows XP
Submission from: (NULL) (82.225.59.146)
savePlot export "eps" graph that seems to be incorrect.
Trying to incorporate them in a LaTeX file, I get :
++
Cannot determine size of graphics in foo.eps (no BoundingBox)
On 23/03/2009 7:25 PM, cgeno...@u-paris10.fr wrote:
Full_Name: Christophe Genolini
Version: 2.8.1, but also 2.9
OS: Windows XP
Submission from: (NULL) (82.225.59.146)
I am using matplot with the option lend="butt", but only the first line (the
black) is printed correctly :
matplot(matrix(1:9
Stavros Macrakis wrote:
> Tested in R 2.8.1 Windows
>
>
>> ff <- formals(function(x)1)
>> ff1 <- as.list(function(x)1)[1]
>>
> # ff1 acts the same as ff in the examples below, but is a list rather
> than a pairlist
>
>
>> dput( ff , control=c("warnIncomplete"))
>>
> list(x = )
>
> T
Tested in R 2.8.1 Windows
> ff <- formals(function(x)1)
> ff1 <- as.list(function(x)1)[1]
# ff1 acts the same as ff in the examples below, but is a list rather
than a pairlist
> dput( ff , control=c("warnIncomplete"))
list(x = )
This string is not parsable, but dput does not give a warning as sp
(this post suggests a patch to the sources, so i allow myself to divert
it to r-devel)
Bert Gunter wrote:
> x a numeric vector, matrix or data frame.
> y NULL (default) or a vector, matrix or data frame with compatible
> dimensions to x. The default is equivalent to y = x (but more efficient).
On 23/03/2009 7:37 PM, Stavros Macrakis wrote:
Tested in R 2.8.1 Windows
ff <- formals(function(x)1)
ff1 <- as.list(function(x)1)[1]
# ff1 acts the same as ff in the examples below, but is a list rather
than a pairlist
dput( ff , control=c("warnIncomplete"))
list(x = )
This string is not p
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
> Sent: Monday, March 23, 2009 5:28 PM
> To: Stavros Macrakis
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] dput(as.list(function...)...) bug
>
> On 23/03/2009
Doesn't Fortran still require that the arguments to
a function not alias each other (in whole or in part)?
I could imagine that var() might call into Fortran code
(BLAS or LAPACK). Wouldn you want to chance erroneous
results at a high optimization level to save a bit of
time in an unusual situati
Oops, I was thinking backwards. This sort of
hack could avoid the Fortran aliasing rules, not
run afoul of them.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On
24 matches
Mail list logo
