Re: [Rd] [FORGED] Re: plotmath degree symbol
Thanks, Paul -- setting the ~/.fonts.conf file the way ?X11 describes it under the section you pointed to resolved the problem for me, on ubuntu. On 09/04/2018 11:55 PM, Paul Murrell wrote: > Hi > > Thanks for that, but I still cannot confirm on ... > > sudo docker run -v $(pwd):/home/work/ -w /home/work --rm -ti > rocker/r-ver:3.5.1 > > Could you please read the comments within the "Cairo Fonts" section of > the ?X11 help page, in case that offers some explanation. > > Paul > > > On 29/08/18 02:15, Martin Møller Skarbiniks Pedersen wrote: >> On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma >> wrote: >>> >>> In plotmath expressions, R's degree symbol, e.g. shown by >>> >>> plot(1, main = parse(text = "1*degree*C")) >>> >>> has sunk to halfway the text line, instead of touching its top. In older >>> R versions this looked much better. >> >> I can confirm this problem. >> >> R version 3.5.1 (2018-07-02) >> Platform: x86_64-pc-linux-gnu (64-bit) >> Running under: Ubuntu 18.04.1 LTS >> >> Matrix products: default >> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 >> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 >> >> locale: >> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> loaded via a namespace (and not attached): >> [1] compiler_3.5.1 >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Edzer Pebesma Institute for Geoinformatics Heisenbergstrasse 2, 48151 Muenster, Germany Phone: +49 251 8333081 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] True length - length(unclass(x)) - without having to call unclass()?
On 08/24/2018 07:55 PM, Henrik Bengtsson wrote: Is there a low-level function that returns the length of an object 'x' - the length that for instance .subset(x) and .subset2(x) see? An obvious candidate would be to use: .length <- function(x) length(unclass(x)) However, I'm concerned that calling unclass(x) may trigger an expensive copy internally in some cases. Is that concern unfounded? Unclass() will always copy when "x" is really a variable, because the value in "x" will be referenced; whether it is prohibitively expensive or not depends only on the workload - if "x" is a very long list and this functions is called often then it could, but at least to me this sounds unlikely. Unless you have a strong reason to believe it is the case I would just use length(unclass(x)). If the copying is really a problem, I would think about why the underlying vector length is needed at R level - whether you really need to know the length without actually having the unclassed vector anyway for something else, so whether you are not paying for the copy anyway. Or, from the other end, if you need to do more without copying, and it is possible without breaking the value semantics, then you might need to switch to C anyway and for a bigger piece of code. If it were still just .length() you needed and it were performance critical, you could just switch to C and call Rf_length. That does not violate the semantics, just indeed it is not elegant as you are switching to C. If you stick to R and can live with the overhead of length(unclass(x)) then there is a chance the overhead will decrease as R is optimized internally. This is possible in principle when the runtime knows that the unclassed vector is only needed to compute something that does not modify the vector. The current R cannot optimize this out, but it should be possible with ALTREP at some point (and as Radford mentioned pqR does it differently). Even with such internal optimizations indeed it is often necessary to make guesses about realistic workloads, so if you have a realistic workload where say length(unclass(x)) is critical, you are more than welcome to donate it as benchmark. Obviously, if you use a C version calling Rf_length, after such R optimization your code would be unnecessarily non-elegant, but would still work and probably without overhead, because R can't do much less than Rf_length. In more complicated cases though hand-optimized C code to implement say 2 operations in sequence could be slower than what better optimizing runtime could do by joining the effect of possibly more operations, which is in principle another danger of switching from R to C. But as far as the semantics is followed, there is no other danger. The temptation should be small anyway in this case when Rf_length() would be the simplest, but as I made it more than clear in the previous email, one should never violate the value semantics by temporarily modifying the object (temporarily removing the class attribute or temporarily remove the object bit). Violating semantics causes bugs, if not with the present then with future versions of R (where version may be an svn revision). A concrete recent example: modifying objects in place in violation of the semantics caused a lot of bugs with introduction of unification of constants in the byte-code compiler. Best Tomas Thxs, Henrik __ 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] True length - length(unclass(x)) - without having to call unclass()?
The bottomline here is that one can always call a base method,
inexpensively and without modifying the object, in, let's say,
*formal* OOP languages. In R, this is not possible in general. It
would be possible if there was always a foo.default, but primitives
use internal dispatch.
I was wondering whether it would be possible to provide a super(x, n)
function which simply causes the dispatching system to avoid "n"
classes in the hierarchy, so that:
> x <- structure(list(), class=c("foo", "bar"))
> length(super(x, 0)) # looks for a length.foo
> length(super(x, 1)) # looks for a length.bar
> length(super(x, 2)) # calls the default
> length(super(x, Inf)) # calls the default
Iñaki
El mié., 5 sept. 2018 a las 10:09, Tomas Kalibera
() escribió:
>
> On 08/24/2018 07:55 PM, Henrik Bengtsson wrote:
> > Is there a low-level function that returns the length of an object 'x'
> > - the length that for instance .subset(x) and .subset2(x) see? An
> > obvious candidate would be to use:
> >
> > .length <- function(x) length(unclass(x))
> >
> > However, I'm concerned that calling unclass(x) may trigger an
> > expensive copy internally in some cases. Is that concern unfounded?
> Unclass() will always copy when "x" is really a variable, because the
> value in "x" will be referenced; whether it is prohibitively expensive
> or not depends only on the workload - if "x" is a very long list and
> this functions is called often then it could, but at least to me this
> sounds unlikely. Unless you have a strong reason to believe it is the
> case I would just use length(unclass(x)).
>
> If the copying is really a problem, I would think about why the
> underlying vector length is needed at R level - whether you really need
> to know the length without actually having the unclassed vector anyway
> for something else, so whether you are not paying for the copy anyway.
> Or, from the other end, if you need to do more without copying, and it
> is possible without breaking the value semantics, then you might need to
> switch to C anyway and for a bigger piece of code.
>
> If it were still just .length() you needed and it were performance
> critical, you could just switch to C and call Rf_length. That does not
> violate the semantics, just indeed it is not elegant as you are
> switching to C.
>
> If you stick to R and can live with the overhead of length(unclass(x))
> then there is a chance the overhead will decrease as R is optimized
> internally. This is possible in principle when the runtime knows that
> the unclassed vector is only needed to compute something that does not
> modify the vector. The current R cannot optimize this out, but it should
> be possible with ALTREP at some point (and as Radford mentioned pqR does
> it differently). Even with such internal optimizations indeed it is
> often necessary to make guesses about realistic workloads, so if you
> have a realistic workload where say length(unclass(x)) is critical, you
> are more than welcome to donate it as benchmark.
>
> Obviously, if you use a C version calling Rf_length, after such R
> optimization your code would be unnecessarily non-elegant, but would
> still work and probably without overhead, because R can't do much less
> than Rf_length. In more complicated cases though hand-optimized C code
> to implement say 2 operations in sequence could be slower than what
> better optimizing runtime could do by joining the effect of possibly
> more operations, which is in principle another danger of switching from
> R to C. But as far as the semantics is followed, there is no other danger.
>
> The temptation should be small anyway in this case when Rf_length()
> would be the simplest, but as I made it more than clear in the previous
> email, one should never violate the value semantics by temporarily
> modifying the object (temporarily removing the class attribute or
> temporarily remove the object bit). Violating semantics causes bugs, if
> not with the present then with future versions of R (where version may
> be an svn revision). A concrete recent example: modifying objects in
> place in violation of the semantics caused a lot of bugs with
> introduction of unification of constants in the byte-code compiler.
>
> Best
> Tomas
>
> >
> > Thxs,
> >
> > Henrik
> >
> > __
> > 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
--
Iñaki Ucar
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] True length - length(unclass(x)) - without having to call unclass()?
More generally, I think one of the issues is that R is not yet able to
decrement a reference count (or mark a 'shared' data object as
'unshared' after it knows only one binding to it exists). This means
passing variables to R closures will mark that object as shared:
x <- list()
.Internal(inspect(x)) # NAM(1)
identity(x)
.Internal(inspect(x)) # NAM(3)
I think for this reason users often resort to 'hacks' that involve
directly setting attributes on the object, since they 'know' only one
reference to a particular object exists. I'm not sure if this really
is 'safe', though -- likely not given potential future optimizations
to R, as Tomas has alluded to.
I think true reference counting has been implemented in the R sources,
but the switch has not yet been flipped to enable that by default.
Hopefully having that will make cases like the above work as expected?
Thanks,
Kevin
On Wed, Sep 5, 2018 at 2:19 AM Iñaki Ucar wrote:
>
> The bottomline here is that one can always call a base method,
> inexpensively and without modifying the object, in, let's say,
> *formal* OOP languages. In R, this is not possible in general. It
> would be possible if there was always a foo.default, but primitives
> use internal dispatch.
>
> I was wondering whether it would be possible to provide a super(x, n)
> function which simply causes the dispatching system to avoid "n"
> classes in the hierarchy, so that:
>
> > x <- structure(list(), class=c("foo", "bar"))
> > length(super(x, 0)) # looks for a length.foo
> > length(super(x, 1)) # looks for a length.bar
> > length(super(x, 2)) # calls the default
> > length(super(x, Inf)) # calls the default
>
> Iñaki
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svg ignores cex.axis in R3.5.1 on macOS
Seems ok on my system. Axis label size changes when cex.axis does.
## tested in the middle of another long session, so many additional packages
are attached, including some personal packages not available elsewhere
> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.6
Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] survival_2.42-3 ROracle_1.3-1 DBI_1.0.0 bookdown_0.7knitr_1.20
rmarkdown_1.10 wdr_3.2 taurus_3.2-4xlsx_0.6.1
[10] rmacq_1.3-8
loaded via a namespace (and not attached):
[1] Rcpp_0.12.17magrittr_1.5splines_3.5.1 lattice_0.20-35 highr_0.7
stringr_1.3.1 tools_3.5.1 grid_3.5.1 xfun_0.3
[10] tinytex_0.6 htmltools_0.3.6 yaml_2.1.19 rprojroot_1.3-2
digest_0.6.15 zip_1.0.0 Matrix_1.2-14 rJava_0.9-10xlsxjars_0.6.1
[19] evaluate_0.10.1 openxlsx_4.1.0 stringi_1.2.3 compiler_3.5.1
backports_1.1.2
--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
Lab cell 925-724-7509
On 8/31/18, 1:02 PM, "R-devel on behalf of Spencer Graves"
wrote:
On 2018-08-31 14:21, Spencer Graves wrote:
> Plots produced using svg in R 3.5.1 under macOS 10.13.6 ignores
> cex.axis=2. Consider the following:
>
>
> > plot(1:2, cex.axis=2)
> > svg('svg_ignores_cex.axis.svg')
> > plot(1:2, cex.axis=2)
> > dev.off()
> > sessionInfo()
> R version 3.5.1 (2018-07-02)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS High Sierra 10.13.6
>
> Matrix products: default
> BLAS:
>
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
> LAPACK:
>
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.1
>
>
> ** The axis labels are appropriately expanded with the first
> "plot(1:2, cex.axis=2)". However, when I wrote that to an svg file
> and opened it in other applications (GIMP and Safari), the cex.axis
> request was ignored. This also occurred inside RStudio on my Mac. It
> worked properly using R 3.2.1 under Windows 7.
I just confirmed that when I created a file like this under Windows 7
and brought it back to my Mac, it displayed fine. I have not tried this
with the current version of R under Windows 7 nor an old version of R on
my Mac. Thanks. Spencer
>
>
> Thanks,
> Spencer Graves
>
> __
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: plotmath degree symbol
Awesome. Thanks for confirming. Paul On 05/09/18 19:46, Edzer Pebesma wrote: Thanks, Paul -- setting the ~/.fonts.conf file the way ?X11 describes it under the section you pointed to resolved the problem for me, on ubuntu. On 09/04/2018 11:55 PM, Paul Murrell wrote: Hi Thanks for that, but I still cannot confirm on ... sudo docker run -v $(pwd):/home/work/ -w /home/work --rm -ti rocker/r-ver:3.5.1 Could you please read the comments within the "Cairo Fonts" section of the ?X11 help page, in case that offers some explanation. Paul On 29/08/18 02:15, Martin Møller Skarbiniks Pedersen wrote: On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. I can confirm this problem. R version 3.5.1 (2018-07-02) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.5.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] True length - length(unclass(x)) - without having to call unclass()?
On Wed, 5 Sep 2018, Kevin Ushey wrote:
More generally, I think one of the issues is that R is not yet able to
decrement a reference count (or mark a 'shared' data object as
'unshared' after it knows only one binding to it exists). This means
passing variables to R closures will mark that object as shared:
x <- list()
.Internal(inspect(x)) # NAM(1)
identity(x)
.Internal(inspect(x)) # NAM(3)
I think for this reason users often resort to 'hacks' that involve
directly setting attributes on the object, since they 'know' only one
reference to a particular object exists. I'm not sure if this really
is 'safe', though -- likely not given potential future optimizations
to R, as Tomas has alluded to.
I think true reference counting has been implemented in the R sources,
but the switch has not yet been flipped to enable that by default.
Hopefully having that will make cases like the above work as expected?
Current R-devel built with reference counting by setting
CFLAGS="-O3 -g -Wall -pedantic -DSWITCH_TO_REFCNT"
gives
x <- list()
.Internal(inspect(x))
## @55ad788e3b28 19 VECSXP g0c0 [REF(1)] (len=0, tl=0)
identity(x)
## list()
.Internal(inspect(x))
## @55ad788e3b28 19 VECSXP g0c0 [REF(1)] (len=0, tl=0)
I'm moderately hopeful we'll be able to switch to this for 3.6.0 but
depends on finding enough time to sort out some loose ends.
Best,
luke
Thanks,
Kevin
On Wed, Sep 5, 2018 at 2:19 AM Iñaki Ucar wrote:
The bottomline here is that one can always call a base method,
inexpensively and without modifying the object, in, let's say,
*formal* OOP languages. In R, this is not possible in general. It
would be possible if there was always a foo.default, but primitives
use internal dispatch.
I was wondering whether it would be possible to provide a super(x, n)
function which simply causes the dispatching system to avoid "n"
classes in the hierarchy, so that:
x <- structure(list(), class=c("foo", "bar"))
length(super(x, 0)) # looks for a length.foo
length(super(x, 1)) # looks for a length.bar
length(super(x, 2)) # calls the default
length(super(x, Inf)) # calls the default
Iñaki
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] config.status: error: cannot find input file: `po/Makefile.in'
Hi, Does anyone else see the following or is it just me? It usually works fine. I checked latest R-devel commits and couldn't see anything very recently changed or fixed w.r.t. po/ or Makefile. wget https://stat.ethz.ch/R/daily/R-devel.tar.gz tar xvf R-devel.tar.gz cd R-devel ./configure --without-recommended-packages ... config.status: error: cannot find input file: `po/Makefile.in' $ lsb_release -a Description:Ubuntu 18.04.1 LTS Release:18.04 Codename: bionic Best, Matt [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
