Re: [R] ggplot geom_line problem
Maybe you will find that coord_cartesian( ylim=c(-30,30) ) works better since
it doesn't filter out data before rendering.
On August 28, 2021 6:45:11 PM PDT, p...@philipsmith.ca wrote:
>I am preparing a time series plot using the ggplot function. It includes
>an area plot outlined at its edges with a line plot. For some reason the
>line plot, drawn with geom_line(), has some broken portions where the
>line does not appear, although the filled geom_area() part of the plot
>is shown. The problem is related to the last line of code because when I
>remove it, the problem disappears.
>Why is this happening and what can I do about it? Thank you. Philip
>
>library(tidyverse)
>df <- dget("df.txt")
>mnGr <- 345.05809
>mnGDP <- 859.752763485
>ggplot(df)+
> geom_area(aes(x=Date,y=GDP*(mnGr/mnGDP)-Gr),
> fill="red",alpha=0.3)+
> geom_line(aes(x=Date,y=GDP*(mnGr/mnGDP)-Gr),
> colour="black",size=1)+
> scale_y_continuous(position="right",limits=c(-30,30))
--
Sent from my phone. Please excuse my brevity.
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[R] ggplot geom_line problem
I am preparing a time series plot using the ggplot function. It includes
an area plot outlined at its edges with a line plot. For some reason the
line plot, drawn with geom_line(), has some broken portions where the
line does not appear, although the filled geom_area() part of the plot
is shown. The problem is related to the last line of code because when I
remove it, the problem disappears.
Why is this happening and what can I do about it? Thank you. Philip
library(tidyverse)
df <- dget("df.txt")
mnGr <- 345.05809
mnGDP <- 859.752763485
ggplot(df)+
geom_area(aes(x=Date,y=GDP*(mnGr/mnGDP)-Gr),
fill="red",alpha=0.3)+
geom_line(aes(x=Date,y=GDP*(mnGr/mnGDP)-Gr),
colour="black",size=1)+
scale_y_continuous(position="right",limits=c(-30,30))
structure(list(Date = structure(c(-3287, -3197, -3106, -3014,
-2922, -2832, -2741, -2649, -2557, -2467, -2376, -2284, -2192,
-2101, -2010, -1918, -1826, -1736, -1645, -1553, -1461, -1371,
-1280, -1188, -1096, -1006, -915, -823, -731, -640, -549, -457,
-365, -275, -184, -92, 0, 90, 181, 273, 365, 455, 546, 638, 730,
821, 912, 1004, 1096, 1186, 1277, 1369, 1461, 1551, 1642, 1734,
1826, 1916, 2007, 2099, 2191, 2282, 2373, 2465, 2557, 2647, 2738,
2830, 2922, 3012, 3103, 3195, 3287, 3377, 3468, 3560, 3652, 3743,
3834, 3926, 4018, 4108, 4199, 4291, 4383, 4473, 4564, 4656, 4748,
4838, 4929, 5021, 5113, 5204, 5295, 5387, 5479, 5569, 5660, 5752,
5844, 5934, 6025, 6117, 6209, 6299, 6390, 6482, 6574, 6665, 6756,
6848, 6940, 7030, 7121, 7213, 7305, 7395, 7486, 7578, 7670, 7760,
7851, 7943, 8035, 8126, 8217, 8309, 8401, 8491, 8582, 8674, 8766,
8856, 8947, 9039, 9131, 9221, 9312, 9404, 9496, 9587, 9678, 9770,
9862, 9952, 10043, 10135, 10227, 10317, 10408, 10500, 10592,
10682, 10773, 10865, 10957, 11048, 11139, 11231, 11323, 11413,
11504, 11596, 11688, 11778, 11869, 11961, 12053, 12143, 12234,
12326, 12418, 12509, 12600, 12692, 12784, 12874, 12965, 13057,
13149, 13239, 13330, 13422, 13514, 13604, 13695, 13787, 13879,
13970, 14061, 14153, 14245, 14335, 14426, 14518, 14610, 14700,
14791, 14883, 14975, 15065, 15156, 15248, 15340, 15431, 15522,
15614, 15706, 15796, 15887, 15979, 16071, 16161, 16252, 16344,
16436, 16526, 16617, 16709, 16801, 16892, 16983, 17075, 17167,
17257, 17348, 17440, 17532, 17622, 17713, 17805, 17897, 17987,
18078, 18170, 18262, 18353, 18444, 18536, 18628), class = "Date"),
GDP = c(40.672, 41.568, 42.68, 43.476, 44.696, 45.2, 46.144,
47.224, 47.668, 48.644, 49.444, 51.452, 52.652, 53.516, 54.676,
55.424, 57.364, 58.764, 60.172, 62.332, 64.428, 66.592, 67.464,
68.756, 69.584, 71.84, 72.484, 73.74, 75.408, 77.76, 79.544,
81.564, 83.876, 85.564, 87.224, 89.408, 91.46, 92.284, 94.196,
95.004, 96.388, 100.42, 103.736, 106.528, 108.256, 112.364,
114.492, 119.384, 124.86, 130.152, 134.652, 142.656, 149.424,
156.088, 162.384, 165.328, 167.572, 173.748, 182.328, 188.532,
196.288, 206.268, 208.464, 213.008, 219.892, 224.772, 229.704,
235.948, 241.296, 248.648, 255.176, 263.056, 271.352, 284.116,
292.9, 301.924, 309.756, 317.208, 324.72, 339.304, 355.992,
367.992, 372.82, 376.628, 383.004, 386.516, 389.56, 393.644,
403.236, 415.804, 428.96, 437.264, 447.84, 459.552, 465.18,
475.372, 486.096, 495.352, 503.872, 514.788, 518.612, 523.844,
530.22, 533.844, 552.484, 567.42, 581.68, 595.76, 610.948,
621.168, 631.392, 644.068, 656.16, 669.792, 679.132, 681.232,
691.928, 695.624, 697.684, 696.768, 694.008, 701.572, 704.796,
706.716, 710.008, 714.744, 721.66, 727.332, 733.952, 745.36,
750.068, 758.768, 772.656, 783.66, 800.784, 810.788, 823.972,
828.856, 832.976, 840.68, 844.208, 852.904, 864.544, 877.68,
891.748, 899.412, 912.564, 923.98, 934.612, 935.212, 938.872,
953.496, 975.24, 994.172, 1021.308, 1040.988, 1070.188, 1099.448,
1121.768, 1132.88, 1149.924, 1152.86, 1138.804, 1136.584,
1158.64, 1185.892, 1204.144, 1226.1, 1250.088, 1237.72, 1258.296,
1272.884, 1296.216, 1328.148, 1351.48, 1367.08, 1380.324,
1399.608, 1436.992, 1469.436, 1476, 1490.716, 1504.936, 1514.764,
1547.276, 1576.612, 1582.248, 1604.508, 1637.296, 1677.448,
1694.512, 1618.908, 1557.232, 1548.488, 1567.924, 1611.692,
1644.032, 1653.24, 1665.372, 1701.548, 1737.952, 1759.852,
1785.748, 1812.7, 1815.12, 1818.984, 1830.636, 1844.064,
1876.844, 1886.592, 1912.428, 1933.124, 1963.452, 1988.404,
2013.792, 2013.944, 1984.3, 1984.92, 2000.864, 1991.68, 1998.42,
2002.152, 2035.42, 2066.148, 2107.924, 2130.024, 2141.764,
2182.852, 2205.12, 2232.188, 2255.156, 2232.208, 2270.664,
2308.236, 2320.44, 2343.508, 2270.42, 2001.596, 2233.052,
2314.552, 2414.348), Gr = c(10.839, 11.284, 11.9, 12.065,
12.216, 12.496, 12.729, 12.835, 13.001, 13.114, 13.593, 14.148,
14.405, 15.27, 15.591, 15.882, 16.285, 16.961, 17.437, 18.085,
19.021, 19.558, 20.254, 21.007, 22.046, 21.875, 22.588, 23.107,
Re: [R] Finding if numbers fall within a range
You messed up the dput somehow... but I think this works: m <- t(structure(c(1, 57, 59, 271, 279, 59, 179, 279, 278, 359, 52, 118, 178, 239, 334), .Dim = c(5L, 3L))) brk <- c( 0, 60, 120, 180, 240, 300 ) mc <- matrix( findInterval( m, brk ), ncol = ncol(m) ) m mc DBI <- apply( mc, 1, function(v) length( unique( v ) ) ) On August 28, 2021 8:57:09 AM PDT, Eliza Botto wrote: >Dear useRs, > >Is there a way in R to see if the numbers in a matrix-row fall within the >given range or not? For example, I have the following data; > >> dput(EB) > >structure(c(1, 57, 59, 271, 279, 59, 179, 279, 278, 359, 52, >118, 178, 239, 334), .Dim = c(3L, 5L)) > >The ranges for which these numbers are to be reserved are; > >0-60, 61-120, 121-180, 181-240, 241-300, 301-360 > >In row 1, the number "1", "57", and "59" fall 2ith the range 0-60. Whereas >"271" and "279" falls within the range 241-300. So in total 2 ranges are >covered and coding should execute 2 for row one. > >In row 2, the number "59" falls in the range 0-60, "179" falls in the range >121-180, "279" and "278" fall within the range 241-300, and 359 falls in the >range 301-360. In total 4 ranges are covered for row 2. > >In the like-wise pattern, 5 ranges are covered in row 3. > >So, what I want is a matrix that looks in the following > >> dput(EBI) > >structure(c(2, 4, 5), .Dim = c(3L, 1L)) > >Is there an easy way of doing it? > >I thank you all very much in advance > >EB > > [[alternative HTML version deleted]] > >__ >R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide http://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code. -- Sent from my phone. Please excuse my brevity. __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Finding if numbers fall within a range
Hello, I think I've found a solution, but it's not producing the same answer as what you're expecting. I think you might've mixed up row and column a few times, but you should be able to alter the following to your needs. Also, see ?.bincode: EB <- matrix(data = c( 1, 271, 179, 359, 178, 57, 279, 279, 52, 239, 59, 59, 278, 118, 334 ), nrow = 3, ncol = 5, byrow = TRUE) # ranges <- list( # c( 0, 60), # c( 61, 120), # c(121, 180), # c(181, 240), # c(241, 300), # c(301, 360) # ) breaks <- seq.int(0, 360, 60) codes <- .bincode(EB, breaks, include.lowest = TRUE) dim(codes) <- dim(EB) num.ranges <- apply(codes, 1, function(xx) length(unique(xx))) I hope this helps! On Sat, Aug 28, 2021 at 11:57 AM Eliza Botto wrote: > Dear useRs, > > Is there a way in R to see if the numbers in a matrix-row fall within the > given range or not? For example, I have the following data; > > > dput(EB) > > structure(c(1, 57, 59, 271, 279, 59, 179, 279, 278, 359, 52, > 118, 178, 239, 334), .Dim = c(3L, 5L)) > > The ranges for which these numbers are to be reserved are; > > 0-60, 61-120, 121-180, 181-240, 241-300, 301-360 > > In row 1, the number "1", "57", and "59" fall 2ith the range 0-60. Whereas > "271" and "279" falls within the range 241-300. So in total 2 ranges are > covered and coding should execute 2 for row one. > > In row 2, the number "59" falls in the range 0-60, "179" falls in the > range 121-180, "279" and "278" fall within the range 241-300, and 359 falls > in the range 301-360. In total 4 ranges are covered for row 2. > > In the like-wise pattern, 5 ranges are covered in row 3. > > So, what I want is a matrix that looks in the following > > > dput(EBI) > > structure(c(2, 4, 5), .Dim = c(3L, 1L)) > > Is there an easy way of doing it? > > I thank you all very much in advance > > EB > > [[alternative HTML version deleted]] > > __ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] [R-pkgs] summary plots with adjusted error bar: A Shiny interface
Dear all, This short email to inform you that a new version of *superb* (SUmmary Plots with adjusted ERror Bars) is now available on CRAN (version 0.9.7.5; codename "two-tail 95% confident"). This package lets you generate plots with correct error bars without heavy programming. I know that this does not concern you, users of this mailing list, but you certainly know people around you for which plotting error bars and adjusting these to the experimental design is a challenge. Please share this announcement. The package now comes with a shiny interface, launched from within R with the command superbShiny(). It is also available online for those who don't have R, from https://dcousin3.shinyapps.io/superbshiny/ Finally, a brief tutorial on YouTube can be found at https://www.youtube.com/watch?v=rw_6ll5nVus Plotting error bars has never been so easy! You can read more from this recently published article to *Advances in Methods and Practices in Psychological Science* (doi: https://doi.org/10.1177/25152459211035109). All the best, Denis, Marc-André and Brad! ___ R-packages mailing list r-packa...@r-project.org https://stat.ethz.ch/mailman/listinfo/r-packages __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] [R-pkgs] monobinShiny: Shiny User Interface for 'monobin' Package
Dear R users, I am happy to announce that my new package monobinShiny is now available on CRAN. This is an add-on package to the 'monobin' package that simplifies its use. As reminder, the goal of 'monobin' is to perform monotonic binning of numeric risk factor in credit rating models (PD, LGD, EAD) development. All functions handle both binary and continuous target variable. Missing values and other possible special values are treated separately from so-called complete cases. 'monobinShiny' provides shiny-based user interface to 'monobin' package and it can be especially handy for less experienced R users as well as for those who intend to perform quick scanning of numeric risk factors when building credit rating models. The additional functions implemented in 'monobinShiny' that do no exist in 'monobin' package are: descriptive statistics, special case and outliers imputation. The function descriptive statistics is exported and can be used in R sessions independently from the user interface, while the special case and the outlier imputation functions are written to be used with shiny UI. Here is, also, the link to github page: https://github.com/andrija-djurovic/monobinShiny Hope that some of you will find the package useful. Best regards, Andrija Djurovic [[alternative HTML version deleted]] ___ R-packages mailing list r-packa...@r-project.org https://stat.ethz.ch/mailman/listinfo/r-packages __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] Finding if numbers fall within a range
Dear useRs, Is there a way in R to see if the numbers in a matrix-row fall within the given range or not? For example, I have the following data; > dput(EB) structure(c(1, 57, 59, 271, 279, 59, 179, 279, 278, 359, 52, 118, 178, 239, 334), .Dim = c(3L, 5L)) The ranges for which these numbers are to be reserved are; 0-60, 61-120, 121-180, 181-240, 241-300, 301-360 In row 1, the number "1", "57", and "59" fall 2ith the range 0-60. Whereas "271" and "279" falls within the range 241-300. So in total 2 ranges are covered and coding should execute 2 for row one. In row 2, the number "59" falls in the range 0-60, "179" falls in the range 121-180, "279" and "278" fall within the range 241-300, and 359 falls in the range 301-360. In total 4 ranges are covered for row 2. In the like-wise pattern, 5 ranges are covered in row 3. So, what I want is a matrix that looks in the following > dput(EBI) structure(c(2, 4, 5), .Dim = c(3L, 1L)) Is there an easy way of doing it? I thank you all very much in advance EB [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] A glitch (???) in tools::texi2pf.
I can understand Rolf's concern. Make is a tool that is very helpful, but also not trivial to learn how to make work. If a good Makefile has been set up, then things are easy, but I've generally found my skills limited to fairly simple Makefiles. I would suggest that what is needed is a bit of modest collaboration to set up a Makefile for dealing with this issue that has enough comments so it is clear what Make will be doing. I suspect that in this case the need is to remove the offending .bbl file and then run the tex*** operations. Possibly the result is small enough to post in this thread. Anyone? Cheers, JN On 2021-08-28 9:14 a.m., Rolf Turner wrote: > > On Sat, 28 Aug 2021 12:49:04 +0300 > Eric Berger wrote: > >> As Achim wrote in point (2), Makefile is your friend. > > Well, all I can say is that Makefile is *not* my friend; I have never > made its acquaintance and wouldn't know where to begin looking. > > Would it be possible for you to provide a template/prototype Makefile > and give me some idea what to *do* with it? > > cheers, > > Rolf Turner > __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] A glitch (???) in tools::texi2pf.
On Sat, 28 Aug 2021 12:49:04 +0300 Eric Berger wrote: > As Achim wrote in point (2), Makefile is your friend. Well, all I can say is that Makefile is *not* my friend; I have never made its acquaintance and wouldn't know where to begin looking. Would it be possible for you to provide a template/prototype Makefile and give me some idea what to *do* with it? cheers, Rolf Turner -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] A glitch (???) in tools::texi2pf.
On Sat, 28 Aug 2021, Rolf Turner wrote: On Sat, 28 Aug 2021 09:47:03 +0200 Achim Zeileis wrote: On Sat, 28 Aug 2021, Rolf Turner wrote: I have found that tools::texi2pf() ignores changes to the *.bib file unless the *.bbl file is removed prior to re-running tools::texi2pdf(). This is how texi2pdf (or actually texi2dvi) from texinfo behaves. This is likely what tools::texi2pdf calles in your setup anyway. In short, texi2dvi considers the .bbl as input files to the .tex and does not remove them if they are available prior to calling texi2dvi. Alternatives: (1) You can always re-run everything. Then simply start with a clean directory and always use tools::texi2pdf(..., clean = TRUE). This cleans up all the files it has produced (except the .pdf). But it will preserve files left in the directory from previous runs. (2) You can detect upstream changes, e.g., based on timestamps etc. Then the traditional approach would be to use a Makefile. Best, Z Thanks. I guess you're saying that it's a feature, not a bug. :-) Also. But the main point is that it's a feature of texi2dvi from texinfo which is called by tools::texi2dvi(). Hence, if you want to raise this somewhere it would have to be with the texinfo maintainers. Well it's a feature that I intensely dislike, but that cuts no ice I'm sure, and I'll just have to cope with it. I can easily build a local function that will remove *.bbl before invoking tools::texi2pdf(), and use that, rather than calling tools::texi2pdf() directly. However I *really* believe that this is a bad feature, and is a Trap For Young Players. Hardly anyone knows what a *.bbl is or is for. Users would expect that changing the *.bib file would change the reference list in the output. (I.e. that texi2pdf() would re-run bibtex "under the bonnet", as the user would do if processing from the OS command line rather than applying texi2pdf() from R.) The problem is that currently texi2dvi has no concept of judging whether the .bib or .bbl were modified last. I wonder how many papers in the R Journal have errors in their reference lists due to the fact that authors corrected the *.bib file, reprocessed using texi2pdf() and did not notice that the error they corrected had *not* been corrected in the *.pdf output? I don't know what the R Journal editors are doing but for JSS I'm cleaning such files up (repeatedly actually) before compiling the final PDFs. Best, Z __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
[R] Configure error: checking if libcurl supports https... no
I'm getting results from a package which differ from results that I got a few weeks ago, and the only thing that I can think of that's changed is the version of R (from 4.1.0 to 4.4.1). So I wanted to install 4.1.0 and play around with that, to see if that is indeed the explanation. (If that is so, a whole new set of questions would be raised, but let's leave that for the moment.) I downloaded the tarball and set about installing 4.1.0 from source. But the configure step threw an error, as given in the subject line of this message. The error went on: > configure: error: libcurl >= 7.28.0 library and headers are required > with support for https A bit of web searching turned up the advice to re-install curl using sudo apt-get install curl but when I did that I was informed that: > curl is already the newest version (7.68.0-1ubuntu2.6). Has anyone got any *useful* advice? If so, please present it in very simple terms if you can. (I am a Bear of Very Little Brain, and long words bother me.) A step-by-step recipe would be appreciated. I'm running Ubuntu 20.04, with a Mate 1.24.0 desktop. Grateful for any pearls of wisdom. cheers, Rolf Turner P.S. The config.log file seems to be full of stuff relating to errors from "openssl.c" but this is *way* beyond my pay grade. R. T. -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] A glitch (???) in tools::texi2pf.
As Achim wrote in point (2), Makefile is your friend. On Sat, Aug 28, 2021 at 12:39 PM Rolf Turner wrote: > > On Sat, 28 Aug 2021 09:47:03 +0200 > Achim Zeileis wrote: > > > On Sat, 28 Aug 2021, Rolf Turner wrote: > > > > > I have found that tools::texi2pf() ignores changes to the *.bib file > > > unless the *.bbl file is removed prior to re-running > > > tools::texi2pdf(). > > > > This is how texi2pdf (or actually texi2dvi) from texinfo behaves. > > This is likely what tools::texi2pdf calles in your setup anyway. In > > short, texi2dvi considers the .bbl as input files to the .tex and > > does not remove them if they are available prior to calling texi2dvi. > > > > Alternatives: > > > > (1) You can always re-run everything. Then simply start with a clean > > directory and always use tools::texi2pdf(..., clean = TRUE). This > > cleans up all the files it has produced (except the .pdf). But it > > will preserve files left in the directory from previous runs. > > > > (2) You can detect upstream changes, e.g., based on timestamps etc. > > Then the traditional approach would be to use a Makefile. > > > > Best, > > Z > > Thanks. I guess you're saying that it's a feature, not a bug. :-) > > Well it's a feature that I intensely dislike, but that cuts no ice I'm > sure, and I'll just have to cope with it. I can easily build a local > function that will remove *.bbl before invoking tools::texi2pdf(), > and use that, rather than calling tools::texi2pdf() directly. > > However I *really* believe that this is a bad feature, and is a Trap > For Young Players. Hardly anyone knows what a *.bbl is or is for. > Users would expect that changing the *.bib file would change the > reference list in the output. (I.e. that texi2pdf() would re-run > bibtex "under the bonnet", as the user would do if processing from the > OS command line rather than applying texi2pdf() from R.) > > I wonder how many papers in the R Journal have errors in their > reference lists due to the fact that authors corrected the *.bib file, > reprocessed using texi2pdf() and did not notice that the error they > corrected had *not* been corrected in the *.pdf output? > > cheers, > > Rolf > > -- > Honorary Research Fellow > Department of Statistics > University of Auckland > Phone: +64-9-373-7599 ext. 88276 > > __ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > [[alternative HTML version deleted]] __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] A glitch (???) in tools::texi2pf.
On Sat, 28 Aug 2021 09:47:03 +0200 Achim Zeileis wrote: > On Sat, 28 Aug 2021, Rolf Turner wrote: > > > I have found that tools::texi2pf() ignores changes to the *.bib file > > unless the *.bbl file is removed prior to re-running > > tools::texi2pdf(). > > This is how texi2pdf (or actually texi2dvi) from texinfo behaves. > This is likely what tools::texi2pdf calles in your setup anyway. In > short, texi2dvi considers the .bbl as input files to the .tex and > does not remove them if they are available prior to calling texi2dvi. > > Alternatives: > > (1) You can always re-run everything. Then simply start with a clean > directory and always use tools::texi2pdf(..., clean = TRUE). This > cleans up all the files it has produced (except the .pdf). But it > will preserve files left in the directory from previous runs. > > (2) You can detect upstream changes, e.g., based on timestamps etc. > Then the traditional approach would be to use a Makefile. > > Best, > Z Thanks. I guess you're saying that it's a feature, not a bug. :-) Well it's a feature that I intensely dislike, but that cuts no ice I'm sure, and I'll just have to cope with it. I can easily build a local function that will remove *.bbl before invoking tools::texi2pdf(), and use that, rather than calling tools::texi2pdf() directly. However I *really* believe that this is a bad feature, and is a Trap For Young Players. Hardly anyone knows what a *.bbl is or is for. Users would expect that changing the *.bib file would change the reference list in the output. (I.e. that texi2pdf() would re-run bibtex "under the bonnet", as the user would do if processing from the OS command line rather than applying texi2pdf() from R.) I wonder how many papers in the R Journal have errors in their reference lists due to the fact that authors corrected the *.bib file, reprocessed using texi2pdf() and did not notice that the error they corrected had *not* been corrected in the *.pdf output? cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] A glitch (???) in tools::texi2pf.
On Sat, 28 Aug 2021, Rolf Turner wrote:
I have found that tools::texi2pf() ignores changes to the *.bib file
unless the *.bbl file is removed prior to re-running tools::texi2pdf().
This is how texi2pdf (or actually texi2dvi) from texinfo behaves. This is
likely what tools::texi2pdf calles in your setup anyway. In short,
texi2dvi considers the .bbl as input files to the .tex and does not remove
them if they are available prior to calling texi2dvi.
Alternatives:
(1) You can always re-run everything. Then simply start with a clean
directory and always use tools::texi2pdf(..., clean = TRUE). This cleans
up all the files it has produced (except the .pdf). But it will preserve
files left in the directory from previous runs.
(2) You can detect upstream changes, e.g., based on timestamps etc. Then
the traditional approach would be to use a Makefile.
Best,
Z
I have constructed a minimal reproducible example which is contained
in the attached file "mreprex.txt".
This *.txt file should be split into two files, mreprex.tex and
mreprex.bib. (I wasn't sure whether *.tex and *.bib files would make
it through to the list.)
After doing the splitting, start R, execute
tools::texi2pf("mreprex.tex")
and view the resulting mreprex.pdf file. Then edit mreprex.bib
and change (e.g.) the version number from "0.0-21" to "0.0-22".
Re-run tools::texi2pf("mreprex.tex") and view mreprex.pdf. You will
see that it hasn't changed; the version number cited is still given as
0.0-21. Now remove mreprex.bbl, re-run tools::texi2pf("mreprex.tex")
and view mreprex.pdf. You will see that the version number is given as
0.0-22 as it should be.
Should this be considered a bug? If so, what is the appropriate way of
drawing this to the attention of those who have the power to fix it?
Thanks.
cheers,
Rolf Turner
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
