From r@dford @ending from c@@toronto@edu  Mon Sep  3 15:18:11 2018
From: r@dford @ending from c@@toronto@edu (Radford Neal)
Date: Mon, 3 Sep 2018 09:18:11 -0400
Subject: [Rd] True length - length(unclass(x)) - without having to call
 unclass()?
In-Reply-To: <mailman.47618.5.1535968801.62998.r-devel@r-project.org>
References: <mailman.47618.5.1535968801.62998.r-devel@r-project.org>
Message-ID: <20180903131811.GA31865@mail.cs.toronto.edu>

Regarding the discussion of getting length(unclass(x)) without an
unclassed version of x being created...

There are already no copies done for length(unclass(x)) in pqR
(current version of 2017-06-09 at pqR-project.org, as well as the
soon-to-be-release new version).  This is part of a more general
facility for avoiding copies from unclass in other circumstances as
well - eg, unclass(a)+unclass(b).

It's implemented using pqR's internal "variant result" mechanism.
Primitives such as "length" and "+" can ask for their arguments to be
evaluated in such a way that an "unclassed" result is possibly
returned with its class attribute still there, but with a flag set
(not in the object) to indicate that it should be ignored.

The variant result mechanism is also central to many other pqR
improvements, including deferred evaluation to enable automatic use of
multiple cores, and optimizations that allow fast evaluation of things
like any(x<0), any(is.na(x)), or all(is.na(x)) without creation of
intermediate results and with early termination when the result is
determined.

It is much better to use such a general mechanism that speeds up
existing code than to implement more and more special-case functions
like anyNA or some special function to allow length(unclass(x)) to be
done quickly.

The variant result mechanism has extremely low overhead, and is not
hard to implement.

   Radford Neal



[Rd] True length - length(unclass(x)) - without having to call unclass()?
Radford Neal