Re: [Rd] literate programming
> On Tue, 5 Aug 2008 09:38:23 -0500 (CDT), > Terry Therneau (TT) wrote: > I'm working on the next iteration of coxme. (Rather slowly during > the summer). This is the most subtle code I've done in S, both > mathematically and technically, and seems a perfect vehicle for > the "literate programming" paradym of Knuth. The Sweave project > is pointed at S output however, not source code. I would > appreciate any pointers to an noweb type client that was > R-aware. > Other suggestions are welcome as well. At the end of the day > I'd like to have a good user guide, technical reference, and solid > enough code documentation that others can begin to participate as > well. (Retirement in 10 years -- I don't expect to maintain this > forever!) Why not use the original noweb in the first place? You can even maintain Sweave files with it, the Sweave latex syntax was written for exactly that purpose ... ESS supported noweb before Sweave existed. In fact the emacs noweb mode was the main reason I chose that syntax for Sweave, and the latex syntax was added lateron because some people write whole packages using noweb and would have had a syntax conflict in their vignettes. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RGtk2 on linux: "stack smashing detected"
Yea I am aware of this. This is because the Ubuntu binary has stack smashing
detection enabled. It's possible to build R without this checking:
export CFLAGS="-fno-stack-protector"
I have not been able to figure out why stack smashing is detected. I'm
cc'ing this to r-devel in case anyone else has an idea.
Michael
On Wed, Aug 6, 2008 at 12:31 AM, Felix Andrews <[EMAIL PROTECTED]> wrote:
> Hi Michael,
>
> I wonder whether you have come across this before? I am testing RGtk2
> on Ubuntu and it seems that any error that occurs in that context
> kills the R process with a message "stack smashing detected". This is
> on Ubuntu 8.04. Minimal example:
>
> > library(RGtk2)
> > sessionInfo()
> R version 2.7.1 (2008-06-23)
> i486-pc-linux-gnu
>
> locale:
>
> LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_AU.UTF-8;LC_PAPER=en_AU.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_AU.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] RGtk2_2.12.1
> > stop("hello")
> Error: hello
> > foo <- GtkWindow()
> Error: could not find function "GtkWindow"
> > foo <- gtkWindow()
> > butt <- gtkButton("error")
> > gSignalConnect(butt, "clicked", function(...) stop("hello"))
> clicked
> 16
> attr(,"class")
> [1] "CallbackID"
> > foo$add(butt)
> ## click button
> > Error in function (...) : hello
> *** stack smashing detected ***: /usr/lib/R/bin/exec/R terminated
> === Backtrace: =
> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7b98138]
> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7b980f0]
> /usr/lib/R/lib/libR.so[0xb7e12094]
> /usr/lib/R/lib/libR.so[0xb7c8422e]
> /usr/lib/R/lib/libR.so[0xb7c86fd7]
> /usr/lib/R/lib/libR.so[0xb7c84082]
> /usr/lib/R/lib/libR.so[0xb7c87b13]
> /usr/lib/R/lib/libR.so(R_GetTraceback+0xc6)[0xb7cb8576]
> /usr/lib/R/lib/libR.so[0xb7cba85c]
> /usr/lib/R/lib/libR.so[0xb7cb966f]
> /usr/lib/R/lib/libR.so(Rf_errorcall+0x3af)[0xb7cb9e7f]
> /usr/lib/R/lib/libR.so[0xb7cba0c5]
> /usr/lib/R/lib/libR.so[0xb7cfc89a]
> /usr/lib/R/lib/libR.so(Rf_eval+0x451)[0xb7cc62e1]
> /usr/lib/R/lib/libR.so[0xb7cc86c2]
> /usr/lib/R/lib/libR.so(Rf_eval+0x451)[0xb7cc62e1]
> /usr/lib/R/lib/libR.so[0xb7cc78f0]
> /usr/lib/R/lib/libR.so(Rf_eval+0x451)[0xb7cc62e1]
> /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac)[0xb7cc9e5c]
> /usr/lib/R/lib/libR.so(Rf_eval+0x349)[0xb7cc61d9]
> /usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac)[0xb7cc9e5c]
> /usr/lib/R/lib/libR.so(Rf_eval+0x349)[0xb7cc61d9]
> /usr/lib/R/lib/libR.so[0xb7c75b89]
> /usr/lib/R/lib/libR.so(R_ToplevelExec+0xb8)[0xb7c763b8]
> /usr/lib/R/lib/libR.so(R_tryEval+0x3e)[0xb7c7643e]
>
> /usr/lib/R/site-library/RGtk2/libs/RGtk2.so(R_GClosureMarshal+0x86)[0xb6ff18c6]
> /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759]
> /usr/lib/libgobject-2.0.so.0[0xb68bbd1d]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c6)[0xb68bd916]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb68bdc59]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x8a)[0xb6bf301a]
> /usr/lib/libgtk-x11-2.0.so.0[0xb6bf4b7e]
>
> /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x4f)[0xb68b4a4f]
> /usr/lib/libgobject-2.0.so.0[0xb68a6079]
> /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759]
> /usr/lib/libgobject-2.0.so.0[0xb68bb975]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c6)[0xb68bd916]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb68bdc59]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x8a)[0xb6bf30aa]
> /usr/lib/libgtk-x11-2.0.so.0[0xb6bf30d1]
> /usr/lib/libgtk-x11-2.0.so.0[0xb6ccc8d4]
> /usr/lib/libgobject-2.0.so.0[0xb68a6079]
> /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759]
> /usr/lib/libgobject-2.0.so.0[0xb68bbea0]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x5fe)[0xb68bd64e]
> /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb68bdc59]
> /usr/lib/libgtk-x11-2.0.so.0[0xb6deb667]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc1)[0xb6cc5b21]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2b8)[0xb6cc6d88]
> /usr/lib/libgdk-x11-2.0.so.0[0xb6b3fa9a]
> /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x178)[0xb681fbf8]
> /usr/lib/libglib-2.0.so.0[0xb6822e5e]
> /usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x6c)[0xb68233ac]
> /usr/lib/libgtk-x11-2.0.so.0(gtk_main_iteration+0x34)[0xb6cc70d4]
>
> /usr/lib/R/site-library/RGtk2/libs/RGtk2.so(R_gtk_eventHandler+0x19)[0xb6f9fb19]
> /usr/lib/R/lib/libR.so(R_runHandlers+0x46)[0xb7db9586]
> /usr/lib/R/lib/libR.so[0xb7dba98f]
> /usr/lib/R/lib/libR.so(R_ReadConsole+0x35)[0xb7db7945]
> /usr/lib/R/lib/libR.so(Rf_ReplIteration+0x42b)[0xb7cea63b]
> /usr/lib/R/lib/libR.so(run_Rmainloop+0x102)[0xb7cea7b2]
> /usr/lib/R/lib/libR.so(Rf_mainloop+0x1c)[0xb7cea80c]
> /usr/lib/R/bin/exec/R(main+0x46)[0x8048776]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7ac145
Re: [Rd] RGtk2 on linux: "stack smashing detected"
Note that this is happening in R_GetTraceback. Running under gdb told me
where (deparse2buff, but I guessed that) and on my system that the problem
was in sprintf.
Eh voila:
case EXTPTRSXP:
{
char tpb[12+sizeof(void *)];
d->sourceable = FALSE;
sprintf(tpb, "", R_ExternalPtrAddr(s));
print2buff(tpb, d);
}
break;
is too small a buffer. I've just fixed that in the R sources.
So the unusual circumstance was deparsing an external pointer.
On Wed, 6 Aug 2008, Michael Lawrence wrote:
Yea I am aware of this. This is because the Ubuntu binary has stack smashing
detection enabled. It's possible to build R without this checking:
export CFLAGS="-fno-stack-protector"
I have not been able to figure out why stack smashing is detected. I'm
cc'ing this to r-devel in case anyone else has an idea.
Michael
On Wed, Aug 6, 2008 at 12:31 AM, Felix Andrews <[EMAIL PROTECTED]> wrote:
Hi Michael,
I wonder whether you have come across this before? I am testing RGtk2
on Ubuntu and it seems that any error that occurs in that context
kills the R process with a message "stack smashing detected". This is
on Ubuntu 8.04. Minimal example:
library(RGtk2)
sessionInfo()
R version 2.7.1 (2008-06-23)
i486-pc-linux-gnu
locale:
LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_AU.UTF-8;LC_PAPER=en_AU.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_AU.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] RGtk2_2.12.1
stop("hello")
Error: hello
foo <- GtkWindow()
Error: could not find function "GtkWindow"
foo <- gtkWindow()
butt <- gtkButton("error")
gSignalConnect(butt, "clicked", function(...) stop("hello"))
clicked
16
attr(,"class")
[1] "CallbackID"
foo$add(butt)
## click button
Error in function (...) : hello
*** stack smashing detected ***: /usr/lib/R/bin/exec/R terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7b98138]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7b980f0]
/usr/lib/R/lib/libR.so[0xb7e12094]
/usr/lib/R/lib/libR.so[0xb7c8422e]
/usr/lib/R/lib/libR.so[0xb7c86fd7]
/usr/lib/R/lib/libR.so[0xb7c84082]
/usr/lib/R/lib/libR.so[0xb7c87b13]
/usr/lib/R/lib/libR.so(R_GetTraceback+0xc6)[0xb7cb8576]
/usr/lib/R/lib/libR.so[0xb7cba85c]
/usr/lib/R/lib/libR.so[0xb7cb966f]
/usr/lib/R/lib/libR.so(Rf_errorcall+0x3af)[0xb7cb9e7f]
/usr/lib/R/lib/libR.so[0xb7cba0c5]
/usr/lib/R/lib/libR.so[0xb7cfc89a]
/usr/lib/R/lib/libR.so(Rf_eval+0x451)[0xb7cc62e1]
/usr/lib/R/lib/libR.so[0xb7cc86c2]
/usr/lib/R/lib/libR.so(Rf_eval+0x451)[0xb7cc62e1]
/usr/lib/R/lib/libR.so[0xb7cc78f0]
/usr/lib/R/lib/libR.so(Rf_eval+0x451)[0xb7cc62e1]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac)[0xb7cc9e5c]
/usr/lib/R/lib/libR.so(Rf_eval+0x349)[0xb7cc61d9]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x2ac)[0xb7cc9e5c]
/usr/lib/R/lib/libR.so(Rf_eval+0x349)[0xb7cc61d9]
/usr/lib/R/lib/libR.so[0xb7c75b89]
/usr/lib/R/lib/libR.so(R_ToplevelExec+0xb8)[0xb7c763b8]
/usr/lib/R/lib/libR.so(R_tryEval+0x3e)[0xb7c7643e]
/usr/lib/R/site-library/RGtk2/libs/RGtk2.so(R_GClosureMarshal+0x86)[0xb6ff18c6]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759]
/usr/lib/libgobject-2.0.so.0[0xb68bbd1d]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c6)[0xb68bd916]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb68bdc59]
/usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x8a)[0xb6bf301a]
/usr/lib/libgtk-x11-2.0.so.0[0xb6bf4b7e]
/usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x4f)[0xb68b4a4f]
/usr/lib/libgobject-2.0.so.0[0xb68a6079]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759]
/usr/lib/libgobject-2.0.so.0[0xb68bb975]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c6)[0xb68bd916]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb68bdc59]
/usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x8a)[0xb6bf30aa]
/usr/lib/libgtk-x11-2.0.so.0[0xb6bf30d1]
/usr/lib/libgtk-x11-2.0.so.0[0xb6ccc8d4]
/usr/lib/libgobject-2.0.so.0[0xb68a6079]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x129)[0xb68a7759]
/usr/lib/libgobject-2.0.so.0[0xb68bbea0]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x5fe)[0xb68bd64e]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb68bdc59]
/usr/lib/libgtk-x11-2.0.so.0[0xb6deb667]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc1)[0xb6cc5b21]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2b8)[0xb6cc6d88]
/usr/lib/libgdk-x11-2.0.so.0[0xb6b3fa9a]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x178)[0xb681fbf8]
/usr/lib/libglib-2.0.so.0[0xb6822e5e]
/usr/lib/libglib-2.0.so.0(g_main_context_iteration+0x6c)[0xb68233ac]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_iteration+0x34)[0xb6cc70d4]
/usr/lib/R/site-library/RGtk2/libs/RGtk2.so(R_gtk_eventHandler+0x19)[0xb6f9fb19]
/usr/lib/R/lib/libR.so(R_runHandlers+0x46)[0xb7db9586]
/usr/lib/R/lib/libR.
Re: [Rd] literate programming
"ESS supported noweb before Sweave existed." That is the bit I didn't know. What I was rather looking for was a noweb mode that knows about S formatting, and here it was available all along. I've used a version of ESS for a lng time - probably should re-read the documentation one of these days to catch up on all the new features! "and the latex syntax was added lateron because some people write whole packages using noweb and would have had a syntax conflict in their vignettes" I'm not quite sure what this means. Thanks much, Terry Therneau __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adding .PDF files to a package
Dear Rense, The way you included your pdf file in your package is appropriate. Normally, when invocking "help.start()" and going to your package link, you should have two links overview and directory where your pdf file should be located. Best, Mathieu Rense Nieuwenhuis a écrit : Deal all, new as I am to developing packages for R-Project, I apologize on beforehand for questions that are too obvious. I am trying to 'add' a PDF document containing some detailed information to a package. The way I understand the Rexts.pdf document, I should add my .PDF document to the /inst/doc/ folder, and links to the files should be build automatically. However, after building it on MacOSX (10.4) using 'R CMD build' and checking it using 'R CMD check', no links seems to be present. All checks are OK, but no vignette or whatever appears in the help-files of the package. Clearly, I'm missing something. I would really appreciate some pointers on how to integrate an 'additional' pdf file to my package. Thanks in advance, Rense Nieuwenhuis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Numerical optimisation and "non-feasible" regions
Dear list,
I'm currently writing a C code to compute the (composite) likelihood -
well this is done but not really robust. The C code is wrapped in an R
one which call the optimizer routine - optim or nlm. However, the
fitting procedure is far from being robust as the parameter space
depends on the parameter - I have a covariance matrix that should be a
valid one for example.
Currently, I set in my header file something like #define MINF -1.0e120
and test if we are in a non-feasible region, then setting the
log-composite likelihood to MINF. The problem I see with this approach
is that for a quite large non-feasible region, we have a kind of plateau
where the log-composite likelihood is constant and may have potential
issues with the optimizer. The other issue is that the gradient is now
badly estimated using finite-differences.
Consequently, I'm not sure this is the most relevant approach as it
seems that (especially the BFGS method, probably due to the estimation
of the gradient) the optimization is really sensitive to this "strategy"
and fails (quite often).
As I'm (really) not an expert in optimization problems, do you know good
ways to deal with non-feasible regions? Or do I need to reparametrize my
model so that all parameters belong to $\mathbb{R}$ - which should be
not so easy...
Thanks for your expertise!
Best,
Mathieu
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adding .PDF files to a package
Dear Mathieu, thank you for your assurance that my manual-reading-skills are on par! ;-) The thing is, though, that I can't get it to work. In the index of the help pages, it reads: ''Read overview or browse directory". The 'browse directory' option does not work. When clicked on the 'Read overview' option, the following text appears: "Vignettes of package Read.isi Sorry, the package contains no vignette meta-information or index. Please browse the directory." So, clearly, some links are missing. Should I manually create an index file? If so, how do I specify the link to the .PDF file? I hope someone can help[. Thank in advance, Rense Nieuwenhuis - - -- --- - Rense Nieuwenhuis +31 6 481 05 683 www.rensenieuwenhuis.nl On Aug 6, 2008, at 17:40 , Mathieu Ribatet wrote: > Dear Rense, > > The way you included your pdf file in your package is appropriate. > Normally, when invocking "help.start()" and going to your package > link, you should have two links overview and directory where your > pdf file should be located. > > Best, > Mathieu > > Rense Nieuwenhuis a écrit : >> Deal all, >> >> new as I am to developing packages for R-Project, I apologize on >> beforehand for questions that are too obvious. I am trying to 'add' a >> PDF document containing some detailed information to a package. >> >> The way I understand the Rexts.pdf document, I should add my .PDF >> document to the /inst/doc/ folder, and links to the files should be >> build automatically. However, after building it on MacOSX (10.4) >> using 'R CMD build' and checking it using 'R CMD check', no links >> seems to be present. All checks are OK, but no vignette or whatever >> appears in the help-files of the package. >> >> Clearly, I'm missing something. I would really appreciate some >> pointers on how to integrate an 'additional' pdf file to my package. >> >> Thanks in advance, >> >> Rense Nieuwenhuis >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Institute of Mathematics > Ecole Polytechnique Fédérale de Lausanne > STAT-IMA-FSB-EPFL, Station 8 > CH-1015 Lausanne Switzerland > http://stat.epfl.ch/ > Tel: + 41 (0)21 693 7907 > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adding .PDF files to a package
This seems a bit too simplistic but, does it make any difference if your
file is .pdf rather than .PDF?
Paul
Rense Nieuwenhuis wrote:
Dear Mathieu,
thank you for your assurance that my manual-reading-skills are on
par! ;-)
The thing is, though, that I can't get it to work. In the index of
the help pages, it reads: ''Read overview or browse directory". The
'browse directory' option does not work. When clicked on the 'Read
overview' option, the following text appears:
"Vignettes of package Read.isi
Sorry, the package contains no vignette meta-information or index.
Please browse the directory."
So, clearly, some links are missing. Should I manually create an
index file? If so, how do I specify the link to the .PDF file?
I hope someone can help[.
Thank in advance,
Rense Nieuwenhuis
- - -- --- -
Rense Nieuwenhuis
+31 6 481 05 683
www.rensenieuwenhuis.nl
On Aug 6, 2008, at 17:40 , Mathieu Ribatet wrote:
Dear Rense,
The way you included your pdf file in your package is appropriate.
Normally, when invocking "help.start()" and going to your package
link, you should have two links overview and directory where your
pdf file should be located.
Best,
Mathieu
Rense Nieuwenhuis a écrit :
Deal all,
new as I am to developing packages for R-Project, I apologize on
beforehand for questions that are too obvious. I am trying to 'add' a
PDF document containing some detailed information to a package.
The way I understand the Rexts.pdf document, I should add my .PDF
document to the /inst/doc/ folder, and links to the files should be
build automatically. However, after building it on MacOSX (10.4)
using 'R CMD build' and checking it using 'R CMD check', no links
seems to be present. All checks are OK, but no vignette or whatever
appears in the help-files of the package.
Clearly, I'm missing something. I would really appreciate some
pointers on how to integrate an 'additional' pdf file to my package.
Thanks in advance,
Rense Nieuwenhuis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential in...{{dropped:26}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] axis() ignores supplied value of argument mgp[3]?
Prof Brian Ripley wrote: On Sun, 3 Aug 2008, J. R. M. Hosking wrote: Prof Brian Ripley wrote: What is true is that the line is set before the inline setting of mgp is processed: it all depends on what 'supplied' means, and you supplied two values. This is changed in R-patched now. Thank you, that works. Here is a perhaps related issue: R Help on 'axis' for argument 'line' says "The relative placing of tick marks and tick labels is unchanged". But this appears not to be the case when graphics parameter mgp[3] is nonzero: plot(1:4, yaxt="n") par(mgp=c(3,2,1)) axis(2, 1:2) axis(2, 3:4, line=1) which one (or, at least, I) would expect to place all the tick labels the same distance into the margin, does not in fact do so. I don't think that is what it says. Setting 'line' or 'pos' temporarily sets mgp[3] to zero (which is what the help implies in parts you did not quote). I'm afraid I read the help closely several times and did not find that implication. Otherwise 'line' would just duplicate mgp[3]. Which is still useful functionality --- easier to supply a single value than to change one element of a 3-element vector. My interpretation is that axis() is taking mgp[2] rather than the correct mgp[2]-mgp[3] as the relative position of the tick mark with Why is it correct when you have been told 'mgp[3]' was overridden? That was my best attempt to interpret the phrase "relative placing of ... tick labels", given that no graphics parameter is explicitly documented as having that meaning. We could explicitly say it is treated as zero for ultimate clarity. respect to the axis line. To summarize (if I now understand things correctly): when the position of the axis line is determined by the value of mgp[3], then mgp[2] is the absolute position (number of lines into the margin) of the tick labels; but if the position of the axis line is determined by the 'line' or 'pos' arguments of axis(), then mgp[2] is the relative position of the tick labels (number of lines between the tick labels and the axis line). If this is the intended behaviour, then certainly I think it would be helpful if it were explicitly documented. J. R. M. Hosking __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical optimisation and "non-feasible" regions
Mathieu Ribatet epfl.ch> writes: > > Dear list, > > I'm currently writing a C code to compute the (composite) likelihood - > well this is done but not really robust. The C code is wrapped in an R > one which call the optimizer routine - optim or nlm. However, the > fitting procedure is far from being robust as the parameter space > depends on the parameter - I have a covariance matrix that should be a > valid one for example. One reasonably straightforward hack to deal with this is to add a penalty that is (e.g.) a quadratic function of the distance from the feasible region, if that is reasonably straightforward to compute -- that way your function will get gently pushed back toward the feasible region. Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] axis() ignores supplied value of argument mgp[3]?
Have you looked at the current documentation on the svn server? On Wed, 6 Aug 2008, J. R. M. Hosking wrote: Prof Brian Ripley wrote: On Sun, 3 Aug 2008, J. R. M. Hosking wrote: Prof Brian Ripley wrote: What is true is that the line is set before the inline setting of mgp is processed: it all depends on what 'supplied' means, and you supplied two values. This is changed in R-patched now. Thank you, that works. Here is a perhaps related issue: R Help on 'axis' for argument 'line' says "The relative placing of tick marks and tick labels is unchanged". But this appears not to be the case when graphics parameter mgp[3] is nonzero: plot(1:4, yaxt="n") par(mgp=c(3,2,1)) axis(2, 1:2) axis(2, 3:4, line=1) which one (or, at least, I) would expect to place all the tick labels the same distance into the margin, does not in fact do so. I don't think that is what it says. Setting 'line' or 'pos' temporarily sets mgp[3] to zero (which is what the help implies in parts you did not quote). I'm afraid I read the help closely several times and did not find that implication. Otherwise 'line' would just duplicate mgp[3]. Which is still useful functionality --- easier to supply a single value than to change one element of a 3-element vector. My interpretation is that axis() is taking mgp[2] rather than the correct mgp[2]-mgp[3] as the relative position of the tick mark with Why is it correct when you have been told 'mgp[3]' was overridden? That was my best attempt to interpret the phrase "relative placing of ... tick labels", given that no graphics parameter is explicitly documented as having that meaning. We could explicitly say it is treated as zero for ultimate clarity. respect to the axis line. To summarize (if I now understand things correctly): when the position of the axis line is determined by the value of mgp[3], then mgp[2] is the absolute position (number of lines into the margin) of the tick labels; but if the position of the axis line is determined by the 'line' or 'pos' arguments of axis(), then mgp[2] is the relative position of the tick labels (number of lines between the tick labels and the axis line). If this is the intended behaviour, then certainly I think it would be helpful if it were explicitly documented. J. R. M. Hosking __ 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] literate programming
> On Wed, 6 Aug 2008 10:25:38 -0500 (CDT),
> Terry Therneau (TT) wrote:
> "ESS supported noweb before Sweave existed."
>That is the bit I didn't know. What I was rather looking for was a
noweb
> mode that knows about S formatting, and here it was available all along.
I've
> used a version of ESS for a lng time - probably should re-read the
> documentation one of these days to catch up on all the new
>features!
>"and the latex
> syntax was added lateron because some people write whole packages using
> noweb and would have had a syntax conflict in their vignettes"
> I'm not quite sure what this means.
Well, you can write your Sweave files also looking like
**
This is some latex documentation bla bla bla
And here comes a code chuck:
\begin{Scode}{echo=FALSE,fig=TRUE}
plot(rnorm(100))
\end{Scode}
and here we go again with latex
**
and Sweave will process it correctly (if the file has extension
.Rtex). As Sweave does not use noweb's magic <<>>= tags in this case,
you can use those for regular noweb processing. Of course you loose
the nice handling of code chunks by ESS in that case ...
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cannot link mypackage to 2 other packages
Hi, I need to link mypackage to 2 other packages so I can call some C functions defined in these 2 packages from mine. I've tried Depends: packageA, packageB LinkingTo: packageA, packageB as suggested by the "5.4 Registering native routines" section of the "Writing R Extensions" manual but then only packageA is seen at compilation time (gcc is called with -I"/some/path/to/packageA/include" only). I've also tried Depends: packageA, packageB LinkingTo: packageA LInkingTo: packageB but this time only packageB is seen at compilation time. How can I link mypackage to both packageA and packageB? Thanks! H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cannot link mypackage to 2 other packages
What platform? We've seen a similar report that said the problem was on Windows only. Like this one, it had nothing to reproduce. On Wed, 6 Aug 2008, [EMAIL PROTECTED] wrote: Hi, I need to link mypackage to 2 other packages so I can call some C functions defined in these 2 packages from mine. I've tried Depends: packageA, packageB LinkingTo: packageA, packageB as suggested by the "5.4 Registering native routines" section of the "Writing R Extensions" manual but then only packageA is seen at compilation time (gcc is called with -I"/some/path/to/packageA/include" only). I've also tried Depends: packageA, packageB LinkingTo: packageA LInkingTo: packageB but this time only packageB is seen at compilation time. How can I link mypackage to both packageA and packageB? Thanks! H. __ 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] Cannot link mypackage to 2 other packages
Quoting Prof Brian Ripley <[EMAIL PROTECTED]>: What platform? 64-bit openSUSE Linux [EMAIL PROTECTED]:~> uname -a Linux george1 2.6.22.12-0.1-default #1 SMP 2007/11/06 23:05:18 UTC x86_64 x86_64 x86_64 GNU/Linux R version 2.8.0 Under development (unstable) (2008-07-07 r46046) We've seen a similar report that said the problem was on Windows only. Like this one, it had nothing to reproduce. Do you want me to send you the packages or to put them somewhere on our website? Thanks! H. On Wed, 6 Aug 2008, [EMAIL PROTECTED] wrote: Hi, I need to link mypackage to 2 other packages so I can call some C functions defined in these 2 packages from mine. I've tried Depends: packageA, packageB LinkingTo: packageA, packageB as suggested by the "5.4 Registering native routines" section of the "Writing R Extensions" manual but then only packageA is seen at compilation time (gcc is called with -I"/some/path/to/packageA/include" only). I've also tried Depends: packageA, packageB LinkingTo: packageA LInkingTo: packageB but this time only packageB is seen at compilation time. How can I link mypackage to both packageA and packageB? Thanks! H. __ 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
