Re: [Rd] problem with \eqn (PR#8322)
Kurt Hornik wrote:
>>Duncan Murdoch writes:
>
>
>>On 11/18/2005 12:40 PM, Hin-Tak Leung wrote:
>>
>>>Martin Maechler wrote:
>>>
>>>
>"Hin-Tak" == Hin-Tak Leung <[EMAIL PROTECTED]>
>on Fri, 18 Nov 2005 16:38:28 + writes:
> Hin-Tak> Your own fault. See below. It is basic LaTeX and any LaTeX person
> Hin-Tak> can tell you the answer...(most probably haven't bothered...)
>
No. Whereas I partly agree that it's Ross ``fault'' trying to
use too smart LaTex (and using outdated \bf instead of \mathbf),
;-)
The bug is really there, since we are talking about the Rd "language",
not LaTeX, an in Rd, \eqn and \deqn are defined to have either
one or two arguments -- where Ross used the 2-argument version
correctly (in principle at least) --> See the manual "Writing R
Extensions".
>>>
>>>
>>>Forgive me for not reading R-ext carefully, but Ross's Rd code is
>>>still "obviously" wrong in the lights of the two-argument \eqn:
>>>(really doesn't differ from the 1-arg interpretaion of \eqn)
>>>
>>>\eqn{{\bf\beta}_j}{\bf\beta}_jnormal-bracket5bracket-normal{b(j)}
>>>
>>>In other words,
>>>\eqn{...}{...}_...
>>>
>>>and the "_" is still outside of any maths environment, which is most
>>>probably not Ross's intention.
>
>
>>But that is Latex code produced by R, not Rd code produced by Ross.
>>The bug is in the Latex production (which I think is done by
>>share/perl/R/Rdconv.pm, but I don't know Perl well enough to attempt
>>to fix it).
>
>
> Definitely a problem in Rdconv.
>
> E.g.,
>
> $ cat foo.Rd
> \description{
> \eqn{{A}}{B}
> }
> [EMAIL PROTECTED]:~/tmp$ R-d CMD Rdconv -t latex foo.Rd | grep eqn
> \eqn{{A}}{A}{{B}
>
> shows what is going on.
>
> My reading of R-exts would suggest that it is not necessary to escape
> braces inside \eqn (and in fact these are not unescaped by Rdconv).
>
> Btw, the conversions of the above example are wrong for at least HTML
> and text as well, giving
>
> A{{B}
>
> and
>
> A{{B}
>
> respectively.
Apologies - the problem is with this section of "share/perl/R/Rdconv.pm"
around line 400 - it basically doesn't try very hard dealing with nested
brackets.
===
## Get the arguments of a command.
sub get_arguments {
my ($command, $text, $nargs) = @_;
## Arguments of get_arguments:
## 1, command: next occurence of 'command' is searched
## 2, text:'text' is the text containing the command
## 3, nargs: the optional number of arguments to be extracted;
## default 1
my @retval;
## Returns a list with the id of the last closing bracket and the
## arguments.
if($text =~ /\\($command)(\[[^\]]+\])?($ID)/){
$id = $3;
$text =~ /$id(.*)$id/s;
$retval[1] = $1;
my $k=2;
while(($k<=$nargs) && ($text =~ /$id($ID)/)){
$id = $1;
$text =~ /$id\s*(.*)$id/s;
$retval[$k++] = $1;
}
}
$retval[0] = $id;
@retval;
}
==
HT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with \eqn (PR#8322)
Kurt Hornik wrote:
> Definitely a problem in Rdconv.
>
> E.g.,
>
> $ cat foo.Rd
> \description{
> \eqn{{A}}{B}
> }
> [EMAIL PROTECTED]:~/tmp$ R-d CMD Rdconv -t latex foo.Rd | grep eqn
> \eqn{{A}}{A}{{B}
>
> shows what is going on.
There is a "work-around" - putting extra spaces between the two braces:
$ cat foo.Rd
\description{
\eqn{ {A} }{B}
}
$R CMD Rdconv -t latex foo.Rd
\HeaderA{}{}{}
\begin{Description}\relax
\eqn{ {A} }{B}
\end{Description}
HT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] formatC adds leading space to exponential format (PR#8337)
Full_Name: Kevin Wright Version: 2.2.0 OS: Windows 2000 Submission from: (NULL) (170.54.58.4) Apologies if my expectations (or reading of the man page) are incorrect. I seem unable to left-justify exponential format numbers. There appears to always be an extra space inserted to the left. Using the example from the formatC help page: R> xx <- pi * 10^(-5:4) R> cbind(formatC(xx, wid = 9, flag = "-")) [,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" # What does R want to do by default? # Exponential numbers have a leading space R> formatC(xx) [1] " 3.142e-05" "0.0003142" "0.003142" "0.03142""0.3142" [6] "3.142" "31.42" "314.2" "3142" " 3.142e+04" # Maybe space is reserved for a +/- sign? Let's try formatting negative numbers # Still an extra space before exponential numbers R> cbind(formatC(-xx, wid = 9, flag = "-")) [,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" # Try to force left-justification using 'width=-1', # still no luck. R> cbind(formatC(xx, wid = -1)) [,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" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
On Fri, 4 Nov 2005, Peter Dalgaard wrote: > Vaidotas Zemlys writes: > > > On 04 Nov 2005 13:51:56 +0100, Peter Dalgaard wrote: > > > > > [SNIP RPM discussion] > > > There you can find xml file for R scripts. I've made it from some > > example. It is really only a proof of a concept. But it would not be > > very difficult to produce xml files for mimetypes of all R related > > files. We must only decide which R related files would benefit from > > having mimetypes. > > > > My proposal is > > 1. R source code, R scripts. Files with extensions .R, .r and others > > (.q?, .s?, .S?). Mimetypes text/x-R, text/x-Rsrc > > My inclination would be to stick with .R, possibly adding .r to guard > against Windows case-folding issues, but .r used to be Ratfor files. > .q/.s/.S are used by some people supporting both R and S-PLUS, but I > don't think they care how such files are displayed by Nautilus and > Konqueror... > > > 2. R documentation files. File extension .Rd. Mimetype text/x-Rd > > OK, modulo case-fold > > > 3. RData files. File extension .RData, files which at beginning have > > RDX2. Mimetype application/x-RData. > > Why the RDX2 bit?? We do have .RDA from windows, too. > > > > 4. Rhistory files. File extension .Rhistory. Mimetype text/x-Rhistory > > OK. > > > 5. R transcript files from ESS/Emacs. File extension .Rt. Mimetype > > text/x-Rtranscript > > .Rout, please. Also .Rout.save and .Rout.fail. (And it's not just > ESS that creates them). > > Also > > 6. Rprofile files .Rprofile or Rprofile. > > > I could write and test the xml code. But first we have to agree on > > which files benefit from having mimetypes and how the mimetypes should > > be named. Feel free to suggest. > What is the status of this problem report? Was a standard set of MIME types ever established for the various R file types? If so, where can I find them? The following seem reasonable comparing against various sources, blended with the above. File types MIME types -- .R text/x-r, text/x-r-source, text/plain .Rd text/x-r-doc, text/plain .RData application/x-r-data .Rhistory text/x-r-history, text/plain .Rout, .Rout.save, .Rout.fail text/x-r-transcript, text/plain .Rprofile, Rprofile.sitetext/x-r-profile, text/plain .Renviron, Renviron text/x-r-environ, text/plain I read long ago about suggestion for using dot-q for S source but don't recall ever having seen it in the wild. Peter mentioned dot-r as having been previously used for Ratfor. It was also used by Rez on Mac OS. Also note that dot-s is for assembly source. Not sure if all of these even deserve MIME types. The first three seem useful though the latter four could be dropped. -- SIGSIG -- signature too long (core dumped) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NAMESPACE, S4, and .onLoad
The Writing R Extensions manual instructs developers who use S4 classes and methods in a package with a name space to: There needs to be an .onLoad action to ensure that the methods package is loaded and attached: .onLoad <- function(lib, pkg) require(methods) I'm wondering if listing methods in the Depends field of the package's DESCRIPTION file is sufficient. My understanding is that doing so will result in the methods package being loaded and attached. Best, + seth Link to section in extension manual: http://cran.r-project.org/doc/manuals/R-exts.html#Name-spaces-with-formal-classes-and-methods __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE, S4, and .onLoad
On Mon, 21 Nov 2005, Seth Falcon wrote: > The Writing R Extensions manual instructs developers who use S4 > classes and methods in a package with a name space to: > > There needs to be an .onLoad action to ensure that the methods package > is loaded and attached: > > .onLoad <- function(lib, pkg) require(methods) > > I'm wondering if listing methods in the Depends field of the package's > DESCRIPTION file is sufficient. My understanding is that doing so > will result in the methods package being loaded and attached. Using DCF Depends provides same service and better documents the external dependency. The manual should reflect this. -- SIGSIG -- signature too long (core dumped) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] windrose (circular package) error in table (PR#8341)
Full_Name: Allyson Williams Version: 2.1.1 OS: Windows XP Submission from: (NULL) (203.25.1.208) I'm using the 'Circular' package to plot windroses. I think the output table (see out2$table below) is incorrect when using different rotations. More precisely, when a rotation is used for the plot, the output table stuffs up. This example is from the code in the help notes, although the input data (dir, mag) are changed): > dir <- c(1:50,1:50) > mag <- c(1:100) > > sample <- data.frame(dir=circular(dir,units="degrees"), mag=mag) > > par(mfrow=c(2,2)) > res <- windrose(sample) > > ## we join two pedals and keep the same shrink (scale of the plot) > breaks <- seq(0, 2 * pi, by = pi/6) > breaks <- breaks[-2] > out1<-windrose(sample, breaks=breaks, increment=50,main="The same but with two pedals joined", shrink=res$shrink) > # > # change the rotation > sample <- data.frame(dir=circular(dir, units="degrees", rotation="clock"), mag=mag) > out2<-windrose(sample, breaks=breaks,increment=50, main="Change the rotation", shrink=res$shrink) > > ## use geographics template > sample <- data.frame(dir=circular(dir, units="degrees", template="geographics"), mag=mag) > out3<-windrose(sample, breaks=breaks, increment=50,main="Use the template 'geographics'", shrink=res$shrink) > THESE are the output tables that seem to be incorrect (I'm sorry they're not clearer): > out1$table [0, 60) [60, 90) [90, 120) [120, 150) [150, 180) [180, 210) [210, 240) [240, 270) [270, 300) [300, 330) [330, 360) >From 0 to 50 0.50 0 0 0 0 > 0 0 0 0 0 >From 50 to 100 0.50 0 0 0 0 > 0 0 0 0 0 > out2$table [0, 60) [60, 90) [90, 120) [120, 150) [150, 180) [180, 210) [210, 240) [240, 270) [270, 300) [300, 330) [330, 360) >From 0 to 50 00 0 0 0 0 > 0 0 0 00.5 >From 50 to 100 00 0 0 0 0 > 0 0 0 00.5 > out3$table [0, 60) [60, 90) [90, 120) [120, 150) [150, 180) [180, 210) [210, 240) [240, 270) [270, 300) [300, 330) [330, 360) >From 0 to 50 0 0.5 0 0 0 0 > 0 0 0 0 0 >From 50 to 100 0 0.5 0 0 0 0 > 0 0 0 0 0 > out1$table is correct. The data is all between 0-60degrees. out2$table (changed rotation) is incorrect. The data are listed as being between 330-360degrees. Out3$table (geographic rotation) is incorrect. The data are listed as being between 60-90degrees. Regardless of the rotation, the data should always be between 0-60degrees! The problem only seems to occur when 'rotating' the plot. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windrose (circular package) error in table (PR#8341)
On 11/21/2005 8:50 PM, [EMAIL PROTECTED] wrote: > Full_Name: Allyson Williams > Version: 2.1.1 > OS: Windows XP > Submission from: (NULL) (203.25.1.208) > > > I'm using the 'Circular' package to plot windroses. I think the output table > (see out2$table below) is incorrect when using different rotations. More > precisely, when a rotation is used for the plot, the output table stuffs up. Please send bug reports about contributed packages to the maintainer, Claudio Agostinelli <[EMAIL PROTECTED]>. Duncan Murdoch > > This example is from the code in the help notes, although the input data (dir, > mag) are changed): > > >>dir <- c(1:50,1:50) >>mag <- c(1:100) >> >>sample <- data.frame(dir=circular(dir,units="degrees"), mag=mag) >> >>par(mfrow=c(2,2)) >>res <- windrose(sample) >> >>## we join two pedals and keep the same shrink (scale of the plot) >>breaks <- seq(0, 2 * pi, by = pi/6) >>breaks <- breaks[-2] >>out1<-windrose(sample, breaks=breaks, increment=50,main="The same but with two > > pedals joined", shrink=res$shrink) > >># >># change the rotation >>sample <- data.frame(dir=circular(dir, units="degrees", rotation="clock"), > > mag=mag) > >>out2<-windrose(sample, breaks=breaks,increment=50, main="Change the rotation", > > shrink=res$shrink) > >>## use geographics template >>sample <- data.frame(dir=circular(dir, units="degrees", > > template="geographics"), mag=mag) > >>out3<-windrose(sample, breaks=breaks, increment=50,main="Use the template > > 'geographics'", shrink=res$shrink) > > > THESE are the output tables that seem to be incorrect (I'm sorry they're not > clearer): > >>out1$table > >[0, 60) [60, 90) [90, 120) [120, 150) [150, 180) [180, 210) > [210, > 240) [240, 270) [270, 300) [300, 330) [330, 360) >>From 0 to 50 0.50 0 0 0 0 >> >0 0 0 0 0 >>From 50 to 100 0.50 0 0 0 0 >> >0 0 0 0 0 > >>out2$table > >[0, 60) [60, 90) [90, 120) [120, 150) [150, 180) [180, 210) > [210, > 240) [240, 270) [270, 300) [300, 330) [330, 360) >>From 0 to 50 00 0 0 0 0 >> >0 0 0 00.5 >>From 50 to 100 00 0 0 0 0 >> >0 0 0 00.5 > >>out3$table > >[0, 60) [60, 90) [90, 120) [120, 150) [150, 180) [180, 210) > [210, > 240) [240, 270) [270, 300) [300, 330) [330, 360) >>From 0 to 50 0 0.5 0 0 0 0 >> >0 0 0 0 0 >>From 50 to 100 0 0.5 0 0 0 0 >> >0 0 0 0 0 > > > > out1$table is correct. The data is all between 0-60degrees. > out2$table (changed rotation) is incorrect. The data are listed as being > between > 330-360degrees. > Out3$table (geographic rotation) is incorrect. The data are listed as being > between 60-90degrees. > Regardless of the rotation, the data should always be between 0-60degrees! > > The problem only seems to occur when 'rotating' the plot. > > __ > 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
Re: [Rd] using a factor as col argument in plot:
Dear Prof. Ripley
Thank you for your reply and for changing the function in
R-devel.
I've intended to ask my question in way 2) but I probably have
chosen a ambiguous formulation. :-)
Regards
Christoph Buser
--
Christoph Buser <[EMAIL PROTECTED]>
Seminar fuer Statistik, LEO C13
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-44-632-4673 fax: 632-1228
http://stat.ethz.ch/~buser/
--
Prof Brian Ripley writes:
> On Fri, 18 Nov 2005, Christoph Buser wrote:
>
> > Dear R core team
>
> and R-devel-listers.
>
> > Using the following code produces an empty plot (similar
> > to col = NA):
> >
> >> plot(1:9, col = factor(rep(1:3,3), labels = c("red", "blue", "black")))
> >
> >
> > My question: Shouldn't one get at least a warning (or an error)
> > if one tries to use a factor as col argument?
> >
> > Thanks for an answer.
>
> I can read that two ways
>
> 1) No, it should not give a warning, as it is programmed to take all
> invalid values as 0.
>
> 2) Is the way it is programmed sensible (yes) or desirable (no)?
>
> The actual code is
>
> /* Convert a sexp element to an R color desc */
> /* We Assume that Checks Have Been Done */
>
> unsigned int RGBpar(SEXP x, int i)
> {
> int indx;
> if(isString(x)) {
> return str2col(CHAR(STRING_ELT(x, i)));
> }
> else if(isInteger(x) || isLogical(x)) {
> if(INTEGER(x)[i] == NA_INTEGER)
> /*
> * Paul 01/07/04
> * Used to be set to NA_INTEGER (see comment in name2col).
> */
> return R_TRANWHITE;
> indx = INTEGER(x)[i] - 1;
> if(indx < 0) return Rf_dpptr(CurrentDevice())->bg;
> else return R_ColorTable[indx % R_ColorTableSize];
> }
> else if(isReal(x)) {
> if(!R_FINITE(REAL(x)[i]))
> /*
> * Paul 01/07/04
> * Used to be set to NA_INTEGER (see comment in name2col).
> */
> return R_TRANWHITE;
> indx = REAL(x)[i] - 1;
> if(indx < 0) return Rf_dpptr(CurrentDevice())->bg;
> else return R_ColorTable[indx % R_ColorTableSize];
> }
> return 0; /* should not occur */
> }
>
> but I could see no checks of type in any of the calling functions. Adding
> a warning would be a good idea.
>
>
> --
> 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
> "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
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
