See my proposal in this mailing list from July 2023 where I documented the
same problem:
[Rd] proposal for WRE: clarify that use of S4 classes implies use of
superclasses
https://stat.ethz.ch/pipermail/r-devel/2023-July/082739.html
Indeed, many of the caching problems would be avoide
I wonder if there is room for improvement here:
> str2lang("if (a) b1else b0")
if (a) b1 else b0
> str2lang("if (a) b1 \n else b0")
Error in str2lang("if (a) b1 \n else b0") : :2:2: unexpected 'else'
1: if (a) b1
2: else
^
It only occurs at top level. When t
rdoch
On 2024-12-02 10:56 a.m., Mikael Jagan wrote:
I wonder if there is room for improvement here:
> str2lang("if (a) b1else b0")
if (a) b1 else b0
> str2lang("if (a) b1 \n else b0")
Error in str2lang("if (a) b1 \n else b0&qu
it's absolutely possible
> that I'm just confused at this point; I don't have a super-simple
> example to show you at the moment. The closest is this example by Mikael
> Jagan: https://github.com/lme4/lme4/issues/794#issuecomment-2155093049
>
> whic
On 2024-04-27 10:53 am, Mikael Jagan wrote:
Reading the body of function 'AnswerType' in bind.c, called from 'do_c'
and 'do_unlist', I notice that EXPRSXP and VECSXP are handled identically
in the recurse = TRUE case.
A corollary is that c(recursive = TRUE)
Reading the body of function 'AnswerType' in bind.c, called from 'do_c'
and 'do_unlist', I notice that EXPRSXP and VECSXP are handled identically
in the recurse = TRUE case.
A corollary is that c(recursive = TRUE) and unlist(recursive = TRUE)
treat expression vectors like expression(a, b)
Naras,
Thanks. I'm a bit confused, because Rmosek does not declare Matrix as a
dependency:
> tools::package_dependencies("Rmosek", which = "all")[[1L]]
[1] "pkgbuild"
nor does it contain code needing compilation:
> packageDescription("Rmosek", fields="NeedsCompilation")
[1] "n
FWIW, a user on Stack Overflow just reported the same issue with list.files
running R 4.3.z on Windows. They do not observe the issue running R-devel,
with Tomas' patch (r84960). It is still the case that their file names did
not exceed 260 wide characters.
https://stackoverflow.com/q/77527
On 2023-11-09 3:13 am, Martin Maechler wrote:
Mikael Jagan
on Wed, 8 Nov 2023 11:13:18 -0500 writes:
> So, to summarize, the open questions are:
> (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0)
> instead of NA_complex_?
> (2) Shou
So, to summarize, the open questions are:
(1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0)
instead of NA_complex_?
(2) Should the first argument in c(NA, x) and c(NA_integer_, x),
where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0)
> There is a call to mosek and I assumed that this wasn’t going to be helpful
for most R-devel recipients. I tried Duncan’s very reasonable suggestion about
options() but it didn’t produce the desired error, so perhaps this isn’t really
a warning but something else???
>
The details are descr
And I think there are quite a few other situations
where looking at Re() and Im() separately makes a lot of sense.
Indeed, and there is no way to "tell" BLAS and LAPACK to treat both the real and
imaginary parts as NA_REAL when either is NA_REAL. Hence the only reliable way
to implement
On 2023-09-22 6:38 am, Martin Maechler wrote:
Mikael Jagan
on Thu, 21 Sep 2023 00:47:39 -0400 writes:
> Revisiting this thread from April:
> https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
> where the decision (not yet backported) was
Revisiting this thread from April:
https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
where the decision (not yet backported) was made for as.complex(NA_real_)
to give NA_complex_ instead of complex(r=NA_real_, i=0), to be consistent
with help("as.complex") and as.complex(NA) and
Two quite related and recent threads on R-devel:
[1] proposal for WRE: clarify that use of S4 classes implies use of superclasses
https://stat.ethz.ch/pipermail/r-devel/2023-July/082739.html
[2] Should package version requirements assume installation from sources?
https://stat.ethz.ch/pipermail/r
If a package has
importClassesFrom(P, C)
in its NAMESPACE, then should it _also_ have
importClassesFrom(P, )
importClassesFrom(Q, )
## and so on
... ? I think that WRE could be more clear on this point, and in any case
I _think_ that the answer is yes.
Notably, I think that t
change to using as.data.frame.vector.
I glanced at the other non-deprecated as.data.frame. and did not
see other usage of the deprecated ones ... a more systematic check could
be worth doing.
Mikael
On 2023-07-06 11:32 am, Mikael Jagan wrote:
Continuing the thread started on R-package-devel, here:
Continuing the thread started on R-package-devel, here:
https://stat.ethz.ch/pipermail/r-package-devel/2023q3/009307.html
The logic of the now soft-deprecated as.data.frame.,
> body(as.data.frame.integer)[[2L]]
if ((sys.nframe() <= 1L || sys.call(-1L)[[1L]] != quote(as.data.frame)) &&
nzchar
Surely this behaviour is just a case of ESS being "too clever", sourcing
*.R files in special way when it detects that a file belongs to a package
(loading dependencies automatically, etc.)?
The function ss() is defined inside of .ess.source(), which is defined here:
https://github.com/emacs-ess
other parameters, usually
have not place in the signature of the generic.
H.
On 6/14/23 20:57, Mikael Jagan wrote:
Thanks all - yes, I think that Simon's diagnosis ("user error") is
correct:
in this situation one should define a reasonable generic function
explicitly,
with a call t
it should only be
part of the method implementation. If one was to implement the same default
behavior in the generic itself (not necessarily a good idea) the default would
be ncol = if (complete) nrow(qr.R(qr, TRUE)) else min(dim(qr.R(qr, TRUE))) to
not rely on the internals of the impleme
eless, that's the intended approach as far as i know.
Best,
~G
On Wed, Jun 7, 2023 at 1:07 AM Serguei Sokol via R-devel <
r-devel@r-project.org> wrote:
Le 03/06/2023 à 17:50, Mikael Jagan a écrit :
In a package, I define a method for not-yet-generic function 'qr.X'
like so:
I was a bit surprised to learn that, if one has an Rd file as below:
%% zzz.Rd
\newcommand{\zzz}{whatever}
\name{zzz}
\title{zzz}
\description{ \zzz{} \eqn{\zzz{}} \deqn{\zzz{}} }
then the macro is _not_ expanded inside of \eqn{} or \deqn{} when parsed to text
or HTML. Is th
In a package, I define a method for not-yet-generic function 'qr.X' like so:
> setOldClass("qr")
> setMethod("qr.X", signature(qr = "qr"), function(qr, complete, ncol) NULL)
The formals of the newly generic 'qr.X' are inherited from the non-generic
function in the base namespace. Notabl
The deparse options used by default by 'deparse' and 'dput' are
c("keepNA", "keepInteger", "niceNames", "showAttributes")
but Defn.h still has
#define DEFAULTDEPARSE 1089 /* KEEPINTEGER | KEEPNA | NICE_NAMES, used for
calls */
i.e., with the SHOWATTRIBUTES bit turned off. Is that o
On 2023-04-15 6:00 am, r-devel-requ...@r-project.org wrote:
Date: Fri, 14 Apr 2023 13:38:00 +0300
From: Ivan Krylov
To:r-devel@r-project.org
Subject: [Rd] sum(), min(), max(), prod() vs. named arguments in ...
Message-ID: <20230414133800.75383dae-6792@arachnoid>
Content-Type: text/plain; ch
I know that it has been discussed in the past, but I wanted to ask
to revisit the idea of exporting
is.formula <- function(x) inherits(x, "formula")
from 'stats', parallel to is.data.frame() in 'base', given how
widely formulae are used these days in conjunction with data frames,
even outside
https://netlib.org/lapack/lapack-3.11.0.html
It is possible that the underlying issue in DGETRF (INFO>0 due to NaN
pivots rather than 0 pivots {=> singular}) still exists for matrices
less trivial than my 2-by-2 examples. Will have to experiment ...
Mikael
On 2022-11-09 3:58 pm, Mikael Jagan wr
Currently, m4/gettext.m4 contains an old version of Autoconf macro
AM_GNU_GETTEXT relying on internal symbols (e.g., _nl_expand_alias)
to detect broken implementations of GNU gettext. System libraries
are searched for the internal symbols unconditionally, i.e., even
when linking against a static
On 2022-11-10 1:10 pm, Mikael Jagan wrote:
Hello,
Currently, solve.default() is defined such that
> identical(dimnames(solve.default(a, b)),
list(dimnames(a)[[2L]], dimnames(b)[[2L]]))
is always TRUE, i.e., ignoring names(dimnames(a)) and names(dimnames(b)).
Hence we
Hello,
Currently, solve.default() is defined such that
> identical(dimnames(solve.default(a, b)),
list(dimnames(a)[[2L]], dimnames(b)[[2L]]))
is always TRUE, i.e., ignoring names(dimnames(a)) and names(dimnames(b)).
Hence we see:
> a <- b <- diag(2L)
> dimnames(a) <- list(A1 = c("a
Hello,
Currently, determinant(A) calculates the determinant of 'A' by factorizing
A=LU and computing prod(diag(U)) [or the logarithm of the absolute value].
The factorization is done by LAPACK routine DGETRF, which gives a status
code INFO, documented [1] as follows:
*> INFO is INTEGER
[Arguably also appropriate for R-package-devel, but posted to R-devel
as the discussion is aimed primarily at "experts" ... ]
We, the authors of Matrix, have encountered a somewhat subtle issue
induced by caching of S4 classes and methods in package namespaces.
The namespaces of three revers
This seems entirely avoidable, given that there is a relatively simple
formula for converting 2-ary indices [i,j] of S to 1-ary indices k of
S[lower.tri(S, TRUE)]:
k <- i + round(0.5 * (2L * n - j) * (j - 1L)) # for i >= j
I ought to be slightly more precise here: _coercion_ is avoidable,
be
Currently, the class for dense symmetric matrices in packed storage,
"dspMatrix", inherits its subset (i.e., `[`) methods from the "Matrix"
class. As a result, subsetting "dspMatrix" requires coercion to
"matrix". If memory cannot be allocated for this "matrix", then an error
results.
n <- 30
35 matches
Mail list logo
