[Rd] Minor bug in lillie.test from nortest package (PR#9784)
Full_Name: David Sterling
Version: 2.4.0
OS: OS X
Submission from: (NULL) (64.81.102.199)
lillie.test() dies without grace producing the error message: 'Error in if
(pvalue > 0.1) { : missing value where TRUE/FALSE needed' when passed a vector
of identical values.
Examples:
> lillie.test(c(0,0,0,0,0,0,0,0,0,0))
Error in if (pvalue > 0.1) { : missing value where TRUE/FALSE needed
> lillie.test(c(1,1,1,1,1,1,1,1,1,1))
Error in if (pvalue > 0.1) { : missing value where TRUE/FALSE needed
> lillie.test(c(1.1,1.1,1.1,1.1,1.1,1.1,1.1,1.1,1.1,1.1))
Error in if (pvalue > 0.1) { : missing value where TRUE/FALSE needed
>
I see that the package maintainer is Juergen Gross, but I am new to R and I
haven't figured out how to contact him directly.
Thanks,
David
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minor bug in lillie.test from nortest package (PR#9784)
[EMAIL PROTECTED] wrote:
> Full_Name: David Sterling
> Version: 2.4.0
For bug reports please try the most recent version of R (which currently
is either R-2.5.1 or R-devel if you are really enthusiastic).
But please never send a bug report for a contributed (non-base) package
to R-bugs, but always to the package maintainer.
Since you already found out that Juergen Gross is maintaining the
package, there are several ways to find his e-mail address, the most
easiest one is to type
library(help=nortest)
which tells you the maintainer's address.
CCing to Juergen ...
Uwe Ligges
> OS: OS X
> Submission from: (NULL) (64.81.102.199)
>
>
> lillie.test() dies without grace producing the error message: 'Error in if
> (pvalue > 0.1) { : missing value where TRUE/FALSE needed' when passed a vector
> of identical values.
>
> Examples:
>> lillie.test(c(0,0,0,0,0,0,0,0,0,0))
> Error in if (pvalue > 0.1) { : missing value where TRUE/FALSE needed
>> lillie.test(c(1,1,1,1,1,1,1,1,1,1))
> Error in if (pvalue > 0.1) { : missing value where TRUE/FALSE needed
>> lillie.test(c(1.1,1.1,1.1,1.1,1.1,1.1,1.1,1.1,1.1,1.1))
> Error in if (pvalue > 0.1) { : missing value where TRUE/FALSE needed
>
> I see that the package maintainer is Juergen Gross, but I am new to R and I
> haven't figured out how to contact him directly.
>
> Thanks,
> David
>
> __
> 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] 'inline' package supports Fortran, .C calls etc
Dear developers, Duncan and me have just finished the update of the 'inline' package, which latest version (0.3.2) is now on CRAN. In addition to the previous update that featured saving and loading cfunction objects with recompiling the code, the current release supports recompiling the code in setCMethod on load, different calling conventions (.C, .Call, .Fortan) and allows to inline not only C, but also Fortran and ObjectiveC (needs testing) code, it performs clean up of all temp files created during compilation etc. Best, Oleg -- Dr Oleg Sklyar * EBI/EMBL, Cambridge CB10 1SD, England * +44-1223-494466 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with {
Why does the error get generated here? Is it a bug? It seems that
f and "{" are the same but when used in sapply f works but { does not.
Is its use in lapply really "an incorrect context"?
> f <- function(x, y) y
> f(1, 2)
[1] 2
> "{"(1, 2)
[1] 2
> lapply("y", function(x, y) y, 1:4) # ok
[[1]]
[1] 1 2 3 4
> lapply("y", "{", 1:4) # error
Error in lapply("y", "{", 1:4) : '...' used in an incorrect context
> R.version.string # XP
[1] "R version 2.5.1 (2007-06-27)"
See:
https://www.stat.math.ethz.ch/pipermail/r-help/2007-July/135999.html
for a variation of the lapply using sapply (which also has the same
problem if one uses { instead of f).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] BLAS / LAPACK version information from within R-session?
Hi, for diagnostic purposes, I would like to get information about the BLAS / LAPACK linked against R from within an R-session. An obvious application could be safety-checks for packages like Matrix and quantreg at load / attach - time. Also you could be more precise on the "framework" in which R is running for comparable benchmark timings on different systems. Perhaps this information may even be included into the output of R.Version() :-) ? So my question: Is this possible/reasonable at all? My impression is that it is not trivial, as you may ---at least on Win32--- even replace the standard Rblas.dll by some of the "better" Rblas.dll 's available on http://cran.at.r-project.org/bin/windows/contrib/ATLAS/ without telling R in any way before launching R. In the (Win32) case I imagine you could read out the StringFileInfo of the Rblas.dll being used --- which, for the time being, however, does not yet contain information on the BLAS version. But a (mid term) solution could be: (1) For building Rblas.dll from source, extend src/gnuwin/dllversion.rc from the standard R tar-ball to a new ressource file, say, src/gnuwin/blasdllversion.rc including version information on BLAS/LAPACK which is then used for building Rblas.dll. (2) Successively replace files from http://cran.at.r-project.org/bin/windows/contrib/ATLAS/ by ones built against blasdllversion.rc Unfortunately, I have no idea whether/how you could use information similar to StringFileInfo in other OS's ... Any suggestions appreciated. Best, Peter Ruckdeschel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] packages using UTF-8 encoding
Hi,
During a recent CRAN upload procedure, I was reminded of the following
regarding R-devel:
o R CMD check now warns on non-ASCII .Rd files without an
\encoding field, rather than just on ones that are definitely
not from an ISO-8859 encoding. This agrees with the
long-standing stipulation in 'Writing R Extensions', and
catches some packages with UTF-8 man pages.
o R CMD check now warns on DESCRIPTION files with a non-portable
Encoding field, or with non-ASCII data and no Encoding field.
So if we need UTF-8 encoding for the DESCRIPTION and *.Rd files, would it
be sufficient to have an "Encoding: UTF-8" line in the former and a
"\encoding{UTF-*}" in the latter? Thanks.
Cheers,
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] packages using UTF-8 encoding
On Mon, 9 Jul 2007, Sebastian P. Luque wrote:
> Hi,
>
> During a recent CRAN upload procedure, I was reminded of the following
> regarding R-devel:
>
>
>o R CMD check now warns on non-ASCII .Rd files without an
>\encoding field, rather than just on ones that are definitely
>not from an ISO-8859 encoding. This agrees with the
>long-standing stipulation in 'Writing R Extensions', and
>catches some packages with UTF-8 man pages.
>
>o R CMD check now warns on DESCRIPTION files with a non-portable
>Encoding field, or with non-ASCII data and no Encoding field.
>
>
> So if we need UTF-8 encoding for the DESCRIPTION and *.Rd files, would it
> be sufficient to have an "Encoding: UTF-8" line in the former and a
> "\encoding{UTF-*}" in the latter? Thanks.
\encoding(UTF-8}, yes.
However, I would be worried about anything which 'needs' UTF-8 encoding,
since it is going to be far from portable. If all you need are characters
from ISO-8859-1, it is more portable to use that.
My current understanding is that the internationalization/charset support
works well on Windows, MacOS X, systems using glibc (e.g. Linux), FreeBSD
and some commercial Unixen. The thing that does not work well is fonts to
display the non-ASCII characters, where glyphs are often silently omitted.
--
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] Problem with {
Gabor Grothendieck wrote:
> Why does the error get generated here? Is it a bug? It seems that
> f and "{" are the same but when used in sapply f works but { does not.
> Is its use in lapply really "an incorrect context"?
>
>
>> f <- function(x, y) y
>> f(1, 2)
>>
> [1] 2
>
>> "{"(1, 2)
>>
> [1] 2
>
>> lapply("y", function(x, y) y, 1:4) # ok
>>
> [[1]]
> [1] 1 2 3 4
>
>> lapply("y", "{", 1:4) # error
>>
> Error in lapply("y", "{", 1:4) : '...' used in an incorrect context
>
lapply() is not really part of the problem:
> (function(x,...) "{"(x,...))(1,2)
Error in (function(x, ...) { : '...' used in an incorrect context
Not sure exactly why this is so, but "{" has somewhat nonstandard
evaluation semantics and you cannot do
"{x, ...}" either, nor for that matter x <- function(...)...; x(2),
which gives off a similar error.
>> R.version.string # XP
>>
> [1] "R version 2.5.1 (2007-06-27)"
>
> See:
>
> https://www.stat.math.ethz.ch/pipermail/r-help/2007-July/135999.html
>
> for a variation of the lapply using sapply (which also has the same
> problem if one uses { instead of f).
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] packages using UTF-8 encoding
On Mon, 9 Jul 2007 14:23:17 +0100 (BST), Prof Brian Ripley <[EMAIL PROTECTED]> wrote: [...] > \encoding(UTF-8}, yes. Oops, yes (shift key pressed longer than needed). > However, I would be worried about anything which 'needs' UTF-8 encoding, > since it is going to be far from portable. If all you need are > characters from ISO-8859-1, it is more portable to use that. Right, this is for accents in some spanish/french words. I was thinking of UTF-8 since that's my current locale, but that's probably irrelevant for setting these directives here (accents). So if ISO-8859-1 is more portable, I think latin1 should be fine in this case. Thanks. -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Planet R - a weblog aggregator for statistical computing
Announcing... Planet R - a weblog aggregator for statistical computing Q: What is it? A: An aggregator for weblog posts about statistical computing topics, focused primarily around the R community. Q2: Where is it? A2: For now, at http://planetr.stderr.org Q3: What's it good for? A3: Hopefully, collecting resources and weblog posts from people who might otherwise not know about each other. Community-building, you see? Q4: How do I get my stuff on there? A4: Send mail to [EMAIL PROTECTED], with a representative subject line (e.g. 'please add to planet r' will be fine..); I'll need the link to the RSS feed of your blog or other resource. If you'd like a personal icon in the style of Planet Debian or Planet Gnome (or one of those other planetplanet-based sites..) feel free to send along a smallish picture or icon as well. (Think 80-by-80 pixels...) Q5: What sort of things are there? A5: A selection of weblogs about statistical computing, a feed from omegahat, some bioconductor-related content, feeds from a couple of journals (including JoSS content, as a subset of the J Computational and Graphical Statistics, as well as Royal Statistical Society content sourced from IngentaConnect...), the changes feed from the R Wiki, and a few other things of great utility to the R community. Please feel free to contact me directly with further content, media, suggestions, et cetera, that you think would enhance the utility of this site as a resource to the community. thanks, --elijah wright indiana university bloomington school of library and information science __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sweep sanity checking?
Ben Bolker zoo.ufl.edu> writes:
> What would R-core think of the following 'enhanced'
> sweep?
(now posted at
http://wiki.r-project.org/rwiki/doku.php?id=rdoc:base:sweep
)
It always warns if dim(x)[MARGIN] is
> not a multiple of length(STATS) {it's very hard indeed
> for me to think of a situation where you'd actually
> want this}; if check.margin=TRUE it is a bit stricter,
> complaining whenever dim(x)[MARGIN] doesn't
> match length(STATS).
>
> This change seems fairly harmless since it never does anything
> more than warn; the default for check.margin could
> be FALSE if you wanted to allow people a bit more rope
> to hang themselves with ... (of course this won't prevent
> you from sweeping the wrong margin of a square matrix,
> but nothing will).
>
> cheers
> Ben Bolker
>
Enough time has now passed that I feel justified following up
on this. Does anyone have any opinions on it, one way or the other?
Ben
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with {
Just one additional observation. { does work with mapply:
> f <- function(x, y) y
> mapply(f, letters, 1:26)
a b c d e f g h i j k l m n o p q r s t u v w x y z
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
> mapply("{", letters, 1:26) # same
a b c d e f g h i j k l m n o p q r s t u v w x y z
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
On 7/9/07, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> Gabor Grothendieck wrote:
> > Why does the error get generated here? Is it a bug? It seems that
> > f and "{" are the same but when used in sapply f works but { does not.
> > Is its use in lapply really "an incorrect context"?
> >
> >
> >> f <- function(x, y) y
> >> f(1, 2)
> >>
> > [1] 2
> >
> >> "{"(1, 2)
> >>
> > [1] 2
> >
> >> lapply("y", function(x, y) y, 1:4) # ok
> >>
> > [[1]]
> > [1] 1 2 3 4
> >
> >> lapply("y", "{", 1:4) # error
> >>
> > Error in lapply("y", "{", 1:4) : '...' used in an incorrect context
> >
> lapply() is not really part of the problem:
>
> > (function(x,...) "{"(x,...))(1,2)
> Error in (function(x, ...) { : '...' used in an incorrect context
>
> Not sure exactly why this is so, but "{" has somewhat nonstandard
> evaluation semantics and you cannot do
> "{x, ...}" either, nor for that matter x <- function(...)...; x(2),
> which gives off a similar error.
>
>
> >> R.version.string # XP
> >>
> > [1] "R version 2.5.1 (2007-06-27)"
> >
> > See:
> >
> > https://www.stat.math.ethz.ch/pipermail/r-help/2007-July/135999.html
> >
> > for a variation of the lapply using sapply (which also has the same
> > problem if one uses { instead of f).
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cleanup and Makevars
Hi This is a question prompted by the mac version of R, but as I see it, it should have broader interest. These days the CRAN Mac binary per default compiles every package for two architectures. First i386 and then ppc. In between the two compilation runs, any object files in pkgname/src is removed. This cleanup is necessary since otherwise Make would not recompile the object files under the next architecture. I have a package which includes a large SDK which I have put in src/fusion_sdk (and subdirectories). I take care of that by using a Makevars file with essentially (the whole Makevars file is reproduced below) PKG_SOURCES = \ fusion_sdk/calvin_files/data/src/CDFData.cpp OBJS=$(PKG_SOURCES:.cpp=.o) all: $(SHLIB) However, this setup does not remove the object files in the fusion_sdk subdirectory. From a posting on R-sig-mac by Simon Urbanek I learned that I need to clean up these directories myself. I have - per R extensions - attempted to do so using a pkgname/ cleanup script. While this works for cleaning up the sub directories when I do R CMD build, it seems as if this script is not being run between compilation runs (is this intentional btw.?). So my question is now: how do I in a simple way clean up my subdirectories? I would prefer it to be as simple as possible because so far I have not really needed anything besides a Makevars file. In fact the impression I have right now from looking at the SHLIB and INSTALL scripts is that I might need a Makefile that removes the object files _before_ starting the compilation, as I don't really see any cleanup process (eg. making a target clean) - but this may very well be due to my limited understanding of these scripts. Any help/hints on how to proceed? Especially if I want it to be portable? Kasper The full Makevars file: MYCXXFLAGS=-O0 %.o: %.cpp $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< -o $@ PKG_CPPFLAGS=\ -imacros R_affx_constants.h\ -Ifusion_sdk/calvin_files/array/src\ -Ifusion_sdk/calvin_files/data/src\ -Ifusion_sdk/calvin_files/exception/src\ -Ifusion_sdk/calvin_files/fusion/src\ -Ifusion_sdk/calvin_files/fusion/src/GCOSAdapter\ -Ifusion_sdk/calvin_files/fusion/src/CalvinAdapter\ -Ifusion_sdk/calvin_files/parameter/src\ -Ifusion_sdk/calvin_files/parsers/src\ -Ifusion_sdk/calvin_files/portability/src\ -Ifusion_sdk/calvin_files/template/src\ -Ifusion_sdk/calvin_files/utils/src\ -Ifusion_sdk/calvin_files/writers/src\ -Ifusion_sdk/file\ -Ifusion_sdk/portability\ -D_USE_MEM_MAPPING_ PKG_SOURCES = \ fusion_sdk/calvin_files/data/src/CDFData.cpp\ fusion_sdk/calvin_files/data/src/CDFProbeGroupInformation.cpp\ fusion_sdk/calvin_files/data/src/CDFProbeInformation.cpp\ fusion_sdk/calvin_files/data/src/CDFProbeSetInformation.cpp\ fusion_sdk/calvin_files/data/src/CDFQCProbeInformation.cpp\ fusion_sdk/calvin_files/data/src/CDFQCProbeSetInformation.cpp\ fusion_sdk/calvin_files/data/src/CELData.cpp\ fusion_sdk/calvin_files/data/src/DataGroup.cpp\ fusion_sdk/calvin_files/data/src/DataGroupHeader.cpp\ fusion_sdk/calvin_files/data/src/DataSet.cpp\ fusion_sdk/calvin_files/data/src/DataSetHeader.cpp\ fusion_sdk/calvin_files/data/src/FileHeader.cpp\ fusion_sdk/calvin_files/data/src/GenericData.cpp\ fusion_sdk/calvin_files/data/src/GenericDataHeader.cpp\ fusion_sdk/calvin_files/exception/src/ExceptionBase.cpp\ fusion_sdk/calvin_files/fusion/src/CalvinAdapter/ CalvinCELDataAdapter.cpp\ fusion_sdk/calvin_files/fusion/src/FusionBPMAPData.cpp\ fusion_sdk/calvin_files/fusion/src/FusionCDFData.cpp\ fusion_sdk/calvin_files/fusion/src/FusionCDFQCProbeSetNames.cpp\ fusion_sdk/calvin_files/fusion/src/FusionCELData.cpp\ fusion_sdk/calvin_files/fusion/src/GCOSAdapter/GCOSCELDataAdapter.cpp\ fusion_sdk/calvin_files/parameter/src/ParameterNameValueType.cpp\ fusion_sdk/calvin_files/parsers/src/CDFFileReader.cpp\ fusion_sdk/calvin_files/parsers/src/CelFileReader.cpp\ fusion_sdk/calvin_files/parsers/src/DataGroupHeaderReader.cpp\ fusion_sdk/calvin_files/parsers/src/DataGroupReader.cpp\ fusion_sdk/calvin_files/parsers/src/DataSetHeaderReader.cpp\ fusion_sdk/calvin_files/parsers/src/DataSetReader.cpp\ fusion_sdk/calvin_files/parsers/src/FileHeaderReader.cpp\ fusion_sdk/calvin_files/parsers/src/FileInput.cpp\ fusion_sdk/calvin_files/parsers/src/GenericDataHeaderReader.cpp\ fusion_sdk/calvin_files/parsers/src/GenericFileReader.cpp\ fusion_sdk/calvin_files/utils/src/AffymetrixGuid.cpp\ fusion_sdk/calvin_files/utils/src/DateTime.cpp\ fusion_sdk/calvin_files/utils/src/FileUtils.cpp\ fusion_sdk/calvin_files/utils/src/StringUtils.cpp\ fusion_sdk/calvin_files/utils/src/checksum.cpp\ fusion_sdk/file/BPMAPFileData.
Re: [Rd] BLAS / LAPACK version information from within R-session?
AFAIK all platforms by default work the same: they use dynamic libraries for BLAS and LAPACK, and these may well be symbolic links. I know of no way to ask a BLAS dynamic library what version it is. On Mon, 9 Jul 2007, Peter Ruckdeschel wrote: > Hi, > > for diagnostic purposes, I would like to get information about > the BLAS / LAPACK linked against R from within an R-session. > > An obvious application could be safety-checks for packages like > Matrix and quantreg at load / attach - time. Why should that be needed? Those packages assume they are talking to working dynamic libraries, and there is no way to check that a particular library works (it might work when compiled under gcc 4.1.2 and not under 4.2.0, to take a non-random example). > Also you could be more precise on the "framework" in which R > is running for comparable benchmark timings on different systems. > > Perhaps this information may even be included into the output > of R.Version() :-) ? I can think of more worthy candidates, e.g. the compilers used to build R, and for Linux something more precise about the distro used. Remember that for most R users the BLAS/LAPACK speed is not very important: it only matters where linear algebra dominates the computations. If I run R CMD check over CRAN with an optimized BLAS the speedup is barely noticeable (but I do get more failures). > So my question: > >Is this possible/reasonable at all? > > My impression is that it is not trivial, as you may ---at least > on Win32--- even replace the standard Rblas.dll by some of the > "better" Rblas.dll 's available on > > http://cran.at.r-project.org/bin/windows/contrib/ATLAS/ > > without telling R in any way before launching R. > > > In the (Win32) case I imagine you could read out the > > StringFileInfo > > of the Rblas.dll being used --- which, for the time > being, however, does not yet contain information on > the BLAS version. But a (mid term) solution could be: > > (1) For building Rblas.dll from source, extend > >src/gnuwin/dllversion.rc > > from the standard R tar-ball to a new ressource file, say, > > src/gnuwin/blasdllversion.rc > > including version information on BLAS/LAPACK which is then > used for building Rblas.dll. > > (2) Successively replace files from > > http://cran.at.r-project.org/bin/windows/contrib/ATLAS/ > > by ones built against blasdllversion.rc > > > > Unfortunately, I have no idea whether/how you could use information > similar to StringFileInfo in other OS's ... > > Any suggestions appreciated. > > Best, > Peter Ruckdeschel > > __ > 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
