Re: [Rd] incorrect linetype with pdf device (PR#14128)
Dear all,
Running this minimal example,
library(grid)
postscript("test-123456.eps")
grid.newpage()
grid.lines(gp=gpar(lty="123456", lineend = "butt"))
dev.off()
produces eps output with the following setdash description towards the
end of the file,
## [ 0.00 3.00 2.00 5.00 4.00 7.00] 0 setdash
I consulted the postscript reference manual (page 667 *), which
indicates that the array should rather be [1 2 3 4 5 6] as intended
(and as produced by, e.g., quartz())
(*): http://www.adobe.com/products/postscript/pdfs/PLRM.pdf
Regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ?setGeneric garbled (PR#14153)
> "DM" == Duncan Murdoch
> on Fri, 18 Dec 2009 15:03:26 -0500 writes:
DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote:
>> On 18/12/2009 12:54 PM, Martin Maechler wrote:
Martin Morgan
on Fri, 18 Dec 2009 07:40:13 -0800 writes:
>>> > Martin Maechler wrote:
>>> >>> Martin Morgan
>>> >>> on Thu, 17 Dec 2009 09:54:54 -0800 writes:
>>> >>
>>> >> > Ross Boylan wrote:
>>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote:
>>> >> Ross Boylan
>>> >> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes:
>>> >> >>> > Full_Name: Ross Boylan
>>> >> >>> > Version: 2.10.0
>>> >> >>> > OS: Windows XP
>>> >> >>> > Submission from: (NULL) (198.144.201.14)
>>> >>
>>>
>>> >> >>> > Some of the help for setGeneric seems to have been garbled.
In the section
>>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a
single line 3rd
>>> >> >>> > paragraph) it says
>>> >> >>> >
>>> >> >>> > Note that calling 'setGeneric()' in this form is not strictly
>>> >> >>> > necessary before calling 'setMethod()' for the same function.
If
>>> >> >>> > the function specified in the call to 'setMethod' is not
generic,
>>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself.
>>> >> >>> > Declaring explicitly that you want the function to be generic
can
>>> >> >>> > be considered better programming style; the only difference in
the
>>> >> >>> > result, however, is that not doing so produces a You cannot
(and
>>> >> >>> > never need to) create an explicit generic version of the
primitive
>>> >> >>> > functions in the base package.
>>> >> >>> >
>>> >> >>>
>>> >> >>> > The stuff after the semi-colon of the final sentence is
garbled, or at least
>>> >> >>> > unparseable by me. Probably something got deleted by mistake.
>>> >> >>>
>>> >> >>
>>> >> >> The last sentence of this paragraph is also garbled:
>>> >> >>
>>> >> >> The description above is the effect when the package that owns the
>>> >> >> non-generic function has not created an implicit generic version.
>>> >> >> Otherwise, it is this implicit generic function that is us_same_
>>> >> >> version of the generic function will be created each time.
>>> >> >>
>>> >>
>>> >> > Off-list, I guess both of these paragraphs have very long lines in
the
>>> >> > source; maybe your emacs is truncating lines instead of wrapping,
or
>>> >> > something similar?
>>> >>
>>> >> Thank you, Martin, but no, we never have very long lines in the
>>> >> R sources (and *.Rd files belong to the sources),
>>> >> and then translation of the *.Rd file to a "data base" of
>>> >> text-help entries should keep newlines.
>>>
>>> > I meant that they _are_ very long in the source. Martin
>>>
>>> Oh dear, yes indeed, you are right!
>>>
>>> So, astonishing as that may be, indeed for the 'text' version of
>>> help, it seems that ... under some circumstances ...
>>> the (NAMESPACE-hidden) method
>>> utils:::print.help_files_with_topic()
>>>
>>> which ends up calling file.show() :
>>>
>>> if (file.exists(paste(RdDB, "rdx", sep = "."))) {
>>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB,
>>> basename(file)), out = tempfile("Rtxt"), package = pkgname)
>>> file.show(temp, title = gettextf("R Help on '%s'",
>>> topic), delete.file = TRUE)
>>> }
>>>
>>>
>>> *is* still influenced by the original *.Rd file's (lack) of new
>>> lines, somewhat astonishingly to me.
>>>
>>> Even more, I cannot understand that other people do not see the
>>> same phenomenon (though maybe they would if they cared to notice...),
>>> and also that you only get the "garbling" problem with ESS, and
>>> only for R version 2.10, but not 2.8.
>>> Did our 'Rd2txt()' change here on purpose?
>>>
>>
>> I seem to recall fixing a bug in the line wrapping code, but I can't
>> spot it in a quick glance over the log. Maybe I forgot to commit the
>> fix? I can't look into this now, but I'll follow up later.
DM> The patch I recalled did get committed on November 8, with this NEWS
entry:
DM> o Text help rendering did not handle very long input lines
DM> properly.
DM> So it made it into 2.10.1. Do you still see the problem there? I
don't
DM> see it in text help for setGeneric in the Windows gui.
DM> Duncan Murdoch
I think it was never a problem in the GUI,
however when using ESS.
For some reason, I did overlook that Ross was talking about
Windows. I had never checked it on Windows,
but did now {using our Windows terminal server}.
Indeed: R 2.10.0 with ESS shows the problem Ross found
R 2.10.1 with ESS *NO LONGER* shows the problem.
--> I'm CC'
Re: [Rd] ?setGeneric garbled (PR#14153)
On 19/12/2009 8:56 AM, Martin Maechler wrote:
>> "DM" == Duncan Murdoch
>> on Fri, 18 Dec 2009 15:03:26 -0500 writes:
>
> DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote:
> >> On 18/12/2009 12:54 PM, Martin Maechler wrote:
> Martin Morgan
> on Fri, 18 Dec 2009 07:40:13 -0800 writes:
> >>> > Martin Maechler wrote:
> >>> >>> Martin Morgan
> >>> >>> on Thu, 17 Dec 2009 09:54:54 -0800 writes:
> >>> >>
> >>> >> > Ross Boylan wrote:
> >>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote:
> >>> >> Ross Boylan
> >>> >> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes:
> >>> >> >>> > Full_Name: Ross Boylan
> >>> >> >>> > Version: 2.10.0
> >>> >> >>> > OS: Windows XP
> >>> >> >>> > Submission from: (NULL) (198.144.201.14)
> >>> >>
> >>>
> >>> >> >>> > Some of the help for setGeneric seems to have been garbled.
> In the section
> >>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a
> single line 3rd
> >>> >> >>> > paragraph) it says
> >>> >> >>> >
> >>> >> >>> > Note that calling 'setGeneric()' in this form is not strictly
> >>> >> >>> > necessary before calling 'setMethod()' for the same
> function. If
> >>> >> >>> > the function specified in the call to 'setMethod' is not
> generic,
> >>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself.
> >>> >> >>> > Declaring explicitly that you want the function to be
> generic can
> >>> >> >>> > be considered better programming style; the only difference
> in the
> >>> >> >>> > result, however, is that not doing so produces a You cannot
> (and
> >>> >> >>> > never need to) create an explicit generic version of the
> primitive
> >>> >> >>> > functions in the base package.
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>> > The stuff after the semi-colon of the final sentence is
> garbled, or at least
> >>> >> >>> > unparseable by me. Probably something got deleted by
> mistake.
> >>> >> >>>
> >>> >> >>
> >>> >> >> The last sentence of this paragraph is also garbled:
> >>> >> >>
> >>> >> >> The description above is the effect when the package that owns
> the
> >>> >> >> non-generic function has not created an implicit generic
> version.
> >>> >> >> Otherwise, it is this implicit generic function that is us_same_
> >>> >> >> version of the generic function will be created each time.
> >>> >> >>
> >>> >>
> >>> >> > Off-list, I guess both of these paragraphs have very long lines
> in the
> >>> >> > source; maybe your emacs is truncating lines instead of
> wrapping, or
> >>> >> > something similar?
> >>> >>
> >>> >> Thank you, Martin, but no, we never have very long lines in the
> >>> >> R sources (and *.Rd files belong to the sources),
> >>> >> and then translation of the *.Rd file to a "data base" of
> >>> >> text-help entries should keep newlines.
> >>>
> >>> > I meant that they _are_ very long in the source. Martin
> >>>
> >>> Oh dear, yes indeed, you are right!
> >>>
> >>> So, astonishing as that may be, indeed for the 'text' version of
> >>> help, it seems that ... under some circumstances ...
> >>> the (NAMESPACE-hidden) method
> >>> utils:::print.help_files_with_topic()
> >>>
> >>> which ends up calling file.show() :
> >>>
> >>> if (file.exists(paste(RdDB, "rdx", sep = "."))) {
> >>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB,
> >>> basename(file)), out = tempfile("Rtxt"), package = pkgname)
> >>> file.show(temp, title = gettextf("R Help on '%s'",
> >>> topic), delete.file = TRUE)
> >>> }
> >>>
> >>>
> >>> *is* still influenced by the original *.Rd file's (lack) of new
> >>> lines, somewhat astonishingly to me.
> >>>
> >>> Even more, I cannot understand that other people do not see the
> >>> same phenomenon (though maybe they would if they cared to notice...),
> >>> and also that you only get the "garbling" problem with ESS, and
> >>> only for R version 2.10, but not 2.8.
> >>> Did our 'Rd2txt()' change here on purpose?
> >>>
> >>
> >> I seem to recall fixing a bug in the line wrapping code, but I can't
> >> spot it in a quick glance over the log. Maybe I forgot to commit the
> >> fix? I can't look into this now, but I'll follow up later.
>
> DM> The patch I recalled did get committed on November 8, with this NEWS
> entry:
>
>
> DM> o Text help rendering did not handle very long input lines
> DM> properly.
>
>
> DM> So it made it into 2.10.1. Do you still see the problem there? I
> don't
> DM> see it in text help for setGeneric in the Windows gui.
>
> DM> Duncan Murdoch
>
> I think it was never a problem in the GUI,
> however when using ESS.
Re: [Rd] ?setGeneric garbled (PR#14153)
I confirm that R 2.10.1 fixes the problem under ESS 5.7.1 on Windows XP.
See below for one more comment.
On Sat, 2009-12-19 at 10:03 -0500, Duncan Murdoch wrote:
> On 19/12/2009 8:56 AM, Martin Maechler wrote:
> >> "DM" == Duncan Murdoch
> >> on Fri, 18 Dec 2009 15:03:26 -0500 writes:
> >
> > DM> On 18/12/2009 1:15 PM, Duncan Murdoch wrote:
> > >> On 18/12/2009 12:54 PM, Martin Maechler wrote:
> > Martin Morgan
> > on Fri, 18 Dec 2009 07:40:13 -0800 writes:
> > >>> > Martin Maechler wrote:
> > >>> >>> Martin Morgan
> > >>> >>> on Thu, 17 Dec 2009 09:54:54 -0800 writes:
> > >>> >>
> > >>> >> > Ross Boylan wrote:
> > >>> >> >> On Thu, 2009-12-17 at 15:24 +0100, Martin Maechler wrote:
> > >>> >> Ross Boylan
> > >>> >> on Thu, 17 Dec 2009 02:15:12 +0100 (CET) writes:
> > >>> >> >>> > Full_Name: Ross Boylan
> > >>> >> >>> > Version: 2.10.0
> > >>> >> >>> > OS: Windows XP
> > >>> >> >>> > Submission from: (NULL) (198.144.201.14)
> > >>> >>
> > >>>
> > >>> >> >>> > Some of the help for setGeneric seems to have been
> > garbled. In the section
> > >>> >> >>> > "Basic Use", 5th paragraph (where the example counts as a
> > single line 3rd
> > >>> >> >>> > paragraph) it says
> > >>> >> >>> >
> > >>> >> >>> > Note that calling 'setGeneric()' in this form is not
> > strictly
> > >>> >> >>> > necessary before calling 'setMethod()' for the same
> > function. If
> > >>> >> >>> > the function specified in the call to 'setMethod' is not
> > generic,
> > >>> >> >>> > 'setMethod' will execute the call to 'setGeneric' itself.
> > >>> >> >>> > Declaring explicitly that you want the function to be
> > generic can
> > >>> >> >>> > be considered better programming style; the only
> > difference in the
> > >>> >> >>> > result, however, is that not doing so produces a You
> > cannot (and
> > >>> >> >>> > never need to) create an explicit generic version of the
> > primitive
> > >>> >> >>> > functions in the base package.
> > >>> >> >>> >
> > >>> >> >>>
> > >>> >> >>> > The stuff after the semi-colon of the final sentence is
> > garbled, or at least
> > >>> >> >>> > unparseable by me. Probably something got deleted by
> > mistake.
> > >>> >> >>>
> > >>> >> >>
> > >>> >> >> The last sentence of this paragraph is also garbled:
> > >>> >> >>
> > >>> >> >> The description above is the effect when the package that
> > owns the
> > >>> >> >> non-generic function has not created an implicit generic
> > version.
> > >>> >> >> Otherwise, it is this implicit generic function that is
> > us_same_
> > >>> >> >> version of the generic function will be created each time.
> > >>> >> >>
> > >>> >>
> > >>> >> > Off-list, I guess both of these paragraphs have very long
> > lines in the
> > >>> >> > source; maybe your emacs is truncating lines instead of
> > wrapping, or
> > >>> >> > something similar?
> > >>> >>
> > >>> >> Thank you, Martin, but no, we never have very long lines in the
> > >>> >> R sources (and *.Rd files belong to the sources),
> > >>> >> and then translation of the *.Rd file to a "data base" of
> > >>> >> text-help entries should keep newlines.
> > >>>
> > >>> > I meant that they _are_ very long in the source. Martin
> > >>>
> > >>> Oh dear, yes indeed, you are right!
> > >>>
> > >>> So, astonishing as that may be, indeed for the 'text' version of
> > >>> help, it seems that ... under some circumstances ...
> > >>> the (NAMESPACE-hidden) method
> > >>> utils:::print.help_files_with_topic()
> > >>>
> > >>> which ends up calling file.show() :
> > >>>
> > >>> if (file.exists(paste(RdDB, "rdx", sep = "."))) {
> > >>> temp <- tools::Rd2txt(tools:::fetchRdDB(RdDB,
> > >>> basename(file)), out = tempfile("Rtxt"), package = pkgname)
> > >>> file.show(temp, title = gettextf("R Help on '%s'",
> > >>> topic), delete.file = TRUE)
> > >>> }
> > >>>
> > >>>
> > >>> *is* still influenced by the original *.Rd file's (lack) of new
> > >>> lines, somewhat astonishingly to me.
> > >>>
> > >>> Even more, I cannot understand that other people do not see the
> > >>> same phenomenon (though maybe they would if they cared to
> > notice...),
> > >>> and also that you only get the "garbling" problem with ESS, and
> > >>> only for R version 2.10, but not 2.8.
> > >>> Did our 'Rd2txt()' change here on purpose?
> > >>>
> > >>
> > >> I seem to recall fixing a bug in the line wrapping code, but I can't
> > >> spot it in a quick glance over the log. Maybe I forgot to commit
> > the
> > >> fix? I can't look into this now, but I'll follow up later.
> >
> > DM> The patch I recalled did get committed on November
Re: [Rd] choose(n,k) when n is almost integer
{I've changed the subject; it's really no longer about
lchoose()'s definition}
> Petr Savicky
> on Fri, 18 Dec 2009 00:14:49 +0100 writes:
> On Thu, Dec 17, 2009 at 03:10:49PM +0100, Martin Maechler wrote:
> [...]
MM> This, of course, is an even more compelling reason to implement
MM> the change of return log(abs(choose(.,.)),
MM> and at the moment, I'd even plan to "backport" that to R "2.10.1
MM> patched", as the current behavior is clearly bugous.
>>
>> This has now happened;
>> svn revisions 50775 and 50776 {R-devel and R-patched}.
> Thank you.
> When preparing a test, whether lchoose(n, k) \approx log(abs(choose(n,
k))), it
> appeared that there is a minor problem also in choose(n, k), when n is
very close
> to k, but not equal.
> options(digits=15)
> n <- 5 + (-15:15)*1e-8
> cbind(n, choose(n, 5))
> #n
> # [1,] 4.9985 0.99657500042
> # [2,] 4.9986 0.9968070
> # [3,] 4.9987 0.99703166698
> # [4,] 4.9988 0.9972627
> # [5,] 4.9989 0.99748833356
> # [6,] 4.9990 0.9977185
> # [7,] 4.9991 0.000
> # [8,] 4.9992 0.000
> # [9,] 4.9993 0.000
> # [10,] 4.9994 0.000
> # [11,] 4.9995 0.000
> # [12,] 4.9996 0.000
> # [13,] 4.9997 0.000
> # [14,] 4.9998 0.000
> # [15,] 4. 0.000
> # [16,] 5. 1.000
> # [17,] 5.0001 5.000
> # [18,] 5.0002 5.000
> # [19,] 5.0003 5.000
> # [20,] 5.0004 5.000
> # [21,] 5.0005 5.000
> # [22,] 5.0006 5.000
> # [23,] 5.0007 5.000
> # [24,] 5.0008 5.000
> # [25,] 5.0009 5.000
> # [26,] 5.0010 1.0022853
> # [27,] 5.0011 1.00251166690
> # [28,] 5.0012 1.0027427
> # [29,] 5.0013 1.00296833365
> # [30,] 5.0014 1.00319666704
> # [31,] 5.0015 1.00342500042
> All the values in the second column should be close to 1, but some are 0
and
> some are 5. The reason seems to be in the line 112 of src/nmath/choose.c,
> which is
> if(n-k < k && n >= 0 && R_IS_INT(n)) k = n-k; /* <- Symmetry */
> If n is not exactly an integer, then k becomes also non-integer.
> Since the code relies on k being an exact integer, we get an error
> as follows.
> If n = k - eps for a small positive eps, then the next line 113
> if (k < 0) return 0.;
> determines the output since k is now - eps.
> If n = k + eps for a small positive eps, then the line 116
> r = n;
> determines the output, since now k = eps, so the condition j <= k is not
> satisfied already at the beginning of the next cycle.
> I suggest two solutions, a more conservative one and a less conservative
one.
> A more conservative solution is to replace the line 112 by
> if(n-k < k && n >= 0 && R_IS_INT(n)) k = floor(n - k + 0.5); /* <-
Symmetry */
> This yields the following in the same test as above.
> #n
> # [1,] 4.9985 0.99657500042
> # [2,] 4.9986 0.9968070
> # [3,] 4.9987 0.99703166698
> # [4,] 4.9988 0.9972627
> # [5,] 4.9989 0.99748833356
> # [6,] 4.9990 0.9977185
> # [7,] 4.9991 1.000
> # [8,] 4.9992 1.000
> # [9,] 4.9993 1.000
> # [10,] 4.9994 1.000
> # [11,] 4.9995 1.000
> # [12,] 4.9996 1.000
> # [13,] 4.9997 1.000
> # [14,] 4.9998 1.000
> # [15,] 4. 1.000
> # [16,] 5. 1.000
> # [17,] 5.0001 1.000
> # [18,] 5.0002 1.000
> # [19,] 5.0003 1.000
> # [20,] 5.0004 1.000
> # [21,] 5.0005 1.000
> # [22,] 5.0006 1.000
> # [23,] 5.0007 1.000
> # [24,] 5.0008 1.000
> # [25,] 5.0009 1.000
> # [26,] 5.0010 1.0022853
> # [27,] 5.0011 1.00251166690
> # [28,] 5.0012 1.0027427
> # [29,] 5.0013 1.00296833365
> # [30,] 5.0014 1.00319666704
> # [31,] 5.0015 1.00342500042
> So, the extreme values 0 and 5 do not occur, but there is an interval
> of constant values and on both ends of this interval, there is a jump
> much larger than machine accuracy.
> A less conservative solution (a patch is in an attachment) re
