Re: [Rd] R.app editor (PR#7928)
What has this to do with your subject line? You've sent three messages already with that uninformative subject. Please do read the FAQ and the posting guide and provide a full reproducible example as they ask. My guess is that this is user error, the user having failed to call dev.off() to complete the files. In the absence of any indication that dev.off() was called, I am closing this report. On Fri, 10 Jun 2005 [EMAIL PROTECTED] wrote: > Full_Name: Christian Meisenbichler > Version: 2.1.0a > OS: 10.3.9 Is that Windows 10.3.9 or Solaris 10.3.9? > Submission from: (NULL) (143.50.77.182) > > device pdf() produces empty files > > and device postscript() produces incompleete graphs -- 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 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wrong environment in anova call inside function (PR#7937)
anova() is a generic function in R, and not implicated here: do read the
error message which pinpoints anova.lme, part of package nlme.
The FAQ asks only package maintainers to use R-bugs for contributed
packages such as nlme. Please do read it.
On Tue, 14 Jun 2005 [EMAIL PROTECTED] wrote:
> Hi,
>
> I am working with R version 2.1.0, and I seem to have run into a bug. I get
> the same bug when I run R on Windows as well as when I run it on Linux.
>
> When I call anova to do a LR test from inside a function, I get an error.
> The same call works outside of a function. I have provided the code below.
>
> Thanks,
> Nisha Mulakken
>
>
>
> myFunction <- function(myDataFrame) {
>
> # Less restricted
> fit1 <- gls(y ~ dose,
> weights=varIdent(form=~1|dose),
> data=myDataFrame)
>
> # more restricted
> fit2 <- gls(y ~ dose,
> data=myDataFrame)
>
> anova.results <- anova(fit1, fit2)
> anova.results
> }
>
> df <- data.frame( y=c(12,3,45,1,53,6),
> dose=c(0,10,200,0,10,200),
> time=c("4.00 hrs", "4.00 hrs", "6.00 hrs", "6.00 hrs",
> "8.00 hrs", "8.00 hrs"),
> time.hours=c(4, 4, 6, 6, 8, 8),
> rep=rep("a", 6)
> )
>
> ## This leads to the following error:
> ## Error in anova.lme(object = fit1, fit2) : Object "fit2" not found
> results <- myFunction(myDataFrame=df)
>
> #
> ## The same thing outside of a function
>
> # Less restricted
> fit3 <- gls(y ~ dose,
> weights=varIdent(form=~1|dose),
> data=df)
>
> # more restricted
> fit4 <- gls(y ~ dose,
> data=df)
>
> ## This works:
> anova(fit3, fit4)
>
> ## The results:
> ## > anova(fit3, fit4)
> ## Model df AIC BIClogLik Test L.Ratio p-value
> ## fit3 1 5 57.98998 54.92145 -23.99499
> ## fit4 2 3 55.75284 53.91172 -24.87642 1 vs 2 1.76286 0.4142
--
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] source() chdir does not work (PR#7940)
This is already fixed:
o source(file, chdir = TRUE) was not checking that 'file' was a
filepath (rather than a URL). For 2.1.0 only, it did not work
even if 'file' was a filepath.
>From the R FAQ:
Before you actually submit a bug report, you should check whether the
bug has already been reported and/or fixed. First, try the "Search
Existing Reports" facility in the Bug Tracking page at
`http://bugs.R-project.org/'. Second, consult
`https://svn.R-project.org/R/trunk/NEWS', which records changes that will
appear in the _next_ release of R, including some bug fixes that do not
appear in Bug Tracking. (Windows users should additionally consult
`https://svn.R-project.org/R/trunk/src/gnuwin32/CHANGES'.) Third, if
possible try the current r-patched or r-devel version of R. If a bug has
already been reported or fixed,
please do not submit further bug reports on it.
^^
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Alex Galakhov
> Version: 2.1.0
> OS: Linux (Debian)
> Submission from: (NULL) (195.19.131.68)
>
>
> After software upgrade source() does not work properly anymore. It completely
> ignores the chdir= parameter. This is because is.character(file) is always
> false
> after the assignment file<-file(file).
>
> The fix is (written by hand in diff-like syntax, hopefully, you'll understand
> it):
>
> source<- function (blablabla) {
> +filename <- file
> ...blablabla
> -if (chdir && is.character (file) && ... dirname(file) ...) {
> +if (chdir && is.character (filename) && ... dirname(filename) ...) {
> +close(file) # since we can have only one on.exit(), we close file here
> ...blablabla
> on.exit(setwd(owd));
> }
--
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] (PR#7942) extra spaces before imag part when printing
This is intentional: it aligns the numbers. E.g. > options(width=12) > print(c(1+1i, 1-10i, 1+100i)) [1] 1+ 1i [2] 1- 10i [3] 1+100i Neat, eh? What made you think this was a bug? On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote: > Hello, > > When printing sequence of complex numbers, extra spaces > are sometimes printed between real and imaginary part of > each number. > > For example: > ## R Version 2.1.1 beta (2005-06-13) [Debian unstable, i386] > ## and R Version 2.1.0 [Debian unstable, i386] > >> print(c(1+1i, 10+1i, 100+1i)) # Ok > [1] 1+1i 10+1i 100+1i > >> print(c(1+1i, 1-10i, 1+100i)) > [1] 1+ 1i 1- 10i 1+100i > ^^ ^ > (extra spaces) > > > > The numbers of inserted spaces depends on the imaginary > part which has the largest number of figures: > >> print(c(1+1i, 1+12i)) > [1] 1+ 1i 1+12i > ^ > >> print(c(1+1i, 1+123i)) > [1] 1+ 1i 1+123i > ^^ > >> print(c(1+1i, 1+1234i)) > [1] 1+ 1i 1+1234i > ^^^ -- 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] italic (PR#7932)
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
>> Full_Name: G. Grothendieck
>> Version: R version 2.1.0, 2005-05-14
>> OS: Windows XP
>> Submission from: (NULL) (216.59.254.207)
>>
>>
>> This code:
>>
>>
>>> plot(1:10)
>>> text(5,5,lab=expression(italic(22*"33")))
>
> For mathematical non-character-string annotation a math font is used
> that does not support italic/bold/bolditalic/plain.
> It seems to be worth adding this information to ?plotmath, such as:
> "(only for characters, but not for math font)".
I don't think that is true: plotmath uses the same 5 fontfaces as any
other form of graph annotation. The reason was staring Grothendieck
in the face: the code is
static BBOX RenderNumber(SEXP expr, int draw, mathContext *mc,
R_GE_gcontext *gc, GEDevDesc *dd)
{
BBOX bbox;
FontType prevfont = SetFont(PlainFont, gc);
bbox = RenderStr(CHAR(asChar(expr)), draw, mc, gc, dd);
SetFont(prevfont, gc);
return bbox;
}
so it is by design. Numeric constants are always in PlainFont.
>> has the effect of italicizing 33 (which is a character string) but not 22
>> (which is not). I would have thought that both, not just 33, would be
>> italicized.
(We do ask people to actually do the thinking before posting a bug
report.)
--
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] (PR#7943) documentation enhancement: Note in ?seek for
I think the proposed change is appropriate only if the return value is
*known* to be reliable for binary files.
I for one do not trust the writers of an OS whom have made such a serious
error in one mode (and many other errors elsewhere) not to have made one
in closely related code. Since it is not Open Source, we cannot find out.
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> [I started a new bug report for this issue because it was not the
> primary issue in the original discussion, which was PR#7899]
>
> [EMAIL PROTECTED] wrote:
> > Tony Plate wrote:
> > [snip]
> >>[EMAIL PROTECTED] wrote:
> >>[snip]
> >>>Note that ?seek currently tells us "The value returned by
> >>>seek(where=NA) appears to be unreliable on Windows systems, at least
> >>>for text files."
> >>>It would be nice if this comment could be removed, of course
> >>
> >>
> >>May the explanation could be given that this happens with text files
> >>because Windows inserts extra characters at end-of-lines when reading
> >>"text" mode files (but with binary files, things should be fine.) This
> >>particular issue is documented in Microsoft Windows documentation (e.g.,
> >>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
> >>by searching on Google using the terms "fseek windows documentation").
> >>Are there any known issues using seek with binary files under Windows?
> >>If there are not, then the caveat could be made specific to text files
> >>and all vagueness removed.
> >
> >
> > Hmm, all I find (including your link) is Windows CE related ...
> >
> > Uwe Ligges
>
> For the record, the documentation I pointed to is for Windows 2000 etc,
> and is not just related to Windows CE (Uwe retracted that claim in a
> private email).
>
> So, the suggestion to refine the note in ?seek stands. Perhaps
> src/library/base/man/seek.Rd could be changed as follows:
>
> OLD:
>
> #ifdef windows
> The value returned by \code{seek(where=NA)} appears to be unreliable
> on Windows systems, at least for text files. Clipboard connections
> can seek too.
> #endif
>
> NEW:
>
> #ifdef windows
> The value returned by \code{seek()} is unreliable
> on Windows systems for text files. This is because the Windows
> file-I/O functions can insert extra characters at end-of-lines
> when working with text mode files. Binary mode files should not
> be affected by this issue. Clipboard connections can seek too.
> #endif
>
> Of course, if someone knows that the return value of seek() is
> unreliable on Windows for binary files, this documentation change is
> innappropriate (and then the documentation should probably be changed
> from "appears to be unreliable, at least for text files" to "is
> unreliable, for both binary and text files".
>
> -- Tony Plate
>
> __
> 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] (PR#7943) documentation enhancement: Note in ?seek for
Actually, there is a known issue: it is often wrong for binary files
opened in append mode, and we have caught by that too. So those writers
did make the sort of error I did not trust them not to make.
On Wed, 15 Jun 2005, Prof Brian Ripley wrote:
> I think the proposed change is appropriate only if the return value is
> *known* to be reliable for binary files.
>
> I for one do not trust the writers of an OS whom have made such a serious
> error in one mode (and many other errors elsewhere) not to have made one in
> closely related code. Since it is not Open Source, we cannot find out.
>
> On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
>
>> [I started a new bug report for this issue because it was not the
>> primary issue in the original discussion, which was PR#7899]
>>
>> [EMAIL PROTECTED] wrote:
>> > Tony Plate wrote:
>> > [snip]
>> >>[EMAIL PROTECTED] wrote:
>> >>[snip]
>> >>>Note that ?seek currently tells us "The value returned by
>> >>>seek(where=NA) appears to be unreliable on Windows systems, at least
>> >>>for text files."
>> >>>It would be nice if this comment could be removed, of course
>> >>
>> >>
>> >>May the explanation could be given that this happens with text files
>> >>because Windows inserts extra characters at end-of-lines when reading
>> >>"text" mode files (but with binary files, things should be fine.) This
>> >>particular issue is documented in Microsoft Windows documentation (e.g.,
>> >>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
>> >>by searching on Google using the terms "fseek windows documentation").
>> >>Are there any known issues using seek with binary files under Windows?
>> >>If there are not, then the caveat could be made specific to text files
>> >>and all vagueness removed.
>> >
>> >
>> > Hmm, all I find (including your link) is Windows CE related ...
>> >
>> > Uwe Ligges
>>
>> For the record, the documentation I pointed to is for Windows 2000 etc,
>> and is not just related to Windows CE (Uwe retracted that claim in a
>> private email).
>>
>> So, the suggestion to refine the note in ?seek stands. Perhaps
>> src/library/base/man/seek.Rd could be changed as follows:
>>
>> OLD:
>>
>> #ifdef windows
>> The value returned by \code{seek(where=NA)} appears to be unreliable
>> on Windows systems, at least for text files. Clipboard connections
>> can seek too.
>> #endif
>>
>> NEW:
>>
>> #ifdef windows
>> The value returned by \code{seek()} is unreliable
>> on Windows systems for text files. This is because the Windows
>> file-I/O functions can insert extra characters at end-of-lines
>> when working with text mode files. Binary mode files should not
>> be affected by this issue. Clipboard connections can seek too.
>> #endif
>>
>> Of course, if someone knows that the return value of seek() is
>> unreliable on Windows for binary files, this documentation change is
>> innappropriate (and then the documentation should probably be changed
>> from "appears to be unreliable, at least for text files" to "is
>> unreliable, for both binary and text files".
>>
>> -- Tony Plate
>>
>> __
>> 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
>
--
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] (PR#7951) DispatchOrEval missing in do_isfinite and
These functions are not generic according to the help page.
The same page says explicitly that is.nan is generic.
Where did you get the (false) idea that they were generic?
On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Lars Hansen
> Version: 2.1.0
> OS: SunOS 5.8
> Submission from: (NULL) (207.66.36.189)
>
>
> Hi,
>
> S4 method displacth does not work for the two generic functions
> 'is.finite' and 'is.infinite'. It turns out that the C functions
> 'do_isfinite' and 'do_isinfinite' in src/main/coerce.c are missing a
> call to 'DispatchOrEval' (see do_isnan). Added in the call fixed the
> problem. My functions no look like this:
>
> Form coerce.c:
>
> SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
> {
>SEXP ans, x, names, dims;
>int i, n;
>
>if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
>return(ans);
>
>checkArity(op, args);
>...
>
> SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
> {
>SEXP ans, x, names, dims;
>double xr, xi;
> int i, n;
>
>if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
>return(ans);
>
>checkArity(op, args);
>...
--
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] Capitalize the title in DESCRIPTION files? (PR#7969)
On Fri, 24 Jun 2005 [EMAIL PROTECTED] wrote: > Full_Name: David Firth > Version: 2.1.1 > OS: Mac OS X > Submission from: (NULL) (137.205.240.25) > > > A small inconsistency in the "Writing R Extensions" manual: at > http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file > the displayed example has > Title: My first collection of functions > but the text that follows it says "The Title field...should be capitalized", > which I take to mean > Title: My First Collection of Functions Well, `do as we say, not do as we do' applies, I think. Thank you, we'll try to set a better example. (As you may guess, the example and advice are from different hands and the example predates the advice.) -- 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 choose language for installing (PR#7971)
The language of the installer is completely unrelated to the language used to run R. This is not a bug: to use R in Chinese, you need to select Chinese as the language to use: see the `R Installation and Administration manual'. This should happen automatically if Windows is set to Simplified Chinese. What do you actually want to do? If you want to run R in English,, set LANAGAGE=en. On Mon, 27 Jun 2005 [EMAIL PROTECTED] wrote: > Full_Name: Jiancang Zhuang > Version: R 2.1.1 > OS: windows xp > Submission from: (NULL) (133.58.102.66) > > > I tried to install R.2.1.1 into my windows xp system. The system is > Japanese version. But I set the unicode fonts to be Chinese to for some > important programme. No matter how I choose the language during the > installation, I always get an R of Japanese version. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] symbol.For problem? (PR#7974)
You are not using symbol.For correctly. Both .Fortran and symbol.For
append an underscore if one is needed:
> symbol.For("add")
[1] "add_"
so you are looking for "add__" which will not be in the function table.
The help file says
Functions 'symbol.C' and 'symbol.For' map function or subroutine
names to the symbol name in the compiled code. These are no
longer of much use in R.
'is.loaded' checks if the symbol name is loaded and hence
available for use in '.C' or '.Fortran': nowadays it needs the
name you would give to '.C' or '.Fortran' and *not* that remapped
by 'symbol.C' and 'symbol.For'.
On Tue, 28 Jun 2005 [EMAIL PROTECTED] wrote:
> It seems as though 'symbol.For' does not work correctly.
Please read the section on BUGS in the FAQ and do not file bug reports on
things about which you are not _certain_, as it asks.
>
>> library("foo")
>> add(3,4)
> [1] 7
>> sym.add(3,5)
>
> Error in .Fortran(symbol.For("add"), as.numeric(a), as.numeric(b), c =
> as.numeric(0)) :
>"Fortran" function name not in load table
>
> The function 'add' is a R wrapper to a simple fortran 77 subroutine that adds
> two numbers.
> In 'add' the .Fortran call looks like this:
> .Fortran("add",...)
>
> In 'sym.add' the .Fortran call looks like this:
> .Fortran(symbol.For("add"),...)
>
> symbol.For works correctly if there is an underscore in the name though.
>
> I have tested this on OSX and linux and get the same results.
>
> I have a test package written up if anyone wants it. Email me
> at [EMAIL PROTECTED]
>
>
>
>
> --please do not edit the information below--
>
> Version:
> platform = i686-pc-linux-gnu
> arch = i686
> os = linux-gnu
> system = i686, linux-gnu
> status =
> major = 2
> minor = 1.0
> year = 2005
> month = 04
> day = 18
> language = R
>
> Search Path:
> .GlobalEnv, package:foo, 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] Failed make (PR#7978)
On Wed, 29 Jun 2005, Simon Urbanek wrote: > On Jun 29, 2005, at 1:52 PM, [EMAIL PROTECTED] wrote: > >> I downloaded R v2.1.1 earlier this morning to compile under Fedora >> Core 4. >> It compiled without incident, but 'make check' failed. Below is the >> relevant >> part of its report. Is this a known problem? > > My guess is that you're using gfortran instead of g77 and you didn't > set GFORTRAN_STDIN_UNIT to -1 nor used FLIBS to force static fortran > libraries - please see B.5.1. "Using gfortran" in "R Installation and > Administration". That is a known problem with vanilla gcc-4.0.0 but not with the version in FC4. I do wonder why anyone would replace a patched compiler with an known buggy one. At least use the latest release candidate of 4.0.1 if you insist on using gcc4. -- 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] Bartlett test problem (PR#7980)
what does example(bartlett.test) do for you? Both that and doing that example in Rcmdr work for me. On Thu, 30 Jun 2005 [EMAIL PROTECTED] wrote: > Full_Name: Leslie Corbett > Version: R 2.1.1 > OS: Windows 2000 Professional > Submission from: (NULL) (142.161.169.185) > > > Every time I try to use the Bartlett.test command, I get a non-responding > system. Can someone help? > > How to reproduce: > Easiest way: 1. load Rcmdr; 2. import data set (one where you would do an > ANOVA); 3. manage variables in data set (choose at least one variable as a > factor). 4. in Rcmdr choose Statistics , variances, Bartlett's test. 5. > This > is where my computer stops, my laptop stops and collegues' computers stop. > > (Of course all this can be done directly in the R Gui window, yet the same > result occurs). We really want something here we can reproduce. It might well only happen with your dataset. -- 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] Sys.timzone() returns NA - problem caused by as.POSIXlt? (PR#8003)
This is not a bug in R: the documentation does say the result is
OS-specific.
`GMT' is a not a proper timezone on Windows, so NA is a valid answer.
(Windows seems to use GMT to refer to the timezone of the UK, e.g.
> Sys.time()
[1] "2005-07-11 07:49:56 GMT Daylight Time"
> Sys.timezone()
[1] "GMT Daylight Time"
although I am in British Summer Time not GMT.)
I'll add yet another workaround for R-patched.
On Thu, 7 Jul 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Martin Keller-Ressel
> Version: 2.1.1
> OS: Windows 2000
> Submission from: (NULL) (128.130.51.88)
>
>
> Sys.timezone() returns NA although the environment variable TZ is set to GMT
> and
> Sys.time() returns the correct time and date including the right timezone.
> The problem is probably due to as.POSIXlt() which is used by Sys.timezone().
>
> The problem has been confirmed by Uwe Ligges for R 2.1.1 on Windows NT 4.0.
> See below for a R session outlining the problem:
>
>
>> Sys.getenv("TZ")
> TZ
> "GMT"
>> Sys.time()
> [1] "2005-07-07 10:28:11 GMT"
>> Sys.timezone()
> [1] NA
>
>> Sys.timezone
> function ()
> {
>z <- as.POSIXlt(Sys.time())
>attr(z, "tzone")[2 + z$isdst]
> }
>
>
>> z <- as.POSIXlt(Sys.time())
>> attributes(z)
> $names
> [1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
>
> $class
> [1] "POSIXt" "POSIXlt"
>
> $tzone
> [1] "GMT"
>
>> attr(z,"tzone")
> [1] "GMT"
>> z$isdst
> [1] 0
>> attr(z,"tzone")[2]
> [1] NA
--
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] Sweave resource leak: leftover temp files (PR#7998)
This is actually a Windows bug. Those files are unlink()ed, and it seems
Windows is not respecting that (not an unknown phenomenon). I have tried
a few workarounds, and am about to commit one that seems to work.
No files are left over on a decent operating system, e.g. Solaris or FC3
Linux.
On Fri, 8 Jul 2005 [EMAIL PROTECTED] wrote:
> Harold, I've taken a closer look at your example and I'd call this an
> Sweave bug. It creates tempfiles each time you run it, and doesn't
> delete them at the end. For example:
>
> > list.files(tempdir())
> character(0)
> > testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package = "utils")
> > Sweave(testfile, out="junk.tex")
> Writing to file junk.tex
> Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403" "Rf27095"
> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055" "Rf724"
> > Sweave(testfile, out="C:/temp/junk.tex")
> Writing to file C:/temp/junk.tex
> Processing code chunks ...
> 1 : print term verbatim
> 2 : term hide
> 3 : echo print term verbatim
> 4 : term verbatim
> 5 : echo term verbatim
> 6 : echo term verbatim eps pdf
> 7 : echo term verbatim eps pdf
>
> You can now run LaTeX on 'C:/temp/junk.tex'
> > list.files(tempdir())
> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129" "Rf17288"
> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095" "Rf2892"
> [15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290" "Rf5551"
> [22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758" "Rf7673"
> > unlink(list.files(tempdir(),full=T))
> > list.files(tempdir())
> character(0)
>
> Harold: a workaround for this would be to wrap your Sweave call in
> something like this:
>
> keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>
> ... Call Sweave here ...
>
> temps <- list.files(tempdir(), full=TRUE)
> unlink(temps[!(temps %in% keep)]) # delete the newly created ones
>
> __
> 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] Sweave resource leak: leftover temp files (PR#7998)
On Tue, 12 Jul 2005, Duncan Murdoch wrote:
> Prof Brian Ripley wrote:
>> This is actually a Windows bug. Those files are unlink()ed, and it seems
>> Windows is not respecting that (not an unknown phenomenon). I have tried a
>> few workarounds, and am about to commit one that seems to work.
>
> I guess you mean the C unlink, since I don't see the R unlink being called.
Yes, I do, but the R unlink calls the C unlink and so has the same
problem.
> Generally deletes fail on Windows when files are locked, e.g. open for
> reading or writing. I haven't seen Windows file deletes fail in other
> circumstances, so I suspect this was an R, MinGW or MSVCRT bug rather than a
> Windows bug.
But unlink() is required by POSIX to work when files are open, so it is a
MSVCRT `feature' (and that is part of Windows since Win95 OSR2). Indeed,
there is nothing in the MSDN documentation on unlink() that says anything
about not working if files are `locked'.
If people use the same name and arg sequence of a standard library call
and partially implement it without saying so or mentioning the
restrictions I believe it is perfectly reasonable to call that a bug.
>
> Duncan Murdoch
>>
>> No files are left over on a decent operating system, e.g. Solaris or FC3
>> Linux.
>>
>> On Fri, 8 Jul 2005 [EMAIL PROTECTED] wrote:
>>
>>
>>> Harold, I've taken a closer look at your example and I'd call this an
>>> Sweave bug. It creates tempfiles each time you run it, and doesn't
>>> delete them at the end. For example:
>>>
>>>
>>>> list.files(tempdir())
>>>
>>> character(0)
>>>
>>>> testfile <- system.file("Sweave", "Sweave-test-1.Rnw", package = "utils")
>>>> Sweave(testfile, out="junk.tex")
>>>
>>> Writing to file junk.tex
>>> Processing code chunks ...
>>> 1 : print term verbatim
>>> 2 : term hide
>>> 3 : echo print term verbatim
>>> 4 : term verbatim
>>> 5 : echo term verbatim
>>> 6 : echo term verbatim eps pdf
>>> 7 : echo term verbatim eps pdf
>>>
>>> You can now run LaTeX on 'junk.tex'
>>>
>>>> list.files(tempdir())
>>>
>>> [1] "Rf10523" "Rf13872" "Rf17129" "Rf2055" "Rf2203" "Rf2403" "Rf27095"
>>> [8] "Rf2892" "Rf31415" "Rf5290" "Rf6251" "Rf6482" "Rf7055" "Rf724"
>>>
>>>> Sweave(testfile, out="C:/temp/junk.tex")
>>>
>>> Writing to file C:/temp/junk.tex
>>> Processing code chunks ...
>>> 1 : print term verbatim
>>> 2 : term hide
>>> 3 : echo print term verbatim
>>> 4 : term verbatim
>>> 5 : echo term verbatim
>>> 6 : echo term verbatim eps pdf
>>> 7 : echo term verbatim eps pdf
>>>
>>> You can now run LaTeX on 'C:/temp/junk.tex'
>>>
>>>> list.files(tempdir())
>>>
>>> [1] "Rf10523" "Rf12679" "Rf1311" "Rf13484" "Rf13872" "Rf17129" "Rf17288"
>>> [8] "Rf2055" "Rf21774" "Rf2203" "Rf23417" "Rf2403" "Rf27095" "Rf2892"
>>> [15] "Rf29444" "Rf31128" "Rf31415" "Rf32520" "Rf3338" "Rf5290" "Rf5551"
>>> [22] "Rf6251" "Rf6482" "Rf7055" "Rf724" "Rf7543" "Rf758" "Rf7673"
>>>
>>>> unlink(list.files(tempdir(),full=T))
>>>> list.files(tempdir())
>>>
>>> character(0)
>>>
>>> Harold: a workaround for this would be to wrap your Sweave call in
>>> something like this:
>>>
>>> keep <- list.files(tempdir(), full=TRUE) # keep previous temp files
>>>
>>> ... Call Sweave here ...
>>>
>>> temps <- list.files(tempdir(), full=TRUE)
>>> unlink(temps[!(temps %in% keep)]) # delete the newly created ones
>>>
>>> __
>>> 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] as.data.frame.table responseName argument (PR#8006)
You need to call as.data.frame.table directly here. If we alter the generic we would need to alter all the many methods too (including those in various CRAN packages), and I am not sure this would be worth it (rather than clarifying the documentation). This was a user-contributed enhancement that seems to have caused more problem that its value. On Wed, 13 Jul 2005 [EMAIL PROTECTED] wrote: > Full_Name: Heather Turner > Version: 2.1.1 > OS: Windows XP > Submission from: (NULL) (137.205.240.44) > > > I get an error when trying to use the responseName argument of > as.data.frame.table, e.g. > >> ## Create table >> f <- gl(3, 3) >> tab <- table(f) >> tab > f > 1 2 3 > 3 3 3 >> ## Convert to data.frame - works fine >> dat1 <- as.data.frame(tab) >> dat1 > f Freq > 1 13 > 2 23 > 3 33 >> ## As above with responseName - get error >> dat2 <- as.data.frame(tab, responseName = "count") > Error in as.data.frame(tab, responseName = "count") : > unused argument(s) (responseName ...) > > I have checked the arguments of as.data.frame.table and responseName is there: >> args(as.data.frame.table) > function (x, row.names = NULL, optional = FALSE, responseName = "Freq", >...) > NULL > but I notice as.data.frame has no dots argument >> args(as.data.frame) > function (x, row.names = NULL, optional = FALSE) > NULL > which would (I think) explain the error, > > Heather > > __ > 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] translation with Rd.sty, Sweave and tex4th (PR#8016)
Why not report this as a bug *in tex4th* that conflicts with R? LaTeX has
no namespaces, and unfortunately name conflicts are common. Doing as you
suggest and allowing one package to clobber another is much worse.
On Tue, 19 Jul 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Paulo Ribeiro
> Version: 2.1-1
> OS: Debian Linux
> Submission from: (NULL) (200.103.144.24)
>
>
> I'm using Sweave with tex4th to generate xhtml documents
> from documents created using Sweave which include \usepackage{Rd}
> in the preamble
>
> However there seems to be a problem with \Link defined in
> Rd.sty, since this is also defined in tex4ht.sty
>
> My workaround was to replace the lines with
> \newcommand{\Link} by \providecommand{\Link}
> in Rd.sty
>
> I'm therefore wondering whether this is the best solution, if there is any
> other
> and, if so, whether this could be modified in the original Rd.sty shipped with
> R.
>
> A possible inconvenient of the suggested above
> is that \providecommand seems to be specific to
> LaTeX and apparently does not work with TeX.
Nor does \newcommand. It is part of LaTeX's extra care in finding
conflicting definitions.
> Another possibility, as suggested by Kurt, would be "emulate" namespaces
> with something of the type [EMAIL PROTECTED]
Really a general-purpose package like tex4th should be doing that, not R.
As many R installations have lots of prebuilt latex files installed,
changing R's macros can only be done for 3.0.0.
--
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] (PR#8017) build of REventLoop package crashes with 2.1 due
char_t *wc, const char *s, size_t n, mbstate_t *ps);
> < void mbcsToLatin1(char *in, char *out);
> < Rboolean mbcsValid(char *str);
> < char *Rf_strchr(const char *s, int c);
> < char *Rf_strrchr(const char *s, int c);
> < #else
> < #define Rf_strchr(s, c) strchr(s, c)
> < #define Rf_strrchr(s, c) strrchr(s, c)
> < #endif
> < #ifdef Win32
> < void R_fixslash(char *s);
> < void R_fixbackslash(char *s);
> < #endif
> < #if defined(Win32) && defined(SUPPORT_UTF8)
> < #define mbrtowc(a,b,c,d) Rmbrtowc(a,b)
> < #define wcrtomb(a,b,c) Rwcrtomb(a,b)
> < #define mbstowcs(a,b,c) Rmbstowcs(a,b,c)
> < #define wcstombs(a,b,c) Rwcstombs(a,b,c)
> < size_t Rmbrtowc(wchar_t *wc, const char *s);
> < size_t Rwcrtomb(char *s, const wchar_t wc);
> < size_t Rmbstowcs(wchar_t *wc, const char *s, size_t n);
> < size_t Rwcstombs(char *s, const wchar_t *wc, size_t n);
> < #endif
> <
> < /* used in relop.c and sort.c */
> < #if defined(Win32) && defined(SUPPORT_UTF8)
> < #define STRCOLL Rstrcoll
> < #else
> <
> < #ifdef HAVE_STRCOLL
> < #define STRCOLL strcoll
> < #else
> < #define STRCOLL strcmp
> < #endif
> <
> < #endif
> <
> < /* Localization */
> <
> < #ifdef ENABLE_NLS
> < #include
> < #ifdef Win32
> < #define _(String) libintl_gettext (String)
> < #undef gettext /* needed for graphapp */
> < #else
> < #define _(String) gettext (String)
> < #endif
> < #define gettext_noop(String) String
> < #define N_(String) gettext_noop (String)
> < #else /* not NLS */
> < #define _(String) (String)
> < #define N_(String) String
> < #endif
> <
> ---
>> char *EncodeString(SEXP, int, int, int);
> 950,957d874
> < /* structure for caching machine accuracy values */
> < typedef struct {
> < int ibeta, it, irnd, ngrd, machep, negep, iexp, minexp, maxexp;
> < double eps, epsneg, xmin, xmax;
> < } AccuracyInfo;
> <
> < extern AccuracyInfo R_AccuracyInfo;
> <
>
> __
> 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] (PR#8017) build of REventLoop package crashes with 2.1 due
> < LibExtern Rboolean mbcslocale INI_as(FALSE); /* is this a MBCS locale? */
>> ---
>>> extern Rboolean utf8locale INI_as(FALSE); /* is this a UTF-8 locale? */
>> 596a594
>>> # define duplicated Rf_duplicated
>> 633c631
>> < # define Mbrtowc Rf_mbrtowc
>> ---
>>> # define matchRf_match
>> 686a685
>>> int R_ShowFile(char*, char*);
>> 799,800c798
>> < SEXP R_data_class(SEXP , Rboolean);
>> < SEXP R_data_class2(SEXP);
>> ---
>>> SEXP R_data_class(SEXP , int);
>> 864,869d861
>> < typedef enum {
>> < Rprt_adj_left = 0,
>> < Rprt_adj_right = 1,
>> < Rprt_adj_centre = 2
>> < } Rprt_adj;
>> <
>> 872,939c864
>> < char *EncodeString(SEXP, int, int, Rprt_adj);
>> <
>> <
>> < #if defined(HAVE_WCHAR_H) && defined(SUPPORT_MBCS)
>> < #include
>> < #endif
>> <
>> < /* main/util.c */
>> < void UNIMPLEMENTED_TYPE(char *s, SEXP x);
>> < void UNIMPLEMENTED_TYPEt(char *s, SEXPTYPE t);
>> < Rboolean utf8strIsASCII(char *str);
>> < #ifdef SUPPORT_MBCS
>> < int utf8clen(char c);
>> < #define mbs_init(x) memset(x, 0, sizeof(mbstate_t))
>> < size_t Mbrtowc(wchar_t *wc, const char *s, size_t n, mbstate_t *ps);
>> < void mbcsToLatin1(char *in, char *out);
>> < Rboolean mbcsValid(char *str);
>> < char *Rf_strchr(const char *s, int c);
>> < char *Rf_strrchr(const char *s, int c);
>> < #else
>> < #define Rf_strchr(s, c) strchr(s, c)
>> < #define Rf_strrchr(s, c) strrchr(s, c)
>> < #endif
>> < #ifdef Win32
>> < void R_fixslash(char *s);
>> < void R_fixbackslash(char *s);
>> < #endif
>> < #if defined(Win32) && defined(SUPPORT_UTF8)
>> < #define mbrtowc(a,b,c,d) Rmbrtowc(a,b)
>> < #define wcrtomb(a,b,c) Rwcrtomb(a,b)
>> < #define mbstowcs(a,b,c) Rmbstowcs(a,b,c)
>> < #define wcstombs(a,b,c) Rwcstombs(a,b,c)
>> < size_t Rmbrtowc(wchar_t *wc, const char *s);
>> < size_t Rwcrtomb(char *s, const wchar_t wc);
>> < size_t Rmbstowcs(wchar_t *wc, const char *s, size_t n);
>> < size_t Rwcstombs(char *s, const wchar_t *wc, size_t n);
>> < #endif
>> <
>> < /* used in relop.c and sort.c */
>> < #if defined(Win32) && defined(SUPPORT_UTF8)
>> < #define STRCOLL Rstrcoll
>> < #else
>> <
>> < #ifdef HAVE_STRCOLL
>> < #define STRCOLL strcoll
>> < #else
>> < #define STRCOLL strcmp
>> < #endif
>> <
>> < #endif
>> <
>> < /* Localization */
>> <
>> < #ifdef ENABLE_NLS
>> < #include
>> < #ifdef Win32
>> < #define _(String) libintl_gettext (String)
>> < #undef gettext /* needed for graphapp */
>> < #else
>> < #define _(String) gettext (String)
>> < #endif
>> < #define gettext_noop(String) String
>> < #define N_(String) gettext_noop (String)
>> < #else /* not NLS */
>> < #define _(String) (String)
>> < #define N_(String) String
>> < #endif
>> <
>> ---
>>> char *EncodeString(SEXP, int, int, int);
>> 950,957d874
>> < /* structure for caching machine accuracy values */
>> < typedef struct {
>> < int ibeta, it, irnd, ngrd, machep, negep, iexp, minexp, maxexp;
>> < double eps, epsneg, xmin, xmax;
>> < } AccuracyInfo;
>> <
>> < extern AccuracyInfo R_AccuracyInfo;
>> <
>>
>> __
>> 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
>
>
--
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] error in text.default (PR#8034)
This is not an error in R but in your X11 fonts setup. It is R reporting your configuration problem to you. What dpi is your screen? If more than 75dpi (very likely these days), do you have 100dpi fonts installed and in your path? We have seen that configuration mistake cause this on SuSe before. On Tue, 26 Jul 2005 [EMAIL PROTECTED] wrote: > Full_Name: roger newton > Version: 2.1.1 > OS: SuSe linux 9.2 > Submission from: (NULL) (80.176.228.157) > > >> data(trees) >> plot(trees) > Error in text.default(x, y, txt, cex = cex, font = font) : >X11 font at size 16 could not be loaded > > > Attempting to plot dataframe trees fails with error message as shown. > > Get similar message (but font size 22) when run demo(graphics). > > Got same error with rpm of R from CRAN linux/SuSe/9.2 (with and without latest > patch) and with downloaded and compiled source code from CRAN (with and > without > latest patch). > > Is problem with R or fonts on my PC? Windows 2000 version of R on another > machine works OK -- 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] (PR#8049) add1.lm and add1.glm not handling weights and
David, Thanks. The reason add1.lm (and drop1.lm) do not support offsets is that lm did not when they were written, and the person who added offsets to lm did not change them. (I do wish they had not added an offset arg and just used the formula as in S's glm.) That is easy to add. For the other point, some care is needed if 'x' is supplied and the upper scope reduces the number of points. We can try harder, but your usage does give a warning and perhaps that needs to be an error in this case. Brian On Thu, 4 Aug 2005 [EMAIL PROTECTED] wrote: > I am using R 2.1.1 under Mac OS 10.3.9. > > Two related problems (see notes 1. and 2. below) are illustrated by > results of the following: > > y <- rnorm(10) > x <- z <- 1:10 > is.na(x[9]) <- TRUE > > lm0 <- lm(y ~ 1) > lm1 <- lm(y ~ 1, weights = rep(1, 10)) > > add1(lm0, scope = ~ x) ## works ok > add1(lm1, scope = ~ x) ## error > > lm2 <- lm(y ~ 1, offset = 1:10) > > add1(lm0, scope = ~ z) ## works ok > add1(lm2, scope = ~ z) ## gives incorrect results (ignores the offset) > > glm0 <- glm(y ~ 1) > glm1 <- glm(y ~ 1, weights = rep(1, 10)) > glm2 <- glm(y ~ 1, offset = rep(0, 10)) > > add1(glm0, scope = ~ x) ## error > add1(glm1, scope = ~ x) ## error > add1(glm2, scope = ~ x) ## error > > > > As I see it, the two problems are: > > 1. add1.lm ignores any offset present in its "object" argument. > > 2. add1.lm and add1.glm both take weights directly from their "object" > argument, and add1.glm also does the same for any offset that is > present. But this does not work when the upper scope includes missing > values and na.omit is used: the weights (and offset) then have the > wrong length. They should presumably be extracted instead from the > reduced model frame. > > > If I can be of help in fixing these things, please let me know. But I > don't want to make things worse, or to duplicate anyone else's work. I > don't see this fixed in the bug-fix list at > https://svn.r-project.org/R/trunk/NEWS > but I haven't checked whether the same problems are in the current > r-devel. > > David > > ______ > 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] unable to start pdf, postscript devices (PR#8052)
The following in NEWS is probably relevant: CHANGES IN R VERSION 2.1.1 patched o File creation errors in pdf(), postscript(), xfig() resulted in a pointer being freed twice. (Reported by Matt McCall) So, 1) Please try R-patched as we do ask you to (before sending a bug report). 2) You probably do not have permission to open the files in the current directory, hence the error that is being handled twice. On Fri, 5 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: Jeffrey Freedman > Version: 2.1.1 > OS: Mac 10.4.2 > Submission from: (NULL) (169.226.95.21) > > > All of a sudden, I cannot generate pdf, postscript, jpeg, png graphics. I get > the following error: > > R(273) malloc: *** Deallocation of a pointer not malloced: 0x113e870; This > could be a double free(), or free() called with the middle of an allocated > block; Try setting environment variable MallocHelp to see tools to help debug > Error in pdf(psfile) : unable to start device pdf > > This originally happened running R version 2.1.0. I upgraded to 2.1.1 and the > same problem still occurs. No other changes to the operating system and no new > software installation has occurred on the computer running R, which is an > Apple > Dual 2 GHz Power PC G5. > > Thank you for your attention to this matter. > > __ > 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] make check-all fails (PR#8063)
Please do read the docs: this test is randomm and will fail about 1 in 50
and if you have already run make check, you have already passed it.
Definitely no bug in R.
On Sun, 14 Aug 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Jed Kaplan
> Version: 2.1.1 Patched
> OS: Fedora Core 4
> Submission from: (NULL) (66.31.221.212)
>
>
> Installation through "make check" succeeds. "Make check-all" fails with the
> following tail message:
> "
> make[3]: Entering directory `/mnt/linuxApp/usr/local/R/R-patched/tests'
> running code in 'p-r-random-tests.R' ...make[3]: *** [p-r-random-tests.Rout]
> Error 1
> make[3]: Leaving directory `/mnt/linuxApp/usr/local/R/R-patched/tests'
> make[2]: *** [test-Random] Error 2
> make[2]: Leaving directory `/mnt/linuxApp/usr/local/R/R-patched/tests'
> make[1]: *** [test-all-devel] Error 1
> make[1]: Leaving directory `/mnt/linuxApp/usr/local/R/R-patched/tests'
> make: *** [check-all] Error 2
> "
>
> The tail of ./tests/p-r-random-tests.Rout.fail is:
> "
>> dkwtest("nbinom",size = 1,prob = 0.8)
> nbinom(size = 1, prob = 0.8) PASSED
> [1] TRUE
>> dkwtest("nbinom",size = 100,prob = 0.8)
> nbinom(size = 100, prob = 0.8) PASSED
> [1] TRUE
>> dkwtest("nbinom",size = 100,prob = 0.999)
> nbinom(size = 100, prob = 0.999) PASSED
> [1] TRUE
>>
>> dkwtest("norm")
> norm() FAILED
> Error in dkwtest("norm") : dkwtest failed
> Execution halted
> "
>
> Here is some system configuration output from "./configure" :
> "
> R is now configured for i686-pc-linux-gnu
>
> Source directory: .
> Installation directory:/usr/local
>
> C compiler:gcc -g -O2
> C++ compiler: g++ -g -O2
> Fortran compiler: f95 -g -O2
>
> Interfaces supported: X11
> External libraries:readline
> Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
> Options enabled: R profiling
>
> Recommended packages: yes
> "
>
> Please advise.
>
> __
> 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] Shutdown by to much data (PR#8065)
This is probably a bug in the editor, but you have given us no way to reproduce it. Please see the posting guide and FAQ and give us a reproducible example. On Mon, 15 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: Jan Bentlage > Version: 2.1.1 > OS: Windows > Submission from: (NULL) (212.62.93.226) > > > I loaded a huge database (textfile, semikolon seperated) by read.csv2. The > data > already appeared in the list (by ls()). When I want to view the data in the > editor, R completly crashes. Which means what, exactly? Again, see the posting guide. -- 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] png and resolution (PR#8066)
Where did you get `result' from? (What program spells that badly and where does ppi come from?) Your last example gives for me (using ImageMagick) identify -format "%wx%h res: %x" Rplot001.png 1920x1920 res: 944.88 PixelsPerCentimeter which is correct. I believe it is your PNG reader that is buggy, not R. On Mon, 15 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: Knut krueger > Version: 2.1.1 > OS: xp Home > Submission from: (NULL) (149.225.134.34) > > > In the png function the value res seems to be inactive: > > bmp(filename = "c:/r/Rplot%03d.bmp", width = 1920, height = 1920, pointsize = > 48, bg = "white", res = 2400) > result: > witdh/heigth = 1920 <> 20.32 mm > ppi=2400 > Results as expected > > > png(filename = "c:/r/Rplot%03d.png", width = 1920, height = 1920, pointsize = > 48, bg = "white", res = 2400) > > witdh/heigth = 1920 <> 20.32 mm > ppi=150 > Result not as expected. > > ______ > 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] quirky behavior from rbinom (PR#8071)
Please supply a reproducible example as both the FAQ and the posting guide do ask. On Tue, 16 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: Chris Paulse > Version: 2.1.1 > OS: WinXP > Submission from: (NULL) (129.98.60.134) > > > This seems strange. I have a small block of code that repeatedly calls > rbinom. > I put a break in there in case it returns NaN, as I've been having problems > with > this. Here is a transcript from the debug session: > > Browse[1]> theP > [1] 1 > Browse[1]> yleft[dataIndex] > [1] 3 > Browse[1]> rbinom(1,3,1) > [1] 3 > Browse[1]> rbinom(1,yleft[dataIndex], theP) > [1] NaN > > Strange, huh? > > __ > 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] PS driver crashes when no permissions (PR#8078)
This is already fixed in 2.1.1 patched: please see the resources the
posting guide and FAQ ask you to consult _before_ sending a bug report!
o File creation errors in pdf(), postscript(), xfig() resulted
in a pointer being freed twice. (Reported by Matt McCall)
As the FAQ says
If a bug has already been reported or fixed, please do not submit
further bug reports on it.
On Fri, 19 Aug 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Jussi Jousimo
> Version: 2.1.1
> OS: Linux
> Submission from: (NULL) (193.167.195.60)
>
>
> R 2.1.1 crashes when it is trying to write a file with the postscript driver
> to
> a directory, where the user has no permission to write. For example,
> postscript("foo.ps") gives an error message: *** glibc detected *** free():
> invalid pointer: 0x08a469b0 ***. The problem is at the PSDeviceDriver function
> in the devPS.c file on line 2357 (free(dd);), where the same memory block is
> tried to free the first time and then the second time at line 5138
> (free(dev);).
> I'd suggest to remove the first free function.
>
> __
> 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] Example in pdf() help file (PR#8083)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-1188682158-1124696849=:32369
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Please consult the help _file_! This is correct in the file, but has been=
=20
incorrectly marked for conversion (now fixed).
On Mon, 22 Aug 2005 [EMAIL PROTECTED] wrote:
>
> The example in the help file for pdf() plots the characters outside
> the plotting area in this for loop:
>
>for(i in c(32:255)) {
> x <- i
> y <- i
> points(x, y, pch=3Di)
> }
>
> The following loop seems to be working as intended
>
> for(i in c(32:255)) {
> x <- (i-31)%%16
> y <- (i-31)%/%16
> points(x, y, pch=3Di)
> }
No, i%%16 etc was intended.
> As an extra observation, with code page ISOLatin2, the pdf-file fails to
> open in Ghostview 4.7 using ghostscript 8.51. Error message below. In
> Acrobat Reader 7.0 it opens without problems. It is quite possible that
> it is the settings on my computer that causes the error,
It's nothing to do with R, but to do with how your computer is set.
BTW, I am pretty sure this is GSView 4.7, a different program.
> but I include the dump of the error message, just in case anybody was
> interested
>
> Best regards
>
> Erik J=F8rgensen
> Danish Institute of Agricultural Sciences
>
> --please do not edit the information below--
>
> Version:
> platform =3D i386-pc-mingw32
> arch =3D i386
> os =3D mingw32
> system =3D i386, mingw32
> status =3D
> major =3D 2
> minor =3D 1.1
> year =3D 2005
> month =3D 06
> day =3D 20
> language =3D R
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=3DDanish_Denmark.1252;LC_CTYPE=3DDanish_Denmark.1252;LC_MONETA=
RY=3DDanish_Denmark.1252;LC_NUMERIC=3DC;LC_TIME=3DDanish_Denmark.1252
>
> Search Path:
> .GlobalEnv, package:lattice, package:methods, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> Autoloads, package:base
>
>
>
> ---
>
> GSview 4.7 2005-03-26
> AFPL Ghostscript 8.51 (2005-04-18)
> Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> Scanning PDF file
> %GSVIEW_PDF_PAGES: 1 1
> Displaying PDF page 1
> %GSVIEW_PDF_PAGE: 1
> %GSVIEW_PDF_MEDIA: [0 0 432 432]
> %GSVIEW_PDF_ROTATE: 0
> Loading NimbusSanL-Regu font from c:\gs\fonts/n019003l.pfb... 2291320
> 946479 1594968 288125 3 done.
> Error: /typecheck in --lt--
> Operand stack:
>--dict:4/4(L)-- F2 1 --dict:5/5(L)-- --dict:5/5(L)--
> --dict:15/16(ro)(G)-- --nostringval-- --nostringval-- 1
> --nostringval-- 1 --nostringval--
> Execution stack:
>%interp_exit .runexec2 --nostringval-- --nostringval--
> --nostringval-- 2 %stopped_push --nostringval-- --nostringval--
> false 1 %stopped_push 1 3 %oparray_pop 1 3
> %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2
> --nostringval-- --nostringval-- --nostringval-- 2
> %stopped_push --nostringval-- --nostringval-- --nostringval--
> --nostringval-- --nostringval-- %array_continue --nostringval--
> false 1 %stopped_push --nostringval-- %loop_continue
> --nostringval-- --nostringval-- --nostringval-- --nostringval--
> --nostringval-- --nostringval-- %array_continue --nostringval--
> Dictionary stack:
>--dict:1129/1686(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)--
> --dict:105/127(ro)(G)-- --dict:251/347(ro)(G)-- --dict:21/24(L)--
> --dict:4/6(L)-- --dict:20/20(L)-- --dict:10/13(L)--
> Current allocation mode is local
> pdf_page failed
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--=20
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
--27464147-1188682158-1124696849=:32369--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#8087) NAs by integer overflow in Spearman's test p-value
There is an even simpler way: someone wrote n*(n^2-1) as n*(n-1)*(n+1)
and caused the problem.
Your superfluous semicolons do definitely make your code harder to read.
On Tue, 23 Aug 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Jan T. Kim
> Version: 2.1.0 (and better)
> OS: Linux
> Submission from: (NULL) (139.222.3.229)
>
>
> The p value in Spearman's test is NA if the length of x exceeds 46340, due to
> an integer overflow, occurring if length(n) > sqrt(2^31):
>
>> n <- 46341;
>> set.seed(1);
>> x <- runif(n);
>> y <- runif(n);
>> cor.test(x, y, method = "spearman");
>
>Spearman's rank correlation rho
>
>data: x and y
>S = 1.654965e+13, p-value = NA
>alternative hypothesis: true rho is not equal to 0
>sample estimates:
>rho
>0.002199426
>
>Warning message:
>NAs produced by integer overflow in: n * n
>
> The integer overflow occurs in src/library/stats/R/cor.test.R, and it can be
> fixed
> by converting n to double appropriately (see *** fix label ***, lines 110
> onwards
> are shown):
>
>## Use the test statistic S = sum(rank(x) - rank(y))^2
>## and AS 89 for obtaining better p-values than via the
>## simple normal approximation.
>## In the case of no ties, S = (1-rho) * (n^3-n)/6.
>pspearman <- function(q, n, lower.tail = TRUE) {
>if(n <= 1290) # n*(n^2 - 1) does not overflow
>.C("prho",
> as.integer(n),
> as.double(q + 1),
> p = double(1),
> integer(1),
> as.logical(lower.tail),
> PACKAGE = "stats")$p
>else { # for large n: aymptotic t_{n-2}
>n <- as.double(n); # *** fix ***
>r <- 1 - 6 * q / (n*(n*n - 1))
>pt(r / sqrt((1 - r^2)/(n-2)), df = n-2,
> lower.tail= !lower.tail)
>}
>}
>q <- round((n^3 - n) * (1 - r) / 6)
>STATISTIC <- c(S = q)
>PVAL <-
>switch(alternative,
> "two.sided" = {
> p <- if(q > (n^3 - n) / 6)
> pspearman(q - 1, n, lower.tail = FALSE)
> else
> pspearman(q, n, lower.tail = TRUE)
> min(2 * p, 1)
> },
> "greater" = pspearman(q, n, lower.tail = TRUE),
> "less" = pspearman(q - 1, n, lower.tail = FALSE))
>if(TIES)
>warning("p-values may be incorrect due to ties")
>
> Inserting the typecast only in the pspearman function is a minimally invasive
> fix -- alternatively, replacing at line 17
>
>n <- length(x)
>
> with
>
>n <- as.double(length(x))
>
> achieves the same fix and may take care of other unnecessary integer
> overflows,
> but it may also introduce new problems e.g. in .C calls etc.
>
> __
> 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] Typo(s) in proc.time.Rd and comment about ?proc.time (PR#8092)
On Wed, 24 Aug 2005 [EMAIL PROTECTED] wrote:
> I just downloaded the file
>
> ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz
>
> and within proc.time.Rd, the second paragraph of the \value
> section contains a typo:
I believe your understanding of the English language is different from the
author here, who is English. (You on the other hand seem to think there
is no need to give your country in your address when writing an addess in
Denmark.) The preferred language for R documentation is English (and not
American).
> The resolution of the times will be system-specific; it is common for
> them to be recorded to of the order of 1/100 second, and elapsed [...]
> ^
>
> I'd say replacing "to of" with just "of" would grammatically
> fix the sentence.
I'd say it was correct and your correction is incorrect. In English we
say `recorded to 1/100th of a second', not `recorded 1/100th second'.
> Second, the \note{} section for Unix-like machines reads:
>
> It is possible to compile \R without support for \code{proc.time},
> when the function will throw an error.
>
> I believe this is ungrammatical and suggest replacing
> "when the function will throw an error" with "in which
> case the function will throw an error".
Again, the statement given is the intended meaning.
> Finally, my comment about ?proc.time is that if across
> platforms the returned value is in seconds, then it might
> be helpful to readers if this were noted explicitly in the
> first paragraph of \value{}.
Yes, *if*. Do you know that?
> My suggestion is in brackets:
>
> A numeric vector of length 5, containing the user, system, and
> total elapsed times [in seconds] for the currently running R
> process [...]
>
> Thank you,
>
> Stephen
>
> ::
> Stephen Weigand
> Division of Biostatistics
> Mayo Clinic Rochester
> Phone (507) 266-1650, fax 284-9542
>
> __
> 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] xerbla called from BLAS routine (PR#8100)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-1060265079-1125299740=:28726
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Please check out
http://www.netlib.org/blas/index.html
file=09xerbla.f
for=09error handler for the Level 2 and 3 BLAS routines.
,=09(Auxiliary Routine)
and the refefence code which says
* XERBLA is an error handler for the LAPACK routines.
* It is called by an LAPACK routine if an input parameter has an
* invalid value. A message is printed and execution stops.
So, XERBLA is an LAPACK handler, intended to be called from LAPACK=20
routines -- the level 2 and level 3 BLAS routines are considered to be
part of LAPACK in the reference implementation.
On Mon, 29 Aug 2005, Prof Brian Ripley wrote:
> I don't believe your message actually came from R's XERBLA. Note that th=
e=20
> name is not quoted and that the name of the routine is not 6 characters l=
ong.
>
> Here is a genuine example from R:
>
> Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10
>
> There is no R 2.2.0, BTW. If referring to R-devel, please do so with an =
SVN=20
> revision.
>
> On Sun, 28 Aug 2005 [EMAIL PROTECTED] wrote:
>
>> Full_Name: G=F6ran Brostr=F6m
>> Version: R-2.1.1, 2.2.0
>> OS: Debian unstable
>> Submission from: (NULL) (213.65.9.59)
>>=20
>>=20
>> Some BLAS routines call xerbla for error messages, which results in a=20
>> message
>> like
>> "LAPACK routine DGER gave error code -9".
>>=20
>> Suggested solution: In
>>=20
>> void F77_NAME(xerbla)(char *srname, int *info)
>> {
>> /* srname is not null-terminated. It should be 6 characters. */
>>char buf[7];
>>strncpy(buf, srname, 6);
>>buf[6] =3D '\0';
>>error(_("LAPACK routine '%6s' gave error code %d"), buf, -(*info));
>> }
>>=20
>> change 'LAPACK' to 'The' (or 'The BLAS/LAPACK').
>>=20
>> ______
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>=20
>>=20
>
> --=20
> 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
--=20
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
--27464147-1060265079-1125299740=:28726--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xerbla called from BLAS routine (PR#8100)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-1510948051-1125298763=:26166
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
I don't believe your message actually came from R's XERBLA. Note that the=
=20
name is not quoted and that the name of the routine is not 6 characters=20
long.
Here is a genuine example from R:
Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10
There is no R 2.2.0, BTW. If referring to R-devel, please do so with an=20
SVN revision.
On Sun, 28 Aug 2005 [EMAIL PROTECTED] wrote:
> Full_Name: G=F6ran Brostr=F6m
> Version: R-2.1.1, 2.2.0
> OS: Debian unstable
> Submission from: (NULL) (213.65.9.59)
>
>
> Some BLAS routines call xerbla for error messages, which results in a mes=
sage
> like
> "LAPACK routine DGER gave error code -9".
>
> Suggested solution: In
>
> void F77_NAME(xerbla)(char *srname, int *info)
> {
> /* srname is not null-terminated. It should be 6 characters. */
>char buf[7];
>strncpy(buf, srname, 6);
>buf[6] =3D '\0';
>error(_("LAPACK routine '%6s' gave error code %d"), buf, -(*info));
> }
>
> change 'LAPACK' to 'The' (or 'The BLAS/LAPACK').
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--=20
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
--27464147-1510948051-1125298763=:26166--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "finite" vs "R_FINITE" in colors.c (PR#8108)
Thanks, but it is already changed in the R-devel sources. On Mon, 29 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: D Kreil > Version: 2.1.1 > OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license > Submission from: (NULL) (62.178.15.60) > > > During compiliation, I get: > > ld: Unsatisfied symbol "finite" in file colors.o > > Fix: replace "finite" with R_FINITE in colors.c line 269. > > I have, this time, searched through the R-admin.html, but not found a mention. > This is all a bit hard for me as I'm installing R as non-admin on a bare-bones > ia64 hpux system with no web browser, and a weird mix of libraries. > Nevertheless, the above seems to me like an innocent typo? -- 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] Ad: Re: R crashes for large formulas in lm() (PR#8180)
On Wed, 5 Oct 2005 [EMAIL PROTECTED] wrote: > And some more informastion I forgot. > R does not crash if I write out the formula: > > set.seed(123) > x1 <- runif(1000) > x2 <- runif(1000) > x3 <- runif(1000) > x4 <- runif(1000) > x5 <- runif(1000) > x6 <- runif(1000) > x7 <- runif(1000) > x8 <- runif(1000) > y <- rnorm(1000) > fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) > -> R crashes > > fit <- lm(y~x1+x2+x3+x4+x5+x6+x7+x8 >+x1:x2+x1:x3+x1:x4+x1:x5+x1:x6+x1:x7+x1:x8 >+x2:x3++x2:x4+x2:x5+x2:x6+x2:x7+x2:x8 >+x3:x4+x3:x5+x3:x6+x3:x7+x3:x8 >+x4:x5+x4:x6+x4:x7+x4:x8 >+x5:x6+x5:x7+x5:x8 >+x6:x7+x6:x8 >+x7:x8) > -> R does not crash > This is the same formula, at least it should be. It is not the same formula at all. Try > terms(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2, simplify=TRUE) y ~ x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8 + x1:x2 + x1:x3 + x1:x4 + x1:x5 + x1:x6 + x1:x7 + x1:x8 + x2:x3 + x2:x4 + x2:x5 + x2:x6 + x2:x7 + x2:x8 + x3:x4 + x3:x5 + x3:x6 + x3:x7 + x3:x8 + x4:x5 + x4:x6 + x4:x7 + x4:x8 + x5:x6 + x5:x7 + x5:x8 + x6:x7 + x6:x8 + x7:x8 + x1:x2:x3 + x1:x2:x4 + x1:x3:x4 + x1:x2:x5 + x1:x3:x5 + ... x1:x3:x4:x5:x6:x7:x8 + x2:x3:x4:x5:x6:x7:x8 + x1:x2:x3:x4:x5:x6:x7:x8 Did you actually want lm(y~(x1+x2+x3+x4+x5+x6+x7+x8)^2) ? > > > > > > Uwe Ligges <[EMAIL PROTECTED]> > 05.10.2005 12:13 > >Til:Prof Brian Ripley <[EMAIL PROTECTED]> >cc: [EMAIL PROTECTED], [EMAIL PROTECTED] >Emne: Re: [Rd] R crashes for large formulas in lm() (PR#8180) > > > Prof Brian Ripley wrote: > >> On Wed, 5 Oct 2005 [EMAIL PROTECTED] wrote: >> >> >>> Full_Name: Hallgeir Grinde >>> Version: 2.1.1 >>> OS: Windows XP >>> Submission from: (NULL) (144.127.1.1) >>> >>> >>> While using lm(y~(x*z*c*...*v)^2) R crashes/closes if the numbers of > variables >>> are at least 8. >> >> >> OK, let's try to reproduce that: >> >> >>> x1 <- runif(1000) >>> x2 <- runif(1000) >>> x3 <- runif(1000) >>> x4 <- runif(1000) >>> x5 <- runif(1000) >>> x6 <- runif(1000) >>> x7 <- runif(1000) >>> x8 <- runif(1000) >>> y <- rnorm(1000) >>> fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) >> >> >> No crash, a quite reasonable fit. >> >> Can we please have a reproducible example, as we do ask? >> > > Hmm, crashes for me as well with R-2.1.1 and R-2.2.0 beta (2005-09-27 > r35682M) on WinNT 4.0, SP6. > > > Let's make it reproducible: > > set.seed(123) > x1 <- runif(1000) > x2 <- runif(1000) > x3 <- runif(1000) > x4 <- runif(1000) > x5 <- runif(1000) > x6 <- runif(1000) > x7 <- runif(1000) > x8 <- runif(1000) > y <- rnorm(1000) > fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) > > > Uwe Ligges > > > >NOTICE > Please immediately e-mail back to sender > if you are not the intended recipient. > > Thereafter delete the e-mail along with > any attachments without making copies. > > Elkem reserves all rights of privilege, > confidentiality and copyright. > > -- 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] Ad: Re: Ad: Re: R crashes for large formulas in lm() (PR#8181)
On Wed, 5 Oct 2005 [EMAIL PROTECTED] wrote: > Yes. > so (x1*x2*x3*x4*x5*x6*x7*x8)^2 = (x1+x2+x3+x4+x5+x6+x7+x8)^8 ? Yes in the sense that the simplified formula given by terms() is the same. > and there is a difference in > (x1*x2*x3*x4*x5*x6*x7*x8)^2 > and > (x1*x2*x3*x4*x5*x6*x7*x8) > althoug the resulting formulas are the same, or? The first is reduced to the second by terms(). > This fikses my problem, but R still crashes for the large formula. It may > be due to stack owerflow, but i guess this can be altered maually? On Unix-alikes, at least. The way the calculation is done can be improved, but is anyone going intentionally to write a 100,000 term formula? > > Prof Brian Ripley <[EMAIL PROTECTED]> > 05.10.2005 12:50 > >Til:[EMAIL PROTECTED] >cc: Uwe Ligges <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] >Emne: Re: Ad: Re: [Rd] R crashes for large formulas in lm() > (PR#8180) > > > On Wed, 5 Oct 2005 [EMAIL PROTECTED] wrote: > >> And some more informastion I forgot. >> R does not crash if I write out the formula: >> >> set.seed(123) >> x1 <- runif(1000) >> x2 <- runif(1000) >> x3 <- runif(1000) >> x4 <- runif(1000) >> x5 <- runif(1000) >> x6 <- runif(1000) >> x7 <- runif(1000) >> x8 <- runif(1000) >> y <- rnorm(1000) >> fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) >> -> R crashes >> >> fit <- lm(y~x1+x2+x3+x4+x5+x6+x7+x8 >>+x1:x2+x1:x3+x1:x4+x1:x5+x1:x6+x1:x7+x1:x8 >>+x2:x3++x2:x4+x2:x5+x2:x6+x2:x7+x2:x8 >>+x3:x4+x3:x5+x3:x6+x3:x7+x3:x8 >>+x4:x5+x4:x6+x4:x7+x4:x8 >>+x5:x6+x5:x7+x5:x8 >>+x6:x7+x6:x8 >>+x7:x8) >> -> R does not crash >> This is the same formula, at least it should be. > > It is not the same formula at all. Try > >> terms(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2, simplify=TRUE) > y ~ x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8 + x1:x2 + x1:x3 + x1:x4 + > x1:x5 + x1:x6 + x1:x7 + x1:x8 + x2:x3 + x2:x4 + x2:x5 + x2:x6 + > x2:x7 + x2:x8 + x3:x4 + x3:x5 + x3:x6 + x3:x7 + x3:x8 + x4:x5 + > x4:x6 + x4:x7 + x4:x8 + x5:x6 + x5:x7 + x5:x8 + x6:x7 + x6:x8 + > x7:x8 + x1:x2:x3 + x1:x2:x4 + x1:x3:x4 + x1:x2:x5 + x1:x3:x5 + > ... > x1:x3:x4:x5:x6:x7:x8 + x2:x3:x4:x5:x6:x7:x8 + x1:x2:x3:x4:x5:x6:x7:x8 > > Did you actually want lm(y~(x1+x2+x3+x4+x5+x6+x7+x8)^2) ? > >> >> >> >> >> >> Uwe Ligges <[EMAIL PROTECTED]> >> 05.10.2005 12:13 >> >>Til:Prof Brian Ripley <[EMAIL PROTECTED]> >>cc: [EMAIL PROTECTED], [EMAIL PROTECTED] >>Emne: Re: [Rd] R crashes for large formulas in lm() (PR#8180) >> >> >> Prof Brian Ripley wrote: >> >>> On Wed, 5 Oct 2005 [EMAIL PROTECTED] wrote: >>> >>> >>>> Full_Name: Hallgeir Grinde >>>> Version: 2.1.1 >>>> OS: Windows XP >>>> Submission from: (NULL) (144.127.1.1) >>>> >>>> >>>> While using lm(y~(x*z*c*...*v)^2) R crashes/closes if the numbers of >> variables >>>> are at least 8. >>> >>> >>> OK, let's try to reproduce that: >>> >>> >>>> x1 <- runif(1000) >>>> x2 <- runif(1000) >>>> x3 <- runif(1000) >>>> x4 <- runif(1000) >>>> x5 <- runif(1000) >>>> x6 <- runif(1000) >>>> x7 <- runif(1000) >>>> x8 <- runif(1000) >>>> y <- rnorm(1000) >>>> fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) >>> >>> >>> No crash, a quite reasonable fit. >>> >>> Can we please have a reproducible example, as we do ask? >>> >> >> Hmm, crashes for me as well with R-2.1.1 and R-2.2.0 beta (2005-09-27 >> r35682M) on WinNT 4.0, SP6. >> >> >> Let's make it reproducible: >> >> set.seed(123) >> x1 <- runif(1000) >> x2 <- runif(1000) >> x3 <- runif(1000) >> x4 <- runif(1000) >> x5 <- runif(1000) >> x6 <- runif(1000) >> x7 <- runif(1000) >> x8 <- runif(1000) >> y <- rnorm(1000) >> fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) >> >> >> Uwe Ligges >> >> >> >>NOTICE >> Please immediately e-mail back to sender >> if you are not the intended recipient. >> >> Thereafter delete the e-mail along with >> any attachments without making copies. >> >> Elkem reserves all rights of privilege, >> confidentiality and copyright. >> >> > > -- > 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 > > -- 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] Help page links to index.html are dead (PR#8196)
On Mon, 10 Oct 2005, Duncan Murdoch wrote: > [EMAIL PROTECTED] wrote: >> Full_Name: Kevin Wright >> Version: 2.2.0 >> OS: windows >> Submission from: (NULL) (66.185.0.208) >> >> >> >> On the help pages for R is a little circle with an up arrow that links to: >> >> file:///C:/R/R220/doc/html/index.htmlu > > That's a typo in Kevin's message: the link is to .../doc/html/index.html. > The link is correct, but the file was not installed. The Makefile creates it > as a copy of rwin.html. Do you remember why we have both files? This bug > has been around for a while... Yes, rwin.html contains an additional link to rw-FAQ.html. Now the Windows index.html should be the same: indeed, it is installed as such by fixed/Makefile. So it's a bug in building the installer. If you are asking why rwin.html is needed: until recently the sources contained doc/html/index.html so it was likely to be restored. It seems to me there is another error in the message: the help pages contain no such link (which threw me for a while). It does appear on the summary page for a package, and on packages.html. >> This link is dead. I suspect the link should be: >> >> file:///C:/R/R220/doc/html/rwin.html >> >> P.S. It should be obvious, but just in case, I have R installed at >> c:/R/R220 >> >> ______ >> 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] GUI error. (PR#8204)
I was also unable to reproduce this in either 2.2.0 or current (from svn) R-devel. On Wed, 12 Oct 2005, Duncan Murdoch wrote: > [EMAIL PROTECTED] wrote: >> Full_Name: Ian G I've never encountered anyone with full surname `G' >> Version: latest > > Please tell us which version. There are at least three versions which > might be called "latest", and by tomorrow two of them may well be different. > >> OS: win xp pro sp1 >> Submission from: (NULL) (193.1.209.251) >> >> >> step one >> start the r project any way you like >> step two >> type "demo()" and press return >> step three >> press then shortcut button to open file 'just under the file menu' >> while then demp screen is up >> the program seem not to like to open a new file when the window demo window >> is >> active. >> the error can be reproduce easly. > > Not reproducible for me in 2.2.0. Things worked just as I'd expect. > > Duncan Murdoch > > __ > 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] Make problem (PR#8210)
In what sense is this a bug in R? The R-admin manual tells you R 2.2.0 has been successfully compiled on several such systems. There is something amiss with your Solaris setup, not generically with R. By guess is that you are out of file space. On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote: > Solaris 8 > Gnu Make 3.79.1 > R-2.2.0 > > ./configure --prefix=/path/to/here > is ok. > make error messages, > > creating doc/html/resources.html > *** Error code 255 > make: Fatal error: Command failed for target `../html/resources.html' > Current working directory /home/zhangj/apps/R/R-patched/doc/manual > cp: ../../bin: is a directory > install: cp ../../bin ./BATCH/bin failed > *** Error code 2 > make: Fatal error: Command failed for target `install-cmds' > Current working directory /home/zhangj/apps/R/R-patched/src/scripts > *** Error code 1 > make: Fatal error: Command failed for target `R' > Current working directory /home/zhangj/apps/R/R-patched/src/scripts > *** Error code 1 > make: Fatal error: Command failed for target `R' > Current working directory /home/zhangj/apps/R/R-patched/src > *** Error code 1 > make: Fatal error: Command failed for target `R' > > Jun H. Zhang > Biostatistics and Applied Mathematics > MD Anderson Cancer Center > 713-792-2606 > [[alternative HTML version deleted]] > > ______ > 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] formatC using a "single" as argument (PR#8211)
Reading the help page for formatC x: an atomic numerical or character object, typically a vector of real numbers. and that for as.single I think you got what you should have expected! Nevertheless we will build some protection into 2.3.0. On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote: > Full_Name: Jochen Maydt > Version: R2.2.0 > OS: Windows > Submission from: (NULL) (139.19.34.7) > > > formatC does not handle "single"s correctly: > >> formatC(as.single(1)) > [1] "5.264e-315" > attr(,"Csingle") > [1] TRUE > > This seems to be an unlikely use-case, however. > > Thank you for creating a great programming language, > Jochen > > __ > 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] can't start csh (scripts) (PR#8220)
This works perfectly correctly in four separate configurations (32-/64-bit
x gcc/cc) on our Solaris 8, and I can see no change in the R sources for
do_system since Mar 2004.
Are you sure that it is not something in your build environment that has
changed since 2.1.1 was built?
Please confirm that if you build 2.1.1 and 2.2.0 with the same tools they
behave differently, and if so tell us what those tools are.
All R is doing here is to call the C system call and the output comes from
the shell directly to the terminal, without any intervention from R. You
might try a command that actually does something permanent to confirm that
csh is executing it: if that is the case the issue is how csh writes to
your terminal.
On Wed, 19 Oct 2005 [EMAIL PROTECTED] wrote:
> Dear R developers,
>
> after upgrading from R 2.1.1 to 2.2.0 I can't start csh (scripts) anymore.
>
> While the following commands work fine
>
> > system("tcsh -c pwd")
> /hom1/users/gloeckler
> > system("bash -c pwd")
> /hom1/users/gloeckler
> > system("ksh -c pwd")
> /hom1/users/gloeckler
>
> csh (in contrast to the shells used above) doesn't give any result:
>
> > system("csh -c pwd")
> >
>
> Outside of R csh and csh scripts do not cause any problems.
>
> I tracked down a problem with starting an HTML browser down to this
> problem with the invocation of any csh process.
>
> The csh used is the normal C-Shell shipped with Solaris 9.
>
> Thanks in advance,
> Jens Gloeckler
>
>
>
> --please do not edit the information below--
>
> Version:
> platform = sparc-sun-solaris2.9
> arch = sparc
> os = solaris2.9
> system = sparc, solaris2.9
> status =
> major = 2
> minor = 2.0
> year = 2005
> month = 10
> day = 06
> svn rev = 35749
> 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] Windows 2000 crash while using rbind (PR#8225)
This is a stack-size issue. Windows provides only a small stack by
default (2Mb in R 2.2.0). Your example will work in R-patched (which has
a 10Mb stack) and R-devel (which has 10Mb and some stack-checking).
The non-technical summary is that you ran out of resources. Fortunately
we have been working on that issue and have builds with more resources.
Why this calculation is taking so much stack needs further investigation.
On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
> Windows 2000 reports that "Rgui.exe has generated errors and will be =
> closed by Windows. You will need to restart the program." when using =
> rbind.=20
>
>
> df1 <- data.frame(cbind(x=3D1, y=3D1:1000), fac=3Dsample(LETTERS[1:3], =
> 1000, repl=3DTRUE))
> df2 <- data.frame(cbind(x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], =
> 10, repl=3DTRUE))
> df3 <- data.frame(cbind(x=3D1, y=3D1:100), =
> fac=3Dsample(LETTERS[1:3], 100, repl=3DTRUE))
> df4 <- rbind(df1,df2)
> df5 <- rbind(df2,df3)
> =20
> =20
> Since this only happens intermittantly and appears to be related to the =
> size of the objects I ran the following code.
>
> sink("rbind test.txt")
> df1 <- data.frame(cbind(x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], 10, =
> repl=3DTRUE))
> for (j in seq(10,100,1)){
> df2 <- data.frame(cbind(x=3D1, y=3D1:j), fac=3Dsample(LETTERS[1:3], j, =
> repl=3DTRUE))
> print(j)
> df3 <- rbind(df2,df1)
> }
> sink()
>
> the output of rbind test.txt is
> [1] 10
> [1] 11
> [1] 12
> ...
> [1] 51
> [1] 52
>
> I then ran=20
>
>
> sink("rbind test 2.txt")
> df1 <- data.frame(cbind(a =3D 1, b =3D 2, c =3D 3, d =3D 4, e =3D 5, f =
> =3D 6, x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], 10, repl=3DTRUE))
> for (j in seq(10,100,1)){
> df2 <- data.frame(cbind(a =3D 1, b =3D 2, c =3D 3, d =3D 4, e =3D 5, f =
> =3D 6, x=3D1, y=3D1:j), fac=3Dsample(LETTERS[1:3], j, repl=3DTRUE))
> print(j)
> df3 <- rbind(df2,df1)
> }
> sink()
>
> which also stopped at 52.
>
> I tried to narrow down where the crash takes place but it would appear =
> that it is a moving feast, however both pieces of code always stopped =
> with the same number, somewhere around 52.
>
>> version
> _ =20
> platform i386-pc-mingw32
> arch i386 =20
> os mingw32 =20
> system i386, mingw32 =20
> status =20
> major2 =20
> minor2.0 =20
> year 2005 =20
> month10=20
> day 06=20
> svn rev 35749 =20
> language R=20
>
> One of the examples that has failed for me looks like
> pop <- rbind(om.tp[,c(6,2,4,5,3)],eas[,c(2,1,3,4,5)])
>
>
>> str(om.tp[,c(6,2,4,5,3)])
> `data.frame': 1001384 obs. of 5 variables:
> $ age5 : Factor w/ 18 levels "0 to 4","5 to 9",..: 1 1 1 1 1 2 2 2 2 2 =
> ...
> $ sex : Factor w/ 2 levels "Females","Males": 1 1 1 1 1 1 1 1 1 1 ...
> $ lga : Factor w/ 142 levels "Albany (C)","Armadale (C)",..: 21 21 21 =
> 21 21 21 21 21 21 21 ...
> $ count: num 7.33 7.45 7.05 6.31 5.71 ...
> $ year : Factor w/ 41 levels "2001","2002",..: 1 1 1 1 1 1 1 1 1 1 ...
>> str(eas[,c(2,1,3,4,5)])
> `data.frame': 25342 obs. of 5 variables:
> $ age5 : Factor w/ 18 levels "0 to 4","5 to 9",..: 1 1 1 1 1 1 1 1 1 1 =
> ...
> $ sex : Factor w/ 2 levels "Females","Males": 2 2 2 2 2 2 2 2 2 2 ...
> $ lga : Factor w/ 142 levels "Albany (C)","Armadale (C)",..: 1 2 3 4 5 =
> 6 7 8 9 10 ...
> $ count: num 1107 2163 532 294 479 ...
> $ year : Factor w/ 5 levels "1991","1996",..: 1 1 1 1 1 1 1 1 1 1 ...
>> gc()
> used (Mb) gc trigger (Mb) max used (Mb)
> Ncells 3255820 87.06193578 165.4 5266303 140.7
> Vcells 22096825 168.6 32770865 250.1 32114295 245.1
>
> Tom Mulholland
> Senior Demographer
> Spatial Information and Research
> State and Regional Policy
> Department for Planning and Infrastructure
> Perth, Western Australia
> +61 (08) 9264 7936
>
> __
> 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] read.table error upon package installation (PR#8230)
What is the R error here? The default delimiter in read.table is not \t but whitespace, so the first example has 2 and 3 rows (fine for header=T) and the second has 2 and 4 rows. On Fri, 21 Oct 2005 [EMAIL PROTECTED] wrote: > Upon upgrading to R 2.2.0 on my Windows box, I found that one of my > packages no longer compiled, giving this error: > > Error in read.table(zfile, header =3D TRUE) : > more columns than column names > Execution halted > > After removing every line of code from my package and still not being > able to compile it, I found the error to be related to a .txt file in my > data directory. I reduced my data file to a very simple example which > causes the error, and a nearly identical file which does not cause the > problem. > > A file with these contents causes the error (I am using \t to indicate > the usual tab delimiter). > x \t y > A B C \t DEF > > However, if I remove one of the spaces between A and B or B and C, the > package compiles fine: > x \t y > A BC \t DEF > > I can only guess that there is some kind of parsing problem when there > is more than one space between tab delimiters. Looks more like a user misunderstanding of ?data. -- 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] read.fwf doesn't work with header = TRUE (PR#8226)
On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Emmanuel Paradis
> Version: 2.1.1
> OS: Linux
> Submission from: (NULL) (193.49.41.105)
>
>
> read.fwf(..., header = TRUE) does not work properly since:
>
> 1/ the original header is printed on the console and not in FILE;
> 2/ the different 'parts' of the header should be separated with tabs
> to work with the call to read.table.
>
> Here is a suggested fix for src/library/utils/R/read.fwf.R:
>
> 38c38,40
> < cat(FILE, headerline, "\n")
> ---
>> headerline <- unlist(strsplit(headerline, " {1,}"))
>> headerline <- paste(headerline, collapse = "\t")
>> cat(file = FILE, headerline, "\n")
Thanks, but I don't think that is right. It assumes the header line is
space-delimited (or at least that spaces get converted to tabs). We have
not specified the format of the header line, and it cannot usefully be
fixed format. So I think we need to specify it is delimited by 'sep'
(not tab).
--
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] read.fwf(...,header=TRUE,...) (PR#8236)
This is the same as PR#8226, and is already fixed in R-patched. Please note the searches you were asked to do before submitting a report. On Fri, 21 Oct 2005 [EMAIL PROTECTED] wrote: > Full_Name: Giovanni Bonafe' > Version: 2.2.0 > OS: Linux > Submission from: (NULL) (195.62.164.225) > > > If the file "example.dat" is like this: > > aaa bbb ccc > 3.4 1.2 5.6 > 4.6 10 32 > 667 343 1.7 > > With the older 1.9.1, as expected: > >> data<-read.fwf(file = "example.dat",widths=c(3,4,4),header=TRUE) >> data >aaa bbb ccc > 1 3.4 1.2 5.6 > 2 4.6 10.0 32.0 > 3 667.0 343.0 1.7 > > While with the newer 2.2.0: > >> data<-read.fwf(file = "example.dat",widths=c(3,4,4),header=TRUE) >> data > X3.4 X1.2 X5.6 > 1 4.6 10 32.0 > 2 667.0 343 1.7 > > On the other side, if I use the option header=FALSE, no difference occurs > between the two versions: > >> data<-read.fwf(file = "example.dat",widths=c(3,4,4)) >> data > V1 V2 V3 > 1 aaa bbb ccc > 2 3.4 1.2 5.6 > 3 4.6 1032 > 4 667 343 1.7 > > __ > 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] new.packages --- wishlist (PR#8239)
On Sat, 22 Oct 2005 [EMAIL PROTECTED] wrote: > new.packages() misses a destdir argument as in > update.packages() and > install.packages(). > > > Adding this new argument is very little work, so please do it! Done in 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] read.fwf doesn't work with header = TRUE (PR#8226)
On Fri, 21 Oct 2005, Emmanuel Paradis wrote:
> Prof Brian Ripley wrote:
>> On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: Emmanuel Paradis
>>> Version: 2.1.1
>>> OS: Linux
>>> Submission from: (NULL) (193.49.41.105)
>>>
>>>
>>> read.fwf(..., header = TRUE) does not work properly since:
>>>
>>> 1/ the original header is printed on the console and not in FILE;
>>> 2/ the different 'parts' of the header should be separated with tabs
>>> to work with the call to read.table.
>>>
>>> Here is a suggested fix for src/library/utils/R/read.fwf.R:
>>>
>>> 38c38,40
>>> < cat(FILE, headerline, "\n")
>>> ---
>>>
>>>> headerline <- unlist(strsplit(headerline, " {1,}"))
>>>> headerline <- paste(headerline, collapse = "\t")
>>>> cat(file = FILE, headerline, "\n")
>>
>>
>> Thanks, but I don't think that is right. It assumes the header line is
>> space-delimited (or at least that spaces get converted to tabs). We have
>> not specified the format of the header line, and it cannot usefully be
>> fixed format. So I think we need to specify it is delimited by 'sep'
>> (not tab).
>
> I see, but suppose we read selectively some columns in a file, eg with
> widths=c(1, -4, 2), how can we know how many variables have been skipped and
> then select the appropriate names in the header line?
You do not: as the help file says
Negative-width fields are used to indicate columns to be skipped,
eg '-5' to skip 5 columns. These fields are not seen by
'read.table' and so should not be included in a 'col.names' or
'colClasses' argument.
> Here is another proposed fix, but this assumes the header line is in
> fixed-width format (as specified by 'widths'):
What happens if there are multi-line records? Your `fix' crashes.
> 38c38,41
> < cat(FILE, headerline, "\n")
> ---
>> head.last <- cumsum(widths)
>> head.first <- head.last - widths + 1
>> headerline <- substring(headerline, head.first, head.last)[drop]
>> cat(file = FILE, headerline, "\n", sep = sep)
>
> ?read.fwf says clearly that sep is used internally.
Not so: please check the current version.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Yates' correction for continuity in chisq.test (PR#8265)
On Sun, 30 Oct 2005, P Ehlers wrote: > [EMAIL PROTECTED] wrote: >> Full_Name: foo ba baz >> Version: R2.2.0 >> OS: Mac OS X (10.4) >> Submission from: (NULL) (219.66.32.183) >> >> >> chisq.test(matrix(c(9,10,9,11),2,2)) >> >> Chi-square value must be 0, and, P value must be 0 >> R does over correction >> >> when | a d - b c | < n / 2 ，chi-sq must be 0 > > (Presumably, you mean P-value = 1.) > If you don't want the correction, set correct=FALSE. (The > results won't differ much.) > > A better example is > > chisq.test(matrix(c(9,10,9,10),2,2)) > > for which R probably should return X-squared = 0. R is using the correction that almost all the sources I looked at suggest. You can't go around adjusting X^2 for just some values of the data: the claim is that the adjusted statistic has a more accurate chisq distribution under the null. I think at this remove it does not matter what Yates' suggested (although if I were writing a textbook I would find out), especially as the R documentation does not mention Yates. -- 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] Im() of negative non-complex numbers is pi (PR#8272)
On Tue, 1 Nov 2005 [EMAIL PROTECTED] wrote: > Sorry, I meant to write 2.1.1 instead of 2.2.1 below. OK, but it was changed in 2.1.1 patched so one needs to be precise. We used to have Arg=Im for such numbers and Arg was wrong, then Im was wrong (and now both are correct in 2.2.0 patched). > On Tue, 1 Nov 2005 [EMAIL PROTECTED] wrote: > >> Hi, >> >> I think the following indicates a bug in Im(). >> >>> Im(-1) >> [1] 3.141592653589793115998 >>> pi >> [1] 3.141592653589793115998 >>> Im(0i-1) >> [1] 0 >>> Im(-0.9876) >> [1] 3.141592653589793115998 >>> Im(-987654321) >> [1] 3.141592653589793115998 >>> Im(1) >> [1] 0 >>> is.complex(-1) >> [1] FALSE >> >> This is R 2.2.0; Im(-1) == 0 with R 2.2.1. >> >> Thanks, >> >> Dan >> >>> version >> _ >> platform i386-pc-linux-gnu >> arch i386 >> os linux-gnu >> system i386, linux-gnu >> status >> major2 >> minor2.0 >> year 2005 >> month10 >> day 06 >> svn rev 35749 >> language R >> >> Debian (stable) linux >> >> __ >> 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 > > -- 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] shared-mime-info (PR#8278)
We do not usually put features in R which are specific to just some distributions of some OSes, and in this case to one editor on those. We do not for example include the ESS mode for the much-more-widely-used Emacs family of editors. This looks as if it might be appropriate to the Linux binary packages for R, so I suggest you contact their maintainers. But my understanding is that this is an issue for gedit and not for R. Indeed .R is just a convention (one of many choices, including .r and .q) for R itself. I do wonder why you concentrated on .R files and not .Rd files, where I find syntax highlighting more useful. On Thu, 3 Nov 2005 [EMAIL PROTECTED] wrote: > Full_Name: Vaidotas Zemlys > Version: 2.1.1 > OS: Ubuntu 05.10 > Submission from: (NULL) (213.197.173.50) > > > Hi, > > This is really a feature request, not a bug. I wrote the mail to R-devel, > but nobody answered it. That's generally a sign of lack of interest, and also in your case that you fail to sign your emails, a basic courtesy especially for people using an anonymous email address. > I use Gnome on my computer and sometimes I use its default text editor > gedit. It uses gtksourceview library for syntax highlighting. I > decided that it would be nice if gedit supported R syntax. So I > created apropriate .lang file: > http://bugzilla.gnome.org/show_bug.cgi?id=157370 > > Gedit picks apropriate lang file according to file mimetype, so I > created apropriate mime type for files with extension .R. I filed a bug > report at freedesktop.org: > https://freedesktop.org/bugzilla/show_bug.cgi?id=1782 > > There Christophe Fergeau suggested that maybe R could take care of > installing this mime type by itself. Is it possible? As I understand it would > only concern Linux installations and R should cooperate with shared-mime-info > package which is responsible for all mime type definitions. > > Vaidotas Zemlys NB: signature missing -- 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] small bug in gl1ce, package lasso2 (PR#8280)
Please do read the FAQ: Finally, check carefully whether the bug is with R, or a contributed package. Bug reports on contributed packages should be sent first to the package maintainer, and only submitted to the R-bugs repository by package maintainers, mentioning the package in the subject line. You are not the maintainer, so this is the wrong place. On Fri, 4 Nov 2005 [EMAIL PROTECTED] wrote: > Full_Name: Grant Izmirlian > Version: 2.2.0 > OS: SuSe Linux version 9.2 > Submission from: (NULL) (156.40.34.177) > > > Sorry about the last submission, my bug-fix had an error in it because ifelse > doesn't vectorize. I'll repost with the correct bug-fix. > --- > The option exists to include all parameters, including the intercept, in the > L-1 > constraint, by specifying the argument, sweep.out=NULL, explicitly in the > call. However, upon doing this, the function stops with an error report > "Matrix build from transformed variables has a constant column" > > I was able to fix it as follows. In the following line, taken from the same > block of code producing the stop error, modify the existing line from > > X.to.C.stds <- sqrt(apply(X.to.C.w, 2, var)) > > to > > > X.to.C.stds <- (!is.null(sweep.out)) * > c(1,sqrt(apply(X.to.C.w[,-is.null(sweep.out)], 2, var))) + > > (is.null(sweep.out)) * sqrt(apply(X.to.C.w,2,var))) > > That should work. > > ______ > 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] Bug in the example of function optim() (PR#8312)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1959301360-1132073234=:9778 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE This is aleady fixed in the current versions of R, R-patched, and R-devel. See the posting guide or FAQ for how you can check such versions (and save your time and ours). On Tue, 15 Nov 2005 [EMAIL PROTECTED] wrote: > Dear R-Team, > > there seems to be a minor bug in the example for optim(). In the > travelling salseman part of the example section the lines > > text(x, y, names(eurodist), cex=3D0.8) (7th line from bottom) > > text(x, y, names(eurodist), cex=3D0.8) (last line) > > do not produce any oputput, because names(eurodist) has value "NULL". To > get the intended output one has just to substitute names() by labels(). > So the correct line will be: > > text(x, y, labels(eurodist), cex=3D0.8) . > > Thanks for all your effort and the software you created. > > Greetings > > Wolfgang Lederer > > --please do not edit the information below-- > > Version: > platform =3D i386-pc-mingw32 > arch =3D i386 > os =3D mingw32 > system =3D i386, mingw32 > status =3D > major =3D 2 > minor =3D 2.0 > year =3D 2005 > month =3D 10 > day =3D 06 > svn rev =3D 35749 > language =3D R > > Windows XP Professional (build 2600) Service Pack 2.0 > > Locale: > LC_COLLATE=3DGerman_Germany.1252;LC_CTYPE=3DGerman_Germany.1252;LC_MONETA= RY=3DGerman_Germany.1252;LC_NUMERIC=3DC;LC_TIME=3DGerman_Germany.1252 > > Search Path: > .GlobalEnv, package:methods, package:stats, package:graphics, > package:grDevices, package:utils, package:datasets, Autoloads, package:ba= se > > --=20 > ** > Wolfgang Lederer > Institut f=FCr Statistik > Ludwig-Maximilians-Universit=E4t M=FCnchen > Martius Str. 4 > D-80539 M=FCnchen > Tel: +49 89 2180 4847 > Fax: +49 89 2180 5308 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > --=20 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 --27464147-1959301360-1132073234=:9778-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Malformed package name (PR#8314)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1563048805-1132142703=:11543 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 16 Nov 2005 [EMAIL PROTECTED] wrote: >>>>>> "petrakl" =3D=3D petrakl <[EMAIL PROTECTED]> >>>>>> on Wed, 16 Nov 2005 10:10:46 +0100 (CET) writes: > >petrakl> Full_Name: L. Petr=E1k >petrakl> Version: 2.2 >petrakl> OS: w2k >petrakl> Submission from: (NULL) (193.109.177.11) > > >petrakl> # rcmd build Translation-it >petrakl> * checking for file 'Translation-it/DESCRIPTION' ... OK >petrakl> * preparing 'Translation-it': >petrakl> * checking DESCRIPTION meta-information ... ERROR >petrakl> Malformed package name > >petrakl> See the information on DESCRIPTION files in section 'Creating= R >petrakl> packages' of the 'Writing R Extensions' manual. > > if you do what this error message tells you, > you should quickly find > >>>The `Package' and `Version' fields give the name and the version of >>> the package, respectively. The name should consist of letters, >>> numbers, and the dot character and start with a letter. ... > > Hence it's clear that the character "-" is not allowed in a > package name. > > So why do you think this is a bug ? Because that form 'Translation-ll' is recommended in the R-exts manual for translation packages. We do say R CMD build will build such=20 packages, and at the time it was written it did. So we need to make an=20 exception in 'build' for translation packages. --=20 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 --27464147-1563048805-1132142703=:11543-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Principal Components Analysis (PR#8320)
Please do RTFM: ?princomp says Note: The signs of the columns of the loadings and scores are arbitrary, and so may differ between different programs for PCA, and even between different builds of R. and ?prcomp has a similar comment. Equally, the signs of eigenvectors are arbitrary, and ?eigen says Recall that the eigenvectors are only defined up to a constant: even when the length is specified they are still only defined up to a scalar of modulus one (the sign for real matrices). If you don't know why these are true, please ask your advisors for help. On Thu, 17 Nov 2005 [EMAIL PROTECTED] wrote: > Full_Name: Sahotra Sarkar > Version: 2.2.0 > OS: Windows XP Professional > Submission from: (NULL) (146.6.130.180) > > > The following two commands should give the same results for the eigenvectors > but > do not (there is a sign reversal for the first one): > >> summary(princomp(bumpus),loading = TRUE) > Importance of components: > Comp.1Comp.2 Comp.3 Comp.4 Comp.5 > Standard deviation 6.2801653 2.4285636 1.13995042 0.560733747 0.03458915 > Proportion of Variance 0.8399662 0.1256084 0.02767525 0.006696272 0.2548 > Cumulative Proportion 0.8399662 0.9655746 0.99324988 0.46156 0.7164 > Comp.6 Comp.7 Comp.8 Comp.9 > Standard deviation 3.025628e-02 1.405339e-02 1.147326e-02 9.339938e-03 > Proportion of Variance 1.949623e-05 4.206121e-06 2.803451e-06 1.857837e-06 > Cumulative Proportion 9.11e-01 9.53e-01 9.81e-01 1.00e+00 > > Loadings: > Comp.1 Comp.2 Comp.3 Comp.4 Comp.5 Comp.6 Comp.7 Comp.8 Comp.9 > V1 0.497 0.851 0.171 > V2 0.853 -0.515 > V3 0.149 0.103 -0.965 0.189 > V4 -0.180 -0.981 > V5 -0.288 0.568 0.327 0.693 > V6 -0.399 0.565 0.154 -0.705 > V7 -0.867-0.475 -0.107 > V80.352 -0.926 0.118 > V9 0.994 >> eigen(cov(bumpus)) > $values > [1] 3.973263e+01 5.941610e+00 1.309113e+00 3.167514e-01 1.205271e-03 > 9.33e-04 > [7] 1.989606e-04 1.326107e-04 8.788062e-05 > > $vectors > [,1] [,2] [,3] [,4] [,5] > [1,] -0.496897319 0.8505093640 0.171388489 0.018744742 -0.0002708851 > [2,] -0.852790441 -0.5152155401 0.081515933 0.025301353 0.0031275939 > [3,] -0.149011771 0.1032588064 -0.965116017 0.188813583 0.0029039523 > [4,] -0.059981091 0.0228574697 -0.180065518 -0.981007482 0.0301789269 > [5,] -0.002474454 -0.0009781164 -0.003402721 -0.011404980 -0.2884751568 > [6,] -0.002255070 -0.0003234929 -0.002776659 -0.014386855 -0.3990284747 > [7,] -0.003505091 -0.0005603692 -0.006526439 -0.022328724 -0.8671382015 > [8,] -0.001124313 0.0005858447 -0.003031985 -0.006957916 -0.0674635788 > [9,] -0.003810707 0.0004531193 -0.006127501 -0.009908937 -0.0122192249 > [,6] [,7] [,8] [,9] > [1,] -0.001028476 1.638253e-06 0.0004887328 -0.0003561342 > [2,] -0.002350593 -8.313864e-04 -0.0003929312 0.0005026715 > [3,] -0.004636198 8.031165e-05 0.0015963693 0.0010649875 > [4,] -0.011239114 -5.568762e-03 0.0035062479 0.0003785351 > [5,] 0.083901242 5.675807e-01 0.3265320650 -0.6934139460 > [6,] 0.032231827 5.646388e-01 0.1541661011 0.7049350072 > [7,] -0.058318858 -4.748060e-01 -0.1070487286 -0.0849487969 > [8,] 0.014813290 3.516922e-01 -0.9260185177 -0.1182046449 > [9,] 0.994055719 -9.937481e-02 -0.0249932592 0.0324567705 > > __ > 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] PR#8282
The attempt made was to reproduce exactly the example you reported (of
course).
Notice that this is incorrect usage, as you are trying to replace one
element by 2. We have since found another example of this, and fixed it,
but it is nothing new in 2.2.0. Please try a current version of R
(R-patched or R-devel). The relevant NEWS item is
o Subassignment of a vector which increased the length of the
vector _and_ had the wrong length of replacement could
occasionally segfault. (This has been there since at least
mid 1997.)
It is poor practice to increase the size of a vector in this way rather
than pre-allocate. Perhaps it has persisted so long because it is a user
error in poor practice that can need 100 repeats to reproduce.
On Fri, 18 Nov 2005 [EMAIL PROTECTED] wrote:
> When an attempt was made to reproduce this on other platforms,
> how high was the index? For one of my Apples, I need to take
> it very high, maybe 100? Sorry, I guess I edited that part
> out.
>
> --
> zi <- vector()
> for(i in 1:100) {
> zi[i] <- c(1,2)
> }
> zi[,1]
> --
>
> __
> 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] (PR#8337) formatC adds leading space -- on some Windoze
On Tue, 22 Nov 2005 [EMAIL PROTECTED] wrote:
>>>>>> "KevinW" == Kevin Wright <[EMAIL PROTECTED]>
>>>>>> on Mon, 21 Nov 2005 18:13:36 +0100 (CET) writes:
>
>KevinW> Full_Name: Kevin Wright
>KevinW> Version: 2.2.0
>KevinW> OS: Windows 2000
> ^^^
> this must be part of the problem
It is, and it is a known inconsistency with Linux (but I do not consider
it to be a bug or `wrong behavior' or not `reasonable').
Windows always uses three digits for the exponent, e.g. E+001. This
results from adjusting the returned result to be more consistent with
other platforms. (BTW, since width (sic) is a lower bound, it _is_
respected.) Even if the layout is not ideal, the results are at least
diff-able against those from other platforms.
If Kevin (or anyone else) wants it done even more consistently, he could
contribute a patch. Now, we _have_ done that for print(), but it did not
seem worth it for formatC (especially as sprintf() is now widely used and
would also need to be made consistent). (It also did not seem worth it
given how little credit is given for such work.)
>KevinW> Submission from: (NULL) (170.54.58.4)
>
>
>
>KevinW> Apologies if my expectations (or reading of the man page) are
> incorrect.
>
>KevinW> I seem unable to left-justify exponential format
>KevinW> numbers. There appears to always be an extra space
>KevinW> inserted to the left.
>
>KevinW> Using the example from the formatC help page:
>
>R> xx <- pi * 10^(-5:4)
>
>R> cbind(formatC(xx, wid = 9, flag = "-"))
>KevinW> [,1]
>KevinW> [1,] " 3.142e-05"
>KevinW> [2,] "0.0003142"
>KevinW> [3,] "0.003142 "
>KevinW> [4,] "0.03142 "
>KevinW> [5,] "0.3142 "
>KevinW> [6,] "3.142"
>KevinW> [7,] "31.42"
>KevinW> [8,] "314.2"
>KevinW> [9,] "3142 "
>KevinW> [10,] " 3.142e+04"
>
> which is also not obeying the 'wid' argument.
>
> I get something much more reasonable:
>
> [,1]
> [1,] "3.142e-05"
> [2,] "0.0003142"
> [3,] "0.003142 "
> [4,] "0.03142 "
> [5,] "0.3142 "
> [6,] "3.142"
> [7,] "31.42"
> [8,] "314.2"
> [9,] "3142 "
> [10,] "3.142e+04"
>
> formatC uses your system's C library printf {that's where the
> "C" comes from in 'formatC'} which seems to be
> broken or at least not performing as we think it should.
>
> On a "Windows 2003 Server" I have access to, I see the same
> wrong behavior as above.
>
> Martin Maechler, ETH Zurich
>
> __
> 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] make check fails for R 2.3.0 (PR#8343)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-1978628741-1132653680=:25449
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[EMAIL PROTECTED]>
On Tue, 22 Nov 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Arne Henningsen
> Version: 2.3.0, 2005-11-21, i686-pc-linux-gnu
Please use the svn revision for unreleased versions of R. There is no 'R=
=20
2.3.0' and the version changes several times a day. But we do expect=20
'make check' to have been run successfully on each of those versions.
> OS: SuSE Linux 9.0, Kernel 2.4.21
> Submission from: (NULL) (134.245.140.242)
You are reporting as a bug in R a problem on your own system in an=20
unreleased ('unstable') version of R. Since it is unstable and=20
unreleased, such things are by definition not bugs in R.
Others are not seeing this, so we cannot do anything about the problems=20
seen on your system. This is not at all a new test, and although random=20
it is run with set.seed(1). I can reproduce the result in the output file=
=20
(on my systems) exactly by
> set.seed(1)
> hist(replicate(100, mean(rexp(10
Please see if you can debug it on your own system. (My guess would be=20
that it only occurs as part of the test file.)
> I did not find any problems in "./configure" and "make", but "make check"
> fails:
>
> make[4]: Entering directory `/home/suapm095/Download/R-devel/tests/Exampl=
es'
> collecting examples for package 'base' ...
> make[5]: Entering directory `/home/suapm095/Download/R-devel/src/library'
> >>> Building/Updating help pages for package 'base'
> Formats: text html latex example
> make[5]: Leaving directory `/home/suapm095/Download/R-devel/src/library'
> running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Fehler 1
> make[4]: Leaving directory `/home/suapm095/Download/R-devel/tests/Example=
s'
> make[3]: *** [test-Examples-Base] Fehler 2
> make[3]: Leaving directory `/home/suapm095/Download/R-devel/tests/Example=
s'
> make[2]: *** [test-Examples] Fehler 2
> make[2]: Leaving directory `/home/suapm095/Download/R-devel/tests'
> make[1]: *** [test-all-basics] Fehler 1
> make[1]: Leaving directory `/home/suapm095/Download/R-devel/tests'
> make: *** [check] Fehler 2
>
>
> At the end of the file "tests/Examples/base-Ex.Rout.fail" I found:
>
>> i39 <- sapply(3:9, seq) # list of vectors
>> sapply(i39, fivenum)
> [,1] [,2] [,3] [,4] [,5] [,6] [,7]
> [1,] 1.0 1.01 1.0 1.0 1.01
> [2,] 1.5 1.52 2.0 2.5 2.53
> [3,] 2.0 2.53 3.5 4.0 4.55
> [4,] 2.5 3.54 5.0 5.5 6.57
> [5,] 3.0 4.05 6.0 7.0 8.09
>>
>> hist(replicate(100, mean(rexp(10
> Fehler in hist.default(replicate(100, mean(rexp(10 :
> =09invalid number of 'breaks'
> Ausf=FChrung angehalten
--=20
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
--27464147-1978628741-1132653680=:25449--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] Add fpicflags for Intel(R) Fortran Compiler (PR#8344)
1) The documented way to specify this is to set FPICFLAGS in config.site:
see the example in R-admin for the PG compilers. When you tried that,
what went wrong?
2) It seems strange to specify this for the Fortran compiler and not the C
or C++ compiler.
3) You have suggested the change to a section for all OSes. Do you know
for sure that all compilers called 'ifort' on all OSes need the -fPIC
flag? Or is it really just for Linux (and AFAICS, just x86_64 Linux, as
i386 Linux seems to work with icc/ifort without it).
On Tue, 22 Nov 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Danny van Dyk
> Version: R-2.2.0
> OS: Gentoo/AMD64
> Submission from: (NULL) (83.129.50.65)
>
>
> I have successfully compiled R-2.2.0 using ifc-9.0.026 on my x86_64 box.
> The only (minor) change that hade to be made was adding fpicflags="-fPIC" to
> configure.ac in case F77 matches either "ifc" (old name) or "ifort" (new
> name).
>
> Please apply following patch:
>
> [EMAIL PROTECTED] trunk $ svn diff
>Index: configure.ac
> ===
> --- configure.ac(revision 36420)
> +++ configure.ac(working copy)
> @@ -942,7 +942,7 @@
> rm -f Imakefile Makefile
> fi
>
> -## Step 2. GNU compilers.
> +## Step 2. GNU and Intel compilers.
> if test "${GCC}" = yes; then
> cpicflags="-fPIC"
> shlib_ldflags="-shared"
> @@ -954,6 +954,11 @@
> cxxpicflags="-fPIC"
> shlib_cxxldflags="-shared"
> fi
> +case "${F77}" in
> + ifc|ifort)
> +fpicflags="-fPIC"
> +;;
> +esac
>
> ## Step 3. Individual platform overrides.
> case "${host_os}" in
> ===
>
> Danny
>
> ______
> 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] terms.object documentation bug? (PR#8353)
On Mon, 28 Nov 2005 [EMAIL PROTECTED] wrote: > Full_Name: simon wood > Version: 2.2.0 (and lower) > OS: linux/windows > Submission from: (NULL) (86.135.153.59) > > > I think that the documentation for the `specials' attribute of a > `terms.object' > is not quite right: > > specials: If the 'specials' argument was given to 'terms.formula' there > is a 'specials' attribute, a list of vectors indicating the > terms that contain these special functions. This is wrong, but it does not say `in the list of terms'. > should read something like: > > specials: If the 'specials' argument was given to 'terms.formula' there > is a 'specials' attribute, a list of vectors indicating the > variables that contain these special functions. You are right it refers to the variables, but we need to make clear that the vectors are numeric indices, and into what (not the variables attribute). > Here is some example code illustrating the problem: > > tf <- terms.formula(y~x+x:z+s(x),specials="s") ## make a `terms' object > attr(tf,"specials") ## documented to index `s' in list of terms > ## but in lists of terms, `s' is in position 2, not 4 > attr(tf,"term.labels") > colnames(attr(tf,"factors")) > > ## in lists of variables `s' *is* in position 4... > attr(tf,"variables") > rownames(attr(tf,"factors")) Thanks, I have adapted that for the help page. -- 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] (PR#8363) R CMD INSTALL fails if cd prints stuff to stdout
What shells are these? You don't give an example that causes trouble, and
in particular no way to reproduce this.
The behaviour you describe is prohibited by the POSIX standard, so the
problem would appear to be with the unnamed shell. I can see how it could
happen if a user redefines 'cd', but then a user could redefine all the
commands in his OS and we have to make some reasonable assumptions
You seem not to have submitted a patch against the R sources, which
contain src/scripts/INSTALL.in, not INSTALL, and it contains changes you
do not mention.
On Fri, 2 Dec 2005 [EMAIL PROTECTED] wrote:
>
> --Boundary_(ID_erFAa+o6kWefQxXf6GD2RA)
> Content-type: text/plain; charset="us-ascii"
> Content-disposition: inline
> Content-transfer-encoding: 7bit
>
> Dear all,
>
> I came across puzzling behaviour of R CMD INSTALL, which I tracked down to the
> fact that in some shells (or in some user customizations of them), the cd
> command prints out the new directory. As a result, the $pkgs variable gets a
> wrong value, e.g.in the following transcript:
>
> [EMAIL PROTECTED]:tmp$ R CMD INSTALL GlobalAncova
> /usr/lib/R/bin/INSTALL: line 873: cd: /home/philip/tmp/GlobalAncova
> /var/tmp/philip/misc/GlobalAncova: No such file or directory
> sed: can't read DESCRIPTION: No such file or directory
> ERROR: no 'Package' field in 'DESCRIPTION'
> [EMAIL PROTECTED]:tmp$
>
> The error at line 873 is due to the variable $pkgs containing the string
> '/home/philip/tmp/GlobalAncova
> /var/tmp/philip/misc/GlobalAncova'
>
> (i.e. including the new line. Incidentally, /home/philip/tmp dir is a symlink
> to /var/tmp/philip/misc; hence the non-identical directory names).
>
> A simple fix (cd "${1}" > /dev/null 2>&1 && ${GETWD}) takes care of this, and
> should work under sh, ksh, bourne shell, zsh. A context diff is attached; I
> hope this will prove useful. Kind regards,
>
>
> Philip
>
> --
> Philip Lijnzaad
> Genomics Laboratory
> Dept. of Biomedical Genetics
> University Medical Center (UMC), Utrecht
> Stratenum room 2.201 (on Mondays and Thursdays not in after 14.45)
> MSN chat (*NOT* email): [EMAIL PROTECTED]
> P.O. Box 85060, 3508 AB Utrecht
> (Universiteitsweg 100, 3584 CG Utrecht)
> The Netherlands
> tel: +31 (0)30 253 8464
> fax: +31 (0)30 253 8479
>
> --Boundary_(ID_erFAa+o6kWefQxXf6GD2RA)
> Content-type: text/x-diff; charset="us-ascii"; name="INSTALL.patch"
> Content-disposition: attachment; filename="INSTALL.patch"
> Content-transfer-encoding: 7bit
>
> *** INSTALL~ Wed Jun 22 11:09:59 2005
> --- INSTALL Fri Dec 2 17:08:50 2005
> ***
> *** 127,136
> get_packages () {
>## get the full path names to all packages contained in $1.
>## NOTE: modifies pkgs!
>if grep "^Contains:" "${1}/DESCRIPTION" >/dev/null; then
> bundlepkg=`get_dcf_field Contains "${1}/DESCRIPTION"`
> for p in ${bundlepkg}; do
> ! pkgs="${pkgs} \"`cd "${1}/${p}" && ${GETWD}`\""
>if test -f "${1}/${p}/DESCRIPTION.in"; then
> ## Try being defensive about missing final newlines, or extra
> ## empty lines.
> --- 127,138
> get_packages () {
>## get the full path names to all packages contained in $1.
>## NOTE: modifies pkgs!
> + PROMPT_COMMAND=
> + BASH_COMMAND=
>if grep "^Contains:" "${1}/DESCRIPTION" >/dev/null; then
> bundlepkg=`get_dcf_field Contains "${1}/DESCRIPTION"`
> for p in ${bundlepkg}; do
> ! pkgs="${pkgs} \"`cd "${1}/${p}>/dev/null 2>&1" && ${GETWD}`\""
>if test -f "${1}/${p}/DESCRIPTION.in"; then
> ## Try being defensive about missing final newlines, or extra
> ## empty lines.
> ***
> *** 139,145
> fi
> done
>else
> ! pkgs="${pkgs} \"`cd "${1}" && ${GETWD}`\""
>fi
> }
>
> --- 141,147
>fi
> done
>else
> ! pkgs="${pkgs} \"`cd "${1}" > /dev/null 2>&1 && ${GETWD}`\""
>fi
> }
>
>
> --Boundary_(ID_erFAa+o6kWefQxXf6GD2RA)--
>
> __
> 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] ???UNSURE??? Re: (PR#8363) R CMD INSTALL fails if cd prints
On Mon, 5 Dec 2005, Philip Lijnzaad wrote: > On Friday 02 December 2005 18:20, Prof Brian Ripley wrote: > >> What shells are these? > > Bash, mostly, but also ksh and zsh; sorry for not mentioning this. I still don't know what you did to be able to reproduce this (and I did ask). And as it is a shell script running under /bin/sh, it must be whatever is masquerading as Bourne shell on your system(s) that is affected. > I now see that the root account usually does not change the behaviour of > cd, so we may as well forget about the matter. My thought was: if a > small change helps avoid this problem (which I think can occur easily > enough), it could be helpful. Incidentally, IMHO the way it is coded in > INSTALL.in (I didn't know about INSTALL.in, sorry) is a bit unusual; cd > does not seem to be required by the POSIX standard to have non-zero exit > status when it fails (and in fact, on older SunOSes, 'cd > non/existant/directory' returns 0). But that is But it _is_ so required: http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html How old are `older SunOSes'? Solaris 8 (which is 4 years old) is POSIX-compilant here, and I would be surprised if any from the last decade was not (at least with suitable paths set). > probably more a matter of style, more than anything else. Our philosphy is to assume that the users tools are standard (e.g. POSIX) unless there is widespread evidence to the contrary. First off, we need to know what was done and to be able to reproduce it. -- 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] standardized residuals (rstandard & plot.lm) (PR#8367)
Curiously, I was just looking at that, since I believe the answer should
be NaN, and some optimizing compilers/fast BLASes are not giving that.
(There's an example in reg-test-3.R.) So I think we need to return NaN
when hat is within rounding error of 1.
My take is that plot.lm should handle this: you will see most but not all
cases have na.rm=TRUE in calculating ylim, but as Inf is theoretically
impossible it has not been considered.
Note that plot.lm does not use rstandard and so needs a separate fix.
Thanks for the report
On Tue, 6 Dec 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Heather Turner
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (137.205.240.44)
>
>
> Standardized residuals as calculated by rstandard.lm, rstandard.glm and
> plot.lm
> are Inf/NaN rather than zero when the un-standardized residuals are zero. This
> causes plot.lm to break when calculating 'ylim' for any of the plots of
> standardized residuals. Example:
>
> "occupationalStatus" <-
>structure(as.integer(c(50, 16, 12, 11, 2, 12, 0, 0, 19, 40, 35,
> 20, 8, 28, 6, 3, 26, 34, 65, 58, 12, 102, 19, 14, 8,
> 18, 66, 110, 23, 162, 40, 32, 7, 11, 35, 40, 25, 90,
> 21, 15, 11, 20, 88, 183, 46, 554, 158, 126, 6, 8,
> 23,
> 64, 28, 230, 143, 91, 2, 3, 21, 32, 12, 177, 71,
> 106)
> ), .Dim = as.integer(c(8, 8)), .Dimnames =
> structure(list(origin = c("1", "2", "3", "4", "5", "6", "7",
> "8"),
> destination = c("1", "2", "3", "4", "5", "6", "7",
> "8")), .Names = c("origin", "destination")),
> class = "table")
> Diag <- as.factor(diag(1:8))
> Rscore <- scale(as.numeric(row(occupationalStatus)), scale = FALSE)
> Cscore <- scale(as.numeric(col(occupationalStatus)), scale = FALSE)
> Uniform <- glm(Freq ~ origin + destination + Diag +
> Rscore:Cscore, family = poisson, data = occupationalStatus)
> residuals(Uniform)[as.logical(diag(8))] #zero/near-zero
> rstandard(Uniform)[as.logical(diag(8))] #mostly Inf/NaN
> plot(Uniform) #breaks on qqnorm plot (or any 'which' > 1)
>
> This could be fixed by replacing standardized residuals with zero where the
> hat
> value is one, e.g.
> rstandard.glm <- function (model,
>infl = lm.influence(model, do.coef = FALSE),
>...) {
> res <- infl$wt.res
> hat <- infl$hat
> ifelse(hat == 1, 0, res/sqrt(summary(model)$dispersion * (1 -
> infl$hat)))
> }
> etc.
>
> __
> 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] (PR#8376 inconsistency between plot(hist(...)) and hist(...)
On Sun, 11 Dec 2005 [EMAIL PROTECTED] wrote: > Full_Name: Andrew Clausen > Version: 2.1.0 > OS: Debian GNU/Linux > Submission from: (NULL) (71.242.192.73) > > > Hi, > > When I type > >hist(x, freq=F) > > I get a density function, as I expect. However, if I type > >plot(hist(x, freq=F)) > > then I get the same output as if I had typed: > >hist(x, freq=T) > > I expect that the second command should have the same semantics as the first. And it actually does, but your usage does not. Did you check the help page? ?plot.histogram shows plot.histogram has a 'freq' argument, and the correct usage is plot(hist(x), freq=FALSE) -- 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] 0/1 vector for indexing leads to funny behaviour (PR#8389)
It is peculiar behaviour on your part, but the developers do not find it
at all `funny'.
On Tue, 13 Dec 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Axel Rasche
> Version: 2.2.0
> OS: Linux
> Submission from: (NULL) (141.14.21.81)
>
>
> Dear Debuggers,
>
> This is not a serious problem. Are 0/1 vectors intended to be used as index
> vectors? If yes, there is a bug. If not, it leads just to some funny behaviour
> rather than an error message.
They are, and in your example they work as documented. You have not even
told us what you think the bug is.
What happens in clearly stated in the R Language Definition and in all
good reference books on R.
> In the appendix is some simple code to reproduce the problem. A logical vector
> as.logic(a) helps by indexing the vector b. The 0/1 vector a just returns the
> first value "a". But as many times as there is a 1 in a.
As it should.
>
> Best regards,
> Axel
>
>
> Appendix:
>
> b = c("a","b","c","d")
> a = c(0,1,1,0)
> b[as.logical(a)]
> b[a]
> a = c(1,0,1,0)
> b[as.logical(a)]
> b[a]
> a = c(0,1,1,1)
> b[as.logical(a)]
> b[a]
--
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] 2 x 2 chisq.test (PR#8415)
This is the same as PR#8265, from a person also not giving his/her name
but sharing your ISP. Please don't submit a repeat, as the FAQ asks.
After last time this was raised, I checked Yates' original paper and
Fisher's book and it seems that R's formula follows what they say.
Do remember that 0 is an impossible value for a chisq-distributed
variable, and so one would not expect the corrected distribution to take
that value with positive probability.
On Tue, 20 Dec 2005 [EMAIL PROTECTED] wrote:
> Full_Name: nobody
Do you expect us to take the word of `nobody' as to the correct definition
of a statistic? We need your credentials and references.
> Version: 2.2.0
> OS: any
> Submission from: (NULL) (219.66.34.183)
>
>
> 2 x 2 table, such as
>
>> x
> [,1] [,2]
> [1,] 10 12
> [2,] 11 13
>
>> chisq.test(x)
>
> Pearson's Chi-squared test with Yates'
> continuity correction
>
> data: x
> X-squared = 0.0732, df = 1, p-value = 0.7868
>
> but, X-squared = 0.0732 is over corrected.
>
> when abs(a*d-b*c) <= sum(a,b,c,d), chisq.value must be 0!, and P-value must be
> 1!
>
> code of chisq.test must be as follows
>
> # if (correct && nrow(x) == 2 && ncol(x) == 2) {
> # YATES <- 0.5
> # METHOD <- paste(METHOD, "with Yates' continuity correction")
> # }
> # else YATES <- 0
> # STATISTIC <- sum((abs(x - E) - YATES)^2/E)
> ## replace begin
> if (correct && nrow(x) == 2 && ncol(x) == 2) {
> STATISTIC <- if (abs(x[1,1]*x[2,2]-x[1,2]*x[2,1]) < sum(x)/2) > 0
>
> else sum((abs(x - E) - 0.5)^2/E)
> METHOD <- paste(METHOD, "with Yates' continuity correction")
> }
> else STATISTIC <- sum((abs(x - E))^2/E)
> ## replace end
--
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] NextMethod causes R 2.2.0 to crash (PR#8416)
Bill,
This is a 2.2.0 Windows problem, solved in 2.2.1. What happened was that
someone trying to be helpful increased the evaluation nesting limit in
2.1.0, and Windows has a small C stack (2Mb) which can easily be exceeded.
I now get
> julian(m)
Error: evaluation nested too deeply: infinite recursion / options(expressions=)?
as I should. The nesting limit has been reduced and the C stack size
increased.
It is legitimate to call NextMethod in a default method, but it is all too
easy to get loops. In your case you want the Date method, not the next
method (which since there is only one class will be the default).
I would advise Windows users of 2.2.0 to
1) update
2) if that is not possible, set options(expressions=1000).
Brian
On Wed, 21 Dec 2005 [EMAIL PROTECTED] wrote:
> I found writing the following default method the for the generic
> function "julian" causes R to crash.
>
>
> julian.default <- function(x, ...) {
>x <- as.Date(x)
>NextMethod("julian", x, ...)
> }
>
> Here is a test example
>
>> m <- as.Date("1972-09-27") + 0:10
>> m
> [1] "1972-09-27" "1972-09-28" "1972-09-29" "1972-09-30" "1972-10-01"
> "1972-10-02" "1972-10-03"
> [8] "1972-10-04" "1972-10-05" "1972-10-06" "1972-10-07"
>> class(m)
> [1] "Date"
>> julian(m)
> [1] 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010
> attr(,"origin")
> [1] "1970-01-01"
>
>> m <- as.character(m)
>> class(m)
> [1] "character"
>
>> julian(m)
>
> < R crashes>
>
> --please do not edit the information below--
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 2.0
> year = 2005
> month = 10
> day = 06
> svn rev = 35749
> language = R
>
>
>
> Bill Venables,
> CMIS, CSIRO Laboratories,
> PO Box 120, Cleveland, Qld. 4163
> AUSTRALIA
> Office Phone (email preferred): +61 7 3826 7251
> Fax (if absolutely necessary):+61 7 3826 7304
> Mobile (rarely used):+61 4 1963 4642
> Home Phone: +61 7 3286 7700
> mailto:[EMAIL PROTECTED]
> http://www.cmis.csiro.au/bill.venables/
>
> __
> 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] (Debian Bug 344248): R segfaults when pressing Delete (PR#8422)
On Wed, 21 Dec 2005 [EMAIL PROTECTED] wrote: > > --CE+1k2dSO48ffgeK > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Resend after type in mailheader. I have the bug on my system with > yesterday's R 2.2.1. A library mismatch is still a likely cause. This seems to be a readline 5.1 error. I was unable to reproduce it with 4.3 or 5.0. gdb) bt #0 0xb7f4c942 in _rl_dispatch_callback () from /usr/local/lib/libreadline.so.5 #1 0xb7f5fd82 in rl_callback_read_char () from /usr/local/lib/libreadline.so.5 #2 0x0816b98b in Rstd_ReadConsole (prompt=0xb7f6fafc "", buf=0xbf8bb1ec "", len=1024, addtohistory=0) at /users/ripley/R/svn/R-devel/src/unix/sys-std.c:663 Switching the link from libreadline.so.5 back to libreadline.so.5.0 made this behave again. Can you confirm you are running rl5.1? Given the segfault is readline not in R itself, it is at the very least a change in behaviour in a supposedly compatible version of a dynamic library so it seems to me the bug should be assigned to readline not R. Brian > > Dirk > > -- > Hell, there are no rules here - we're trying to accomplish something. > -- Thomas A. Edison > > --CE+1k2dSO48ffgeK > Content-Type: message/rfc822 > Content-Disposition: inline > > Return-path: <> > X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on basebud.nulle.part > X-Spam-Level: > X-Spam-Status: No, score=-2.5 required=4.9 tests=BAYES_00,FORGED_RCVD_HELO > autolearn=ham version=3.1.0 > Received: from sccrmhc11.comcast.net ([63.240.77.81]) > by master.debian.org with esmtp (Exim 4.50) > id 1Ep3A7-0001sJ-Py > for [EMAIL PROTECTED]; Wed, 21 Dec 2005 06:33:43 -0600 > Received: from basebud.nulle.part > (c-67-174-11-185.hsd1.il.comcast.net[67.174.11.185]) > by comcast.net (sccrmhc11) with ESMTP > id <20051221123308011005fbjme>; Wed, 21 Dec 2005 12:33:13 + > Received: from Debian-exim by basebud.nulle.part with local (Exim 4.60) > id 1Ep39X-0005dm-5V > for [EMAIL PROTECTED]; Wed, 21 Dec 2005 06:33:07 -0600 > Auto-Submitted: auto-replied > From: Mail Delivery System <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Mail failure - malformed recipient address > Message-Id: <[EMAIL PROTECTED]> > Date: Wed, 21 Dec 2005 06:33:07 -0600 > Delivered-To: [EMAIL PROTECTED] > > A message that you sent contained one or more recipient addresses that were > incorrectly constructed: > > [EMAIL PROTECTED]@ku.dk: malformed address: @ku.dk may not follow [EMAIL > PROTECTED] > > This address has been ignored. The other addresses in the message were > syntactically valid and have been passed on for an attempt at delivery. > > -- This is a copy of your message, including all the headers. -- > > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Message-ID: <[EMAIL PROTECTED]> > Date: Wed, 21 Dec 2005 06:33:07 -0600 > To: [EMAIL PROTECTED]@ku.dk > CC: Ethan Glasser-Camp <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > Subject: Re: Bug#344248: R crashes when I press "Delete" > In-Reply-To: <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > X-Mailer: VM 7.19 under Emacs 21.4.1 > From: Dirk Eddelbuettel <[EMAIL PROTECTED]> > X-rewrote-sender: [EMAIL PROTECTED] > > > On 21 December 2005 at 01:50, Ethan Glasser-Camp wrote: > | Package: r-base-core > | Version: 2.2.1-1 > | > | When I run R, I can cause a crash by simply pressing Delete. Backspace works > | fine, and I can use ESS without problems. > > Uh-oh. > > | [EMAIL PROTECTED]:~$ R > | > | R : Copyright 2005, The R Foundation for Statistical Computing > | Version 2.2.1 (2005-12-20 r36812) > | ISBN 3-900051-07-0 > | > | R is free software and comes with ABSOLUTELY NO WARRANTY. > | You are welcome to redistribute it under certain conditions. > | Type 'license()' or 'licence()' for distribution details. > | > | R is a collaborative project with many contributors. > | Type 'contributors()' for more information and > | 'citation()' on how to cite R or R packages in publications. > | > | Type 'demo()' for some demos, 'help()' for on-line help, or > | 'help.start()' for an HTML browser interface to help. > | Type 'q()' to quit R. > | > | [Previously saved workspace restored] > > Could you (temporarily) remove that file? > > | > Segmentation fault > | [EMAIL PROTECTED]:~$ > > That said, I just tried this where I seemed to have no
Re: [Rd] 'last.warning' problem at startup; package Matrix (PR#8453)
This *is* a bug in package Matrix and yes, bugs in packages can be bad enough to stop a saved image (sic) being loaded. You could have started R --no-restore and load()ed it later. Matrix has several uses of assignInNamespace in .onLoad and .onUnload, and that is in package utils and so not necessarily loaded. Try loading Matrix with R_DEFAULT_PACKAGES=NULL to reproduce this. R-bugs was not the appropriate place to report this, as the FAQ makes quite clear. On Thu, 29 Dec 2005 [EMAIL PROTECTED] wrote: > On starting an R session, I get the messages: > > Fatal errir: unable to restore save data in .RData > > Error in fun(...): couldn't find function "assignInNamespace" > > Error: .onLoad failed in 'loadNamespace' for 'Matrix' > > The only object in my .RData is last.warning, thus: > > > last.warning > $"optim or nlminb returned message false convergence (8)" > "LMEoptimize<-"(`*tmp*`, value = list(maxIter = 200, tolerance = > 1.49011611938477e-08, > msMaxIter = 200, msVerbose = 0, niterEM = 15, EMverbose = FALSE, > PQLmaxIt = 30, analyticGradient = TRUE, analyticHessian = FALSE)) > > This was generated by a call, in a previous session,to lmer() > There may be a problem with the package Matrix, but it seems a bit > extreme that this prevents restoration of the session. > > John Maindonald > [EMAIL PROTECTED] > > --please do not edit the information below-- > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 2 > minor = 2.1 > year = 2005 > month = 12 > day = 20 > svn rev = 36812 > language = R > > Windows XP Home Edition (build 2600) Service Pack 2.0 > > Locale: > LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 > > 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] follow-up on qr.coef bug (PR#8478)
It certainly _was_ there, in incoming as PR#8476, and also in the R-devel
archives.
BTW, you have not given the minimal information required, e.g. the R
version. The pivot logic _is_ correct (your patch was broken), but there
was a problem with multiple RHSs, now fixed.
On Thu, 12 Jan 2006 [EMAIL PROTECTED] wrote:
> This is a multi-part message in MIME format.
> --090308090600080800090200
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> The bug I submitted yesterday (It's not entered in the bug data base, so
> I have no ID for it) included a suggested fix that
> is not correct. It worked for the examples I gave because there was no
> pivoting in fact, or only pivot permutations that were
> idempotent. A correction that works in general on the examples I gave
> makes these two changes in qr.coef():
>
>## coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
> "base")[1:p]
>coef[qr$pivot,] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
> "base")[1:p,]
>
>##coef[qr$pivot,] <- .Call("qr_coef_real", qr, y, PACKAGE =
> "base")[1:p]
>coef[qr$pivot,] <- .Call("qr_coef_real", qr, y, PACKAGE =
> "base")[1:p,]
>
> I'm not sure why the [1:p,] on the right is needed. For my examples, it
> works without this extraction operation, but maybe there is some case in
> which the output of qr_coef_real or qr_coef_cmplx could have more than p
> rows.
Read the C code: B is a copy of Bin (y) and so no, it cannot happen any
more (it could in an earlier version).
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help.start() and Debian packaging (PR#8483)
This is all based on a false premise: that a partial install of Debian files is 'R'. R's own scripts do always install the HTML documentation, so help.start() is entitled to assume that it is present. (That is under Unix-alikes: R for Windows allows Compiled HTML rather than HTML, and so help.start makes appropriate tests). Note that your version of 'R' is not current. If there is a bug here, it is in the Debian re-packaging. I trust the Debian packages do contain a bug reporting address other than this one: please use the correct one. (The other binary distributions that I am aware of, e.g. RPMs, do seem to include all of R.) On Sat, 14 Jan 2006 [EMAIL PROTECTED] wrote: > Full_Name: Greg Kochanski > Version: 2.2.0 > OS: Debian Linux on i686 > Submission from: (NULL) (212.159.16.190) > > > Debian packages the R documentation separately from the R core code. > Consequently, it is possible for people to have R without > the HTML documentation. (In fact, the docs are not installed by default, > so it's very likely.) > > > Thus, help.start() cannot depend on the HTML documentation being there. > It should check for one (or a few) files and produce some reasonable > error message if it is not there. Maybe something like > "Warning: the HTML documentation is not installed." > > Alternatively, help.start() could produce references to some on-line > HTML documentation, instead of local documentation. > > > > A related bug is that if one calls > help.start() when the HTML documentation does not exist, > all future calls to help() will lead to errors. Working as documented is not a bug. -- 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] phyper returns 1 if x==k (PR#8499)
On Wed, 18 Jan 2006 [EMAIL PROTECTED] wrote: > Full_Name: Utz J. Pape > Version: 2.2.0 > OS: linux > Submission from: (NULL) (141.14.23.12) > > > If I use phyper and set parameter x equal to k (meaning that all balls I draw > are white) phyper returns 1 which is not (always) correct: I think you are confusing this with dhyper. How can you possibly get more white balls than exist in the urn? That you cannot is what p = 1 is telling you. We do quite specifically ask you not to report on obselete versions of R. Of course, as this is NOT A BUG, it is the same in the current R. > > [EMAIL PROTECTED]:~> R2.2.0 --vanilla > > R : Copyright 2005, The R Foundation for Statistical Computing > Version 2.2.0 (2005-10-06 r35749) > ISBN 3-900051-07-0 > > R is free software and comes with ABSOLUTELY NO WARRANTY. > You are welcome to redistribute it under certain conditions. > Type 'license()' or 'licence()' for distribution details. > > R is a collaborative project with many contributors. > Type 'contributors()' for more information and > 'citation()' on how to cite R or R packages in publications. > > Type 'demo()' for some demos, 'help()' for on-line help, or > 'help.start()' for a HTML browser interface to help. > Type 'q()' to quit R. > >> x <- 10; m <- 20; n <- 5; k <- 10 >> phyper(x,m,n,k) > [1] 1 >> choose(m,x) * choose(n,k-x) / choose(m+n,k) > [1] 0.05652174 >> version > _ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major2 > minor2.0 > year 2005 > month10 > day 06 > svn rev 35749 > language R >> sessionInfo() > R version 2.2.0, 2005-10-06, i686-pc-linux-gnu > > attached base packages: > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" > [7] "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] data.matrix returns mode logical for zero rows (PR#8496)
On Tue, 17 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: Jonathan Swinton
> Version: 2.2.1
> OS: Windows
> Submission from: (NULL) (193.132.159.169)
>
>
> #The first line of description for data.matrix says that it will
> # 'Return the matrix obtained by converting all the variables in a
> #data frame to numeric mode and then binding them together as the
> # columns of a matrix.'
>
> #However when called with a data.frame with zero rows, data.matrix returns a
> matrix
> #of mode logical rather than numeric. This conflicts with the documentation
> #and is not what seems sensible.
You don't show us an example of a data frame with zero rows, nor do you
show an example of data.matrix returning logical, so this report was very
confusing. Please do give a reproducible example as the posting guide and
FAQ ask.
df[FALSE,] is not a data frame, so I don't know why you expect data.matrix
to be applicable (it is the same as as.matrix in such cases).
Here is an actual reproducible example:
DF <- data.frame(x=c("a", "b"), y=2:3)[FALSE,]
typeof(data.matrix(DF))
> One underlying reason for this is that when a zero-length column of a
> matrix of mode logical is asserted to be numeric the matrix is not
> actually cast to numeric. I wonder if that too is a bug?
No, but there is a bug in your description as you are describing
replacement indexing, not `assertion'. Coercion in replacement indexing
is done to accommodate the new values, and there are none in your example.
(That is how S has always done it in my experience, although the Blue
Book p.359 says otherwise.)
If you want to assert that an object be numeric, use mode(x) <- "numeric".
>> R.version.string
> [1] "R version 2.2.1, 2005-12-20"
>> df <- data.frame(matrix(1:2,nrow=2))
>> mode(data.matrix(df)[,1])
> [1] "numeric"
>> mode(data.matrix(df[FALSE,])[,1])
> [1] "numeric"
>>
>> # Underlying cause
>> x <- matrix(nr = 2,nc = 1 )
>> mode(x)
> [1] "logical"
>> x[, 1] <- c(1,2)
>> mode(x)
> [1] "numeric"
>>
>> x0 <- matrix(nr = 0, nc = 1)
>> x0[, 1] <- numeric(0)
>> mode(x0)
> [1] "logical"
>> mode(x0[,1])
> [1] "logical"
--
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] function 'eigen' (PR#8503)
o show the > imaginary portion which is 0 > > $vectors > [,1] [,2] [,3] > [1,] -0.5345225+0i 4.720910e-17+2.643897e-09i 4.720910e-17-2.643897e-09i > [2,] -0.2672612+0i 7.071068e-01+0.00e+00i 7.071068e-01+0.00e+00i > [3,] -0.8017837+0i 7.071068e-01-2.643897e-09i 7.071068e-01+2.643897e-09i > > Incorrect imaginary portions, again, in eigenvectors 2 and 3. > > ______ > 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] Suboptimal EPS output (PR#8502)
I am unable to reproduce the claimed bug here in R-devel (although I can
in 2.2.1), and the files are all readable in GSView/gs.
We do ask you to consult the appropriate files and test the current
versions to see if this has been changed. As the FAQ says
If a bug has already been reported or fixed, please do not submit
further bug reports on it.
I am not sure that the page numbering is inappropriate but it is
easy to change (pdf() works the way you desire) and I have done so.
On Wed, 18 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: Mike Prager
> Version: 2.2.1
> OS: Windows XP with SP2
> Submission from: (NULL) (205.156.36.17)
>
>
> When several EPS files are made with one invocation of postscript(), only the
> first displays correctly in gsview. Examination of the generated eps files
> with
> a diff utility reveals that subsequent eps files lack the encoding vector
> definition and report page numbers higher than one. This causes (e.g.) gsview
> to
> fail when trying to display the subsequent files.
>
> My copy of the EPS specification does not prohibit %%Pages DSC comments higher
> than one, but since an EPS file is not allowed to have multiple pages, it
> seems
> inconsistent at least for the R-generated file to claim to be page 2 or that
> it
> contains more than one page.
Not for it to claim to be page 2: it does not say it is page 2 in that
file.
> The lack of encoding vector definition causes font loading to fail when it the
> file later specifies WinAnsiEncoding (as it does by default).
>
> Therefore, it would be desirable for each generated eps file to include the
> encoding vector and to state that it is page 1 of 1 and that the number of
> pages
> is 1.
>
> (This can be worked around by closing the device between plots, thus making
> sure
> each EPS file is the first file.)
>
> The following example generates two files, the second of which is incompatible
> with gsview on Windows as described:
>
> ##
> # epstest.r
> # M. H. Prager
> # Demonstrate (1) possible wrapper function for postscript() and
> # (2) problems with current EPS output
> # January 17, 2006
> ##
> eps <- function (...)
> {
>postscript(height = 5, width = 7, onefile = FALSE, horizontal = FALSE,
>paper = "special", file = "Rplot%03d.eps", ...)
> }
>
> eps()
> plot(1:5, rnorm(5))
> plot(1:6, rnorm(6))
> dev.off()
> # END OF EXAMPLE
> ##
>
> In addition, although it is NOT a bug, I would like to request that a wrapper
> function like eps() above be included with the R distribution. This would save
> R-help readers from answering the same questions over and over. It would also
> make it easier for newcomers to use R for generating eps files. Consideration
> by
> the R Core Team would be appreciated.
The people who do not read the help page also do not do what is suggested
to them on R-help, so how would this help? If you really think this is
an FAQ (as distinct from being asked over and over again by a single
person), you should submit an FAQ entry on it.
We already provide many simple ways, including menu items, for saving to
EPS.
--
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] read.table with ":" in column names (PR#8511)
Please do not report documented behaviour as a bug!
See the 'check.names' argument to read.table.
In your second example you are applying as.character to a data frame, and
you seem not to realize that. We specifically ask you NOT to use R-bugs
to ask questions. (What is happening is that you got the internal codes
of the factor columns, which is not what you intended. If you want
character columns, read them as such.)
On Fri, 20 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: emiel ver loren
> Version: 2.2.0
We do ask you not to send reports on obselete versions of R.
> OS: Windows XP
> Submission from: (NULL) (145.117.31.248)
>
>
> Dear R-community and developers,
>
> I have been trying to read in a tab delimeted file where the column names and
> the row names are of the form "GO:051" (gene ontology IDs). When using:
>
>> gomat<-read.table("test.txt")
>> colnames(gomat)[1]
> [1] "GO.051"
>> rownames(gomat)[1]
> [1] "GO:002"
>
> Which means that ":" is transformed into a "." !! This seems like Excel when
> it
> is trying to guess what I am really ment (and turning 1/1/1 into 1-1-2001).
>
> Furthermore, I found the following quite strange as well:
>
>> gomat2<-read.delim2("test.txt",header=FALSE)
>> gomat2[1,1:2]
> V1 V2
> 1 GO:051 GO:280
>> as.character(gomat2[1,1:2])
> [1] "8" "2"
>> as.character(gomat2[1,1])
> [1] "GO:051"
>
> I have found a way to work around it, but I am wandering what's happening
>
> The tab-delimited file look like:
>
> GO:051GO:280 GO:740
> GO:0020 0 0
> GO:0040 0 0
> GO:0120 0 0
> GO:0140 0 0
> GO:0150 0 0
> GO:0180 0 0
> GO:0190 0 0
>
> Thanks for helping, and
>
> Emiel
>
> __
> 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] (PR#8524) Report on obselete version of R (was example in
Please do not report on obselete versions of R. (See the section on Bugs in the FAQ, which specifically asks you not to.) R 2.2.1 and later use the correct labels(eurodist) On Fri, 27 Jan 2006 [EMAIL PROTECTED] wrote: > Full_Name: Joe Voelkel > Version: R 2.2.0 > OS: Windows > Submission from: (NULL) (67.139.200.41) > > > In ?plot.window, the example includes the argument > names(eurodist) > > in the text function. The argument should be > attr(eurodist,"Labels") -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pgamma - inadequate algorithm design and poor coding (PR#8528)
R versions 2.1.0 to present. Examples shown were computed under Windows R-devel, current SVN, but ix86 Linux shows similar behaviour (sometimes NaN or -Inf rather than Inf, depending on the compiler and optimization level used). The replacement pgamma algorithm used from R 2.1.0 has an inadequate design and no supporting documentation whatsoever. There is no reference given to support the algorithm, and it seems very desirable to use only algorithms with a published (and preferably refereed) analysis, or at least of impeccable provenance. The following errors were found by investigating an example in the d-p-q-r-tests.R regression tests that gave NaN on a real system. These errors were not present in R 2.0.0, which used a normal approximation in that region. We could fix this by reverting where needed to a normal approximation, but that leaves the problem that we have no proof of the validity or accuracy of the rest of the algorithm (if indeed it is accurate). ?pgamma says As from R 2.1.0 'pgamma()' uses a new algorithm (mainly by Morten Welinder) which should be uniformly as accurate as AS 239. Well, it 'should be' but it is not, and we should not be making statements like that. Those in the email quoted in pgamma.c exhibit hubris. There are also at least two examples of sloppy coding that lead to numeric overflow and complete loss of accuracy. Consider > pgamma(seq(0.75, 1.25, by=0.05)*1e100, shape = 1e100, log=T) [1] -3.768207e+98 NaN NaN NaN NaN [6] -6.931472e-01 NaN NaN NaN NaN [11] 0.00e+00 Warning message: NaNs produced in: pgamma(q, shape, scale, lower.tail, log.p) > pgamma(seq(0.75, 1.25, by=0.05)*1e100, shape = 1e100, log=T, lower=F) [1] 0.00e+00 NaN NaN NaN NaN [6] -6.931472e-01 Inf Inf Inf Inf [11] -2.685645e+98 Warning message: NaNs produced in: pgamma(q, shape, scale, lower.tail, log.p) > pgamma(c(1-1e-10, 1+1e-10)*1e100, shape = 1e100) [1] NaN NaN (shape=1e25 is enough to cause a breakdown in the first of these, and 1e60 in the rest.) The code has four branches 1) x <= 1 2) x <= alph - 1 && x < 0.8 * (alph + 50)). This has the comment /* incl. large alph */, but that is false. 3) if (alph - 1 < x && alph < 0.8 * (x + 50)). This has the comment /* incl. large x */, but again false. 4) The rest, which uses an asymptotic expansion in pt_ = -x * (log(1 + (lambda-x)/x) - (lambda-x)/x) = -x * log((lambda-x)/x) - (lambda-x) and naively assumes that this is small enough to use a power series expansion in 1/x with coefficients as powers of pt_. To make matters worse, consider > pgamma(0.9*1e25, 1e25, log=T) pgamma_raw(x=9e+024, alph=1e+025, low=1, log=1) using ppois_asymp() pt_ = 5.3605156578263e+022 pp*_asymp(): f=-2.0803930924076e-013 np=-5.3605156578263e+022 nd=-5.3605156578263e+022 f*nd=11151979746.284 [1] -Inf Hmm, how did that manage to lose *all* the accuracy here? Hubris again appears in the comments. Here np and nd are on log scale and if they are large they will be almost equal (and negative), and f is not large (and if it were we could have computed log f). So we can compute the log of np+f*nd accurately as log(np*(1+f*nd/np)) = lnp + log(1+f*nd/np) = lnp + log1p(f*exp(lnd-lnp)) Almost all the mass of gamma(shape=1e100) is concentrated at the nearest representable value to 1e100: > qgamma(c(1e-16, 1-1e-16), 1e100)-1e100 [1] 0 0 (if it can be believed, but this can be verified independently). So being accurate in the middle of the range is pretty academic, but one can at least avoid returning the nonsense of non-monotone cdfs and NaN/infinite probabilities. -- 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] Your false remark on PR#1654
The comment says `Works in 2.3.0: BDR fixed inline [xy]axp' and 2.2.1 is not 2.3.0. Your example is not reproducible, so we cannot check. If you get a copy of R-devel (as the FAQ and posting guide ask you to before posting) you can check for yourself. Please do study the FAQ and avoid time-wasting. On Sat, 28 Jan 2006 [EMAIL PROTECTED] wrote: > Full_Name: Kevin Cain > Version: 2.2.1 > OS: Windows XP > Submission from: (NULL) (128.95.124.144) > > > In the following command, R ignores the xaxp command - it places tick marks at > 1, 1.5, 2.0, etc regardless of what the third argument is (I want them only at > integer values). > > plot(x=c(min(time),max(time)),y=c(min(y-se),max(y+se)),type='n',xaxp=c(1,4,3), > xlab='Measurement Time Point', > ylab='Accelerometer Mean VMU/min') > > A prior bug report says this problem has been fixed (Graphics-fixed/1654), but > it looks like that referred to the unix version. > > __ > 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] R 2.1.1 installation fails under Suse 10.0 (PR#8533)
I am afraid
1) This is a message about an outdated version of R, and
2) The problem is most likely the compiler and the way it (mis)compiles
src/modules/lapack/dlamc.f. This is covered in the R-admin manual (which
INSTALL asked you to read). This said in 2.1.1
It seems that @samp{gcc 3.4.x} and later on @samp{ix86} Linux defeat
attempts by the LAPACK code to avoid computations entirely in
extended-precision registers, so file @file{src/modules/lapack/dlamc.f}
may need to be compiled without optimization. If configure detects
@acronym{GNU} Fortran it adds flag @option{-ffloat-store} which
suffices, but it is possible that @file{src/modules/lapack/Makefile}
will need to be edited to remove optimization on other platforms.
and the NEWS for 2.2.0 says
o src/modules/lapack/dlamc.f is now compiled with -ffloat-store
if f2c/gcc are used, as well as if g77 is used.
If the current version of R does not work for you, please ask a question
on R-devel describing exactly what you are using (you have not mentioned
your cpu type or your compilers, for example) and what the error messages
are.
On Sun, 29 Jan 2006 [EMAIL PROTECTED] wrote:
> Full_Name: Sigbert Klinke
> Version: 2.1.1
> OS: Suse Linux 10.0 (Full DVD)
> Submission from: (NULL) (141.20.100.252)
>
>
> Suse 10.0 installs only a Fortran 95 compiler
Which compiler is this? According to its man page, gfortran is *not* a
Fortran 95 compiler, and you have not mentioned what you think is.
(I don't believe there is a free F95 compiler for Linux.)
> with g77 compability mode. Using this leads in "configure" to an
> abortion with problems about "FPICFLAGS".
Which were? What happened when you set FPICFLAGS in config.site?
> Deinstalling g77 compatiblity
> mode, using f2c, compiles R. But after calling R() the program shows its
> entrance message and then hangs up, using 100% of the processor
> capacity.
>
> What finally works on my computer was setting a softlink from /usr/bin/g77 to
> gfortran such that the fortran 95 compiler was used directly during the R
> compilation.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Integer bit size and the modulus operator (PR#8541)
On Mon, 30 Jan 2006 [EMAIL PROTECTED] wrote:
> On 1/30/2006 1:39 PM, Ionut Florescu wrote:
>> Thank you for the quick reply, I will look into the R packages.
>> For crashing R try this:
>>
>> generator.zp=function(x,p)
>> {a=1:(p-1); b=x^a%%p;
>> if(all(b[1:(p-2)]!=1)&&(b[p-1]==1)){return(x, " Good ")}
>> else{return(x, " No Good, try another integer ")}
>> }
>
> Thanks, I can reproduce the crash using
>
> for (x in 10:100) generator.zp(x, 41)
>
> I'll see if I can track down what's going wrong. By the way, you're not
> supposed to use two arguments to return(): that's not supposed to be
> allowed any more. I'm somewhat surprised you don't get an error from
> it. But that's not the cause of the crash.
You do get a warning, though. It *is* allowed, see ?return.
One error is the following in real_binary:
if (n1 > n2)
copyMostAttrib(s1, ans);
else if (n1 == n2) {
copyMostAttrib(s2, ans);
copyMostAttrib(s1, ans);
}
else
copyMostAttrib(s2, ans);
Here ans is not PROTECTED.
The second is in the warning, which causes allocation when ans is not
protected.
Fixed in R-devel and 2.2.1 patched.
> Duncan Murdoch
>
>
>>
>> This checks if element x is a generator of the group Z_p. If you try
>> this function for p = 41 and x various increasing values eventually it
>> will crash R. That is what I meant by random, at first I started x=2,3
>> so on, when I got to 8, R crashed. Now apparently I can get to 15. When
>> I tried again I got to 20.
>>
>> Ionut Florescu
>>
>>
>> Duncan Murdoch wrote:
>>> On 1/30/2006 11:32 AM, Ionut Florescu wrote:
>>>> I am a statistician and I come up to an interesting problem in
>>>> cryptography. I would like to use R since there are some statistical
>>>> procedures that I need to use.
>>>> However, I run into a problem when using the modulus operator %%.
>>>>
>>>> I am using R 2.2.1 and when I calculate modulus for large numbers
>>>> (that I need with my problem) R gives me warnings. For instance if
>>>> one does:
>>>> a=1:40;
>>>> 8^a %% 41
>>>> one obtains zeros which is not possible since 8 to any power is not a
>>>> multiple of 41.
>>>> In addition when working with numbers larger that this and with the
>>>> mod operator R crashes randomly.
>>>
>>> Could you keep a record of the random crashes, and see if you can make
>>> any of them repeatable? R shouldn't crash. If you can find a
>>> repeatable way to make it crash, then that's a bug that needs to be
>>> fixed. (If it crashes at random it should still be fixed, but it's so
>>> much harder to fix that it's unlikely to happen unless the cases are
>>> ones that look likely to come up in normal situations.)
>>>
>>>
>>>>
>>>> I believe this is because R stores large integers as real numbers
>>>> thus there may be lack of accuracy when applying the modulus operator
>>>> and converting back to integers.
>>>>
>>>> So my question is this: Is it possible to increase the size of memory
>>>> used for storing integers? Say from 32 bits to 512 bits (Typical size
>>>> of integers in cryptography).
>>>
>>> No, but there is at least one contributed package that does multiple
>>> precision integer arithmetic. I can't remember the name of it right
>>> now, but Google should be able to find it for you...
>>>
>>> Duncan Murdoch
>>>>
>>>> Thank you, any help would be greatly appreciated.
>>>> Ionut Florescu
>>>>
>>>> __
>>>> R-help@stat.math.ethz.ch mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>> PLEASE do read the posting guide!
>>>> http://www.R-project.org/posting-guide.html
>>>
>>>
>
> __
> 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] [R] Integer bit size and the modulus operator (PR#8541)
On Mon, 30 Jan 2006, Prof Brian Ripley wrote:
> On Mon, 30 Jan 2006 [EMAIL PROTECTED] wrote:
>
>> On 1/30/2006 1:39 PM, Ionut Florescu wrote:
>>> Thank you for the quick reply, I will look into the R packages.
>>> For crashing R try this:
>>>
>>> generator.zp=function(x,p)
>>> {a=1:(p-1); b=x^a%%p;
>>> if(all(b[1:(p-2)]!=1)&&(b[p-1]==1)){return(x, " Good ")}
>>> else{return(x, " No Good, try another integer ")}
>>> }
>>
>> Thanks, I can reproduce the crash using
>>
>> for (x in 10:100) generator.zp(x, 41)
>>
>> I'll see if I can track down what's going wrong. By the way, you're not
>> supposed to use two arguments to return(): that's not supposed to be
>> allowed any more. I'm somewhat surprised you don't get an error from
>> it. But that's not the cause of the crash.
>
> You do get a warning, though. It *is* allowed, see ?return.
>
> One error is the following in real_binary:
>
>if (n1 > n2)
> copyMostAttrib(s1, ans);
>else if (n1 == n2) {
> copyMostAttrib(s2, ans);
> copyMostAttrib(s1, ans);
>}
>else
> copyMostAttrib(s2, ans);
>
> Here ans is not PROTECTED.
I think this one was a consequence of the other one. I did get a valgrind
error from there, but it looks as if copyMostAttrib does the necessary
protection, if ans has not already been damaged.
> The second is in the warning, which causes allocation when ans is not
> protected.
>
> Fixed in R-devel and 2.2.1 patched.
>
>
>> Duncan Murdoch
>>
>>
>>>
>>> This checks if element x is a generator of the group Z_p. If you try
>>> this function for p = 41 and x various increasing values eventually it
>>> will crash R. That is what I meant by random, at first I started x=2,3
>>> so on, when I got to 8, R crashed. Now apparently I can get to 15. When
>>> I tried again I got to 20.
>>>
>>> Ionut Florescu
>>>
>>>
>>> Duncan Murdoch wrote:
>>>> On 1/30/2006 11:32 AM, Ionut Florescu wrote:
>>>>> I am a statistician and I come up to an interesting problem in
>>>>> cryptography. I would like to use R since there are some statistical
>>>>> procedures that I need to use.
>>>>> However, I run into a problem when using the modulus operator %%.
>>>>>
>>>>> I am using R 2.2.1 and when I calculate modulus for large numbers
>>>>> (that I need with my problem) R gives me warnings. For instance if
>>>>> one does:
>>>>> a=1:40;
>>>>> 8^a %% 41
>>>>> one obtains zeros which is not possible since 8 to any power is not a
>>>>> multiple of 41.
>>>>> In addition when working with numbers larger that this and with the
>>>>> mod operator R crashes randomly.
>>>>
>>>> Could you keep a record of the random crashes, and see if you can make
>>>> any of them repeatable? R shouldn't crash. If you can find a
>>>> repeatable way to make it crash, then that's a bug that needs to be
>>>> fixed. (If it crashes at random it should still be fixed, but it's so
>>>> much harder to fix that it's unlikely to happen unless the cases are
>>>> ones that look likely to come up in normal situations.)
>>>>
>>>>
>>>>>
>>>>> I believe this is because R stores large integers as real numbers
>>>>> thus there may be lack of accuracy when applying the modulus operator
>>>>> and converting back to integers.
>>>>>
>>>>> So my question is this: Is it possible to increase the size of memory
>>>>> used for storing integers? Say from 32 bits to 512 bits (Typical size
>>>>> of integers in cryptography).
>>>>
>>>> No, but there is at least one contributed package that does multiple
>>>> precision integer arithmetic. I can't remember the name of it right
>>>> now, but Google should be able to find it for you...
>>>>
>>>> Duncan Murdoch
>>>>>
>>>>> Thank you, any help would be greatly appreciated.
>>>>> Ionut Florescu
>>>>>
>>>>> __
>>>>> R-help@stat.math.ethz.ch mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>>> PLEASE do read the posting guide!
>>>>> http://www.R-project.org/posting-guide.html
>>>>
>>>>
>>
>> __
>> 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
>
--
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] recover() (PR#8546)
Why are you calling recover() at the browse() prompt? What the help page says is When finished browsing in this call, type 'c' to return to 'recover' from the browser. Type another frame number to browse some more, or type '0' to exit 'recover'. You can also type Q in the browser. You seem never to have typed 'c' as instructed. On Wed, 1 Feb 2006 [EMAIL PROTECTED] wrote: > After using options(error=recover), > it takes a long time (too long) to get back > to the prompt. Look at: > > Browse[1]> recover() > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > 5: function () > 6: eval(quote(browser()), envir = sys.frame(which)) > 7: eval(expr, envir, enclos) > > Selection: recover() > Enter an item from the menu, or 0 to exit > Selection: 0 > Browse[1]> recover() > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > 5: function () > 6: eval(quote(browser()), envir = sys.frame(which)) > 7: eval(expr, envir, enclos) > > Selection: 0 > Browse[1]> recover() > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > 5: function () > 6: eval(quote(browser()), envir = sys.frame(which)) > 7: eval(expr, envir, enclos) > > Selection: 0 > Browse[1]> recover() > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > 5: function () > 6: eval(quote(browser()), envir = sys.frame(which)) > 7: eval(expr, envir, enclos) > > Selection: 0 > Browse[1]> recover() > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > 5: function () > 6: eval(quote(browser()), envir = sys.frame(which)) > 7: eval(expr, envir, enclos) > > Selection: 0 > Browse[1]> > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > > Selection: 0 > > > > I had to type 0 [to exit] 6 times to actually > exit! > > > Kjetil > > (windows, R2.2.1 from CRAN) > > __ > 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] window() problem (PR#8545)
This was never intended to work, but can easily be programmed in. I have done so for R-devel. On Wed, 1 Feb 2006 [EMAIL PROTECTED] wrote: > window() does not work correctly when called with extend=TRUE and > the new time range intersect null with the old time range! Maybe this is > really a feature request, but the documentation does not say what to > expect in this case. > > This case does occur in programming! It is hard to see that it would not be known about in advance. > This is R2.2.1 on windows, latest compiled from CRAN. > > Look at the excerps below: > > > test <- ts(1:144, start=c(1,1), frequency=12) > > tsp(test) > [1] 1.0 12.91667 12.0 > > test2 <- window(test, start=c(5,1), end=c(16,4), extend=TRUE) > > test2 >Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec > 5 49 50 51 52 53 54 55 56 57 58 59 60 > 6 61 62 63 64 65 66 67 68 69 70 71 72 > 7 73 74 75 76 77 78 79 80 81 82 83 84 > 8 85 86 87 88 89 90 91 92 93 94 95 96 > 9 97 98 99 100 101 102 103 104 105 106 107 108 > 10 109 110 111 112 113 114 115 116 117 118 119 120 > 11 121 122 123 124 125 126 127 128 129 130 131 132 > 12 133 134 135 136 137 138 139 140 141 142 143 144 > 13 NA NA NA NA NA NA NA NA NA NA NA NA > 14 NA NA NA NA NA NA NA NA NA NA NA NA > 15 NA NA NA NA NA NA NA NA NA NA NA NA > 16 NA NA NA NA > > tsp(test2) > [1] 5.00 16.25 12.00 > > test3 <- window(test, start=c(15,1), end=c(17,1), extend=TRUE) > Error in window.default(x, ...) : invalid time series parameters specified > > Enter a frame number, or 0 to exit > > 1: window(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 2: window.ts(test, start = c(15, 1), end = c(17, 1), extend = TRUE) > 3: as.ts(window.default(x, ...)) > 4: window.default(x, ...) > > Selection: 4 > Called from: eval(expr, envir, enclos) > Browse[1]> x >Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec > 11 2 3 4 5 6 7 8 9 10 11 12 > 2 13 14 15 16 17 18 19 20 21 22 23 24 > 3 25 26 27 28 29 30 31 32 33 34 35 36 > 4 37 38 39 40 41 42 43 44 45 46 47 48 > 5 49 50 51 52 53 54 55 56 57 58 59 60 > 6 61 62 63 64 65 66 67 68 69 70 71 72 > 7 73 74 75 76 77 78 79 80 81 82 83 84 > 8 85 86 87 88 89 90 91 92 93 94 95 96 > 9 97 98 99 100 101 102 103 104 105 106 107 108 > 10 109 110 111 112 113 114 115 116 117 118 119 120 > 11 121 122 123 124 125 126 127 128 129 130 131 132 > 12 133 134 135 136 137 138 139 140 141 142 143 144 > Browse[1]> tsp(x) > [1] 1.0 12.91667 12.0 > Browse[1]> y > [1] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA > NA NA NA NA NA NA NA NA NA > [32] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA > Browse[1]> tsp(y) > NULL > Browse[1]> > > As one can see from the above, the calculated answer y does not have a > tsp attribute. > > Kjetil > > __ > 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] R 2.2.1 installation trouble on SGI/Sun (PR#8575)
Please do not send questions to R-bugs (especially as well as to R-devel).
The thing you are getting as "" is from (see doc/Makefile)
$(INSTALL_DATA) $(srcdir)/$${f} "$(rdocdir)"; \
What is rdocdir set to in Makeconf? It (and related quantities) should be
rhome = ${libdir}/R
rsharedir = ${rhome}/share
rincludedir = ${rhome}/include
rdocdir = ${rhome}/doc
unless you set something non-standard during configure. (If you did not,
the code is very simple and anything else here would seem to indicate a
bug in the shell used, but please debug it.)
Solaris 7 is very old: this does work on Solaris 8 (from where I copied
the above). You can always specify it on the make install line (as
described in the R-admin manual you were pointed to).
On Wed, 8 Feb 2006 [EMAIL PROTECTED] wrote:
> Hi,
>
> I'm upgrading to R 2.2.1 and have bumped into some problems.
>
> I have been successful with installing on x86 and PPC Linux, but am
> unable to install R on Solaris 7 and on IRIX 6.5. Configuration
> and compilation go through just fine, but "make install" fails:
>
> gmake[1]: Entering directory `/scratch/atossava/R-2.2.1/doc'
> installing doc ...
> ../tools/install-sh: no destination specified.
> ../tools/install-sh: no destination specified.
> ../tools/install-sh: no destination specified.
> gmake[1]: *** [install-sources] Error 1
> gmake[1]: Leaving directory `/scratch/atossava/R-2.2.1/doc'
> gmake: *** [install] Error 1
>
> Running "gmake -n install" reveals this is because:
>
> echo "installing doc ..."
> /bin/ksh ../src/scripts/mkinstalldirs ""
> /bin/ksh ../src/scripts/mkinstalldirs
> /afs/bi/v/sun4x_57/apps/stats/R/2.2.1/man/man1
> for f in CRAN_mirrors.csv KEYWORDS KEYWORDS.db; do \
> ../tools/install-sh -c -m 644 ./${f} ""; \
> done
>
> Any ideas what might be causing "" to appear as the destination directory?
>
> --
> Atro Tossavainen (Mr.) / The Institute of Biotechnology at
> Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
> +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
> < URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
>
> __
> 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] identify() bug (PR#8576)
Please do not use R-bugs to ask questions. Well under half the traffic on R-bugs is related to actual bug reports. On Wed, 8 Feb 2006 [EMAIL PROTECTED] wrote: > Full_Name: Vladan Arsenijevic > Version: 2.2.1 > OS: linux/gentoo > Submission from: (NULL) (193.136.128.14) > > > I have a vector of floats that I want to assign to a set of the points in the > plot with identify(). When I print the vector, it appears with a certain > precision (let's say 2 decimal places), while in the plot it gets 12 more. > For example 8.97 turns to 8.970025. Any hint? The 'labels' are character strings and as.character is using the full precision of your numbers. If you do not want what you asked for, ask for something else, e.g. via round() or format(). -- 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] Inconsistent documentation in Writing R Extensions (PR#13878)
On Thu, 6 Aug 2009, brandon.j.whitc...@gsk.com wrote: > Greetings, > > I think there is an inconsistency in the Writing R Extensions document. > Please let me know if I am right or wrong on this one. > > Working from the PDF document (R-exts-2.9.1.pdf) > > - page 9 states that the file -Ex.Rout.save should be placed in > tests/Examples in order to check against the current set of examples. > - page 17 (item 16) states that the file -Ex-Rout.save should be > placed in tests/Examples. > > I have checked in one of my packages, and I believe the first case > -Ex.Rout.save is correct. Is this true? Yes. > > cheers... > > Brandon > > > --- > This e-mail was sent by GlaxoSmithKline Services Unlimited > (registered in England and Wales No. 1047315), which is a > member of the GlaxoSmithKline group of companies. The > registered address of GlaxoSmithKline Services Unlimited > is 980 Great West Road, Brentford, Middlesex TW8 9GS. > --- > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] names<- in data.frame (PR#13916)
It does work correctly:
> names(tdf)
[1] "" ""
The thing you have overlooked is that data frames are required to have
non-empty (not 'zero-length': yours has length 2) names, and the print
method has created some (as data.frame will if you give unnamed
arguments).
Please be careful to distinguish between an object and its printed
representation.
On Fri, 28 Aug 2009, vitosm...@rambler.ru wrote:
> Full_Name: Spinu Vitalie
> Version: 2.9.0
> OS: Windows
> Submission from: (NULL) (130.115.113.15)
>
>
> In assignment of "zero length" names to data.frame:
>
>> tdf <- data.frame(rbind(c(1, 2), c(1, 2)))
>> names(tdf) <- c("", "")
>> tdf
> structure(c("1", "1"), class = "AsIs") structure(c("2", "2"), class = "AsIs")
> 1 1
> 2
> 2 1
> 2
>
> For vectors it works nicely:
>
>> tv <- c(1, 2)
>> names(tv) <- c("", "")
>> tv
>
> 1 2
>
>
>
>
>> sessionInfo()
> R version 2.9.0 (2009-04-17)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics uti
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] OS X PDF bug (PR#13943)
On Mon, 7 Sep 2009, paul.m.mcguire...@att.net wrote: No graphics device is specified here: which was it? My guess is quartz() and that this is nothing to do with R but with copying in Mac OS X from a quartz() window. > par(mfrow=c(2,2)) > y<-1:20 > plot(y, pch="+") > plot(y, pch="+") > plot(y, pch="+") > plot(y, pch="+") > > produces a pdf that is viewable in Preview (copied from the > clipboard) but fails to print. > > pch default or ="." or =3 prints. > > Unfortunately pch=3 doesn't fix the mfrow=c(5,6) graph that I'm > actually trying to print, > so the bug lies somewhere deeper. Why not use pdf()? That works for me (but then I don't have your printer drivers). > OS X 10.4.11 > R 2.9.2 GUI 1.29 Tiger build 32-bit (5464) > Laserjet 5MP > > Paul McGuire -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] 'make install' fails on Solaris (PR#13946)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-1085614336-1252597171=:13955
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
I can see what has happened: one of the paths contains : as Peter
suggested. By not why, and there seem to be more wrong with it: look
at the lines I've enclosed in ===. There is no space after -Rblas,
and other odd things, so changing the sed script would not help here.
As Peter say, -Wlfoo,bar is just as likely as : in there if things go
this badly wrong. (Of course mailer may have garbled this.)
I have
STATIC_LIBR_PC = $(BLAS_LIBS) $(FLIBS) $(LIBINTL) -lreadline -ltermcap $(LIBS)
and nothing strange in the expansion.
Try not using --enable-R-static-lib.
What we could do it to allow the script to fail: having libR.pc is a
convenience, and --enable-R-static-lib is rarely used.
On Thu, 10 Sep 2009, Bob Bownes wrote:
> Sorry, typo.
>
> Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed. Here
> is the error:
>
> bash-3.00# make install
> installing doc ...
> ../tools/install-sh -c -m 644 ../NEWS
> "/home/dev/scratch/bbownes/R/lib/R/doc"
> installing doc/html ...
> installing doc/html/search ...
> installing doc/manual ...
> installing etc ...
> installing share ...
> cc -I. -I../../src/include -I../../src/include -I/usr/local/include
> -DHAVE_CONFIG_H -g -DR_HOME='"/home/dev/scratch/bbownes/R/lib/R"' -o
> Rscript \
> ./Rscript.c
> sed: command garbled: s:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
===
> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
===
> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm -lnsl -lsocket -ldl -lm
> -licuuc -licui18n:
> *** Error code 2
> The following command caused the error:
> /usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
> "s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
> -e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm -lnsl -lsocket -ldl -lm
> -licuuc -licui18n:' \
> -e 's/@VERSION/2.9.2/' ./libR.pc.in \
> > "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
> make: Fatal error: Command failed for target `install-pc'
> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
> *** Error code 1
> The following command caused the error:
> for d in scripts include extra appl nmath unix main modules library; do \
> (cd ${d} && make install) || exit 1; \
> done
> make: Fatal error: Command failed for target `install'
> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
> *** Error code 1
> The following command caused the error:
> for d in m4 tools doc etc share src tests po; do \
> (cd ${d} && make install) || exit 1; \
> done
> make: Fatal error: Command failed for target `install'
> bash-3.00#
>
> and the configure that started it all:
> ./configure --with-readline=no --with-iconv=no --with-x=no
> --enable-static=yes --enable-R-static-lib
> --prefix=/home/dev/scratch/bbownes/R
>
>
>
>
> On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard
> wrote:
> Prof Brian Ripley wrote:
> On Thu, 10 Sep 2009, bow...@gmail.com wrote:
>
> Full_Name: Bob Bownes
> Version: 2.9.2
> OS: Solaris 10
> Submission from: (NULL) (164.55.254.106)
>
>
> The sed lines in src/unix/Makefile
> confuse the grep distributed with
> Solaris
> that gets configured by ./configure.
>
>
> Well, it calls sed not grep! Which version was that
> -- it works for me and for several others. I have
> SED = /usr/xpg4/bin/sed (see file Makeconf), and
>
[Rd] Detaching one package can remove the S4 methods of another (PR#14087)
Putting on public record
library(spdep)
showMethods("[")
detach("package:spdep", unload = TRUE)
detach("package:Matrix", unload=TRUE)
showMethods("[") # sp methods still there
detach("package:spam", unload = TRUE)
showMethods("[") # sp methods have gone
This is one of several examples found by package testing in R-devel
(this one from BayesX) with _R_CHECK_UNLOAD_NAMESPACES_ set.
Session info after the first command:
R version 2.10.0 Patched (2009-11-23 r50545)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_GB.utf8 LC_NUMERIC=C
[3] LC_TIME=en_GB.utf8LC_COLLATE=C
[5] LC_MONETARY=C LC_MESSAGES=en_GB.utf8
[7] LC_PAPER=en_GB.utf8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] spdep_0.4-52 nlme_3.1-96coda_0.13-4MASS_7.3-4
[5] Matrix_0.999375-32 lattice_0.17-26spam_0.15-5boot_1.2-41
[9] maptools_0.7-26foreign_0.8-38 sp_0.9-47 deldir_0.0-10
loaded via a namespace (and not attached):
[1] grid_2.10.0
Happens also in 2.10.0 and
R version 2.11.0 Under development (unstable) (2009-11-25 r50568)
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] Long execution time for quantile() and difftime objects (PR#14092)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27501778-1317196171-1259330723=:5696
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID:
Did you read the help page?
x: numeric vector whose sample quantiles are wanted. ¡NA¢ and
¡NaN¢ values are not allowed unless ¡na.rm¢ is ¡TRUE¢.
so only 'numeric' vectors are really supported, although it does say
The default method does not allow factors, but works with objects
sufficiently like numeric vectors that ¡sort¢, addition and
multiplication work correctly. In principle only sorts and
weighted means are needed, so datatimes could have quantiles - but
this is not implemented.
There is no claim that it works (let alone works well) for class
"difftime". If you follow the link to 'sort' it says
The default ¡sort¢ method makes use of ¡order¢ for objects with
classes, which in turn makes use of the generic function ¡xtfrm¢.
and from ?xtfrm
The default method will make use of ¡==¢ and ¡>¢ methods for the
class of ¡x[i]¢ (for integers ¡i¢), and the ¡is.na¢ method for the
class of ¡x¢, but might be rather slow when doing so.
So, if you want this to be fast, you need to write an xtfrm method.
There is one in R-devel
> xtfrm.difftime
function (x)
as.numeric(x)
and you can use that in your workspace (and your example is fast in
R-devel, because of that function I think, there being other
development work in progress in the version I tried).
On Fri, 27 Nov 2009, hong@anz.com wrote:
> Full_Name: Hong Ooi
> Version: 2.10.0
> OS: Windows XP
> Submission from: (NULL) (203.110.235.1)
>
>
> While trying to get summary statistics on a duration variable (the difference
> between a start and end date), I ran into the following issue. Using summary
> or
> quantile (which summary calls) on a difftime object takes an extremely long
> time
> if the object is even moderately large.
>
> A reproducible example:
>
>> x <- as.Date(1:1, origin="1900-01-01")
>> x[1:10]
> [1] "1900-01-02" "1900-01-03" "1900-01-04" "1900-01-05" "1900-01-06"
> [6] "1900-01-07" "1900-01-08" "1900-01-09" "1900-01-10" "1900-01-11"
>> d <- x - as.Date("1900-01-01")
>> d[1:10]
> Time differences in days
> [1] 1 2 3 4 5 6 7 8 9 10
>> system.time(summary(d[1:10]))
> user system elapsed
> 0.010.000.01
>> system.time(summary(d[1:100]))
> user system elapsed
> 0.210.000.20
>> system.time(summary(d[1:1000]))
> user system elapsed
> 3.020.003.02
>> system.time(summary(d[1:1]))
> user system elapsed
> 43.560.04 43.66
>
>
> If I unclass d, there is no problem:
>
>> system.time(summary(unclass(d[1:1])))
> user system elapsed
> 0 0 0
>
> Testing with Rprof() indicates that the problem lies in [.difftime, although
> the
> code for that function seems innocuous enough.
>
>
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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
--27501778-1317196171-1259330723=:5696--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#14103) read.csv confused by newline characters in
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-536455723-1259929222=:18586
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID:
It's not to do with pushback per se. The works as one might expect,
e.g.
f <- file("test.txt", "r")
pushBack('"A1\nA2"', f)
pushBackLength(f)
scan(f, "", quote='"')
gives "A1\nA2" on a single line, then whatever was in test.txt.
Rather, the issue is
if (header) {
readLines(file, 1L) # skip over header
and that stops at the embedded newline. The fix is to read the header
again the same way as before.
It seems to me that this is esoteric and the fix could tickle similar
esoteric constructions, so I am only going to put the fix into R-devel
and not the upcoming 2.10.1.
On Wed, 2 Dec 2009, Peter Dalgaard wrote:
> g.russ...@eos-solutions.com wrote:
>> Full_Name: George Russell
>> Version: 2.10.0
>> OS: Microsoft Windows XP Service Pack 2
>> Submission from: (NULL) (217.111.3.131)
>>
>>
>> The following code (typed into R --vanilla)
>>
>> testString <- '"B1\nB2"\n1\n'
>> con <- textConnection(testString)
>> tab <- read.csv(con,stringsAsFactors = FALSE)
>>
>> produces a data frame with with one row and one column; the name of the
>> column
>> is "B1.B2" (alright so far). However according to
>> print(tab[[1,1]])
>>
>> the value of the entry in the first row and first column is
>>
>> "B2\n1\n"
>>
>> So B2 has somehow got into both the names of the data frame and its entry.
>> Either R is confused or I am. What is going on?
>
> Presumably, read.table is not obeying quotes when removing what it
> thinks is the header line. Another variation is this:
>
>> tab <- read.table(stdin(), head=T)
> 0: "B1
> 0: B2"
> 1: 1
> 2:
>> tab
> B1.B2
> 1 B2"
> 2 1
>
>
> It's somehow connected to the
>
> pushBack(c(lines, lines), file)
>
> bits in readtable.R, but I don't quite get it.
>
> --
> 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
> ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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
--27464147-536455723-1259929222=:18586--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash with Unicode and sub (PR#14114)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-153156736-1260394708=:548
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID:
It seems (from the debugger output) that this is corruption in the R
memory allocation routines. Such things can usually be tracked down
via valgrind and a valgrind-instrumented build of R, but I cannot
trigger this on any system with valgrind. I've tried 64- and 32-bit
versions, and Latin-1 locales as well as UTF-8.
So I am inclining to think this is Windows-specific. One thing that
is specific to Windows is UCS-2 (16-bit) wide characters, which might
be the issue. But we simply don't have the tools on Windows that we
do on other platforms.
On Wed, 9 Dec 2009, g.russ...@eos-solutions.com wrote:
> Hello Peter,
>
> I have now installed R-2.10.1 RC (sessionInfo() says "R version 2.10.1 RC
> (2009-12-06 r50684)", the rest I believe is as before). The following code
> always brings R --vanilla down (with a crash, not a normal exit):
> -- cut here --
> gctorture()
> u <- intToUtf8(c(rep(1e3,1e2),32,c(rep(1e3,1e2
> v <- rep(u,1e2)
> v <- sub(" ","",v)
> v %in% ""
> q()
> -- cut here --
>
> I've tried this several times now, with different effects. Sometimes R
> crashes after 'v %in% ""'. Sometimes it survives that command, but crashes
> during the q(). I have also had the error message "Fehler in match(x,
> table, nomatch = 0L) > 0L : Vergleich (6) ist nur für atomare und
> Listentypen möglich" from that command (the match seems to be the
> problem), when I type q() R still crashes.
>
> Best wishes,
>
> George Russell | KG EOS Holding GmbH & Co
>
> Tel: +49 40 2850 â 1574 | g.russ...@eos-solutions.com
>
> EOS. With head and heart in finance
>
> KG EOS Holding GmbH & Co | Steindamm 71, 20099 Hamburg | AG Hamburg HRA 95
> 748
> Persönlich haftend | EOS Holding GmbH | AG Hamburg HRB 78 748
> Geschäftsführer | Hans-Werner Scherer, Klaus Engberding, Justus
> Hecking-Veltman, Paul Leary sen., Christos Savvides, Dr. Andreas Witzig
> Vorsitzender des Beirates | Jürgen Schulte-Laggenbeck
>
> Save a tree. Donât print this email unless itâs really necessary.
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This email may contain confidential and/or privileged information.
> If you are not the intended recipient or have received this email in
> error, please notify the sender immediately and destroy this email.
> Any unauthorized copying, disclosure or distribution of the material in
> this email is strictly forbidden.
>
> Peter Dalgaard schrieb am 08.12.2009 11:24:50:
>
>> g.russ...@eos-solutions.com wrote:
>>> Full_Name: George Russell
>>> Version: 2.10.0
>>> OS: Windows XP Version 2002 SP 2
>>> Submission from: (NULL) (217.111.3.131)
>>>
>>>
>>> The following typed into R --vanilla induces a crash:
>>> -- cut here --
>>> gctorture()
>>> u <- intToUtf8(c(rep(1e3,1e2),32,c(rep(1e3,1e2
>>> v <- rep(u,1e2)
>>> v <- sub(" ","",v)
>>> v %in% ""
>>> -- cut here --
>>>
>>> sessionInfo() says:
>>>
>>> -- cut here --
>>> R version 2.10.0 (2009-10-26)
>>> i386-pc-mingw32
>>>
>>> locale:
>>> [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252
>>> [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
>>> [5] LC_TIME=German_Germany.1252
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices datasets utils methods base
>>> -- cut here --
>>>
>>> I apologise for not testing this with R-2.10.1 but as far as I can
>> see there are
>>> only source releases available so far, which I am not able to compile.
>>>
>>
>> 2.10.1 RC is available now. Please check. It does seem to be
>> reproducible in the Windows version, or at least it takes a very long
>> time, but that means running under Wine on SUSE for me. I don't see the
>> effect with the Linux build.
>>
>> --
>>O__ Peter Dalgaard Ãster Farimagsgade 5, Entr.B
>>
Re: [Rd] Incorrect Kendall's tau for ordered variables (PR#14207)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-2083486994-1265648951=:12668
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Mon, 8 Feb 2010, Peter Dalgaard wrote:
> m...@biostat.mgh.harvard.edu wrote:
>> Full_Name: Marek Ancukiewicz
>> Version: 2.10.1
>> OS: Linux
>> Submission from: (NULL) (74.0.49.2)
>>
>>
>> Both cor() and cor.test() incorrectly handle ordered variables with
>> method="kendall", cor() incorrectly handles ordered variables for
>> method="spearman" (method="person" always works correctly, while
>> method="spearman" works for cor.test, but not for cor()).
>>
>> In erroneous calculations these functions ignore the inherent ordering
>> of the ordered variable (e.g., '9'<'10'<'11') and instead seem to assume
>> an alphabetic ordering ('10'<'11'<'9').
>
> Strictly speaking, not a bug, since the documentation has
>
> x: a numeric vector, matrix or data frame.
>
> respectively
>
>x, y: numeric vectors of data values. âxâ and âyâ must have the
> same length.
>
> so noone ever claimed that class "ordered" variables should work.
>
> However, the root cause is that as.vector on a factor variable (ordered
> or not) converts it to a character vector, hence
>
>> rank(as.vector(as.ordered(9:11)))
> [1] 3 1 2
>
> Looks like a simple fix would be to use as.vector(x, "numeric") inside
> the definition of cor().
A fix for that particular case: the problem is that relies on the
underlying representation. I think a better fix would be to do either
of
- test for numeric and throw an error otherwise, or
- use xtfrm, which has the advantage of being more general and
allowing methods to be written (S3 or S4 methods in R-devel).
>
>
>>> cor(9:11,1:3,method="k")
>> [1] 1
>>> cor(as.ordered(9:11),1:3,method="k")
>> [1] -0.333
>>> cor.test(as.ordered(9:11),1:3,method="k")
>>
>> Kendall's rank correlation tau
>>
>> data: as.ordered(9:11) and 1:3
>> T = 1, p-value = 1
>> alternative hypothesis: true tau is not equal to 0
>> sample estimates:
>>tau
>> -0.333
>>
>>> cor(9:11,1:3,method="s")
>> [1] 1
>>> cor(as.ordered(9:11),1:3,method="s")
>> [1] -0.5
>>> cor.test(as.ordered(9:11),1:3,method="s")
>>
>> Spearman's rank correlation rho
>>
>> data: as.ordered(9:11) and 1:3
>> S = 0, p-value = 0.
>> alternative hypothesis: true rho is not equal to 0
>> sample estimates:
>> rho
>> 1
>>
>> ______
>> 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
> ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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
--27464147-2083486994-1265648951=:12668--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in loadNamespace(name) (PR#9464)
It does not help, except to show that your original report was not a
true reflection of the situation, and that you are not willing to give
the more information that we did ask for, namely the saved image.
When I do what you said you did, there is no reference to 'lattice' in the
saved image.
It seems likely that
1) Your Windows setup is not factory-fresh in ways that you have not told
us.
2) Your 'Lunix' setup is broken, as Peter Dalgaard suggested.
I am going to close this non-bug report.
On Sat, 27 Jan 2007, Ross Darnell wrote:
> Thank you for your reply. There is some more information that may help your
> reproduce the error.
>
> The .RData file was generated under MSWindows. I started with an empty
> workspace and generated an object by
>
> y <- runif(200)
>
> or very similar.
>
> the quit, saving the workspace. (NTFS partition)
>
> I then logged out of Windows, logged into Lunix (Ubuntu Edgy Eft), cd'ed to
> where the .RData file lived and tried to start R.
>
> I have had the same experience with larger (real) workspaces. If I remove the
> .RData file there is no problem.
>
> Regards
> Ross Darnell
>
>
>
> Prof Brian Ripley wrote:
>> There is nothing here to reproduce.
>> It clearly depends on your .RData, which is not available to us.
>> Unless you can make it available, we cannot help.
>>
>> On Thu, 25 Jan 2007, [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: Ross Darnell
>>> Version: 2.4.1
>>> OS: Linux
>>> Submission from: (NULL) (130.102.133.33)
>>>
>>>
>>> [EMAIL PROTECTED]:~/Data$ ls -al .RData
>>> -rwxrwxrwx 2 root root 13551 2006-12-06 08:58 .RData
>>> [EMAIL PROTECTED]:~/Data$ R
>>>
>>> R version 2.4.1 (2006-12-18)
>>> Copyright (C) 2006 The R Foundation for Statistical Computing
>>> ISBN 3-900051-07-0
>>>
>>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>>> You are welcome to redistribute it under certain conditions.
>>> Type 'license()' or 'licence()' for distribution details.
>>>
>>> Natural language support but running in an English locale
>>>
>>> R is a collaborative project with many contributors.
>>> Type 'contributors()' for more information and
>>> 'citation()' on how to cite R or R packages in publications.
>>>
>>> Type 'demo()' for some demos, 'help()' for on-line help, or
>>> 'help.start()' for an HTML browser interface to help.
>>> Type 'q()' to quit R.
>>>
>>> Error in loadNamespace(name) : there is no package called 'lattice'
>>> Fatal error: unable to restore saved data in .RData
>>>
>>> [EMAIL PROTECTED]:~/Data$ R --no-restore-data
>>>
>>>> load(".RData")
>>> Error in loadNamespace(name) : there is no package called 'lattice'
>>>
>>>
>>>
>>> --please do not edit the information below--
>>>
>>> Version:
>>> platform = i486-pc-linux-gnu
>>> arch = i486
>>> os = linux-gnu
>>> system = i486, linux-gnu
>>> status =
>>> major = 2
>>> minor = 4.1
>>> year = 2006
>>> month = 12
>>> day = 18
>>> svn rev = 40228
>>> language = R
>>> version.string = R version 2.4.1 (2006-12-18)
>>>
>>> Locale:
>>> LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=en_AU.UTF-8;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
>>>
>>>
>>> Search Path:
>>> .GlobalEnv, package:stats, package:graphics, package:grDevices,
>>> package:utils,
>>> package:datasets, package:methods, 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] Makevars PKG_LIBS ignored by SHLIB (PR#9473)
This is a report on an obsolete version of R, on a problem that existed in _only_ that version and has already been fixed in the current release (and in R-patched before it). Please learn the courtesy and respect that both the posting guide and FAQ ask for in not abusing the project's resources in this way. On Fri, 26 Jan 2007, [EMAIL PROTECTED] wrote: > Full_Name: Rick Sayre > Version: 2.4.0 > OS: Windows > Submission from: (NULL) (138.72.27.164) > > > PKG_LIBS works fine on *nix > on windows, it seems to be ignored by the "SHLIB" script > so, R CMD SHLIB blah > properly uses PKG_CPPFLAGS and PKG_CFLAGS from Makevars, but PKG_LIBS is > ignored > > __ > 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] plot.lm (PR#9474)
There is nothing to reproduce here. Please supply a self-contained, commented, reproducible example. On Sun, 28 Jan 2007, [EMAIL PROTECTED] wrote: > Full_Name: Robert Kushler > Version: 2.4.1 > OS: Windows XP > Submission from: (NULL) (69.245.71.40) > > > > In the constant leverage case, plot #5 is not correctly produced. > The labels on the x-axis are sorted correctly by magnitude of the > fitted value, but the data are plotted in the original factor order. > > I changed >facval[ord] <- facval >xx <- facval >plot(facval, rs, xlim = c(-1/2, sum((nlev - 1) * > > to > # facval[ord] <- facval >xx <- facval[ord] >plot(xx, rs, xlim = c(-1/2, sum((nlev - 1) * > > in the "if (isConst.hat)" section of "show[5]". The data then > plotted correctly but the extreme point labels did not move. > I'm not up to the task of figuring out how to fix the labels, and > there might be other side effects of the change I made. In any > case, something needs to be done. > > Thanks for your attention (and thanks for a wonderful software system). > > Regards,Rob Kushler > > ______ > 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] misspelling - intension (PR#9470)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1141997210-1170077752=:21657 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT But not in the SVN trunk (R 2.3.1 is long obsolete). https://svn.r-project.org/R/trunk/src/library/methods/man/setClass.Rd A concerted effort on spelling was made a few weeks ago, in R-devel (not that 'intension' is not a correct spelling). On Thu, 25 Jan 2007, [EMAIL PROTECTED] wrote: > Full_Name: Nathan Coulter > Version: R-2.3.1 > OS: Linux > Submission from: (NULL) (148.168.40.4) > > > On page 827 of the Reference Index, "intention" is spelled as "intension": > > Another variety of extension starts with one of the built-in data types, > perhaps > with the intension of > modifying Rs standard behavior for that class. > > __ > 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 --27464147-1141997210-1170077752=:21657-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes when used from within rpy (PR#9481)
This is not the address for bug reports on 'rpy'. Your example works in R. On Tue, 30 Jan 2007, [EMAIL PROTECTED] wrote: > Full_Name: Jose Gaetan Pierre > Version: 2.4.1 > OS: Fedora Core 6 > Submission from: (NULL) (196.27.87.14) > > > I have been using R from within rpy for a while because I am more familiar > with > Python syntax. I first noticed this bug with R-2.4.0. > Screendump: -- >>>> from rpy import * >>>> beer = r.scan() > 1: 3 4 1 1 3 4 3 3 1 3 2 1 2 1 2 3 2 3 1 1 1 1 4 3 1 > 26: > Read 25 items >>>> c = r.table(beer) >>>> c > array([10, 4, 8, 3]) >>>> r.pie(c) >>>> Error during wrapup: C stack usage is too close to the limit > > *** caught segfault *** > address (nil), cause 'memory not mapped' > > Possible actions: > 1: abort (with core dump) > 2: normal R exit > 3: exit R without saving workspace > 4: exit R saving workspace > Selection: 3 > 3 >>>> > End of screendump > > R crashes when the mouse is dragged onto the graphics display. > > The version of rpy I am using is rpy-1.0-RC2. > > Please note that I also have the same problem on OpenSuSe-10.2. > > It does not matter whether I install R using provided rpm packages for the > respective Linux system or whether I compile R myself. > > > Many thanks for your attention. > > Jose G Pierre > > ______ > 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] Bug in 'pchisq' for x=0.0 (PR#9485)
Please do not report on obsolete versions of R! From the changes from 2.4.1: o pchisq() would sometimes use the wrong tail when calculating non-central probabilities with lower.tail = FALSE. (PR#9406) You are quite explicitly asked not to waste the R project's resources in this way. Please do re-read the FAQ. On Wed, 31 Jan 2007, [EMAIL PROTECTED] wrote: > The function 'pchisq' from the 'stats' library gives a wrong result if the > argument equals exactly zero: > > # Upper tail of central 1-df chi^2 distribution >> pchisq(1 , 1, ncp=0, lower.tail = F, log.p = FALSE) > [1] 0.3173105 >> pchisq(0.5 , 1, ncp=0, lower.tail = F, log.p = FALSE) > [1] 0.4795001 >> pchisq(0.01 , 1, ncp=0, lower.tail = F, log.p = FALSE) > [1] 0.9203443 >> pchisq(0.0001, 1, ncp=0, lower.tail = F, log.p = FALSE) > [1] 0.9920213 >> pchisq(0.0001, 1, ncp=0, lower.tail = F, log.p = FALSE) > [1] 0.202 >> pchisq(0.00 , 1, ncp=0, lower.tail = F, log.p = FALSE) > [1] 0 ## Should be 1.0 > > The error occurred with R version 2.4.0 (windows) and version 2.3.1 (linux). > > > Best regards, > > Michael Nothnagel > > --- > Dr. Michael Nothnagel > Institute of Medical Informatics and Statistics, > University of Kiel > http://capella.uni-kiel.de/ > --- > > ______ > 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
