Re: [Rd] Posting Guide
Gabor, I agree. Furthermore I think it might be useful to add that in my experience (and I'm sure others as well) that the process of creating a simple reproduceable example for an email to r-help will in most cases clarify what I'm trying to do and actually solve my own problem for me - once or twice I've been tempted to email my problem and my own solution for the archive. As a side note I tend to put a fair bit of work (i.e. measured in days of calendar time and hours of work) for fear of being abused on the list for not doing enough prep work. Fear is probably not the idea motivator though... Regards, Sean 2008/6/6 Gabor Grothendieck <[EMAIL PROTECTED]>: > People read the posting guide yet they are still unable to create an > acceptable > post. e.g. > https://stat.ethz.ch/pipermail/r-help/2008-June/164092.html > > I think the problem is that the guide is not clear or concise enough. > I suggest we add a summary at the beginning which gets to the heart > of what a poster is expected to provide: > > Summary > > To maximize your change of getting a response when posting provide (1) > commented, > (2) minimal, (3) self-contained and (4) reproducible code. (This one > line summary > also appears at the end of each message to r-help.) > > "Self-contained" and "reproducible" mean that a responder can copy the > questioner's code to > the clipboard, paste it into their R session and see the same problem > you as the questioner > see. Note that dput(mydata) will display mydata in a reproducible way. > Self-contained and reproducible are needed because: > (1) Self-Effort. It shows that the questioner tried to solve the > problem by themself first. > (2) Test framework. Often the responder needs to play with the code a > bit in order to respond > or at least to give the best answer. They can't do that without a > test framework that includes > the data and the code to run it and its not fair to ask them to not > only answer the question but > also to come up with test data and to complete incomplete code. > (3) Archives. Questions and answers go into the archives so they are > not only for the benefit of > of the questioner but also for the benefit of all future searchers of > the archive. That means > that its not finished if you have solved the problem for yourself. > You still need to ensure that > the thread has a complete solution. (For that reason its also > important to give a meaningful > subject to each post.) > > "Commented" and "minimal" also reduce the time it takes to understand > the problem. > Don't just dump your code as is into the message since you are just > wasting your own > time. Its not likely anyone will answer a message if the questioner > has not taken the > time to reduce it to its essential elements. Surprisingly, quite > often understanding what > the problem is takes the responder most of the time -- not solving the > problem. Once the > question is actually understood its often quite fast to answer. Thus > in addition to posting > it in a minimal form, comment on it sufficiently so that the responder > knows what the code > does and is intended to produce. It may be obvious to the questioner > who is embroiled in > the problem but that does not mean its obvious to others. > > Introduction > > rest of posting guide ... > > __ > 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] Fail to call AC_CACHE_CHECK on R 2.7.0 for Solaris
I've tried to build R 2.6.1 and 2.7.0 on Solaris 10 update 4 (SPARC) and
both configure ok, so you might ask why I suspect there is a problem.
I tried to build the maths program Sage
http://www.sagemath.org/
version 3.0.3alpha1. Sage fails when building R 2.6.1 - (Sage includes R
in the package). The relavant bit of Sage, which is only using an
unmodified R configure script is:
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking for iconv... in libiconv
checking whether iconv accepts "UTF-8", "latin1" and "UCS-*"... no
checking for iconvlist... yes
configure: error: --with-iconv=yes (default) and a suitable iconv is
not available
Looking at the Sage problem in detail, I believe I know the reason and
are somewhat surprised R builds at all on Solaris. I think this problem
is an R problem, not a Sage problem.
For some reason the R "configure" script was not happy with my readline,
but after trying to configure with the configure option
--with-readline=no
The R 2.6.1 source configured ok. I did not bother running 'make' but
there were
no failures when the configure script was run. I then repeated this
with the latest version of R (2.7.0) and got similar results.
Looking at the file configure.ac in R (both 2.6.1 and 2.7.0), I see:
## iconv headers and function.
if test "${use_iconv}" = yes; then
R_ICONV
if test "$r_cv_iconv_latin1" != yes; then
AC_MSG_ERROR([--with-iconv=yes (default) and a suitable iconv is
not available])
fi
else
AC_MSG_WARN([--with-iconv=no is deprecated and will be withdrawn
shortly])
fi
Clearly the value of r_cv_iconv_latin1 determines if this test passes
or fails and so whether the error message that I get is printed or not.
The variable r_cv_iconv_latin1 is never set directly in configure, but
by in a Macro called AC_CACHE_CHECK in the file m4/R.m4.
Looking in that macro r4/R.m4 we see:
AC_CACHE_CHECK([whether iconv accepts "UTF-8", "latin1" and "UCS-
*"],
[r_cv_iconv_latin1],
So it would appear to me that AC_CACHE_CHECK needs to be run in order
that r_cv_iconv_latin will be set properly. But looking at
configure.ac, I think AC_CACHE_CHECK is only called on Linux, and not
on Solaris. Obviously this could explain why this bit of Sage works on
Linux, but not Solaris.
## check for visible __libc_stack_end on Linux
case "${host_os}" in
linux*)
AC_CACHE_CHECK([for visible __lib_stack_end],
[r_cv_libc_stack_end],
[AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include "confdefs.h"
#include
extern void * __libc_stack_end;
So it seems to me this will never work, as the the relevant macro is
not run on Solaris. It begs the obvious question why does this work
when I download the source of R. I can't see the answer to that one,
but there are reports of R failing to build on Solaris, but for me at
least, it configures ok.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fail to call AC_CACHE_CHECK on R 2.7.0 for Solaris
This is covered in the 'R Installation and Administration' manual that
INSTALL asked you to read. Specifically for Solaris:
Modern Solaris systems allow a large selection of Open Source software
to be installed via @command{pkg-get}: a Sparc Solaris 10 system came
with @code{libreadline} and @code{libiconv} and a choice of @code{gcc3}
and @code{gcc4} compilers, installed under @file{/opt/csw}. (You will
need GNU @code{libiconv}: the Solaris version of @code{iconv} is not
sufficiently powerful.)
R 2.7.0 is documented to build on several versions of Solaris in that
manual, so the problem is definitely not 'R on Solaris'.
You analysis is plain wrong. Search for r_cv_iconv_latin1 in
configure and you will see three lines which set it (plus one that checks
if it was set in the cache).
On Sat, 7 Jun 2008, Dr. David Kirkby wrote:
I've tried to build R 2.6.1 and 2.7.0 on Solaris 10 update 4 (SPARC) and both
configure ok, so you might ask why I suspect there is a problem.
I tried to build the maths program Sage
http://www.sagemath.org/
version 3.0.3alpha1. Sage fails when building R 2.6.1 - (Sage includes R in
the package). The relavant bit of Sage, which is only using an unmodified R
configure script is:
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking for iconv... in libiconv
checking whether iconv accepts "UTF-8", "latin1" and "UCS-*"... no
checking for iconvlist... yes
configure: error: --with-iconv=yes (default) and a suitable iconv is
not available
Looking at the Sage problem in detail, I believe I know the reason and are
somewhat surprised R builds at all on Solaris. I think this problem is an R
problem, not a Sage problem.
For some reason the R "configure" script was not happy with my readline, but
after trying to configure with the configure option
--with-readline=no
The R 2.6.1 source configured ok. I did not bother running 'make' but there
were
no failures when the configure script was run. I then repeated this
with the latest version of R (2.7.0) and got similar results.
Looking at the file configure.ac in R (both 2.6.1 and 2.7.0), I see:
## iconv headers and function.
if test "${use_iconv}" = yes; then
R_ICONV
if test "$r_cv_iconv_latin1" != yes; then
AC_MSG_ERROR([--with-iconv=yes (default) and a suitable iconv is
not available])
fi
else
AC_MSG_WARN([--with-iconv=no is deprecated and will be withdrawn
shortly])
fi
Clearly the value of r_cv_iconv_latin1 determines if this test passes
or fails and so whether the error message that I get is printed or not.
The variable r_cv_iconv_latin1 is never set directly in configure, but
by in a Macro called AC_CACHE_CHECK in the file m4/R.m4.
Looking in that macro r4/R.m4 we see:
AC_CACHE_CHECK([whether iconv accepts "UTF-8", "latin1" and "UCS-
*"],
[r_cv_iconv_latin1],
So it would appear to me that AC_CACHE_CHECK needs to be run in order
that r_cv_iconv_latin will be set properly. But looking at
configure.ac, I think AC_CACHE_CHECK is only called on Linux, and not
on Solaris. Obviously this could explain why this bit of Sage works on
Linux, but not Solaris.
## check for visible __libc_stack_end on Linux
case "${host_os}" in
linux*)
AC_CACHE_CHECK([for visible __lib_stack_end],
[r_cv_libc_stack_end],
[AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include "confdefs.h"
#include
extern void * __libc_stack_end;
So it seems to me this will never work, as the the relevant macro is
not run on Solaris. It begs the obvious question why does this work
when I download the source of R. I can't see the answer to that one,
but there are reports of R failing to build on Solaris, but for me at
least, it configures ok.
__
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] Fail to call AC_CACHE_CHECK on R 2.7.0 for Solaris
Prof Brian Ripley wrote:
This is covered in the 'R Installation and Administration' manual that
INSTALL asked you to read. Specifically for Solaris:
Modern Solaris systems allow a large selection of Open Source software
to be installed via @command{pkg-get}: a Sparc Solaris 10 system came
with @code{libreadline} and @code{libiconv} and a choice of @code{gcc3}
and @code{gcc4} compilers, installed under @file{/opt/csw}. (You will
need GNU @code{libiconv}: the Solaris version of @code{iconv} is not
sufficiently powerful.)
R 2.7.0 is documented to build on several versions of Solaris in that
manual, so the problem is definitely not 'R on Solaris'.
You analysis is plain wrong. Search for r_cv_iconv_latin1 in
configure and you will see three lines which set it (plus one that
checks if it was set in the cache).
Thanks a lot. Clearly when I compiled R directly, it see my GNU libiconv
rather than the Sun supplied one, but when built as part of Sage, it see
the Sun one. That should be easy to fix.
Dave
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide
Here is a second version of the summary. Its been rearranged to place most important info at top. Also shortened it a bit. It still needs links to example posts, as suggested. Anyone? Summary Surprisingly, the main problem for responders is not to answer the posted questions but to quickly figure out what the question is, reproduce it in their own R session and test their answer. Test Framework. To faciliate that provide a test framework of: (1) reproducible self-contained minimal code and data. That means responders can copy it from the questioner's post and paste it into their session to see the same output without having to enter even one R command. NB. dput(mydata) produces mydata in reproducible form. (2) comments/explanations of what the code is intended to produce and (3) versions of all software used, e.g. sessionInfo(). Without self-contained reproducible code the responder must not only understand the question but must also create a test framework and that typically takes more time than answering the question! Its not fair to ask the responder to provide all that on top of answering the question. Do NOT assume the problem is so simple that it is not necessary. Effort. The effort taken to reduce the problem to its essentials and produce a test framework often solves the problem avoiding the need for a post in the first place. It at the least shows that the questioner tried to solve it themself. Subscribers. The questioner should ensure that the thread is complete and that it has an appropriate Subject. The purpose of the post is not only to help the questioner but also the other list subscribers and those later searching the archives. On Fri, Jun 6, 2008 at 1:30 PM, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > People read the posting guide yet they are still unable to create an > acceptable > post. e.g. > https://stat.ethz.ch/pipermail/r-help/2008-June/164092.html > > I think the problem is that the guide is not clear or concise enough. > I suggest we add a summary at the beginning which gets to the heart > of what a poster is expected to provide: > > Summary > > To maximize your change of getting a response when posting provide (1) > commented, > (2) minimal, (3) self-contained and (4) reproducible code. (This one > line summary > also appears at the end of each message to r-help.) > > "Self-contained" and "reproducible" mean that a responder can copy the > questioner's code to > the clipboard, paste it into their R session and see the same problem > you as the questioner > see. Note that dput(mydata) will display mydata in a reproducible way. > Self-contained and reproducible are needed because: > (1) Self-Effort. It shows that the questioner tried to solve the > problem by themself first. > (2) Test framework. Often the responder needs to play with the code a > bit in order to respond > or at least to give the best answer. They can't do that without a > test framework that includes > the data and the code to run it and its not fair to ask them to not > only answer the question but > also to come up with test data and to complete incomplete code. > (3) Archives. Questions and answers go into the archives so they are > not only for the benefit of > of the questioner but also for the benefit of all future searchers of > the archive. That means > that its not finished if you have solved the problem for yourself. > You still need to ensure that > the thread has a complete solution. (For that reason its also > important to give a meaningful > subject to each post.) > > "Commented" and "minimal" also reduce the time it takes to understand > the problem. > Don't just dump your code as is into the message since you are just > wasting your own > time. Its not likely anyone will answer a message if the questioner > has not taken the > time to reduce it to its essential elements. Surprisingly, quite > often understanding what > the problem is takes the responder most of the time -- not solving the > problem. Once the > question is actually understood its often quite fast to answer. Thus > in addition to posting > it in a minimal form, comment on it sufficiently so that the responder > knows what the code > does and is intended to produce. It may be obvious to the questioner > who is embroiled in > the problem but that does not mean its obvious to others. > > Introduction > > rest of posting guide ... > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide
Here's my attempt at making a little more friendly: Removed self-contained - implied by reproducible Used slightly less formal language (and you instead of the questioner) Fixed a couple of spelling mistakes Removed references to testing framework - I don't think that that term needs to be introduced --- For most questions, the main problem isn't answering the question, but understanding exactly what the question is, reproducing the problem and checking the answer. To make easy for others to help you, you should provide: (1) reproducible, minimal code, and the data needed to run it. That means others can copy and paste from your email and see the same output that you did. An easy way to include data in an email is to include the output of dput(mydata) (2) comments/explanations of what the code is supposed to do, and (3) the version of R and the packages that you used, easily produced by sessionInfo(). Without reproducible code, others have to spend a lot of time recreating the problem so that they can provide an answer that works. Do NOT assume the problem is so simple that it is not necessary. This can seem like a lot of work, but it often pays off by revealing the solution without having to ask anyone else. Even if it doesn't, your effort shows the list that you have tried to solve it yourself. It's also worthwhile spending some time writing a good subject line that succinctly summarises your problem. This also helps others trying to solve the same problem in the future as they can more easily locate relevant messages. Hadley On Sat, Jun 7, 2008 at 8:38 AM, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > Here is a second version of the summary. Its been rearranged to > place most important info at top. Also shortened it a bit. > > It still needs links to example posts, as suggested. Anyone? > > Summary > > Surprisingly, the main problem for responders is not to answer the > posted questions but to quickly figure out what the question is, reproduce > it in their own R session and test their answer. > > Test Framework. To faciliate that provide a test framework of: > > (1) reproducible self-contained minimal code and data. That means > responders can copy it from the questioner's post and paste it > into their session to see the same output without having to > enter even one R command. > NB. dput(mydata) produces mydata in reproducible form. > (2) comments/explanations of what the code is intended to produce and > (3) versions of all software used, e.g. sessionInfo(). > > Without self-contained reproducible code the responder must not only > understand the question but must also create a test framework and that > typically takes more time than answering the question! Its not fair > to ask the responder to provide all that on top of answering the > question. Do NOT assume the problem is so simple that it is not > necessary. > > Effort. The effort taken to reduce the problem to its essentials and > produce a test framework often solves the problem avoiding the need > for a post in the first place. It at the least shows that the > questioner tried to solve it themself. > > Subscribers. The questioner should ensure that the thread is complete > and that it has an appropriate Subject. The purpose of the post is > not only to help the questioner but also the other list subscribers > and those later searching the archives. > > > > On Fri, Jun 6, 2008 at 1:30 PM, Gabor Grothendieck > <[EMAIL PROTECTED]> wrote: >> People read the posting guide yet they are still unable to create an >> acceptable >> post. e.g. >> https://stat.ethz.ch/pipermail/r-help/2008-June/164092.html >> >> I think the problem is that the guide is not clear or concise enough. >> I suggest we add a summary at the beginning which gets to the heart >> of what a poster is expected to provide: >> >> Summary >> >> To maximize your change of getting a response when posting provide (1) >> commented, >> (2) minimal, (3) self-contained and (4) reproducible code. (This one >> line summary >> also appears at the end of each message to r-help.) >> >> "Self-contained" and "reproducible" mean that a responder can copy the >> questioner's code to >> the clipboard, paste it into their R session and see the same problem >> you as the questioner >> see. Note that dput(mydata) will display mydata in a reproducible way. >> Self-contained and reproducible are needed because: >> (1) Self-Effort. It shows that the questioner tried to solve the >> problem by themself first. >> (2) Test framework. Often the responder needs to play with the code a >> bit in order to respond >> or at least to give the best answer. They can't do that without a >> test framework that includes >> the data and the code to run it and its not fair to ask them to not >> only answer the question but >> also to come up with test data and to complete incomplete code. >> (3) Archives. Questions and answers go into the archiv
Re: [Rd] Posting Guide
Might I suggest the following two additions: For item (1), I suggest adding to the end of it something like "Consider attaching this output/data as a txt file if it is too large, or consider using one of the built in data sets (as produced e.g. by data() ) if they suffice to illustrate the problem." I find it rather distracting to have to wade through pages and pages of the the output of dput before I can read the questions to be answered, and perhaps they are the kinds of questions that indeed can be answered without that output, in which case having it pasted straight into the text can be quite distracting. Unless we can at least convince them to append the output to the end, instead of the core of the message. With regards to sessionInfo, I would consider it equally important, many times, to have the output of ls(), to make sure that functions etc are not masked by user defined global variables. But perhaps I'm alone in that? At least mention clearly that the code provided should be reproducible on a clean R workspace, or something like that? I think creating this summary section to the posting guide is a great idea. The posting guide, though chock full with useful information on how to do a proper post, ends up having just way too much information, resulting, as experienced, in people not following it. Haris Skiadas Department of Mathematics and Computer Science Hanover College On Jun 7, 2008, at 10:48 AM, hadley wickham wrote: Here's my attempt at making a little more friendly: Removed self-contained - implied by reproducible Used slightly less formal language (and you instead of the questioner) Fixed a couple of spelling mistakes Removed references to testing framework - I don't think that that term needs to be introduced --- For most questions, the main problem isn't answering the question, but understanding exactly what the question is, reproducing the problem and checking the answer. To make easy for others to help you, you should provide: (1) reproducible, minimal code, and the data needed to run it. That means others can copy and paste from your email and see the same output that you did. An easy way to include data in an email is to include the output of dput(mydata) (2) comments/explanations of what the code is supposed to do, and (3) the version of R and the packages that you used, easily produced by sessionInfo(). Without reproducible code, others have to spend a lot of time recreating the problem so that they can provide an answer that works. Do NOT assume the problem is so simple that it is not necessary. This can seem like a lot of work, but it often pays off by revealing the solution without having to ask anyone else. Even if it doesn't, your effort shows the list that you have tried to solve it yourself. It's also worthwhile spending some time writing a good subject line that succinctly summarises your problem. This also helps others trying to solve the same problem in the future as they can more easily locate relevant messages. Hadley On Sat, Jun 7, 2008 at 8:38 AM, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: Here is a second version of the summary. Its been rearranged to place most important info at top. Also shortened it a bit. It still needs links to example posts, as suggested. Anyone? Summary Surprisingly, the main problem for responders is not to answer the posted questions but to quickly figure out what the question is, reproduce it in their own R session and test their answer. Test Framework. To faciliate that provide a test framework of: (1) reproducible self-contained minimal code and data. That means responders can copy it from the questioner's post and paste it into their session to see the same output without having to enter even one R command. NB. dput(mydata) produces mydata in reproducible form. (2) comments/explanations of what the code is intended to produce and (3) versions of all software used, e.g. sessionInfo(). Without self-contained reproducible code the responder must not only understand the question but must also create a test framework and that typically takes more time than answering the question! Its not fair to ask the responder to provide all that on top of answering the question. Do NOT assume the problem is so simple that it is not necessary. Effort. The effort taken to reduce the problem to its essentials and produce a test framework often solves the problem avoiding the need for a post in the first place. It at the least shows that the questioner tried to solve it themself. Subscribers. The questioner should ensure that the thread is complete and that it has an appropriate Subject. The purpose of the post is not only to help the questioner but also the other list subscribers and those later searching the archives. On Fri, Jun 6, 2008 at 1:30 PM, Gabor Grothendieck <[EMAIL PROTECTED]> wr
Re: [Rd] Posting Guide
Here is another update. I have added the following:
- info about using a fresh R session. (In that case ls() output is less
essential; however, the developers of sessionInfo() might consider
adding that as a default or as an option.)
- questioner should consider use of functions.
- for data use dump(x, file = "") to reproducibly display data or use
builtin datasets listed by data()
- minimal versions of slow code should be presented in cases where
questioner is looking for faster code.
- we still need to add links to illustrative sample questions in r-help
The following were not added for the reason cited:
- guide is not just for questioners. Important to distinguish roles
of questioner, responder and reader.
- what is to be provided ought to be given a name to make it easier
to refer to. An unlabelled set of points is too vague. Test
framework seems appropriately descriptive. By giving it a name
one can request that a questioner "provide a test framework as
defined in the posting guide summary".
- self contained is not implied by reproducible. Reproducible
only means that info is available somewhere -- not that its all
available right in the questioner's post and all in a manner that
is readily accessible.
- focus should be on making data minimal. Don't like attachments
since responder must save them and read them in. It encourages
use of large rather than minimal data sets.
Summary
Surprisingly, the main problem for responders is not to answer the
question but to quickly figure out what the question is, reproduce it
in their own R session and test their answer.
Test Framework. To faciliate this provide a test framework of:
(1) minimal reproducible self-contained commented code and data
that has been run in a fresh R session. That means code and
data have been cut down as far as possible to the essentials
needed to illustrate the problem and were run are just after
starting up R. Also it means that its possible for responders
to just copy the code and data section from the questioner's
post to the clipboard and paste it into their session to see
the same output without having to enter even one R command.
In some cases there may be an advantage to present the code as
a function and in the case of needing a speedup be sure to post
a minimal version of the slow code. Use builtin data sets such
as those listed by data() to illustrate problem or reduce your
data to a minimum and present it reproducibly by using:
dump("mydata", file = "")
(2) comments/explanation of what the code is intended to produce
-- Don't assume its obvious!
(3) versions of all software used, e.g. sessionInfo(),
or R.version.string; packageDescription("zoo")$Version
Without self-contained reproducible code the responder must not only
understand the question but must also create a test framework and that
typically takes more time than answering the question! Its not fair
to ask the responder to provide all that on top of answering the
question. Do NOT assume the problem is so simple that it is not
necessary.
Effort. The effort taken to reduce the problem to its essentials and
produce a test framework often solves the problem avoiding the need
for a post in the first place. It at the least shows that the
questioner tried to solve it themself.
Subscribers. The questioner should ensure that the thread is complete
and that it has an appropriate Subject. The purpose of the post is
not only to help the questioner but also the other list subscribers
and those later searching the archives.
On Sat, Jun 7, 2008 at 9:38 AM, Gabor Grothendieck
<[EMAIL PROTECTED]> wrote:
> Here is a second version of the summary. Its been rearranged to
> place most important info at top. Also shortened it a bit.
>
> It still needs links to example posts, as suggested. Anyone?
>
> Summary
>
> Surprisingly, the main problem for responders is not to answer the
> posted questions but to quickly figure out what the question is, reproduce
> it in their own R session and test their answer.
>
> Test Framework. To faciliate that provide a test framework of:
>
> (1) reproducible self-contained minimal code and data. That means
> responders can copy it from the questioner's post and paste it
> into their session to see the same output without having to
> enter even one R command.
> NB. dput(mydata) produces mydata in reproducible form.
> (2) comments/explanations of what the code is intended to produce and
> (3) versions of all software used, e.g. sessionInfo().
>
> Without self-contained reproducible code the responder must not only
> understand the question but must also create a test framework and that
> typically takes more time than answering the question! Its not fair
> to ask the responder to provide all that on top of answering the
> question. Do NOT assume the pro
[Rd] slot(obj, "nosuch") documentation question
Using slot() on object (or "@") and using a nonexistent
slotname returns an error (see example code).
R> setClass("foobar", representation=list(a="numeric"))
[1] "foobar"
R> foobar <- new("foobar", a=5)
R> [EMAIL PROTECTED]
[1] 5
R> [EMAIL PROTECTED]
Error: no slot of name "b" for this object of class "foobar"
The details section of manpage has a paragraph that
seems to agree with above:
Unlike attributes, slots are not partially matched,
and asking for (or trying to set) a slot with an
invalid name for that class generates an error.
But then the last paragraph in that same section seems to
suggest otherwise.
Currently the @ extraction operator and slot function
do no checking, neither that object has a formal class
nor that name is a valid slot name for the class. (They
will extract the attribute of the given name if it
exists from any R object.) The replacement forms do
check (at least if check=TRUE).
Are these two paragraphs not in partial conflict with each
other? I had initially expected (my initial bottom-up
quick glance only read last paragraph) to get NULL from
invalid slotname.
This is in reference to writing method that might be
passed an object created by previous version of software,
and new slots were added to class in later revisions.
For such situations, is the norm then to do
"slotNames(obj) %in% " prior to accessing any
slotname from extended class?
TIA
R version 2.7.0 Patched (2008-06-04 r45830)
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Computational singularity of a positive definite matrix
I'm trying to use function "solve" to find the inverse of a matrix, which is positive definite in theory. But for some situations, I get error message because of computational singularity. I'm wondering if I can set the tolerance for detecting linear independence to an infinitely small value to avoid this problem. Is there any serious consequence by doing this? Are there other solutions to this problem? Thanks. -- View this message in context: http://www.nabble.com/Computational-singularity-of-a-positive-definite-matrix-tp17702809p17702809.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] doc buglet / as.Date method
> "PR" == Paul Roebuck <[EMAIL PROTECTED]> > on Thu, 5 Jun 2008 10:55:54 -0500 (CDT) writes: PR> Under Details section for as.Date: PR> as.Date will accept numeric data (the number of days PR> since an epoch), but only is origin is supplied. PR> ^^ PR> should be "if" Thank you; that's fixed now. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
