Re: [Rd] Expressions from boxplot() passed to bxp()

[peter dalgaard]

It's not new anyway. You see the same behaviour with

boxplot(dat, ylab=quote(X[2]))

and it boils down to the use of do.call("bxp", ...) in the internals. 

As a general matter, expression() exists to prevent this sort of confusion, 
e.g., in this construction,

> X <- quote(Y+1); bquote(f(.(X)))
f(Y + 1)

is indistinguishable from just entering f(Y+1), so f has no way of detecting 
whether or not it is intended to evaluate Y + 1. The same thing is happening 
with do.call: call objects are being "spliced into" the generated call, and if 
they are not protected with expression, you have the trouble.

I don't know whether it is worth trying to change this. You know the 
workaround. 

-pd



> On 27 Mar 2020, at 02:55 , Marius Hofert  wrote:
> 
> Hi,
> 
> Is this expected behavior (R-3.6.0)?
> 
> dat <- cbind(x = 1:10, y = 10:1)
> ylab <- substitute(X[t], list(t = 2))
> plot(dat, ylab = ylab) # works (correctly displays ylab)
> boxplot(dat, ylab = ylab) # fails
> boxplot(dat, ylab = as.expression(ylab)) # works
> 
> Thanks & cheers,
> M
> 
> __
> 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

[Rd] Possibility of Less Verbose Stack Trace

[Dario Strbenac]

Good day,

Is there a setting the user can change to make R CMD check stack traces output 
less and make it easier to spot the line of code that's the problem? I use R 
Under development. Part of the trace I see looks like:

 --- R stacktrace ---
where 1: .local(model, test, ...)
where 2: (new("nonstandardGenericFunction", .Data = function (model, test, 
...) 
{
standardGeneric("elasticNetGLMpredictInterface")
}, generic = "elasticNetGLMpredictInterface", package = "ClassifyR", 
group = list(), valueClass = character(0), signature = c("model", 
"test"), default = NULL, skeleton = (function (model, test, 
...) 
stop("invalid call in method dispatch to 'elasticNetGLMpredictInterface' 
(no default method)", 
domain = NA))(model, test, ...)))(list(a0 = c(6.93889390390723e-18, 
-6.93889390390723e-18, -0.0310874816356895, 0.0310874816356895, 
-0.0620911054955688, 0.0620911054955688, -0.0928473601925787, 
0.0928473601925787, -0.123341821729885, 0.123341821729885, -0.153584353208459, 
0.153584353208459, -0.183545850472993, 0.183545850472993, -0.214085623051265, 
0.214085623051265, -0.248487474466851, 0.248487474466851, -0.28259316439965, 
0.28259316439965, -0.316570319872031, 0.316570319872031, -0.35002247515684, 
0.35002247515684, -0.383505934741196, 0.383505934741196, -0.416591574658365, 
0.416591574658365, -0.449236359758103, 0.449236359758103, -0.481785697995159, 

and hundreds more lines of numbers. R CMD check -h doesn't seem to list any 
options which could be applicable.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
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?

[Iñaki Ucar]

On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
 wrote:
>
> 
>
> 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.

So, in the light of Nicolas' input (thanks!), I think that font
selection should be fixed upstream in R. I'd be happy to put all this
together in R's bugzilla, but I don't have an account. Could someone
please invite me?

Iñaki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [External] Re: Expressions from boxplot() passed to bxp()

[luke-tierney]

On Fri, 27 Mar 2020, peter dalgaard wrote:


It's not new anyway. You see the same behaviour with

boxplot(dat, ylab=quote(X[2]))

and it boils down to the use of do.call("bxp", ...) in the internals.

As a general matter, expression() exists to prevent this sort of confusion, 
e.g., in this construction,


X <- quote(Y+1); bquote(f(.(X)))

f(Y + 1)

is indistinguishable from just entering f(Y+1), so f has no way of detecting whether or 
not it is intended to evaluate Y + 1. The same thing is happening with do.call: call 
objects are being "spliced into" the generated call, and if they are not 
protected with expression, you have the trouble.


do.call has a 'quote' argument that can be used to address this. The
default is quote = FALSE, which means all arguments will be evaluated
by the called function. Which is fine for arguments that evaluate to
themselves. For symbols and calls it isn't.

I did try to make the case some time ago that quote = TRUE should be
the default but I lost that argument.

It might be worth revisiting that, or at least reviewing the uses of
do.call in our code sometime (there are a couple of hundred).

Best,

luke



I don't know whether it is worth trying to change this. You know the workaround.

-pd




On 27 Mar 2020, at 02:55 , Marius Hofert  wrote:

Hi,

Is this expected behavior (R-3.6.0)?

dat <- cbind(x = 1:10, y = 10:1)
ylab <- substitute(X[t], list(t = 2))
plot(dat, ylab = ylab) # works (correctly displays ylab)
boxplot(dat, ylab = ylab) # fails
boxplot(dat, ylab = as.expression(ylab)) # works

Thanks & cheers,
M

__
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

Re: [Rd] object.size vs lobstr::obj_size

[Tomas Kalibera]

On 2/19/20 3:55 AM, Stefan Schreiber wrote:

I have posted this question on R-help where it was suggested to me
that I might get a better response on R-devel. So far I have gotten no
response. The post I am talking about is here:
https://stat.ethz.ch/pipermail/r-help/2020-February/465700.html

My apologies for cross-posting, which I am aware is impolite and I
should have posted on R-devel in the first place - but I wasn't sure.

Here is my question again:

I am currently working through Advanced R by H. Wickham and came
across the `lobstr::obj_size` function which appears to calculate the
size of an object by taking into account whether the same object has
been referenced multiple times, e.g.

x <- runif(1e6)
y <- list(x, x, x)
lobstr::obj_size(y)
# 8,000,128 B

# versus:
object.size(y)
# 24000224 bytes

Reading through `?object.size` in the "Details" it reads: [...] but
does not detect if elements of a list are shared [...].

My questions are:

(1) is the result of `obj_size()` the "correct" one when it comes to
actual size used in memory?

(2) And if yes, why wouldn't `object.size()` be updated to reflect the
more precise calculation of an object in question similar to
`obj_size()`?


Please keep in mind that "actual size used in memory" is an elusive 
concept, particularly in managed languages such as R. Even in native 
languages, you have on-demand paging (not all data in physical memory, 
some may be imputed (all zeros), some may be swapped out, some may be 
stored in files (code), etc). Also you have internal and external 
fragmentation caused by the "C library" memory allocator, overhead of 
object headers and allocator meta-data. On top of that you have the 
managed heap: more of internal and external fragmentation, more headers. 
Moreover, memory representation may change invisibly and sometimes in 
surprising ways (in R it is copy-on-write, so the sharing, but also 
compact objects via ALTREP, e.g. sequences). R has the symbol table, 
string cache (strings are interned, as in some other language runtimes, 
so the price is paid only once for each string). In principle, managed 
runtimes could do much more, including say compression of objects with 
adaptive decompression, some systems internally split representation of 
large objects depending on their size with additional overheads, systems 
could have some transparent de-duplication (not only for strings), some 
choices could be adaptive based on memory pressure. Then in R, packages 
often can maintain memory related to specific R objects, linked say via 
external pointers, and again there may be no meaningful way to map that 
usage to individual objects.


Not only that what is a size of an object tree is not easy to define. 
That information is in addition not very useful, either, because 
innocuous changes may change it in arbitrary ways out of control of the 
user: there is no good intuition how much that size will change from 
intended application-level modifications of the tree. Users of the 
system could hardly create a reliable mental model of the memory usage, 
because it depends on internal design of the virtual machine, which in 
addition can change over time.


As the concept is elusive, the best advice would be don't ask for the 
object size, find some other solutions to your problem. In some cases, 
it makes sense to ask for object size in some application-specific way, 
and then implement object size methods for specific application classes 
(e.g. structures holding strings would sum up number of characters in 
the strings, etc). Such application-specific way may be inspired by some 
particular (perhaps trivial) serialization format.


I've used object.size() myself only for profiling when quickly 
identifying objects that are probably very large from objects of trivial 
size, where these nuances did not matter, but for that I knew roughly 
what the objects were (e.g. that they were not hiding things in 
environments).


Intuitively, the choices made by object.size() in R are conservative, 
they provide an over-approximation that somewhat intuitively makes sense 
at user level, and they reduce surprises of significant size expansion 
due to minimal updates. The choices and their limitations are 
documented. I think this at least no worse than than say taking into 
account sharing, looking at current "size" of compact objects, etc. One 
could provide more options to object.size(), but I don't think that it 
would be useful.


Best,
Tomas




There are probably valid reasons for this and any insight would be
greatly appreciated.

__
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] object.size vs lobstr::obj_size

[Hervé Pagès]

Hi Tomas,

On 3/27/20 07:01, Tomas Kalibera wrote:

they provide an over-approximation


They can also provide an "under-approximation" (to say the least) e.g. 
on reference objects where the entire substance of the object is ignored 
which makes object.size() completely meaningless in that case:


  setRefClass("A", fields=c(stuff="ANY"))
  object.size(new("A", stuff=raw(0)))  # 680 bytes
  object.size(new("A", stuff=runif(1e8)))  # 680 bytes

Why wouldn't object.size() look at the content of environments?

Thanks,
H.

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Tomas Kalibera]

On 3/27/20 4:39 PM, Hervé Pagès wrote:

Hi Tomas,

On 3/27/20 07:01, Tomas Kalibera wrote:

they provide an over-approximation


They can also provide an "under-approximation" (to say the least) e.g. 
on reference objects where the entire substance of the object is 
ignored which makes object.size() completely meaningless in that case:


  setRefClass("A", fields=c(stuff="ANY"))
  object.size(new("A", stuff=raw(0)))  # 680 bytes
  object.size(new("A", stuff=runif(1e8)))  # 680 bytes

Why wouldn't object.size() look at the content of environments?


Yes, the treatment of environments is not "over-approximative". It has 
to be bounded somewhere, you can't traverse all captured environments, 
getting to say package namespaces, global environment, code of all 
functions, that would be too over-approximating. For environments used 
as hash maps that contain data, such as in reference classes, it would 
of course be much better to include them, but you can't differentiate 
programmatically. In principle the same environment can be used for both 
things, say a namespace environment can contain data (not clearly 
related to any user-level R object) as well as code. Not mentioning 
things like source references and parse data.


Tomas



Thanks,
H.



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Hadley Wickham]

On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès  wrote:

> Hi Tomas,
>
> On 3/27/20 07:01, Tomas Kalibera wrote:
> > they provide an over-approximation
>
> They can also provide an "under-approximation" (to say the least) e.g.
> on reference objects where the entire substance of the object is ignored
> which makes object.size() completely meaningless in that case:
>
>setRefClass("A", fields=c(stuff="ANY"))
>object.size(new("A", stuff=raw(0)))  # 680 bytes
>object.size(new("A", stuff=runif(1e8)))  # 680 bytes
>
> Why wouldn't object.size() look at the content of environments?
>

As the author, I'm obviously biased, but I do like lobstr::obj_sizes()
which allows you to see the additional size occupied by one object given
any number of other objects. This is particularly important for reference
classes since individual objects appear quite large:

A <- setRefClass("A", fields=c(stuff="ANY"))
lobstr::obj_size(new("A", stuff=raw(0)))
#> 567,056 B

But the vast majority is shared across all instances of that class:

lobstr::obj_size(A)
#> 719,232 B
lobstr::obj_sizes(A, new("A", stuff=raw(0)))
#> * 719,232 B
#> * 720 B
lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
#> * 719,232 B
#> * 800,000,720 B

Hadley
-- 
http://hadley.nz

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Hadley Wickham]

On Fri, Mar 27, 2020 at 11:08 AM Tomas Kalibera 
wrote:

> On 3/27/20 4:39 PM, Hervé Pagès wrote:
> > Hi Tomas,
> >
> > On 3/27/20 07:01, Tomas Kalibera wrote:
> >> they provide an over-approximation
> >
> > They can also provide an "under-approximation" (to say the least) e.g.
> > on reference objects where the entire substance of the object is
> > ignored which makes object.size() completely meaningless in that case:
> >
> >   setRefClass("A", fields=c(stuff="ANY"))
> >   object.size(new("A", stuff=raw(0)))  # 680 bytes
> >   object.size(new("A", stuff=runif(1e8)))  # 680 bytes
> >
> > Why wouldn't object.size() look at the content of environments?
>
> Yes, the treatment of environments is not "over-approximative". It has
> to be bounded somewhere, you can't traverse all captured environments,
> getting to say package namespaces, global environment, code of all
> functions, that would be too over-approximating. For environments used
> as hash maps that contain data, such as in reference classes, it would
> of course be much better to include them, but you can't differentiate
> programmatically. In principle the same environment can be used for both
> things, say a namespace environment can contain data (not clearly
> related to any user-level R object) as well as code. Not mentioning
> things like source references and parse data.
>
>
I think the heuristic used in lobstr works well in practice: don't traverse
further than the current environment (supplied as an argument so you can
override), and don't ever traverse past the global or base environments.

Hadley

-- 
http://hadley.nz

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Hervé Pagès]

On 3/27/20 12:00, Hadley Wickham wrote:



On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès > wrote:


Hi Tomas,

On 3/27/20 07:01, Tomas Kalibera wrote:
 > they provide an over-approximation

They can also provide an "under-approximation" (to say the least) e.g.
on reference objects where the entire substance of the object is
ignored
which makes object.size() completely meaningless in that case:

    setRefClass("A", fields=c(stuff="ANY"))
    object.size(new("A", stuff=raw(0)))      # 680 bytes
    object.size(new("A", stuff=runif(1e8)))  # 680 bytes

Why wouldn't object.size() look at the content of environments?


As the author, I'm obviously biased, but I do like lobstr::obj_sizes() 
which allows you to see the additional size occupied by one object given 
any number of other objects. This is particularly important for 
reference classes since individual objects appear quite large:


A <- setRefClass("A", fields=c(stuff="ANY"))
lobstr::obj_size(new("A", stuff=raw(0)))
#> 567,056 B

But the vast majority is shared across all instances of that class:

lobstr::obj_size(A)
#> 719,232 B
lobstr::obj_sizes(A, new("A", stuff=raw(0)))
#> * 719,232 B
#> *     720 B
lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
#> *     719,232 B
#> * 800,000,720 B


Nice. Can you clarify the situation with lobstr::obj_size vs 
pryr::object_size? I've heard of the latter before and use it sometimes 
but never heard of the former before seeing Stefan's post. Then I 
checked the authors of both and thought maybe they should talk to each 
other ;-)


Thanks,
H.



Hadley
--
http://hadley.nz 



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Hadley Wickham]

On Fri, Mar 27, 2020 at 4:01 PM Hervé Pagès  wrote:

>
>
> On 3/27/20 12:00, Hadley Wickham wrote:
> >
> >
> > On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès  > > wrote:
> >
> > Hi Tomas,
> >
> > On 3/27/20 07:01, Tomas Kalibera wrote:
> >  > they provide an over-approximation
> >
> > They can also provide an "under-approximation" (to say the least)
> e.g.
> > on reference objects where the entire substance of the object is
> > ignored
> > which makes object.size() completely meaningless in that case:
> >
> > setRefClass("A", fields=c(stuff="ANY"))
> > object.size(new("A", stuff=raw(0)))  # 680 bytes
> > object.size(new("A", stuff=runif(1e8)))  # 680 bytes
> >
> > Why wouldn't object.size() look at the content of environments?
> >
> >
> > As the author, I'm obviously biased, but I do like lobstr::obj_sizes()
> > which allows you to see the additional size occupied by one object given
> > any number of other objects. This is particularly important for
> > reference classes since individual objects appear quite large:
> >
> > A <- setRefClass("A", fields=c(stuff="ANY"))
> > lobstr::obj_size(new("A", stuff=raw(0)))
> > #> 567,056 B
> >
> > But the vast majority is shared across all instances of that class:
> >
> > lobstr::obj_size(A)
> > #> 719,232 B
> > lobstr::obj_sizes(A, new("A", stuff=raw(0)))
> > #> * 719,232 B
> > #> * 720 B
> > lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
> > #> * 719,232 B
> > #> * 800,000,720 B
>
> Nice. Can you clarify the situation with lobstr::obj_size vs
> pryr::object_size? I've heard of the latter before and use it sometimes
> but never heard of the former before seeing Stefan's post. Then I
> checked the authors of both and thought maybe they should talk to each
> other ;-)
>

pryr is basically retired :) TBH I don't know why I gave up on it, except
lobstr is a cooler name 🤣 That's where all active development is
happening. (The underlying code is substantially similar although
lobstr includes bug fixes not present in pryr)

Hadley

-- 
http://hadley.nz

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Hervé Pagès]

On 3/27/20 15:19, Hadley Wickham wrote:



On Fri, Mar 27, 2020 at 4:01 PM Hervé Pagès > wrote:




On 3/27/20 12:00, Hadley Wickham wrote:
 >
 >
 > On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès
mailto:hpa...@fredhutch.org>
 > >> wrote:
 >
 >     Hi Tomas,
 >
 >     On 3/27/20 07:01, Tomas Kalibera wrote:
 >      > they provide an over-approximation
 >
 >     They can also provide an "under-approximation" (to say the
least) e.g.
 >     on reference objects where the entire substance of the object is
 >     ignored
 >     which makes object.size() completely meaningless in that case:
 >
 >         setRefClass("A", fields=c(stuff="ANY"))
 >         object.size(new("A", stuff=raw(0)))      # 680 bytes
 >         object.size(new("A", stuff=runif(1e8)))  # 680 bytes
 >
 >     Why wouldn't object.size() look at the content of environments?
 >
 >
 > As the author, I'm obviously biased, but I do like
lobstr::obj_sizes()
 > which allows you to see the additional size occupied by one
object given
 > any number of other objects. This is particularly important for
 > reference classes since individual objects appear quite large:
 >
 > A <- setRefClass("A", fields=c(stuff="ANY"))
 > lobstr::obj_size(new("A", stuff=raw(0)))
 > #> 567,056 B
 >
 > But the vast majority is shared across all instances of that class:
 >
 > lobstr::obj_size(A)
 > #> 719,232 B
 > lobstr::obj_sizes(A, new("A", stuff=raw(0)))
 > #> * 719,232 B
 > #> *     720 B
 > lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
 > #> *     719,232 B
 > #> * 800,000,720 B

Nice. Can you clarify the situation with lobstr::obj_size vs
pryr::object_size? I've heard of the latter before and use it sometimes
but never heard of the former before seeing Stefan's post. Then I
checked the authors of both and thought maybe they should talk to each
other ;-)


pryr is basically retired :) TBH I don't know why I gave up on it, 
except lobstr is a cooler name 🤣 That's where all active development is 
happening. (The underlying code is substantially similar although 
lobstr includes bug fixes not present in pryr)


Good to know, thanks! Couldn't find any mention of pryr being abandoned 
and superseded by lobster (which definitely sounds more yummy) in pryr's 
README.md or DESCRIPTION file. Would be good to put this somewhere.


H.




Hadley
--
http://hadley.nz 



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] object.size vs lobstr::obj_size

[Stefan Schreiber]

Thank you Tomas, Hervé and Hadley for the input. Much appreciated!

Stefan

Stefan Schreiber, PhD, P. Biol.
Director EnviroStats Solutions Inc.
Adjunct Professor, Faculty of Agricultural, Life & Environmental
Sciences, University of Alberta
Phone: 780-221-1838
https://envirostats.ca/



On Fri, 27 Mar 2020 at 16:25, Hervé Pagès  wrote:
>
> On 3/27/20 15:19, Hadley Wickham wrote:
> >
> >
> > On Fri, Mar 27, 2020 at 4:01 PM Hervé Pagès  > > wrote:
> >
> >
> >
> > On 3/27/20 12:00, Hadley Wickham wrote:
> >  >
> >  >
> >  > On Fri, Mar 27, 2020 at 10:39 AM Hervé Pagès
> > mailto:hpa...@fredhutch.org>
> >  > >> wrote:
> >  >
> >  > Hi Tomas,
> >  >
> >  > On 3/27/20 07:01, Tomas Kalibera wrote:
> >  >  > they provide an over-approximation
> >  >
> >  > They can also provide an "under-approximation" (to say the
> > least) e.g.
> >  > on reference objects where the entire substance of the object is
> >  > ignored
> >  > which makes object.size() completely meaningless in that case:
> >  >
> >  > setRefClass("A", fields=c(stuff="ANY"))
> >  > object.size(new("A", stuff=raw(0)))  # 680 bytes
> >  > object.size(new("A", stuff=runif(1e8)))  # 680 bytes
> >  >
> >  > Why wouldn't object.size() look at the content of environments?
> >  >
> >  >
> >  > As the author, I'm obviously biased, but I do like
> > lobstr::obj_sizes()
> >  > which allows you to see the additional size occupied by one
> > object given
> >  > any number of other objects. This is particularly important for
> >  > reference classes since individual objects appear quite large:
> >  >
> >  > A <- setRefClass("A", fields=c(stuff="ANY"))
> >  > lobstr::obj_size(new("A", stuff=raw(0)))
> >  > #> 567,056 B
> >  >
> >  > But the vast majority is shared across all instances of that class:
> >  >
> >  > lobstr::obj_size(A)
> >  > #> 719,232 B
> >  > lobstr::obj_sizes(A, new("A", stuff=raw(0)))
> >  > #> * 719,232 B
> >  > #> * 720 B
> >  > lobstr::obj_sizes(A, new("A", stuff=runif(1e8)))
> >  > #> * 719,232 B
> >  > #> * 800,000,720 B
> >
> > Nice. Can you clarify the situation with lobstr::obj_size vs
> > pryr::object_size? I've heard of the latter before and use it sometimes
> > but never heard of the former before seeing Stefan's post. Then I
> > checked the authors of both and thought maybe they should talk to each
> > other ;-)
> >
> >
> > pryr is basically retired :) TBH I don't know why I gave up on it,
> > except lobstr is a cooler name 🤣 That's where all active development is
> > happening. (The underlying code is substantially similar although
> > lobstr includes bug fixes not present in pryr)
>
> Good to know, thanks! Couldn't find any mention of pryr being abandoned
> and superseded by lobster (which definitely sounds more yummy) in pryr's
> README.md or DESCRIPTION file. Would be good to put this somewhere.
>
> H.
>
>
> >
> > Hadley
> > --
> > http://hadley.nz
> > 
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel