Re: [Rd] Build failure on powerpc64
> Martin Maechler
> on Tue, 17 Dec 2019 11:25:31 +0100 writes:
> Tom Callaway
> on Fri, 13 Dec 2019 11:06:25 -0500 writes:
>> An excellent question. It is important to remember two key
>> facts:
>> 1. With gcc on ppc64, long doubles exist, they can
>> be used, just not safely as constants (and maybe they
>> still can be used safely under specific conditions?).
>> 2. I am not an expert in either PowerPC64 or gcc. :)
>> Looking at connections.c, we have (in order):
>> * handling long double as a valid case in a switch statement checking
size
>> * adding long double as a field in the u union define
>> * handling long double as a valid case in a switch statement checking
size
>> * handling long double as a valid case in a switch statement checking
size
>> * memcpy from the address of a long double
>> In format.c, we have (in order):
>> * conditionally creating private_nearbyintl for R_nearbyintl
>> * defining a static const long double tbl[]
>> * use exact scaling factor in long double precision
>> For most of these, it seems safe to leave them as is for ppc64. I would
>> have thought that the gcc compiler might have had issue with:
>> connections.c:
>> static long double ld1;
>> for (i = 0, j = 0; i < len; i++, j += size) {
>> ld1 = (long double) REAL(object)[i];
>> format.c:
>> static const long double tbl[] =
>> ... but it doesn't. Perhaps the original code at issue:
>> arithmetic.c:
>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
>> only makes gcc unhappy because of the very large value trying to be
stored
>> in the static long double, which would make it span the "folded double"
on
>> that architecture.
>> *
>> It seems that the options are:
>> A) Patch the one place where the compiler determines it is not safe to
use
>> a static long double on ppc64.
>> B) Treat PPC64 as a platform where it is never safe to use a static long
>> double
>> FWIW, I did run the test suite after applying my patch and all of the
tests
>> pass on ppc64.
>> Tom
> Thank you, Tom.
> You were right... and only A) is needed.
> In the mean time I've also been CC'ed in a corresponding debian
> bug report on the exact same architecture.
> In the end, after explanation and recommendation by Tomas
> Kalibera, I've committed a slightly better change to R's
> sources, both in the R-devel (trunk) and the "R-3.6.x patched"
> branch: Via a macro, it continues to use long double also for
> the PPC 64 in this case:
> $ svn diff -c77587
> Index: src/main/arithmetic.c
> ===
> --- src/main/arithmetic.c (Revision 77586)
> +++ src/main/arithmetic.c (Revision 77587)
> @@ -176,8 +176,14 @@
> #endif
> }
> +
> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> +# ifdef __PPC64__
> + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding
with LDOUBLE
> +# define q_1_eps (1 / LDBL_EPSILON)
> +# else
> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> +# endif
> #else
> static double q_1_eps = 1 / DBL_EPSILON;
> #endif
> - - -
Now, Debian Bug#946836 has been reopened,
because __PPC64__ does not cover all powerpc architectures
and in their build farm they found non-PPC64 cases which also
needed to switch from a static variable to a macro,
the suggestion being to replace __PPC64__ by __powerpc__
which is what I'm going to commit now (for R-3.6.x patched and
for R-devel !).
I hope that these macros are +- universally working and not too
much depending on the exact compiler flavor.
Martin Maechler
ETH Zurich and R Core team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build failure on powerpc64
Do note that 3.6-patched will only be live for a day or two as we branch for
4.0.0 on Friday. Anything committed there is unlikely to make it into an
official release (in principle, the 3.6 branch can be revived but it would take
a very strong incentive to do so.)
If you want an R-3.6.3-for-ppc, I think a vendor patch is the way. AFAIR (it's
been more than a decade since I looked at this stuff) the RPM spec files make
it fairly easy to apply changes to the sources before building.
-pd
> On 25 Mar 2020, at 10:00 , Martin Maechler wrote:
>
>> Martin Maechler
>>on Tue, 17 Dec 2019 11:25:31 +0100 writes:
>
>> Tom Callaway
>>on Fri, 13 Dec 2019 11:06:25 -0500 writes:
>
>>> An excellent question. It is important to remember two key
>>> facts:
>
>>> 1. With gcc on ppc64, long doubles exist, they can
>>> be used, just not safely as constants (and maybe they
>>> still can be used safely under specific conditions?).
>
>>> 2. I am not an expert in either PowerPC64 or gcc. :)
>
>>> Looking at connections.c, we have (in order):
>>> * handling long double as a valid case in a switch statement checking size
>>> * adding long double as a field in the u union define
>>> * handling long double as a valid case in a switch statement checking size
>>> * handling long double as a valid case in a switch statement checking size
>>> * memcpy from the address of a long double
>
>>> In format.c, we have (in order):
>>> * conditionally creating private_nearbyintl for R_nearbyintl
>>> * defining a static const long double tbl[]
>>> * use exact scaling factor in long double precision
>
>>> For most of these, it seems safe to leave them as is for ppc64. I would
>>> have thought that the gcc compiler might have had issue with:
>
>>> connections.c:
>>> static long double ld1;
>>> for (i = 0, j = 0; i < len; i++, j += size) {
>>> ld1 = (long double) REAL(object)[i];
>
>>> format.c:
>>> static const long double tbl[] =
>
>>> ... but it doesn't. Perhaps the original code at issue:
>
>>> arithmetic.c:
>>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
>
>>> only makes gcc unhappy because of the very large value trying to be stored
>>> in the static long double, which would make it span the "folded double" on
>>> that architecture.
>
>>> *
>
>>> It seems that the options are:
>
>>> A) Patch the one place where the compiler determines it is not safe to use
>>> a static long double on ppc64.
>>> B) Treat PPC64 as a platform where it is never safe to use a static long
>>> double
>
>>> FWIW, I did run the test suite after applying my patch and all of the tests
>>> pass on ppc64.
>
>>> Tom
>
>> Thank you, Tom.
>> You were right... and only A) is needed.
>
>> In the mean time I've also been CC'ed in a corresponding debian
>> bug report on the exact same architecture.
>
>> In the end, after explanation and recommendation by Tomas
>> Kalibera, I've committed a slightly better change to R's
>> sources, both in the R-devel (trunk) and the "R-3.6.x patched"
>> branch: Via a macro, it continues to use long double also for
>> the PPC 64 in this case:
>
>> $ svn diff -c77587
>> Index: src/main/arithmetic.c
>> ===
>> --- src/main/arithmetic.c(Revision 77586)
>> +++ src/main/arithmetic.c(Revision 77587)
>> @@ -176,8 +176,14 @@
>> #endif
>> }
>
>> +
>> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
>> +# ifdef __PPC64__
>> + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with
>> LDOUBLE
>> +# define q_1_eps (1 / LDBL_EPSILON)
>> +# else
>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
>> +# endif
>> #else
>> static double q_1_eps = 1 / DBL_EPSILON;
>> #endif
>
>> - - -
>
> Now, Debian Bug#946836 has been reopened,
> because __PPC64__ does not cover all powerpc architectures
> and in their build farm they found non-PPC64 cases which also
> needed to switch from a static variable to a macro,
>
> the suggestion being to replace __PPC64__ by __powerpc__
>
> which is what I'm going to commit now (for R-3.6.x patched and
> for R-devel !).
> I hope that these macros are +- universally working and not too
> much depending on the exact compiler flavor.
>
> Martin Maechler
> ETH Zurich and R Core team
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build failure on powerpc64
This change seems correct, but as we don't have any non-PPC64 systems or
build targets in the Fedora buildsystem, it won't affect Fedora if it
doesn't make it.
Tom
On Wed, Mar 25, 2020, 6:16 AM peter dalgaard wrote:
> Do note that 3.6-patched will only be live for a day or two as we branch
> for 4.0.0 on Friday. Anything committed there is unlikely to make it into
> an official release (in principle, the 3.6 branch can be revived but it
> would take a very strong incentive to do so.)
>
> If you want an R-3.6.3-for-ppc, I think a vendor patch is the way. AFAIR
> (it's been more than a decade since I looked at this stuff) the RPM spec
> files make it fairly easy to apply changes to the sources before building.
>
> -pd
>
> > On 25 Mar 2020, at 10:00 , Martin Maechler
> wrote:
> >
> >> Martin Maechler
> >>on Tue, 17 Dec 2019 11:25:31 +0100 writes:
> >
> >> Tom Callaway
> >>on Fri, 13 Dec 2019 11:06:25 -0500 writes:
> >
> >>> An excellent question. It is important to remember two key
> >>> facts:
> >
> >>> 1. With gcc on ppc64, long doubles exist, they can
> >>> be used, just not safely as constants (and maybe they
> >>> still can be used safely under specific conditions?).
> >
> >>> 2. I am not an expert in either PowerPC64 or gcc. :)
> >
> >>> Looking at connections.c, we have (in order):
> >>> * handling long double as a valid case in a switch statement checking
> size
> >>> * adding long double as a field in the u union define
> >>> * handling long double as a valid case in a switch statement checking
> size
> >>> * handling long double as a valid case in a switch statement checking
> size
> >>> * memcpy from the address of a long double
> >
> >>> In format.c, we have (in order):
> >>> * conditionally creating private_nearbyintl for R_nearbyintl
> >>> * defining a static const long double tbl[]
> >>> * use exact scaling factor in long double precision
> >
> >>> For most of these, it seems safe to leave them as is for ppc64. I would
> >>> have thought that the gcc compiler might have had issue with:
> >
> >>> connections.c:
> >>> static long double ld1;
> >>> for (i = 0, j = 0; i < len; i++, j += size) {
> >>> ld1 = (long double) REAL(object)[i];
> >
> >>> format.c:
> >>> static const long double tbl[] =
> >
> >>> ... but it doesn't. Perhaps the original code at issue:
> >
> >>> arithmetic.c:
> >>> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> >
> >>> only makes gcc unhappy because of the very large value trying to be
> stored
> >>> in the static long double, which would make it span the "folded
> double" on
> >>> that architecture.
> >
> >>> *
> >
> >>> It seems that the options are:
> >
> >>> A) Patch the one place where the compiler determines it is not safe to
> use
> >>> a static long double on ppc64.
> >>> B) Treat PPC64 as a platform where it is never safe to use a static
> long
> >>> double
> >
> >>> FWIW, I did run the test suite after applying my patch and all of the
> tests
> >>> pass on ppc64.
> >
> >>> Tom
> >
> >> Thank you, Tom.
> >> You were right... and only A) is needed.
> >
> >> In the mean time I've also been CC'ed in a corresponding debian
> >> bug report on the exact same architecture.
> >
> >> In the end, after explanation and recommendation by Tomas
> >> Kalibera, I've committed a slightly better change to R's
> >> sources, both in the R-devel (trunk) and the "R-3.6.x patched"
> >> branch: Via a macro, it continues to use long double also for
> >> the PPC 64 in this case:
> >
> >> $ svn diff -c77587
> >> Index: src/main/arithmetic.c
> >> ===
> >> --- src/main/arithmetic.c(Revision 77586)
> >> +++ src/main/arithmetic.c(Revision 77587)
> >> @@ -176,8 +176,14 @@
> >> #endif
> >> }
> >
> >> +
> >> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> >> +# ifdef __PPC64__
> >> + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding
> with LDOUBLE
> >> +# define q_1_eps (1 / LDBL_EPSILON)
> >> +# else
> >> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> >> +# endif
> >> #else
> >> static double q_1_eps = 1 / DBL_EPSILON;
> >> #endif
> >
> >> - - -
> >
> > Now, Debian Bug#946836 has been reopened,
> > because __PPC64__ does not cover all powerpc architectures
> > and in their build farm they found non-PPC64 cases which also
> > needed to switch from a static variable to a macro,
> >
> > the suggestion being to replace __PPC64__ by __powerpc__
> >
> > which is what I'm going to commit now (for R-3.6.x patched and
> > for R-devel !).
> > I hope that these macros are +- universally working and not too
> > much depending on the exact compiler flavor.
> >
> > Martin Maechler
> > ETH Zurich and R Core team
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Bu
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On Wed, 25 Mar 2020 at 01:14, Gavin Simpson wrote: > > Dear list > > On Fedora 31 the pango library has recently updated to version >= 1.44 > and in doing so has switched to using the HarfBuzz library (from > FreeType) and dropped Adobe Type 1 font support. This causes problems > with plotmath as all bar one of the glyphs doesn't render (see > attached PNG image if it makes it through the list filters - if not I > have shared a copy via my google drive: > https://drive.google.com/file/d/1llFqKHD7LFKzQbVuq6sibY1UizRn7xxS/view?usp=sharing > ) > > I'm not the only person who has come across this, e.g. > https://stackoverflow.com/q/60656445/429846 and the resulting reported > bug on the RedHat Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=1815128 > > Beyond switching to `type = 'Xlib'`, has anyone worked around this > issue on a Fedora 31 or later system? Adding de...@lists.fp.o to CC. A workaround is to avoid using PS fonts for symbols. If you run the following, you'll see $ fc-match Symbol StandardSymbolsPS.t1: "Standard Symbols PS" "Regular" So let's change this. Install a TTF symbol font, such as Symbola: $ sudo dnf install gdouros-symbola-fonts Then add the following to /etc/fonts/local.conf (system-wide) or ~/.fonts.conf (just for your user): Symbol Symbola Now you should see this: $ fc-match Symbol Symbola.ttf: "Symbola" "Regular" and symbols should render correctly. Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Le mercredi 25 mars 2020 à 11:28 +0100, Iñaki Ucar a écrit : > On Wed, 25 Mar 2020 at 01:14, Gavin Simpson > wrote: Hi, > Adding de...@lists.fp.o to CC. A workaround is to avoid using PS > fonts for symbols. PS fonts are dead mid-term everywhere, and already forbidden in new Fedora font packages (because we are somewhat leading edge, but not as much as people think) https://docs.fedoraproject.org/en-US//packaging-guidelines/FontsPolicy/#_font_file_formats PS font users need to switch to OpenType fonts or work with their prefered font upstream to convert in modern well supported formats (font format wars have endend last millenium, even before the browser wars ended, it’s long past time to deprecate the losers). That’s normal IT format obsolescence. That being said, that’s not what is happening here. R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. Fontconfig upstream already told this to R users in its own issue tracker. Regards, -- Nicolas Mailhot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] contribution to package graphics::barplot
Dear R-devel members, I made a small modification in the graphics::barplot function when used with a matrix and beside argument set to false in order to be able to order each bar according to its value (from smaller to bigger or bigger to smaller), while keeping the colors. It may be of general interest (for example to be able to visualize the occurrences of letters from different texts, or the rank of a condition...). I used it in Figure 3 of one of my article here (http://dx.doi.org/10./eea.12693). I would like to ask you if it's worth proposing the modification to the barplot function (and how to do so ?) or if I should consider building a separate R package ? The modified function is attached with modifications from lines 119 and 170, and examples from lines 230. Thanks in advance, Best regards __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] WISH: Sys.setlocale() to return value invisibly
I case someone runs into this topic. I just found the following
comment from 2012 on BugZilla explaining why Sys.setlocale() does
*not* return invisibly contrary to most++ other setters in R:
PR#15128: Sys.setlocale() - return previous setting invisibly?
Brian Ripley on 2012-12-09 16:53:43 UTC:
> It was a deliberate decision. Unlike options() the locale is usually set at
> startup and it is major thing to change it in a session--and it is usually
> only done recording the previous value to return to. The author certainly
> wanted to see what he was changing from in a session.
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15128#c1
/Henrik
On Tue, Mar 20, 2018 at 2:11 PM Henrik Bengtsson
wrote:
>
> Contrary to, say, Sys.setenv(), Sys.setlocale() returns it's value
> visibly. This means that if you for instance add:
>
> Sys.setlocale("LC_COLLATE", "C")
>
> to your .Rprofile file, it will print:
>
> [1] "C"
>
> at startup. The workaround is to wrap the call in invisible(), but I'd
> argue that any "setter" function should return invisibly.
>
> Some more details:
>
> > withVisible(Sys.setlocale("LC_COLLATE", "C"))
> $value
> [1] "C"
>
> $visible
> [1] TRUE
>
> > withVisible(Sys.setenv(FOO = "C"))
> $value
> [1] TRUE
>
> $visible
> [1] FALSE
>
> /Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Thanks Iñaki, that worked a treat. Gavin On Wed, 25 Mar 2020 at 04:28, Iñaki Ucar wrote: > > On Wed, 25 Mar 2020 at 01:14, Gavin Simpson wrote: > > > > Dear list > > > > On Fedora 31 the pango library has recently updated to version >= 1.44 > > and in doing so has switched to using the HarfBuzz library (from > > FreeType) and dropped Adobe Type 1 font support. This causes problems > > with plotmath as all bar one of the glyphs doesn't render (see > > attached PNG image if it makes it through the list filters - if not I > > have shared a copy via my google drive: > > https://drive.google.com/file/d/1llFqKHD7LFKzQbVuq6sibY1UizRn7xxS/view?usp=sharing > > ) > > > > I'm not the only person who has come across this, e.g. > > https://stackoverflow.com/q/60656445/429846 and the resulting reported > > bug on the RedHat Bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=1815128 > > > > Beyond switching to `type = 'Xlib'`, has anyone worked around this > > issue on a Fedora 31 or later system? > > Adding de...@lists.fp.o to CC. A workaround is to avoid using PS fonts > for symbols. If you run the following, you'll see > > $ fc-match Symbol > StandardSymbolsPS.t1: "Standard Symbols PS" "Regular" > > So let's change this. Install a TTF symbol font, such as Symbola: > > $ sudo dnf install gdouros-symbola-fonts > > Then add the following to /etc/fonts/local.conf (system-wide) or > ~/.fonts.conf (just for your user): > > > > Symbol > >Symbola > > > > > Now you should see this: > > $ fc-match Symbol > Symbola.ttf: "Symbola" "Regular" > > and symbols should render correctly. > > Iñaki -- Gavin Simpson, PhD __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] contribution to package graphics::barplot
> Francois Rebaudo
> on Wed, 25 Mar 2020 15:47:45 +0100 writes:
> Dear R-devel members,
> I made a small modification in the graphics::barplot function when used
with a matrix and beside argument set to false in order to be able to order
each bar according to its value (from smaller to bigger or bigger to smaller),
while keeping the colors. It may be of general interest (for example to be able
to visualize the occurrences of letters from different texts, or the rank of a
condition...). I used it in Figure 3 of one of my article here
(http://dx.doi.org/10./eea.12693).
> I would like to ask you if it's worth proposing the modification to the
barplot function (and how to do so ?) or if I should consider building a
separate R package ? The modified function is attached with modifications from
lines 119 and 170, and examples from lines 230.
Because you did *not* attach the R script as a text file (well
from one of the 99% of mail programs which do *not* allow you to
set the MIME-type of an attachment)
it was attached as MIME type "application/octet-stream" which
translates to basically "unspecified/binary"
and such unknown attachments are not allowed (for virus and spam
protection).
But then, because I'm one of the moderators of the R-devel list who
had to approve your message, I got an e-mail from which I can
extract the attachment, and as I'm using e-mail software from
the rare group where you *can* specify the MIME type, I attach
it here, for you and all readers.
Best regards,
Martin Maechler
> Thanks in advance,
> Best regards
# File src/library/graphics/R/barplot.R
# Part of the R package, https://www.R-project.org
#
# Copyright (C) 1995-2019 The R Core Team
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# A copy of the GNU General Public License is available at
# https://www.R-project.org/Licenses/
# modified by F. Rebaudo to be able to order bar according to its value
# while keeping the color.
barplot <- function(height, ...) UseMethod("barplot")
barplot2 <-
function(height, width = 1, space = NULL, names.arg = NULL,
legend.text = NULL, beside = FALSE, horiz = FALSE,
density = NULL, angle = 45,
col = NULL, border = par("fg"),
main = NULL, sub = NULL, xlab = NULL, ylab = NULL,
xlim = NULL, ylim = NULL, xpd = TRUE, log = "",
axes = TRUE, axisnames = TRUE,
cex.axis = par("cex.axis"), cex.names = par("cex.axis"),
inside = TRUE, plot = TRUE, axis.lty = 0, offset = 0, add = FALSE,
ann = !add && par("ann"), args.legend = NULL, order = FALSE,
decr = TRUE, ...)
{
if (!missing(inside)) .NotYetUsed("inside", error = FALSE)# -> help(.)
if (is.null(space))
space <- if (is.matrix(height) && beside) c(0, 1) else 0.2
space <- space * mean(width)
if (plot && axisnames && is.null(names.arg))
names.arg <-
if(is.matrix(height)) colnames(height) else names(height)
vectorInput <- (is.vector(height)
|| (is.array(height) && (length(dim(height)) == 1)))
## Treat vectors and 1-d arrays the same.
if(vectorInput){
height <- cbind(height)
beside <- TRUE
## The above may look strange, but in particular makes color
## specs work as most likely expected by the users.
if(is.null(col)) col <- "grey"
} else if (is.matrix(height)) {
## In the matrix case, we use "colors" by default.
if(is.null(col))
col <- gray.colors(nrow(height))
} else {
stop("'height' must be a vector or a matrix")
}
if(is.logical(legend.text))
legend.text <-
if(legend.text && is.matrix(height)) rownames(height)
stopifnot(is.character(log))
logx <- logy <- FALSE
if (log != "") {
logx <- length(grep("x", log)) > 0L
logy <- length(grep("y", log)) > 0L
}
## Cannot use rect(*, density=.) when log scales used
if ((logx || logy) && !is.null(density))
stop("Cannot use shading lines in bars when log scale is used")
NR <- nrow(height)
NC <- ncol(height)
if (beside) {
if (length(space) == 2 && !vectorInput)
space <- rep.int(c(space[2L], rep.int(space[1L], NR - 1)), NC)
width <- rep_len(width, NR)
} else {
width <- rep_len(width, NC)
}
offset <- rep_len(as.vector(offset), length(width))
delta <- width / 2
w.r <- cumsum(space + width)
w.m <- w.r - delta
[Rd] unstable corner of parameter space for qbeta?
I've discovered an infelicity (I guess) in qbeta(): it's not a bug,
since there's a clear warning about lack of convergence of the numerical
algorithm ("full precision may not have been achieved"). I can work
around this, but I'm curious why it happens and whether there's a better
workaround -- it doesn't seem to be in a particularly extreme corner of
parameter space. It happens, e.g., for these parameters:
phi <- 1.1
i <- 0.01
t <- 0.001
shape1 = i/phi ## 0.009090909
shape2 = (1-i)/phi ## 0.9
qbeta(t,shape1,shape2) ## 5.562685e-309
## brute-force uniroot() version, see below
Qbeta0(t,shape1,shape2) ## 0.9262824
The qbeta code is pretty scary to read: the warning "full precision
may not have been achieved" is triggered here:
https://github.com/wch/r-source/blob/f8d4d7d48051860cc695b99db9be9cf439aee743/src/nmath/qbeta.c#L530
Any thoughts? Should I report this on the bug list?
A more general illustration:
http://www.math.mcmaster.ca/bolker/misc/qbeta.png
===
fun <- function(phi,i=0.01,t=0.001, f=qbeta) {
f(t,shape1=i/phi,shape2=(1-i)/phi, lower.tail=FALSE)
}
## brute-force beta quantile function
Qbeta0 <- function(t,shape1,shape2,lower.tail=FALSE) {
fn <- function(x) {pbeta(x,shape1,shape2,lower.tail=lower.tail)-t}
uniroot(fn,interval=c(0,1))$root
}
Qbeta <- Vectorize(Qbeta0,c("t","shape1","shape2"))
curve(fun,from=1,to=4)
curve(fun(x,f=Qbeta),add=TRUE,col=2)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
