Re: [Rd] BOD causes error in 2.4.0
> "Gabor" == Gabor Grothendieck <[EMAIL PROTECTED]>
> on Thu, 10 Aug 2006 11:34:48 -0400 writes:
Gabor> Using "R version 2.4.0 Under development (unstable)
Gabor> (2006-08-08 r38825)" on Windows XP and starting in a
Gabor> fresh session we get an error if we type BOD. (There
Gabor> is no error in "Version 2.3.1 Patched (2006-06-04
Gabor> r38279)".)
>> BOD
Gabor> Error in data.frame(Time = c("1", "2"), demand = c(" 8.3", "10.3"),
Gabor> check.names = FALSE, :
Gabor> row names contain missing values
Gabor> In addition: Warning message:
Gabor> corrupt data frame: columns will be truncated or padded with NAs in:
Gabor> format.data.frame(x, digits = digits, na.encode = FALSE)
Yes, thank you Gabor.
At first, this it's peculiar that our standard checks haven't
detected this bug themselvs, since the help page of BOD uses
BOD without any error..
Indeed the error happens in format.data.frame() which is called
from print.data.frame.
Interestingly, good old str() "works" - and quite interestingly
> str(BOD)
'data.frame': 2 obs. of 2 variables:
$ Time : num 1 2 3 4 5 7
$ demand: num 8.3 10.3 19 16 15.6 19.8
- attr(*, "reference")= chr "A1.4, p. 270"
note the '2 obs' observations part when there obviously are 6 of
them ...
Now, if you really inspect the object,
> dput(BOD, control = "all")
structure(list(Time = c(1, 2, 3, 4, 5, 7), demand = c(8.3, 10.3,
19, 16, 15.6, 19.8)), .Names = c("Time", "demand"), row.names = c(NA,
6), class = "data.frame", reference = "A1.4, p. 270")
it becomes more clear: the row.names have really become a mess,
where they should have been (as in R <= 2.3.x)
the equivalent of
row.names = c("1", "2", "3", "4", "5", "6")
Now if you look at the source code,
<..R..>/src/library/datasets/data/BOD.R
you'll see that `bug' is already in the source : it has
row.names = c(NA, 6),
explicitly there.
Of course this has something to do with the new R-devel feature
of storing rownames ``compressedly'' when they are equivalent to
as.character(1:n)
and I assume the c(NA, 6) used to be a trick for making the
row.names `compressed' - however the trick was not working correctly.
I've temporarily fixed the problem by putting
row.names = as.character(1:6),
there.
Thanks again for the report.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] uniroot arguments (PR#9139)
<> --please do not edit the information below-- Version: platform = i686-redhat-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 2 minor = 2.1 year = 2005 month = 12 day = 20 svn rev = 36812 language = R Locale: C Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] uniroot arguments (PR#9140)
<> When invoking "uniroot" with any argument named "u", uniroot exits with error: "Error in f(lower, ...) : argument "u" is missing, with no default". This error occurs whether or not "u" determines the root. Giving "u" a default value results in garbage from uniroot. ## Define a function with a root: > test<-function(x,a) (x-a)^3 ## Find the root: > uniroot(test,c(0,1),a=.75) $root [1] 0.7500141 $f.root [1] 2.793453e-15 $iter [1] 22 $estim.prec [1] 6.103516e-05 ## All is well. Change argument "a" to "u": > test<-function(x,u) (x-u)^3 ## Plot it: > plot(seq(0,1,by=.1),test(seq(0,1,by=.1),u=.75),type='l') ## All is well. Find the root: > uniroot(test,c(0,1),u=.75) Error in f(lower, ...) : argument "u" is missing, with no default ## Define a new function with the same root: > test<-function(x,a,u) (x-a)^3 /u ## Plot it: > plot(seq(0,1,by=.1),test(seq(0,1,by=.1),a=.75,u=.2),type='l') ## All is well. Find the root: > uniroot(test,c(0,1),a=.75,u=.2) Error in f(lower, ...) : argument "u" is missing, with no default ## Give u a default value: > test<-function(x,a,u=.2) (x-a)^3 /u ## Find the root: > uniroot(test,c(0,1),a=.75,u=.2) Error in uniroot(test, c(0, 1), a = 0.75, u = 0.2) : f() values at end points not of opposite sign ## Oh, really? > test(0,.75,.2) [1] -2.109375 > test(1,.75,.2) [1] 0.078125 --please do not edit the information below-- Version: platform = i686-redhat-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 2 minor = 2.1 year = 2005 month = 12 day = 20 svn rev = 36812 language = R Locale: C Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] uniroot arguments (PR#9140)
[EMAIL PROTECTED] writes: > <> > > When invoking "uniroot" with any argument named "u", uniroot exits > with error: "Error in f(lower, ...) : argument "u" is missing, with no > default". This error occurs whether or not "u" determines the root. > > Giving "u" a default value results in garbage from uniroot. > > ## Define a function with a root: > > test<-function(x,a) (x-a)^3 > > ## Find the root: > > uniroot(test,c(0,1),a=.75) > $root > [1] 0.7500141 > > $f.root > [1] 2.793453e-15 > > $iter > [1] 22 > > $estim.prec > [1] 6.103516e-05 > > ## All is well. Change argument "a" to "u": > > test<-function(x,u) (x-u)^3 > ## Plot it: > > plot(seq(0,1,by=.1),test(seq(0,1,by=.1),u=.75),type='l') > > ## All is well. Find the root: > > uniroot(test,c(0,1),u=.75) > Error in f(lower, ...) : argument "u" is missing, with no default > > ## Define a new function with the same root: > > test<-function(x,a,u) (x-a)^3 /u > ## Plot it: > > plot(seq(0,1,by=.1),test(seq(0,1,by=.1),a=.75,u=.2),type='l') > > ## All is well. Find the root: > > uniroot(test,c(0,1),a=.75,u=.2) > Error in f(lower, ...) : argument "u" is missing, with no default > > ## Give u a default value: > > test<-function(x,a,u=.2) (x-a)^3 /u > ## Find the root: > > uniroot(test,c(0,1),a=.75,u=.2) > Error in uniroot(test, c(0, 1), a = 0.75, u = 0.2) : > f() values at end points not of opposite sign > > ## Oh, really? > > test(0,.75,.2) > [1] -2.109375 > > test(1,.75,.2) > [1] 0.078125 This is partial matching playing tricks on you. Annoying, but not a bug: > test<-function(x,a,u=.2) (x-a)^3 /u > uniroot(test,c(0,1),a=.75,u=.2,upper=1) $root [1] 0.7500141 $f.root [1] 1.396726e-14 $iter [1] 21 $estim.prec [1] 6.103516e-05 -- 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] uniroot arguments (PR#9140)
You seem not to understand that 'u' matches 'upper' by the standard argument-matching rules. test<-function(x,u) (x-u)^3 debug(uniroot) uniroot(test,c(0,1), u=.75) Browse[1]> match.call() uniroot(f = test, interval = c(0, 1), upper = 0.75) Please learn to use R's debugging facilities (see `Writing R Extensions') to help you find your own errors. Sending one empty report (9139) and one incorrect report on an obselete version of R was not kind: please study the section on 'BUGS' in the FAQ. On Fri, 11 Aug 2006, [EMAIL PROTECTED] wrote: > > <> > > When invoking "uniroot" with any argument named "u", uniroot exits > with error: "Error in f(lower, ...) : argument "u" is missing, with no > default". This error occurs whether or not "u" determines the root. > > Giving "u" a default value results in garbage from uniroot. > > ## Define a function with a root: > > test<-function(x,a) (x-a)^3 > > ## Find the root: > > uniroot(test,c(0,1),a=.75) > $root > [1] 0.7500141 > > $f.root > [1] 2.793453e-15 > > $iter > [1] 22 > > $estim.prec > [1] 6.103516e-05 > > ## All is well. Change argument "a" to "u": > > test<-function(x,u) (x-u)^3 > ## Plot it: > > plot(seq(0,1,by=.1),test(seq(0,1,by=.1),u=.75),type='l') > > ## All is well. Find the root: > > uniroot(test,c(0,1),u=.75) > Error in f(lower, ...) : argument "u" is missing, with no default > > ## Define a new function with the same root: > > test<-function(x,a,u) (x-a)^3 /u > ## Plot it: > > plot(seq(0,1,by=.1),test(seq(0,1,by=.1),a=.75,u=.2),type='l') > > ## All is well. Find the root: > > uniroot(test,c(0,1),a=.75,u=.2) > Error in f(lower, ...) : argument "u" is missing, with no default > > ## Give u a default value: > > test<-function(x,a,u=.2) (x-a)^3 /u > ## Find the root: > > uniroot(test,c(0,1),a=.75,u=.2) > Error in uniroot(test, c(0, 1), a = 0.75, u = 0.2) : > f() values at end points not of opposite sign > > ## Oh, really? > > test(0,.75,.2) > [1] -2.109375 > > test(1,.75,.2) > [1] 0.078125 > > > > > --please do not edit the information below-- > > Version: > platform = i686-redhat-linux-gnu > arch = i686 > os = linux-gnu > system = i686, linux-gnu > status = > major = 2 > minor = 2.1 > year = 2005 > month = 12 > day = 20 > svn rev = 36812 > language = R > > Locale: > C > > Search Path: > .GlobalEnv, package:methods, package:stats, package:graphics, > package:grDevices, package:utils, package:datasets, Autoloads, package:base > > __ > 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] SystemRequirements (was DESCRIPTION and PACKAGES files )
Martin Maechler <[EMAIL PROTECTED]> writes: > I think some R-core members would welcome a detailed proposal on how > 'SystemRequirements' should be formatted -- maybe even accompanied > by R code to parse it. That's a topic also quite well fit to be > discussed in "this theatre" .. Discussion follows, and code follows discussion. So, I've been chewing on this offline with Dirk and Simon, and I think we've settled into, if not complete agreement, a local minimum of dissatisfaction. :) Since we may be talking about a new field in DESCRIPTIONs, I'll refer to 'SystemDepends:' as a machine-readable version of the currently human-readable SystemRequirements:. The critical concern which affects SystemDepends: but does not affect the Depends: field is that Depends: operates over the set of R packages names, which are nominally under the control of the R community, and unique in their domain. Unfortunately, SystemDepends: needs to refer to the domain of "names different systems have arrived at for things R packages might depend on". Sticky. This is not simply a theoretical problem; the first package I cared about demonstrated the problem case. GDD requires that the GD library be available. Mr Boutell appears to call his package 'gd', and some Linux distros do the same, others use 'libgd' in an entirely reasonable convention. Dirk thinks the bookkeeping for the variations would be too much to be useful: } I still think that CRAN should not care about distributions; there } are simply too many of them and stay tend to appear and disappear } too. But I think that we only need to mention exceptions, which will probably be few. So, if we wish to represent these SystemDepends: data, I see several choices: 1) per-package, pick a name and tell folks in distros with different names to suck it up. 2) Apply to the package owner for resolution of the "official" name, then 1) 3) Permit some speciation in what packages are required for what "system type". My code is intended to aid 3); If R-devel decides 3) is not useful, I would strongly commend 2) over 1); we should not resolve package nomenclature by local fiat. Here is the format I suggest for a SystemDepends: src <- "libgd (>= 1.9.0) (gentoo gd >= 2.0) (debian >= 1.9.2)" = [] =[, ] =([ []] []) the code I wrote is intended to take a list of dependencies in this format, and an optional system-type identifier, and return a string in normal Depends: format, 'localized' for the supplied system-type. This was intended to let whatever random cruft folks had written against extant R Depends: strings to manipulate the extended format too. So, extdepstring2depstring(src) yields "libgd (>= 1.9.0)" and extdepstring2depstring(src,systype="debian") yields "libgd (>= 1.9.2)" and extdepstring2depstring(src,systype="WhoTheHeckAreYou") yeilds the default. The code: Submitted for your delectation (or abuse, I suppose) http://nersp.osg.ufl.edu/~asr/media/extdepstring2depstring_0.6.tar.gz This package houses a single function, extdepstring2depstring(instring, systype = "", debug=FALSE) and some tests. It's my first attempt at an R package, and it passed check on my box, so please be gentle if I've done dumb stuff. Thank you for your time and consideration. - Allen S. Rout __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] download.packages() ignores too recent packages
Hi list,
I don't know if it's a bug or a feature but I can't download a package
that requires a more recent version of R than the one I'm currently
using for the download:
> rep <- "http://bioconductor.org/packages/1.9/bioc";
> download.packages("Biobase", destdir=".", repos=rep)
Warning in download.packages("Biobase", destdir = ".", repos = rep) :
no package 'Biobase' at the repositories
[,1] [,2]
There _is_ a 'Biobase' package here but since it requires R >= 2.3.0
and I'm doing this from R 2.2.1 then it's ignored.
I realize that this is consistent with the behaviour of available.packages()
but... I guess the most confusing part here (at least for me) is the
warning message. May be it could say something like "no package 'Biobase'
at the repositories for your version of R"?
Best,
H.
--
Hervé Pagès
E-mail: [EMAIL PROTECTED]
Phone: (206) 667-5791
Fax: (206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] MiKTeX 2.5
As you may already know, the MiKTeX distribution just went through a major upgade: from 2.4 to 2.5 with some major changes in the configuration files and directory structure. SInce I routinely build new versions of R-patched and R-dvel from tarballs (this includes PDF documentation) I wnated to check how the new version will work. I am happy to report that things went pretty smoothly. Here is a short synopsis fo what I did: 1. First of all I am on Win2000 system with all recent security patches applied (my company takes care of that). 2. I tried to update my old version of MiKTeX using the new Update Wizard which poped up by itself after a routine MiKTeX update. This did not go over too well. The upgrade crashed in the middle complaining something about not being able to replace files in use. I ended up with unusable MiKTeX. 3. I uninstalled MiKTeX and downloaded the "basic" installer from a mirror. I ran the installer making sure that I used the same path as the old installation. This probably is not necessary, but then one might need to change the PATH environmental variable. The install ran with no problem. 4. I downloaded a fresh tarball of R-dvel and ran "make distribution >& zzz &" in the command (cygwin) window. The compilation ran up to a point when it started making PDF documentation. Then a window popped up asking me if I wanted to download a missing *.sty file (I do nor remember which one). I clicked on the Install button and after a short while the make process picked up the compilation. This happened one more time and the whole process finished with no further problems. 5. I did some spot checks of the *.pdf manuals and they seem to be fine. Also, I inspected the zzz file for error messages and there were none, so it looks like things worked OK. 6. The basic MiKTeX installation apparently has an "on the fly" installation of missing packages feature that seems to work. I think someplace on the MiKTeX site I saw something to that effect. 7. With the old version of MiKTeX I had to copy the files from the share/texmf directory to MiKTeX's localtexmf/tex/latex. This does not seem to be necessary anymore. In fact the localtexmf does not exist in the new MiKTeX. Hope this helps, Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: [EMAIL PROTECTED] Tel: (651) 733-6092 Fax: (651) 736-3122 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] MiKTeX 2.5
On 8/11/2006 8:01 PM, [EMAIL PROTECTED] wrote: > As you may already know, the MiKTeX distribution just went through a major > upgade: from 2.4 to 2.5 with some major changes in the configuration files > and directory structure. SInce I routinely build new versions of R-patched > and R-dvel from tarballs (this includes PDF documentation) I wnated to > check how the new version will work. I am happy to report that things went > pretty smoothly. Here is a short synopsis fo what I did: Thanks for the report. I haven't upgraded to 2.5 yet, and am heading out on vacation for a week or two, so won't likely try it until late in the month. > > 1. First of all I am on Win2000 system with all recent security patches > applied (my company takes care of that). > 2. I tried to update my old version of MiKTeX using the new Update Wizard > which poped up by itself after a routine MiKTeX update. This did not go > over too well. The upgrade crashed in the middle complaining something > about not being able to replace files in use. I ended up with unusable > MiKTeX. > 3. I uninstalled MiKTeX and downloaded the "basic" installer from a > mirror. I ran the installer making sure that I used the same path as the > old installation. This probably is not necessary, but then one might need > to change the PATH environmental variable. The install ran with no > problem. > 4. I downloaded a fresh tarball of R-dvel and ran "make distribution >& > zzz &" in the command (cygwin) window. The compilation ran up to a point > when it started making PDF documentation. Then a window popped up asking > me if I wanted to download a missing *.sty file (I do nor remember which > one). I clicked on the Install button and after a short while the make > process picked up the compilation. This happened one more time and the > whole process finished with no further problems. > 5. I did some spot checks of the *.pdf manuals and they seem to be fine. > Also, I inspected the zzz file for error messages and there were none, so > it looks like things worked OK. > 6. The basic MiKTeX installation apparently has an "on the fly" > installation of missing packages feature that seems to work. I think > someplace on the MiKTeX site I saw something to that effect. > 7. With the old version of MiKTeX I had to copy the files from the > share/texmf directory to MiKTeX's localtexmf/tex/latex. This does not seem > to be necessary anymore. In fact the localtexmf does not exist in the new > MiKTeX. This may or may not be a MiKTeX change. As of release 2.2.0, MikTeX has been working with R builds (though Rcmd Rd2dvi had a lingering bug until a post 2.3.1 patch). It's possible they've reinstated the standard method of specifying TEXINPUTS through environment variables, and then it would work with older R builds, or maybe you just never noticed the 2.2.0 change ;). Duncan Murdoch > > Hope this helps, > > Andy > > __ > Andy Jaworski > 518-1-01 > Process Laboratory > 3M Corporate Research Laboratory > - > E-mail: [EMAIL PROTECTED] > Tel: (651) 733-6092 > Fax: (651) 736-3122 > > __ > 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] Small problem building a package containing .f90 source on Windows
I am working on a package that includes some Fortran 90 source code, it builds and functions correctly, but I did run into a little problem when building the Windows version that I thought might of interest. In 'Writing R Extensions' (2.3.1, 01 Jun 2006), the authors note that .f90 code can be used in packages on Windows if an F95 compiler (such a gfortran) is installed and if the user "...Set[s] F95 in MkRules to point to the installed compiler. Then R CMD SHLIB and R CMD INSTALL work for packages containing FORTRAN 90/95 source code." (p. 13) I found that it was also necessary to alter line 17 of gnuwin32/MakeDLL to include FCSOURCES in the list of variables that are used to form OBJSA. Without making that addition, neither SHLIB nor INSTALL compiled my .f90 files (though they both used gfortran to build a .dll from the other object files that were correctly compiled from .c source). Is this the correct solution to this problem? Best, Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
