Re: [Rd] Minumum memory requirements to run R.
Liaw, Andy wrote: > From: Kjetil Brinchmann Halvorsen > >>Prof Brian Ripley wrote: >> >>>Quite a while back we set the goal of running R in 16Mb >> >>RAM, as people (I >> >>>think Kjetil) had teaching labs that small. >> >>It's a while since I actually har R used on such small >>machines, I think >>64 MB is quite acceptable now. >> >>Kjetil >> >> >>>Since then R has grown, and we has recently started to >> >>optimize R for >> >>>speed rather than size. I recently tested R-devel on my >> >>ancient Win98 >> >>>notebook with 64Mb RAM -- it ran but startup was rather >> >>slow on what I >> >>>think is a 233MHz processor and very slow disc. >>> >>>R still runs in 16Mb, but that is getting tight. Does >> >>anyone have any >> >>>need to run on a smaller machine than my 64Mb notebook? > > > I sure don't, but I wouldn't be surprised if one of these days someone > figures out how to get R to run on a video card... (I recall that there was > a tutorial session at some datamining conference last year that showed > people how to use the GPU for numerical computation, so this may not be too > far fetched.) If you want to run R on a videocard because of its enormous floating point speed, you have access to quite a lot of RAM (fast cards already have huge amounts of RAM). Well, my 20 EUR card has 32Mb only, but you certainly don't want to perform calculations on it... ;-) Are there already PCIe cards that support fast writing to the main memory (not only fast reading)? Uwe > > Andy > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Loading of namespace on load of .Rdata (was strange behaviour of load)
[R-help removed]
See below.
Heather Turner wrote:
>
> 1. There is a more general situation where it would be useful to load
> the namespace of a package after loading a saved workspace: when the
> workspace contains objects of a class for which special methods are
> required. E.g. if 'fm' from the example above were saved in a
> workspace, the namespace of MASS would not be loaded when the
> workspace was loaded into R. Thus unless MASS was loaded by the user,
> default methods would be used by summary(), print() etc rather than
> the specialised methods for objects of class "loglm".
>
> Of course the user should quickly realise this, but there may be
> cases where the default method gives a convincing but incorrect or
> unhelpful result. An alternative would be to add an attribute to
> objects of class "loglm" (say), e.g. attr(loglmObject,
> ".Environment") <- environment(MASS) so that the namespace would
> automatically be loaded when it is required. [In fact alternatives
> such as environment(loglmObject) <- environment(MASS) or
> loglmObject$anyoldthing <- environment(MASS) would work just as well,
> but perhaps the first suggestion is neatest.].
>
> What do others think of this idea? Should it (or an equivalent idea)
> be encouraged amongst package writers?
If I understand you correctly here, what you are talking about works
with S4 classes. For example, if I load an object 'x' (say, from a
saved workspace) of class "foo" and it has a 'show()' method in package
"bar", then
show(x)
will automatically load package "bar". I this is accomplished because
there is a "package" attribute that is part of the class of the object.
It's true, what you're talking about does not exist in S3, but since it
does in S4, I'm not sure it's worth enhancing the older system.
>
> 2. In the case highlighted by Giovanni, the namespace of ipred was
> loaded, but the package was not. This would be fine, except that the
> packages on which ipred depends *were* loaded. This seems
> inconsistent. I guess as long as there are packages without
> namespaces though, this is the only way to proceed. Perhaps in the
> meantime, package authors should be encouraged to use importFrom()
> rather than import()? Or perhaps where packages do have namespaces,
> only the namespace should be loaded in such a case.
>
> Heather
>
>
>> From: Prof Brian Ripley <[EMAIL PROTECTED]> Date: 12 January
>> 2006 08:21:35 GMT To: giovanni parrinello <[EMAIL PROTECTED]>
>> Cc: r-help@stat.math.ethz.ch Subject: Re: [R] Strange behaviour of
>> load
>>
>> On Wed, 11 Jan 2006, giovanni parrinello wrote:
>>
>>
>>> Dear All, simetimes when I load an Rdata I get this message
>>>
>>> ### Code:
>>>
>>> load('bladder1.RData') Carico il pacchetto richiesto: rpart ( Bad
>>> traslastion: Load required package-...) Carico il pacchetto
>>> richiesto: MASS Carico il pacchetto richiesto: mlbench Carico il
>>> pacchetto richiesto: survival Carico il pacchetto richiesto:
>>> splines
>>>
>>> Carico il pacchetto richiesto: 'survival'
>>>
>>>
>>> The following object(s) are masked from package:Hmisc :
>>>
>>> untangle.specials
>>>
>>> Carico il pacchetto richiesto: class Carico il pacchetto
>>> richiesto: nnet #
>>>
>>> So I have many unrequired packages loaded. Any idea?
>>
>> They are required! My guess is that you have object(s) saved with
>> environment the namespace of some package, and loading that
>> namespace is pulling these in. The only CRAN package which
>> requires mlbench appears to be ipred, and that requires all of
>> those except splines, required by survival.
>>
>> So I believe you have been using ipred and have saved a reference
>> to its namespace.
>>
>> -- Brian D. Ripley, [EMAIL PROTECTED]
>> Professor of Applied Statistics,
>> http://www.stats.ox.ac.uk/~ripley/ University of Oxford,
>> Tel: +44 1865 272861 (self) 1 South Parks Road,
>> +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44
>> 1865 272595
>>
>> __
>> R-help@stat.math.ethz.ch mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the
>> posting guide! http://www.R-project.org/posting-guide.html
>
>
> Dr H Turner Research Assistant Dept. of Statistics The University of
> Warwick Coventry CV4 7AL
>
> Tel: 024 76575870 Url: www.warwick.ac.uk/go/heatherturner
>
> __ R-devel@r-project.org
> mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in xy.coords() or documentation error?
Hi,
I noticed the following problem with xy.coords() in R 2.2.1-patched
(version info at the foot of this email) and R 2.3.0 unstable
(subversion no: r37123):
> xy.coords(x = matrix(1:20, ncol = 2))
Error in xy.coords(x = matrix(1:20, ncol = 2)) :
argument "y" is missing, with no default
> xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
$x
[1] 1 2 3 4 5 6 7 8 9 10
$y
[1] 11 12 13 14 15 16 17 18 19 20
$xlab
[1] "[,1]"
$ylab
[1] "[,2]"
And:
> xy.coords(x = data.frame(x = 1:10, y = 1:10))
Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
argument "y" is missing, with no default
> xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
$x
[1] 1 2 3 4 5 6 7 8 9 10
$y
[1] 1 2 3 4 5 6 7 8 9 10
$xlab
[1] "x"
$ylab
[1] "y"
... for example.
?xy.coords states:
x, y: the x and y coordinates of a set of points. Alternatively, a
single argument 'x' can be provided.
Given that, I would have thought the above examples would have worked
without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
later states:
If 'y' is 'NULL' and 'x' is a
and the examples all illustrate the use of NULL passed as y.
Is this a documentation error and a single argument x is not allowed, or
is this a bug in the code? Either way, ?xy.coords contradicts itself as
one would expect to be able to pass only x given the statement above.
If this is a bug in the code, a potential workaround appears to be to
change the first line of xy.coords from:
if (is.null(y)) {
to
if (missing(y) || is.null(y)) {
but I haven't tested this on anything other than my two examples.
I will file a bug report if my observation is correct - but given all
the erroneous bug reports lately, I thought I'd try my luck here where
an error on my part would not cause the maintainers of the bug tracker
any extra work.
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Patched
major2
minor2.1
year 2006
month01
day 18
svn rev 37123
language R
> sessionInfo()
R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices"
[5] "utils" "datasets" "base"
All the best,
Gav
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson [T] +44 (0)20 7679 5522
ENSIS Research Fellow [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
London. WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in xy.coords() or documentation error?
This was discussed just recently. This is a design
error but the maintainers claim there are no cases of
interest where it matters.
On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I noticed the following problem with xy.coords() in R 2.2.1-patched
> (version info at the foot of this email) and R 2.3.0 unstable
> (subversion no: r37123):
>
> > xy.coords(x = matrix(1:20, ncol = 2))
> Error in xy.coords(x = matrix(1:20, ncol = 2)) :
>argument "y" is missing, with no default
> > xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
> $x
> [1] 1 2 3 4 5 6 7 8 9 10
>
> $y
> [1] 11 12 13 14 15 16 17 18 19 20
>
> $xlab
> [1] "[,1]"
>
> $ylab
> [1] "[,2]"
>
> And:
>
> > xy.coords(x = data.frame(x = 1:10, y = 1:10))
> Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
>argument "y" is missing, with no default
> > xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
> $x
> [1] 1 2 3 4 5 6 7 8 9 10
>
> $y
> [1] 1 2 3 4 5 6 7 8 9 10
>
> $xlab
> [1] "x"
>
> $ylab
> [1] "y"
>
> ... for example.
>
> ?xy.coords states:
>
>x, y: the x and y coordinates of a set of points. Alternatively, a
> single argument 'x' can be provided.
>
> Given that, I would have thought the above examples would have worked
> without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
> later states:
>
>If 'y' is 'NULL' and 'x' is a
>
> and the examples all illustrate the use of NULL passed as y.
>
> Is this a documentation error and a single argument x is not allowed, or
> is this a bug in the code? Either way, ?xy.coords contradicts itself as
> one would expect to be able to pass only x given the statement above.
>
> If this is a bug in the code, a potential workaround appears to be to
> change the first line of xy.coords from:
>
> if (is.null(y)) {
>
> to
>
> if (missing(y) || is.null(y)) {
>
> but I haven't tested this on anything other than my two examples.
>
> I will file a bug report if my observation is correct - but given all
> the erroneous bug reports lately, I thought I'd try my luck here where
> an error on my part would not cause the maintainers of the bug tracker
> any extra work.
>
> > version
> _
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status Patched
> major2
> minor2.1
> year 2006
> month01
> day 18
> svn rev 37123
> language R
> > sessionInfo()
> R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices"
> [5] "utils" "datasets" "base"
>
> All the best,
>
> Gav
>
> --
> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> Gavin Simpson [T] +44 (0)20 7679 5522
> ENSIS Research Fellow [F] +44 (0)20 7679 7565
> ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
> UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
> 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
> London. WC1H 0AP.
> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in xy.coords() or documentation error?
On Sat, 2006-01-21 at 13:12 -0500, Gabor Grothendieck wrote:
> This was discussed just recently. This is a design
> error but the maintainers claim there are no cases of
> interest where it matters.
Thanks Gabor,
I must have missed that discussion whilst I was on vacation. If what you
say was the outcome of that discussion, it still means that the
documentation for xy.coords is in error, as you may *not* provide a
single argument 'x'.
If the intention is to keep the current behaviour - which is fine - then
the documentation should be changed, perhaps along the lines of:
x, y: the x and y coordinates of a set of points. Alternatively, a
single object 'x' can be provided if 'y = NULL' is also
supplied.
'object' might not be correct here - is a formula an 'object'?
Cheers,
Gav
>
> On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I noticed the following problem with xy.coords() in R 2.2.1-patched
> > (version info at the foot of this email) and R 2.3.0 unstable
> > (subversion no: r37123):
> >
> > > xy.coords(x = matrix(1:20, ncol = 2))
> > Error in xy.coords(x = matrix(1:20, ncol = 2)) :
> >argument "y" is missing, with no default
> > > xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
> > $x
> > [1] 1 2 3 4 5 6 7 8 9 10
> >
> > $y
> > [1] 11 12 13 14 15 16 17 18 19 20
> >
> > $xlab
> > [1] "[,1]"
> >
> > $ylab
> > [1] "[,2]"
> >
> > And:
> >
> > > xy.coords(x = data.frame(x = 1:10, y = 1:10))
> > Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
> >argument "y" is missing, with no default
> > > xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
> > $x
> > [1] 1 2 3 4 5 6 7 8 9 10
> >
> > $y
> > [1] 1 2 3 4 5 6 7 8 9 10
> >
> > $xlab
> > [1] "x"
> >
> > $ylab
> > [1] "y"
> >
> > ... for example.
> >
> > ?xy.coords states:
> >
> >x, y: the x and y coordinates of a set of points. Alternatively, a
> > single argument 'x' can be provided.
> >
> > Given that, I would have thought the above examples would have worked
> > without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
> > later states:
> >
> >If 'y' is 'NULL' and 'x' is a
> >
> > and the examples all illustrate the use of NULL passed as y.
> >
> > Is this a documentation error and a single argument x is not allowed, or
> > is this a bug in the code? Either way, ?xy.coords contradicts itself as
> > one would expect to be able to pass only x given the statement above.
> >
> > If this is a bug in the code, a potential workaround appears to be to
> > change the first line of xy.coords from:
> >
> > if (is.null(y)) {
> >
> > to
> >
> > if (missing(y) || is.null(y)) {
> >
> > but I haven't tested this on anything other than my two examples.
> >
> > I will file a bug report if my observation is correct - but given all
> > the erroneous bug reports lately, I thought I'd try my luck here where
> > an error on my part would not cause the maintainers of the bug tracker
> > any extra work.
> >
> > > version
> > _
> > platform i686-pc-linux-gnu
> > arch i686
> > os linux-gnu
> > system i686, linux-gnu
> > status Patched
> > major2
> > minor2.1
> > year 2006
> > month01
> > day 18
> > svn rev 37123
> > language R
> > > sessionInfo()
> > R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
> >
> > attached base packages:
> > [1] "methods" "stats" "graphics" "grDevices"
> > [5] "utils" "datasets" "base"
> >
> > All the best,
> >
> > Gav
> >
> > --
> > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > Gavin Simpson [T] +44 (0)20 7679 5522
> > ENSIS Research Fellow [F] +44 (0)20 7679 7565
> > ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
> > UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
> > 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
> > London. WC1H 0AP.
> > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson [T] +44 (0)20 7679 5522
ENSIS Research Fellow [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
London. WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in xy.coords() or documentation error?
I think the docs have been changed for the next vesion
of R.
On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-01-21 at 13:12 -0500, Gabor Grothendieck wrote:
> > This was discussed just recently. This is a design
> > error but the maintainers claim there are no cases of
> > interest where it matters.
>
> Thanks Gabor,
>
> I must have missed that discussion whilst I was on vacation. If what you
> say was the outcome of that discussion, it still means that the
> documentation for xy.coords is in error, as you may *not* provide a
> single argument 'x'.
>
> If the intention is to keep the current behaviour - which is fine - then
> the documentation should be changed, perhaps along the lines of:
>
>x, y: the x and y coordinates of a set of points. Alternatively, a
> single object 'x' can be provided if 'y = NULL' is also
> supplied.
>
> 'object' might not be correct here - is a formula an 'object'?
>
> Cheers,
>
> Gav
>
> >
> > On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > I noticed the following problem with xy.coords() in R 2.2.1-patched
> > > (version info at the foot of this email) and R 2.3.0 unstable
> > > (subversion no: r37123):
> > >
> > > > xy.coords(x = matrix(1:20, ncol = 2))
> > > Error in xy.coords(x = matrix(1:20, ncol = 2)) :
> > >argument "y" is missing, with no default
> > > > xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
> > > $x
> > > [1] 1 2 3 4 5 6 7 8 9 10
> > >
> > > $y
> > > [1] 11 12 13 14 15 16 17 18 19 20
> > >
> > > $xlab
> > > [1] "[,1]"
> > >
> > > $ylab
> > > [1] "[,2]"
> > >
> > > And:
> > >
> > > > xy.coords(x = data.frame(x = 1:10, y = 1:10))
> > > Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
> > >argument "y" is missing, with no default
> > > > xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
> > > $x
> > > [1] 1 2 3 4 5 6 7 8 9 10
> > >
> > > $y
> > > [1] 1 2 3 4 5 6 7 8 9 10
> > >
> > > $xlab
> > > [1] "x"
> > >
> > > $ylab
> > > [1] "y"
> > >
> > > ... for example.
> > >
> > > ?xy.coords states:
> > >
> > >x, y: the x and y coordinates of a set of points. Alternatively, a
> > > single argument 'x' can be provided.
> > >
> > > Given that, I would have thought the above examples would have worked
> > > without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
> > > later states:
> > >
> > >If 'y' is 'NULL' and 'x' is a
> > >
> > > and the examples all illustrate the use of NULL passed as y.
> > >
> > > Is this a documentation error and a single argument x is not allowed, or
> > > is this a bug in the code? Either way, ?xy.coords contradicts itself as
> > > one would expect to be able to pass only x given the statement above.
> > >
> > > If this is a bug in the code, a potential workaround appears to be to
> > > change the first line of xy.coords from:
> > >
> > > if (is.null(y)) {
> > >
> > > to
> > >
> > > if (missing(y) || is.null(y)) {
> > >
> > > but I haven't tested this on anything other than my two examples.
> > >
> > > I will file a bug report if my observation is correct - but given all
> > > the erroneous bug reports lately, I thought I'd try my luck here where
> > > an error on my part would not cause the maintainers of the bug tracker
> > > any extra work.
> > >
> > > > version
> > > _
> > > platform i686-pc-linux-gnu
> > > arch i686
> > > os linux-gnu
> > > system i686, linux-gnu
> > > status Patched
> > > major2
> > > minor2.1
> > > year 2006
> > > month01
> > > day 18
> > > svn rev 37123
> > > language R
> > > > sessionInfo()
> > > R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
> > >
> > > attached base packages:
> > > [1] "methods" "stats" "graphics" "grDevices"
> > > [5] "utils" "datasets" "base"
> > >
> > > All the best,
> > >
> > > Gav
> > >
> > > --
> > > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > > Gavin Simpson [T] +44 (0)20 7679 5522
> > > ENSIS Research Fellow [F] +44 (0)20 7679 7565
> > > ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
> > > UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
> > > 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
> > > London. WC1H 0AP.
> > > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> --
> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> Gavin Simpson [T] +44 (0)20 7679 5522
> ENSIS Research Fellow [F] +44 (0)20 7679 7565
> ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
> UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
> 26 Bedford Way[W] http://www.ucl.ac.uk
Re: [Rd] Bug in xy.coords() or documentation error?
On Sat, 2006-01-21 at 13:39 -0500, Gabor Grothendieck wrote:
> I think the docs have been changed for the next vesion
> of R.
Not in R Version 2.3.0 Under development (unstable) (2006-01-18 r37123)
downloaded today.
G
>
> On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> > On Sat, 2006-01-21 at 13:12 -0500, Gabor Grothendieck wrote:
> > > This was discussed just recently. This is a design
> > > error but the maintainers claim there are no cases of
> > > interest where it matters.
> >
> > Thanks Gabor,
> >
> > I must have missed that discussion whilst I was on vacation. If what you
> > say was the outcome of that discussion, it still means that the
> > documentation for xy.coords is in error, as you may *not* provide a
> > single argument 'x'.
> >
> > If the intention is to keep the current behaviour - which is fine - then
> > the documentation should be changed, perhaps along the lines of:
> >
> >x, y: the x and y coordinates of a set of points. Alternatively, a
> > single object 'x' can be provided if 'y = NULL' is also
> > supplied.
> >
> > 'object' might not be correct here - is a formula an 'object'?
> >
> > Cheers,
> >
> > Gav
> >
> > >
> > > On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > > I noticed the following problem with xy.coords() in R 2.2.1-patched
> > > > (version info at the foot of this email) and R 2.3.0 unstable
> > > > (subversion no: r37123):
> > > >
> > > > > xy.coords(x = matrix(1:20, ncol = 2))
> > > > Error in xy.coords(x = matrix(1:20, ncol = 2)) :
> > > >argument "y" is missing, with no default
> > > > > xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
> > > > $x
> > > > [1] 1 2 3 4 5 6 7 8 9 10
> > > >
> > > > $y
> > > > [1] 11 12 13 14 15 16 17 18 19 20
> > > >
> > > > $xlab
> > > > [1] "[,1]"
> > > >
> > > > $ylab
> > > > [1] "[,2]"
> > > >
> > > > And:
> > > >
> > > > > xy.coords(x = data.frame(x = 1:10, y = 1:10))
> > > > Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
> > > >argument "y" is missing, with no default
> > > > > xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
> > > > $x
> > > > [1] 1 2 3 4 5 6 7 8 9 10
> > > >
> > > > $y
> > > > [1] 1 2 3 4 5 6 7 8 9 10
> > > >
> > > > $xlab
> > > > [1] "x"
> > > >
> > > > $ylab
> > > > [1] "y"
> > > >
> > > > ... for example.
> > > >
> > > > ?xy.coords states:
> > > >
> > > >x, y: the x and y coordinates of a set of points. Alternatively, a
> > > > single argument 'x' can be provided.
> > > >
> > > > Given that, I would have thought the above examples would have worked
> > > > without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
> > > > later states:
> > > >
> > > >If 'y' is 'NULL' and 'x' is a
> > > >
> > > > and the examples all illustrate the use of NULL passed as y.
> > > >
> > > > Is this a documentation error and a single argument x is not allowed, or
> > > > is this a bug in the code? Either way, ?xy.coords contradicts itself as
> > > > one would expect to be able to pass only x given the statement above.
> > > >
> > > > If this is a bug in the code, a potential workaround appears to be to
> > > > change the first line of xy.coords from:
> > > >
> > > > if (is.null(y)) {
> > > >
> > > > to
> > > >
> > > > if (missing(y) || is.null(y)) {
> > > >
> > > > but I haven't tested this on anything other than my two examples.
> > > >
> > > > I will file a bug report if my observation is correct - but given all
> > > > the erroneous bug reports lately, I thought I'd try my luck here where
> > > > an error on my part would not cause the maintainers of the bug tracker
> > > > any extra work.
> > > >
> > > > > version
> > > > _
> > > > platform i686-pc-linux-gnu
> > > > arch i686
> > > > os linux-gnu
> > > > system i686, linux-gnu
> > > > status Patched
> > > > major2
> > > > minor2.1
> > > > year 2006
> > > > month01
> > > > day 18
> > > > svn rev 37123
> > > > language R
> > > > > sessionInfo()
> > > > R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
> > > >
> > > > attached base packages:
> > > > [1] "methods" "stats" "graphics" "grDevices"
> > > > [5] "utils" "datasets" "base"
> > > >
> > > > All the best,
> > > >
> > > > Gav
> > > >
> > > > --
> > > > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > > > Gavin Simpson [T] +44 (0)20 7679 5522
> > > > ENSIS Research Fellow [F] +44 (0)20 7679 7565
> > > > ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
> > > > UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
> > > > 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
> > > > London. WC1H 0AP.
> > > > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > > >
> > > > __
> > > > R-devel@r-project.org mailing list
> > > > https://stat
[Rd] Quits immediately / missing files (PR#8515)
Full_Name: Dennis Sweitzer Version: 1.14? 2.2.1? OS: 10.3.5 Submission from: (NULL) (216.83.100.22) I just downloaded R, performed the installation as instructed, but when I run the program it immediately quits. The system generates the following bug report to be sent to Apple. After that is a copy of the version information displayed at installation. R.Frameworks is not in the library/frameworks directory, so it appears that it is not being loaded. However, the installation program reported that it successfully loaded. Installing the file R.Frameworks.pkg yields the same results. Sincerely, Dennis Sweitzer ++ Date/Time: 2006-01-20 12:17:18 -0500 OS Version: 10.3.5 (Build 7P220) Report Version: 2 Command: R Path:/Applications/R.app/Contents/MacOS/R Version: 1.14 (2129) PID: 450 Thread: Unknown Link (dyld) error: dyld: /Applications/R.app/Contents/MacOS/R Undefined symbols: /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _cacos expected to be defined in /usr/lib/libSystem.B.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _cacosh expected to be defined in /usr/lib/libSystem.B.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _carg expected to be defined in /usr/lib/libSystem.B.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _casin expected to be defined in /usr/lib/libSystem.B.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _casinh expected to be defined in /usr/lib/libSystem.B.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _catan expected to be defined in /usr/lib/libSystem.B.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib undefined reference to _catanh expected Package information from the installation: R 2.2.1 Version 2.2.1 (2005-12-20) for Mac OS X 10.3 (Panther) and higher This multi-package contains following main components: - R Framework 2.2.1 - R.app GUI 1.14 .. Requirements: - Mac OS X 10.3 (Panther) or higher on a PowerPC Mac The Cocoa GUI called R.app will be installed by default in your Applications folder, R framework will be installed in /Library/Frameworks. .. + __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in xy.coords() or documentation error?
If the latest version does not have it then I guess it
was not done. I do agree with you that there is
a problem and here and think that the code, not
just the docs, should be fixed.
On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-01-21 at 13:39 -0500, Gabor Grothendieck wrote:
> > I think the docs have been changed for the next vesion
> > of R.
>
> Not in R Version 2.3.0 Under development (unstable) (2006-01-18 r37123)
> downloaded today.
>
> G
>
> >
> > On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> > > On Sat, 2006-01-21 at 13:12 -0500, Gabor Grothendieck wrote:
> > > > This was discussed just recently. This is a design
> > > > error but the maintainers claim there are no cases of
> > > > interest where it matters.
> > >
> > > Thanks Gabor,
> > >
> > > I must have missed that discussion whilst I was on vacation. If what you
> > > say was the outcome of that discussion, it still means that the
> > > documentation for xy.coords is in error, as you may *not* provide a
> > > single argument 'x'.
> > >
> > > If the intention is to keep the current behaviour - which is fine - then
> > > the documentation should be changed, perhaps along the lines of:
> > >
> > >x, y: the x and y coordinates of a set of points. Alternatively, a
> > > single object 'x' can be provided if 'y = NULL' is also
> > > supplied.
> > >
> > > 'object' might not be correct here - is a formula an 'object'?
> > >
> > > Cheers,
> > >
> > > Gav
> > >
> > > >
> > > > On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> > > > > Hi,
> > > > >
> > > > > I noticed the following problem with xy.coords() in R 2.2.1-patched
> > > > > (version info at the foot of this email) and R 2.3.0 unstable
> > > > > (subversion no: r37123):
> > > > >
> > > > > > xy.coords(x = matrix(1:20, ncol = 2))
> > > > > Error in xy.coords(x = matrix(1:20, ncol = 2)) :
> > > > >argument "y" is missing, with no default
> > > > > > xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
> > > > > $x
> > > > > [1] 1 2 3 4 5 6 7 8 9 10
> > > > >
> > > > > $y
> > > > > [1] 11 12 13 14 15 16 17 18 19 20
> > > > >
> > > > > $xlab
> > > > > [1] "[,1]"
> > > > >
> > > > > $ylab
> > > > > [1] "[,2]"
> > > > >
> > > > > And:
> > > > >
> > > > > > xy.coords(x = data.frame(x = 1:10, y = 1:10))
> > > > > Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
> > > > >argument "y" is missing, with no default
> > > > > > xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
> > > > > $x
> > > > > [1] 1 2 3 4 5 6 7 8 9 10
> > > > >
> > > > > $y
> > > > > [1] 1 2 3 4 5 6 7 8 9 10
> > > > >
> > > > > $xlab
> > > > > [1] "x"
> > > > >
> > > > > $ylab
> > > > > [1] "y"
> > > > >
> > > > > ... for example.
> > > > >
> > > > > ?xy.coords states:
> > > > >
> > > > >x, y: the x and y coordinates of a set of points. Alternatively, a
> > > > > single argument 'x' can be provided.
> > > > >
> > > > > Given that, I would have thought the above examples would have worked
> > > > > without explicitly passing y = NULL to xy.coords(). However,
> > > > > ?xy,coords
> > > > > later states:
> > > > >
> > > > >If 'y' is 'NULL' and 'x' is a
> > > > >
> > > > > and the examples all illustrate the use of NULL passed as y.
> > > > >
> > > > > Is this a documentation error and a single argument x is not allowed,
> > > > > or
> > > > > is this a bug in the code? Either way, ?xy.coords contradicts itself
> > > > > as
> > > > > one would expect to be able to pass only x given the statement above.
> > > > >
> > > > > If this is a bug in the code, a potential workaround appears to be to
> > > > > change the first line of xy.coords from:
> > > > >
> > > > > if (is.null(y)) {
> > > > >
> > > > > to
> > > > >
> > > > > if (missing(y) || is.null(y)) {
> > > > >
> > > > > but I haven't tested this on anything other than my two examples.
> > > > >
> > > > > I will file a bug report if my observation is correct - but given all
> > > > > the erroneous bug reports lately, I thought I'd try my luck here where
> > > > > an error on my part would not cause the maintainers of the bug tracker
> > > > > any extra work.
> > > > >
> > > > > > version
> > > > > _
> > > > > platform i686-pc-linux-gnu
> > > > > arch i686
> > > > > os linux-gnu
> > > > > system i686, linux-gnu
> > > > > status Patched
> > > > > major2
> > > > > minor2.1
> > > > > year 2006
> > > > > month01
> > > > > day 18
> > > > > svn rev 37123
> > > > > language R
> > > > > > sessionInfo()
> > > > > R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
> > > > >
> > > > > attached base packages:
> > > > > [1] "methods" "stats" "graphics" "grDevices"
> > > > > [5] "utils" "datasets" "base"
> > > > >
> > > > > All the best,
> > > > >
> > > > > Gav
> > > > >
> > > > > --
> > > > > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > > > > Gavin Simpson [T] +44
Re: [Rd] Bug in xy.coords() or documentation error?
On 1/21/2006 1:21 PM, Gavin Simpson wrote:
> On Sat, 2006-01-21 at 13:12 -0500, Gabor Grothendieck wrote:
>> This was discussed just recently. This is a design
>> error but the maintainers claim there are no cases of
>> interest where it matters.
>
> Thanks Gabor,
>
> I must have missed that discussion whilst I was on vacation. If what you
> say was the outcome of that discussion, it still means that the
> documentation for xy.coords is in error, as you may *not* provide a
> single argument 'x'.
You need to read the whole page. You provide a single argument x by
setting y to NULL, not by leaving it missing (as the docs said in
earlier versions).
If you want to submit a patch to the docs, I'll take a look, but I don't
like the one below. It has basically the same flaw as the current docs:
you're providing two objects, not a single object. Probably the
clearest thing to do is just to say "see below" after the current
wording, to point out that there are funny conventions here.
> If the intention is to keep the current behaviour - which is fine - then
> the documentation should be changed, perhaps along the lines of:
>
> x, y: the x and y coordinates of a set of points. Alternatively, a
> single object 'x' can be provided if 'y = NULL' is also
> supplied.
>
> 'object' might not be correct here - is a formula an 'object'?
Sure, why not?
Duncan Murdoch
>
> Cheers,
>
> Gav
>
>> On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> I noticed the following problem with xy.coords() in R 2.2.1-patched
>>> (version info at the foot of this email) and R 2.3.0 unstable
>>> (subversion no: r37123):
>>>
xy.coords(x = matrix(1:20, ncol = 2))
>>> Error in xy.coords(x = matrix(1:20, ncol = 2)) :
>>>argument "y" is missing, with no default
xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
>>> $x
>>> [1] 1 2 3 4 5 6 7 8 9 10
>>>
>>> $y
>>> [1] 11 12 13 14 15 16 17 18 19 20
>>>
>>> $xlab
>>> [1] "[,1]"
>>>
>>> $ylab
>>> [1] "[,2]"
>>>
>>> And:
>>>
xy.coords(x = data.frame(x = 1:10, y = 1:10))
>>> Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
>>>argument "y" is missing, with no default
xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
>>> $x
>>> [1] 1 2 3 4 5 6 7 8 9 10
>>>
>>> $y
>>> [1] 1 2 3 4 5 6 7 8 9 10
>>>
>>> $xlab
>>> [1] "x"
>>>
>>> $ylab
>>> [1] "y"
>>>
>>> ... for example.
>>>
>>> ?xy.coords states:
>>>
>>>x, y: the x and y coordinates of a set of points. Alternatively, a
>>> single argument 'x' can be provided.
>>>
>>> Given that, I would have thought the above examples would have worked
>>> without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
>>> later states:
>>>
>>>If 'y' is 'NULL' and 'x' is a
>>>
>>> and the examples all illustrate the use of NULL passed as y.
>>>
>>> Is this a documentation error and a single argument x is not allowed, or
>>> is this a bug in the code? Either way, ?xy.coords contradicts itself as
>>> one would expect to be able to pass only x given the statement above.
>>>
>>> If this is a bug in the code, a potential workaround appears to be to
>>> change the first line of xy.coords from:
>>>
>>> if (is.null(y)) {
>>>
>>> to
>>>
>>> if (missing(y) || is.null(y)) {
>>>
>>> but I haven't tested this on anything other than my two examples.
>>>
>>> I will file a bug report if my observation is correct - but given all
>>> the erroneous bug reports lately, I thought I'd try my luck here where
>>> an error on my part would not cause the maintainers of the bug tracker
>>> any extra work.
>>>
version
>>> _
>>> platform i686-pc-linux-gnu
>>> arch i686
>>> os linux-gnu
>>> system i686, linux-gnu
>>> status Patched
>>> major2
>>> minor2.1
>>> year 2006
>>> month01
>>> day 18
>>> svn rev 37123
>>> language R
sessionInfo()
>>> R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
>>>
>>> attached base packages:
>>> [1] "methods" "stats" "graphics" "grDevices"
>>> [5] "utils" "datasets" "base"
>>>
>>> All the best,
>>>
>>> Gav
>>>
>>> --
>>> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
>>> Gavin Simpson [T] +44 (0)20 7679 5522
>>> ENSIS Research Fellow [F] +44 (0)20 7679 7565
>>> ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
>>> UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
>>> 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/
>>> London. WC1H 0AP.
>>> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A patch for do_sample: check replace arg
A colleague sent me the following:
If you specify probabilities in the 'sample' function and forget
to type 'prob=...', then you get nonsense. E.g.
sample(1:10,1,c(0,0,0,0,1,0,0,0,0,0))
does not filter '5', while
sample(1:10,1,prob=c(0,0,0,0,1,0,0,0,0,0))
does it correctly. I wish this would return an error because the
'replace' argument should only take logical args. Anyway, it is
easy to make this mistake and having it produce an error would be
nice.
Assuming there is not a use-case for specifying a logical vector for
the 'replace' argument, I like the idea of raising an error if replace
is not length one. The following patch provides an implementation.
+ seth
Diff is against svn Revision: 37141
--- a/src/main/random.c Sat Jan 21 10:54:11 2006 -0800
+++ b/src/main/random.c Sat Jan 21 11:17:20 2006 -0800
@@ -453,15 +453,18 @@
/* with/without replacement according to r. */
SEXP attribute_hidden do_sample(SEXP call, SEXP op, SEXP args, SEXP rho)
{
-SEXP x, y, prob;
+SEXP x, y, prob, sreplace;
int k, n, replace;
double *p;
checkArity(op, args);
n = asInteger(CAR(args)); args = CDR(args);
k = asInteger(CAR(args)); args = CDR(args);
-replace = asLogical(CAR(args)); args = CDR(args);
+sreplace = CAR(args); args = CDR(args);
prob = CAR(args);
+if (length(sreplace) != 1)
+errorcall(call, _("invalid '%s' argument"), "replace");
+replace = asLogical(sreplace);
if (replace == NA_LOGICAL)
errorcall(call, _("invalid '%s' argument"), "replace");
if (n == NA_INTEGER || n < 1)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in xy.coords() or documentation error?
On Sat, 2006-01-21 at 14:07 -0500, Duncan Murdoch wrote:
> On 1/21/2006 1:21 PM, Gavin Simpson wrote:
> > On Sat, 2006-01-21 at 13:12 -0500, Gabor Grothendieck wrote:
> >> This was discussed just recently. This is a design
> >> error but the maintainers claim there are no cases of
> >> interest where it matters.
> >
> > Thanks Gabor,
> >
> > I must have missed that discussion whilst I was on vacation. If what you
> > say was the outcome of that discussion, it still means that the
> > documentation for xy.coords is in error, as you may *not* provide a
> > single argument 'x'.
>
> You need to read the whole page. You provide a single argument x by
> setting y to NULL, not by leaving it missing (as the docs said in
> earlier versions).
>
> If you want to submit a patch to the docs, I'll take a look, but I don't
> like the one below. It has basically the same flaw as the current docs:
> you're providing two objects, not a single object. Probably the
> clearest thing to do is just to say "see below" after the current
> wording, to point out that there are funny conventions here.
How about:
x, y: the x and y coordinates of a set of points. Alternatively, 'x' may
be a formula, list, time series or a matrix-like object with two
columns, in which case 'y' should be 'NULL', see Details below.
Or,
x, y: the x and y coordinates of a set of points. Alternatively, 'x' may
take different forms. If so, 'y' must be supplied as 'NULL'. See Details
below.
Or,
x, y: the x and y coordinates of a set of points. Alternatively, 'x' may
take different forms. See Details below.
I can provide you with a revised Rd file for xy.coords() if you think
any of the above are acceptable
All the best,
Gav
>
> > If the intention is to keep the current behaviour - which is fine - then
> > the documentation should be changed, perhaps along the lines of:
> >
> > x, y: the x and y coordinates of a set of points. Alternatively, a
> > single object 'x' can be provided if 'y = NULL' is also
> > supplied.
> >
> > 'object' might not be correct here - is a formula an 'object'?
>
> Sure, why not?
>
> Duncan Murdoch
>
> >
> > Cheers,
> >
> > Gav
> >
> >> On 1/21/06, Gavin Simpson <[EMAIL PROTECTED]> wrote:
> >>> Hi,
> >>>
> >>> I noticed the following problem with xy.coords() in R 2.2.1-patched
> >>> (version info at the foot of this email) and R 2.3.0 unstable
> >>> (subversion no: r37123):
> >>>
> xy.coords(x = matrix(1:20, ncol = 2))
> >>> Error in xy.coords(x = matrix(1:20, ncol = 2)) :
> >>>argument "y" is missing, with no default
> xy.coords(x = matrix(1:20, ncol = 2), y = NULL)
> >>> $x
> >>> [1] 1 2 3 4 5 6 7 8 9 10
> >>>
> >>> $y
> >>> [1] 11 12 13 14 15 16 17 18 19 20
> >>>
> >>> $xlab
> >>> [1] "[,1]"
> >>>
> >>> $ylab
> >>> [1] "[,2]"
> >>>
> >>> And:
> >>>
> xy.coords(x = data.frame(x = 1:10, y = 1:10))
> >>> Error in xy.coords(x = data.frame(x = 1:10, y = 1:10)) :
> >>>argument "y" is missing, with no default
> xy.coords(x = data.frame(x = 1:10, y = 1:10), y = NULL)
> >>> $x
> >>> [1] 1 2 3 4 5 6 7 8 9 10
> >>>
> >>> $y
> >>> [1] 1 2 3 4 5 6 7 8 9 10
> >>>
> >>> $xlab
> >>> [1] "x"
> >>>
> >>> $ylab
> >>> [1] "y"
> >>>
> >>> ... for example.
> >>>
> >>> ?xy.coords states:
> >>>
> >>>x, y: the x and y coordinates of a set of points. Alternatively, a
> >>> single argument 'x' can be provided.
> >>>
> >>> Given that, I would have thought the above examples would have worked
> >>> without explicitly passing y = NULL to xy.coords(). However, ?xy,coords
> >>> later states:
> >>>
> >>>If 'y' is 'NULL' and 'x' is a
> >>>
> >>> and the examples all illustrate the use of NULL passed as y.
> >>>
> >>> Is this a documentation error and a single argument x is not allowed, or
> >>> is this a bug in the code? Either way, ?xy.coords contradicts itself as
> >>> one would expect to be able to pass only x given the statement above.
> >>>
> >>> If this is a bug in the code, a potential workaround appears to be to
> >>> change the first line of xy.coords from:
> >>>
> >>> if (is.null(y)) {
> >>>
> >>> to
> >>>
> >>> if (missing(y) || is.null(y)) {
> >>>
> >>> but I haven't tested this on anything other than my two examples.
> >>>
> >>> I will file a bug report if my observation is correct - but given all
> >>> the erroneous bug reports lately, I thought I'd try my luck here where
> >>> an error on my part would not cause the maintainers of the bug tracker
> >>> any extra work.
> >>>
> version
> >>> _
> >>> platform i686-pc-linux-gnu
> >>> arch i686
> >>> os linux-gnu
> >>> system i686, linux-gnu
> >>> status Patched
> >>> major2
> >>> minor2.1
> >>> year 2006
> >>> month01
> >>> day 18
> >>> svn rev 37123
> >>> language R
> sessionInfo()
> >>> R version 2.2.1, 2006-01-18, i686-pc-linux-gnu
> >>>
> >>> attached base packages:
> >>> [1] "methods" "stats" "g
Re: [Rd] nls profiling with algorithm="port" may viol ate bounds (PR#8508)
Spencer Graves pdf.com> writes: > > Hi, Ben, et al.: > > The issue Ben identified with confint(nls(... )) generates a hard > failure for me. "We" (being Brian Ripley and I) know about this already. I'm sorry I failed to specify enough info in my bug report, but I was using R-devel/2.3.0 of (I think?) 11 January, under Linux. Your problem is actually PR #8428, which is fixed enough to prevent a crash in 2.2.1 patched and really fixed in 2.3.0, all thanks to Brian Ripley. cheers Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nls profiling with algorithm="port" may violate bounds (PR#8508)
Dear Professors. Bolker & Ripley: Thank you both very much for all your creativity and hard work both in your generall contributions to human knowledge and specifically for helping make R the great thing it is today. I had not seen a reply to that email in several days, so I made time to check it out. When I replicated the error, I thought it my duty to report same. I know that's more appropraite with "r-help" than with "r-devel", but I thought such a comment might help someone. I certainly did NOT want to add to someones' workload a requirement to reply to my comment. Thanks again, spencer graves Ben Bolker wrote: > Spencer Graves pdf.com> writes: > > >>Hi, Ben, et al.: >> >>The issue Ben identified with confint(nls(... )) generates a hard >>failure for me. > > > "We" (being Brian Ripley and I) know about this already. > I'm sorry I failed to specify enough info in my bug report, > but I was using R-devel/2.3.0 of (I think?) 11 January, under Linux. > Your problem is actually PR #8428, which is fixed enough to prevent > a crash in 2.2.1 patched and really fixed in 2.3.0, all thanks to > Brian Ripley. > > cheers > Ben > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
