Re: [Rd] .leap.seconds
You don't seriously expect R 2.2.1 to know about events after its release
do you? And as the new leap second is not a bug, it will not go into a
patched version.
I have been looking into this for R-devel, but there is a lot more to it.
We really need consistency with the OS, and as this leap second was not
even announced until 2005-07-04, probably most R platforms will not know
about it. Some systems count leapseconds in their clock time, but most do
not: see ?DateTimeClasses. So we need to find out if the OS knows about
this leap second when we make internal adjustments, and even that is
tricky as e.g. FC3 as originally shipped does not but the latest patched
glibc does. I am not convinced I have a good enough solution as yet.
On Thu, 12 Jan 2006, McGehee, Robert wrote:
> I glanced at the .leap.seconds object and noticed that it has not been
> updated for the most recent leap second that occurred 2005 December 31,
> 23h 59m 60s. See the IERS bulletin here:
> http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
>
> Moreover, after a more careful glance at the .leap.seconds object, I
> noticed that there are two incorrect entries. First, there was not a
> leap second on 1986 June 30, and second there was a leap second that was
> omitted on 1982 June 30.
A (harmless) typo.
> For a list of past offsets see this IERS table:
> http://www.iers.org/MainDisp.csl?pid=95-106
>
> Best,
> Robert
>
>> version
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status Patched
> major2
> minor2.1
> year 2006
> month01
> day 07
> svn rev 37024
> language R
>
> Robert McGehee
> Quantitative Analyst
> Geode Capital Management, LLC
> 53 State Street, 5th Floor | Boston, MA | 02109
> Tel: 617/392-8396Fax:617/476-6389
> mailto:[EMAIL PROTECTED]
>
>
>
> This e-mail, and any attachments hereto, are intended for us...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving a plot from R-LINUX(2)
For jpeg see ?dev2bitmap as well as my earlier reply.
On Fri, 13 Jan 2006 [EMAIL PROTECTED] wrote:
> Dirk,
>
> Thanks a lot for taking the time to reply.
>
> Please have a look at my comments below:
>
>
> On 13 January 2006 at 11:02, [EMAIL PROTECTED] wrote:
> | Is there any way to save a plot produced by
> | R in a LINUX (Debian) machine?
>
> (Dirk)It is the same on every platform and ...
>
> (Augusto) No, I can see an option to save my plot from the plot window
> in MS Windows. That option does not exist in the LINUX window,
> does it? (maybe there is something wrong with my LINUX config.)
>
> say, I have an arbitrary set of data x,y (not a pdf).
> I can plot the data using plot(x,y) and I can see the plot
> in a plot window in LINUX.
>
> The problem is: how can I save that plot into an external
> file? I expect to find a command like:
>
> save_a_displayed_plot("myplot1","jpeg","/mnt/store")
>
> Then, I expect to find the file myplot1.jpeg in "store".
>
> I have read the documentation, sect. 1.6, and found no reference
> to this problem.
>
> Again, thank you for your reply.
>
> Augusto
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving a plot in R-LINUX
That does not save the current plot though, and dev.copy() and
dev.print() can do so. They _are_ in the manual Dirk pointed you at.
Windows versions of R have other options, e.g. savePlot() and menu items
to save the plot, and my guess is that is what
'[EMAIL PROTECTED]' has seen.
I don't see what this has to do with this list rather than R-help, though.
On Thu, 12 Jan 2006, Dirk Eddelbuettel wrote:
>
> On 13 January 2006 at 11:02, [EMAIL PROTECTED] wrote:
> | Is there any way to save a plot produced by
> | R in a LINUX (Debian) machine?
>
> It is the same on every platform and ...
>
> | The window opened by R to put the plot in,
> | does not give any option to save it (there
> | are options to move, close, minimise it, etc.
Those `options' are from your X11 Window Manager, not from R.
> | but not to save it). How do you do that?
>
> ... explained in section 12.6 of the fine 'R Introduction' manual available
> in Debian in each one of the packages
>
> r-doc-info
> r-doc-html
> r-doc-pdf
>
> for your choice of format to read.
>
> Short form:
>
>> pdf("/tmp/foo.pdf")
>> plot(x, y)
>> dev.off()
>
> Don't forget the dev.off(). And do read the manual, section 12.6, also on the
> web at eg http://cran.r-project.org/doc/manuals/R-intro.html#Graphics
>
> Dirk
>
> --
> Hell, there are no rules here - we're trying to accomplish something.
> -- Thomas A. Edison
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Saving a plot from R-LINUX(2)
Dirk,
Thanks a lot for taking the time to reply.
Please have a look at my comments below:
On 13 January 2006 at 11:02, [EMAIL PROTECTED] wrote:
| Is there any way to save a plot produced by
| R in a LINUX (Debian) machine?
(Dirk)It is the same on every platform and ...
(Augusto) No, I can see an option to save my plot from the plot window
in MS Windows. That option does not exist in the LINUX window,
does it? (maybe there is something wrong with my LINUX config.)
say, I have an arbitrary set of data x,y (not a pdf).
I can plot the data using plot(x,y) and I can see the plot
in a plot window in LINUX.
The problem is: how can I save that plot into an external
file? I expect to find a command like:
save_a_displayed_plot("myplot1","jpeg","/mnt/store")
Then, I expect to find the file myplot1.jpeg in "store".
I have read the documentation, sect. 1.6, and found no reference
to this problem.
Again, thank you for your reply.
Augusto
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving a plot in R-LINUX
On 13 January 2006 at 11:02, [EMAIL PROTECTED] wrote:
| Is there any way to save a plot produced by
| R in a LINUX (Debian) machine?
It is the same on every platform and ...
| The window opened by R to put the plot in,
| does not give any option to save it (there
| are options to move, close, minimise it, etc.
| but not to save it). How do you do that?
... explained in section 12.6 of the fine 'R Introduction' manual available
in Debian in each one of the packages
r-doc-info
r-doc-html
r-doc-pdf
for your choice of format to read.
Short form:
> pdf("/tmp/foo.pdf")
> plot(x, y)
> dev.off()
Don't forget the dev.off(). And do read the manual, section 12.6, also on the
web at eg http://cran.r-project.org/doc/manuals/R-intro.html#Graphics
Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Saving a plot in R-LINUX
Good day, Is there any way to save a plot produced by R in a LINUX (Debian) machine? The window opened by R to put the plot in, does not give any option to save it (there are options to move, close, minimise it, etc. but not to save it). How do you do that? Thanks, Augusto Augusto Sanabria. MSc, PhD. Mathematical Modeller Risk Research Group Geospatial & Earth Monitoring Division Geoscience Australia (www.ga.gov.au) Cnr. Jerrabomberra Av. & Hindmarsh Dr. Symonston ACT 2609 Ph. (02) 6249-9155 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .leap.seconds
I glanced at the .leap.seconds object and noticed that it has not been
updated for the most recent leap second that occurred 2005 December 31,
23h 59m 60s. See the IERS bulletin here:
http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
Moreover, after a more careful glance at the .leap.seconds object, I
noticed that there are two incorrect entries. First, there was not a
leap second on 1986 June 30, and second there was a leap second that was
omitted on 1982 June 30.
For a list of past offsets see this IERS table:
http://www.iers.org/MainDisp.csl?pid=95-106
Best,
Robert
> version
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Patched
major2
minor2.1
year 2006
month01
day 07
svn rev 37024
language R
Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended for us...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rcpp 1.1: R/C++ interface class library update
Hello, Based on feedback from this list I have updated the Rcpp R/C++ interface class library and uploaded the new version to CRAN. Just as the .C interface can be viewed as a C programmer-friendly version of the more demanding .Call interface, Rcpp essentially provides a C++ programmer-friendly version of the .Call interface, with automatic type checking and error reporting via a try/catch protocol. Rcpp also eliminates the need to work with the low-level SEXP macros. The API documentation is in RHOME/library/Rcpp/doc/RcppAPI.pdf. If there is interest in providing a supported C++ API for R, then Rcpp might be a useful starting point. The RQuantLib package has also been updated to use the new version of Rcpp. Dominick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] follow-up on qr.coef bug (PR#8478)
It certainly _was_ there, in incoming as PR#8476, and also in the R-devel
archives.
BTW, you have not given the minimal information required, e.g. the R
version. The pivot logic _is_ correct (your patch was broken), but there
was a problem with multiple RHSs, now fixed.
On Thu, 12 Jan 2006 [EMAIL PROTECTED] wrote:
> This is a multi-part message in MIME format.
> --090308090600080800090200
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> The bug I submitted yesterday (It's not entered in the bug data base, so
> I have no ID for it) included a suggested fix that
> is not correct. It worked for the examples I gave because there was no
> pivoting in fact, or only pivot permutations that were
> idempotent. A correction that works in general on the examples I gave
> makes these two changes in qr.coef():
>
>## coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
> "base")[1:p]
>coef[qr$pivot,] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
> "base")[1:p,]
>
>##coef[qr$pivot,] <- .Call("qr_coef_real", qr, y, PACKAGE =
> "base")[1:p]
>coef[qr$pivot,] <- .Call("qr_coef_real", qr, y, PACKAGE =
> "base")[1:p,]
>
> I'm not sure why the [1:p,] on the right is needed. For my examples, it
> works without this extraction operation, but maybe there is some case in
> which the output of qr_coef_real or qr_coef_cmplx could have more than p
> rows.
Read the C code: B is a copy of Bin (y) and so no, it cannot happen any
more (it could in an earlier version).
--
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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hello World problem
On 1/12/2006 10:46 AM, Romain Francois wrote:
> Hi,
>
> I'm trying to build a simple R package 'helloWorld' with just one
> function that prints 'hello World' on the C side.
> I agree that it is completely useless, but I just start mixing R and C.
>
> My C file is as follows :
>
> #include
> void helloWorld() {
> printf("hello world !\n") ;
> }
>
> When I call it from R, here is what happens :
> R> .C("helloWorld", PACKAGE = "helloWorld")
> hello world !
> list()
>
> is it normal that 'list()' is printed ?
Yes, because that is the return value from .C. If you don't want to
print it, you could call
invisible(.C( ... ))
or, more likely, you'd embed this call in a function that produced its
own return value after calling .C().
By the way, you should call Rprintf() rather than printf(), if you want
your function to work in environments like Windows Rgui. See the
Writing R Extensions manual for the details.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hello World problem
On Thu, 12 Jan 2006, Romain Francois wrote:
> Hi,
>
> I'm trying to build a simple R package 'helloWorld' with just one
> function that prints 'hello World' on the C side.
> I agree that it is completely useless, but I just start mixing R and C.
>
> My C file is as follows :
>
> #include
> void helloWorld() {
> printf("hello world !\n") ;
> }
>
> When I call it from R, here is what happens :
> R> .C("helloWorld", PACKAGE = "helloWorld")
> hello world !
> list()
>
> is it normal that 'list()' is printed ?
Yes. That is the return value of .C(). (It is not normal to call .C() at
the toplevel, rather as part of a function.) The value section of the
help page says
The functions '.C' and '.Fortran' return a list similar to the
'...' list of arguments passed in, but reflecting any changes made
by the C or Fortran code.
You have no ... args, so get an empty list.
--
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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hello World problem
See the `Value' section of ?.C. Also, it's better to use the i/o provided
by the R API; i.e., something like:
#include "R.h"
void helloworld() {
Rprintf("Hello world!\n");
}
Andy
From: Romain Francois
>
> Hi,
>
> I'm trying to build a simple R package 'helloWorld' with just one
> function that prints 'hello World' on the C side.
> I agree that it is completely useless, but I just start
> mixing R and C.
>
> My C file is as follows :
>
> #include
> void helloWorld() {
> printf("hello world !\n") ;
> }
>
> When I call it from R, here is what happens :
> R> .C("helloWorld", PACKAGE = "helloWorld")
> hello world !
> list()
>
> is it normal that 'list()' is printed ?
>
> Thanks.
>
> Romain
>
> --
> visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
> mixmod 1.7 is released :
> http://www-math.univ-> fcomte.fr/mixmod/index.php
>
>
> +---+
> | Romain FRANCOIS - http://francoisromain.free.fr |
> | Doctorant INRIA Futurs / EDF |
> +---+
>
> __
> 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] follow-up on qr.coef bug (PR#8478)
This is a multi-part message in MIME format.
--090308090600080800090200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The bug I submitted yesterday (It's not entered in the bug data base, so
I have no ID for it) included a suggested fix that
is not correct. It worked for the examples I gave because there was no
pivoting in fact, or only pivot permutations that were
idempotent. A correction that works in general on the examples I gave
makes these two changes in qr.coef():
## coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
"base")[1:p]
coef[qr$pivot,] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
"base")[1:p,]
##coef[qr$pivot,] <- .Call("qr_coef_real", qr, y, PACKAGE =
"base")[1:p]
coef[qr$pivot,] <- .Call("qr_coef_real", qr, y, PACKAGE =
"base")[1:p,]
I'm not sure why the [1:p,] on the right is needed. For my examples, it
works without this extraction operation, but maybe there is some case in
which the output of qr_coef_real or qr_coef_cmplx could have more than p
rows.
--090308090600080800090200
Content-Type: text/x-vcard; charset=utf-8;
name="sims.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="sims.vcf"
begin:vcard
fn:Chris Sims
n:Sims;Chris
org:Princeton University;Department of Economics
adr:;;Fisher Hall;Princeton;NJ;08544-1021;USA
email;internet:[EMAIL PROTECTED]
tel;work:609 258 4033
tel;fax:609 258 6419
x-mozilla-html:FALSE
url:http://www.princeton.edu/~sims
version:2.1
end:vcard
--090308090600080800090200--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] hello World problem
Hi,
I'm trying to build a simple R package 'helloWorld' with just one
function that prints 'hello World' on the C side.
I agree that it is completely useless, but I just start mixing R and C.
My C file is as follows :
#include
void helloWorld() {
printf("hello world !\n") ;
}
When I call it from R, here is what happens :
R> .C("helloWorld", PACKAGE = "helloWorld")
hello world !
list()
is it normal that 'list()' is printed ?
Thanks.
Romain
--
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
mixmod 1.7 is released : http://www-math.univ-fcomte.fr/mixmod/index.php
+---+
| Romain FRANCOIS - http://francoisromain.free.fr |
| Doctorant INRIA Futurs / EDF |
+---+
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] natural sorting
On Wed, Jan 11, 2006 at 05:45:10PM -0500, Gabor Grothendieck wrote: > It would be nifty to incorporate this into R or into an R package: > > http://sourcefrog.net/projects/natsort/ Btw, I haven't looked at the implementation, but Tcl also contains equivalent functionality, they call it dictionary sort: http://tcl.activestate.com/man/tcl8.4/TclCmd/lsort.htm -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange lme errors (PR#8477)
lme is not part of R, but of the contributed package nlme. So if you thought this is an lme error, you reported it in the wrong place. See the BUGS section in the FAQ. On Thu, 12 Jan 2006 [EMAIL PROTECTED] wrote: > Full_Name: Wilhelm Bernhard Kloke > Version: R-2.2.1 > OS: FreeBSD-5.3-i386 > Submission from: (NULL) (195.253.22.63) > > > Since 2.2.0 I am getting strange lme errors like > >> lme(ampl ~ gapf * bl,hframe2,~1|VP) > Fehler in lme.formula(ampl ~ gapf * bl, hframe2, ~1 | VP) : >See PORT documentation. Code (27) > > I have no clue how to understand this. The specification worked well until > 2.1.0. > I tried a second dataset with the same error message. Try traceback(). It will probably tell you the message comes from nlminb, in which case try ?nlminb. The problem here is the change in lme from optim to nlminb which seems to have broken many examples. Searching for that message would have lead you to suggestions that it comes from a bug in your compiler. RSiteSearch() lead me to http://finzi.psych.upenn.edu/R/Rhelp02a/archive/60118.html And googling showed that your OS has gcc 3.4.2 with its broken Fortran compiler. So it seems this is not a bug in lme nor in R but in your OS. > At least the said "PORT documentation" should be included in the R > distribution, just in case. The reference is! More specifically the URL given points you to http://netlib.bell-labs.com/cm/cs/cstr/153.pdf section 3. -- 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-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.2.2-1 RPM build problem and solution on RH AS 4 x86_64
On Wed, 2006-01-11 at 17:26 -0500, Dan Lipsitt wrote:
> I have a dual Xeon x86_64 system running Red Hat AS 4. There are no
> x86_64 rpms in http://cran.us.r-project.org/bin/linux/redhat/el4/ (the
> i386 ones are a point release behind anyway) , and the fc4 rpms have a
> whole web of dependencies I don't want to pull in. So I decided to
> build
> http://cran.us.r-project.org/bin/linux/redhat/SRPMS/R-2.2.1-1.fc3.src.rpm
> .
>
> When I ran rpmbuild. one of the make-check tests failed.
>
> from /BUILD/R-2.2.1/tests/p-r-random-tests.Rout.fail:
> > dkwtest("weibull",shape = 1)
> weibull(shape = 1) FAILED
> Error in dkwtest("weibull", shape = 1) : dkwtest failed
> Execution halted
>
> I was able to build the rpm after removing "--enable-r-shlib" from the
> spec file.
>
> http://cran.us.r-project.org/bin/linux/redhat/SRPMS/ReadMe says:
> "The new SRPM for R 2.1.1 builds the shared library version of R. This is,
> unfortunately, slower than the version without the shared library."
>
> It doesn't say why, if it's slower, it builds it that way. Can anyone
> shed some light on the subject?
Well, I did it because people were asking for it. You need the shared
library to use embedded R or use a GUI. I considered that most people
using R on the command line would pay the speed penalty (or not notice)
and that people who really need the speed could always compile their
own. The penalty is not so bad (~10%) on x86_64 anyway.
Martyn
---
This message and its attachments are strictly confidential. ...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with replicate and "..." (PR#8472)
Yesterday morning, Peter Dalgaard wrote:
> [EMAIL PROTECTED] writes:
>
>> I am using R version 2.0.0 (2004-10-04) on Fedora Core 2.
>>
>> This works correctly:
>>
>> > foo <- function(x=1,y=2) { c(x,y) }
>> > bar <- function(n,...) c(n,foo(...))
>> > bar(10,3)
>> [1] 10 3 2
>>
>> But it goes wrong if I replace "c" in bar with "replicate":
>>
>> > foo <- function(x=1,y=2) { c(x,y) }
>> > bar <- function(n,...) replicate(n,foo(...))
>> > bar(10,3)
>> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
>> [1,]000000000 0
>> [2,]222222222 2
>>
>> It is mysterious why x was bound to the apparently arbitrary
>> value 0 while y was left at its default.
>>
>> The ... arguments to bar seems to be ignored altogether.
>> bar(10), bar(10,x=3), and bar(10,3,4) give the same result.
>> Furthermore, bar(10,extra=3) does not give an error.
>>
>> Perhaps this mysterious behavior is unavoidable because of
>> the kind of hack replicate is?
>
> Yes. It is really a wrapper for
>
> sapply(integer(n), eval.parent(substitute(function(...) expr))
>
> Now, integer(n) is n zeroes, and the function that is passed to sapply
> is
>
> Browse[1]> FUN
> function (...)
> foo(...)
>
>
> Now, this gets called as FUN(0) and in turn foo(0) which is c(0,2).
>
> So, the short answer is "don't do that", and the long answer is "don't
> do that". If you're adventurous, you could try experimenting with a
> different definition, possibly
>
> sapply(integer(n), eval.parent(substitute(function(...) eval.parent(expr)))
>
> but I'm far from sure that it works...
Peter: thanks for the good explanation.
Perhaps the OFFICIAL replicate function can be fixed as you suggest
above, or by somehow incorporating this workaround:
bar <- function(n,...) { f <- function() foo(...);
replicate(n,f()) }
If not, then may I suggest that help("replicate") should document the
limitation, and perhaps the workaround as well?
(The help page does mention that replicate is just a convenience
wrapper, but without a BUGS or LIMITATIONS section as on Unix
manpages, a user might be forgiven for assuming that it actually works
in all cases. Obviously, a user shouldn't have to understand how a
function is implemented in order to avoid nasty special cases.)
Thanks! -jason
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange lme errors (PR#8477)
I have seen this error before. I think that you need to upgrade gcc. See http://tolstoy.newcastle.edu.au/R/help/05/08/10820.html I hope that this helps. Andrew On Thu, Jan 12, 2006 at 11:50:56AM +0100, [EMAIL PROTECTED] wrote: > Full_Name: Wilhelm Bernhard Kloke > Version: R-2.2.1 > OS: FreeBSD-5.3-i386 > Submission from: (NULL) (195.253.22.63) > > > Since 2.2.0 I am getting strange lme errors like > > > lme(ampl ~ gapf * bl,hframe2,~1|VP) > Fehler in lme.formula(ampl ~ gapf * bl, hframe2, ~1 | VP) : > See PORT documentation. Code (27) > > I have no clue how to understand this. The specification worked well until > 2.1.0. > I tried a second dataset with the same error message. > > At least the said "PORT documentation" should be included in the R > distribution, > just in case. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Andrew Robinson Department of Mathematics and StatisticsTel: +61-3-8344-9763 University of Melbourne, VIC 3010 Australia Fax: +61-3-8344-4599 Email: [EMAIL PROTECTED] http://www.ms.unimelb.edu.au __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] strange lme errors (PR#8477)
Full_Name: Wilhelm Bernhard Kloke Version: R-2.2.1 OS: FreeBSD-5.3-i386 Submission from: (NULL) (195.253.22.63) Since 2.2.0 I am getting strange lme errors like > lme(ampl ~ gapf * bl,hframe2,~1|VP) Fehler in lme.formula(ampl ~ gapf * bl, hframe2, ~1 | VP) : See PORT documentation. Code (27) I have no clue how to understand this. The specification worked well until 2.1.0. I tried a second dataset with the same error message. At least the said "PORT documentation" should be included in the R distribution, just in case. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] naiveBayes.plot does not accept ask=FALSE (needed for use with tkrplot)
Dear mailing list members,
I am writing a tiny tcltk interface for a few basic classification
methods which should also include plotting density curves with
naiveBayes.plot() and tkrplot(). I try to replot the curve using the
next input variable of the NaiveBayes by clicking a button in the
tkrplot window. Well, it kind of works but:
Now I want to make R stop asking me to "Hit to see next plot"
The plot function does not accept the parameter "ask=FALSE". Warning:
parameter "ask" could not be set in high-level plot() function.
If I precede par(ask=FALSE), nothing changes. Well, I am really not
shure wether I use "par()" correctly. (please see function plotfun()
below) What do I have to do to run R completley in batch-mode?
thank you in advance
any hint would be greatly appreciated
Dominik Heier
#my codelooks like this:
require(tcltk)
require(tkrplot)
require(klaR)
doBayes<-function() {
## selected by former widget . For instance:
DATA<-as.data.frame(iris)
Output_var="Species"
##
AnzahlZeilen<-nrow(DATA)
form<-as.formula(paste(Output_var,"~."))
bays<-NaiveBayes(form,data=DATA,usekernel=TRUE)
bbb<-tktoplevel()
tkwm.title(bbb,"Bayes-Plot")
inVars<-names(DATA)[names(DATA)!=Output_var]
varcount<-1
plotfun<-function() {
#par(ask=FALSE)
plot(bays,inVars[varcount],legendplot = TRUE,ask=FALSE)
## I tried to set ask=FALSE but got following warning:
## parameter "ask" could not be set in high-level plot() function
}
bplot<-tkrplot(bbb,plotfun)
plotNextVariable <- function() {
if (varcount==length(inVars)) {
varcount<<-1
} else {
varcount<<-(varcount+1)
}
tkrreplot(bplot,function() plot(bays,inVars[varcount],legendplot
= TRUE))
}
next.but <- tkbutton(bbb,text="Next input
variable",command=plotNextVariable)
tkpack(bplot,next.but)
}
doBayes()
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
