d which
defines exactly how arithmetic on signed zeros should work, I see nothing odd in
your output.
Mikael
Date: Sat, 26 Apr 2025 11:10:00 +0200
From: Antoine Fabri
Dear r-devel,
In R `sign(0)` and `sign(-0)` both return `0` but negative zeroes do exist
in the sense that dividing by them gives
, 'PackageSlot<-', ...
Well, that's just just one idea ... I understand reluctance to make non-trivial
changes to model.c, but maybe there is a basis here, if people are more and more
(for better or worse (mostly worse)) trying to use '::' everywhere including in
mod
hanges and stale cached S4 class definitions.
Mikael
Date: Sat, 18 Jan 2025 13:10:10 +0300
From: Ivan Krylov
To: r-devel@r-project.org
Subject: [Rd] How setClass() may introduce a binary dependency between
packages
Message-ID: <20250118131010.035cf539@Tarkus>
Content-Type: text/plain
logies if this issue has been seen and discussed before (most likely
by people like me in the habit of dropping braces in calls to 'if' where
not strictly necessary).
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Thanks - that makes sense. It's also documented in help("if"), so it's
doubly clear now that I did not do my homework here.
Mikael
On 2024-12-02 11:09 am, Duncan Murdoch wrote:
BTW, this is discussed in section 3.2.1 of "The R Language Definition".
Duncan Mu
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)
lt; list < expression)
is coerced to a lower type.
I'll add here that, confusingly, help("expression") says: "an object of
mode 'expression' is a list". I understand the author's intent (lists and
expression vectors differ only in the 'type' fiel
AN and BioC at the time that Matrix 1.6-2 was released. We can
suggest replacements (probably off list; I don't know that R-devel is the
right forum) but only if we are able to see the code being compiled ...
Mikael
> Package Rmosek compiles fine using Matrix versions 1.6.2- but not with
> an
com/q/77527167/12685768
Mikael
On 2023-08-17 6:00 am, r-devel-requ...@r-project.org wrote:
Message: 5
Date: Wed, 16 Aug 2023 16:00:13 +0200
From: Tomas Kalibera
To: Ivan Krylov
Cc:"r-devel@r-project.org"
Subject: Re: [Rd] R-4.3 version list.files function could not work
corre
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
ors 'x'.
And while typing this response I noticed the following in current R-devel and
current R-patched:
> 0+1i
[1] 0+1i
> 1i
[1] 0+1i
> as.complex("0+1i")
[1] 0+1i
> as.complex("1i")
[1] NA
Warning message:
NAs int
trix.warnDeprecatedCoerce=n)
on the command line:
R_MATRIX_WARN_DEPRECATED_COERCE=n R CMD check *.tar.gz
But maybe it is time to begin signaling warnings unconditionally ...
Mikael
> For those who might have rmosek installed, I’m doing:
>
> library(REBayes)
> demo(GL
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
rly lost ...
Whatever decision is made about as.complex(NA_real_), maybe these points
should be weighed before it becomes part of R-release ...
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
definition at install time, so indeed it is liable to become stale with
Matrix updates ...
Not to derail Dirk's proposal for "Breaks", which could certainly have
uses beyond this particular example where a "correct" NAMESPACE directive
would solve the problems ...
Mikael
On 20
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:
se
'as.data.frame.vector()' or 'as.data.frame()' instead
i.e., the condition sys.call(-1L)[[1L]] != quote(as.data.frame) is not precise
enough ... would !identical(sys.function(-1L), as.data.frame) work instead?
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
.com/emacs-ess/ESS/blob/5c4ae91cefa5c56fd13b204a9a996825af836a67/etc/ESSR/R/.basic.R#L168
If you think that there is a bug, then you could report it there ...
Mikael
On 2023-06-21 6:00 am, r-devel-requ...@r-project.org wrote:
When I run a script foo.R containing some trivial code in my home
dire
e my hope that an implicit generic qr.X could
become part of package methods, notably as an implicit generic qr.R
already lives there ...
Or maybe there is a way for Matrix to define qr.X as an implicit generic
without creating other problems, but my experiments with setGenericImplicit
were not
mplicit generic
'qr.X' in methods via '.initImplicitGenerics' in methods/R/makeBasicFunsList.R,
where I see that an implicit generic 'qr.R' is already defined ... ?
The patch pasted below "solves everything
not bothered
by
def <- function(x = y) { y <- 0; x }
but still complains about
setMethod("someGeneric", "someClass", def)
...
Mikael
On 2023-06-07 5:13 am, Gabriel Becker wrote:
The API supported workaround is to call globalVariables, which,
essential
this behaviour intentional? Could it be changed? Inside of \eqn{}
and \deqn{} is where I am _most_ likely to want to use macros, at least since
R 4.2.0, which added KaTeX support ...
See output pasted below.
Mikael
> tools::Rd2txt(tools::parse_Rd("zzz.Rd"))
zzz
Description:
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
*/
i.e., with the SHOWATTRIBUTES bit turned off. Is that on purpose?
Note that this leads to weird things like:
> (expr <- call("is.matrix", matrix(1:4, 2L, 2L)))
is.matrix(1:4)
> eval(expr)
[1] TRUE
which can confuse anyone not paying close attention ..
= na.rm)
sum(structure(100, class = 'foo'), ExtraArg = -1)
==> sum(structure(100, class = 'foo'), ExtraArg = -1, na.rm = na.rm)
The new call is evaluated, this time dispatching the internal default method,
giving the results that you observed.
FWIW, help("N
ted by way
of a primitive (the `~` operator, calling do_tilde() in names.c), so
it is really in some sense "special" { compared to 'factor', 'POSIXlt',
etc. }.
What do people think?
In case it helps, I've gathered some data from 'base' and the
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
ed from a sufficiently newer release
of GNU gettext, without major disruption?
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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
`, which
_does_ respect names(dimnames(.)) :
> a %*% b
B2
A1b21 b22
a11 1 0
a12 0 1
If others agree, then I would submit a minimal patch to the R-level
solve.default() in src/library/base/R/solve.R and to the C-level
La_solve() and La_solve_cmplx() in src/modules/lapack/Lapac
2L, 2L))
[,1] [,2]
[1,] NaN0
[2,] NaN0
> det(C)
[1] NaN
> (D <- t(C))
[,1] [,2]
[1,] NaN NaN
[2,]00
> det(D)
[1] 0
Furthermore, the proposed change should _not_ decrease the performance
of determinant(A) for nonsingular 'A' ...
For those looking, the relev
uot; version requirement, but do not want this practice
to spread ...
2. For how long should Matrix retain the superceded 'Dim_validate' and
'dimNames_validate', in order to ensure that "stale" cached validity
methods continue to work?
We hope that th
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
But that attempt failed for a entirely different reason. For large
enough n, I would hit a memory limit at the line:
x[-i] <- from
So I guess my second question is: what is problematic about this
benign-seeming subset-assignment?
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Full_Name: Mikael Weigelt
Version: 2.0
OS: windows
Submission from: (NULL) (207.171.180.101)
The calculation of the qpois attempts to use the Cornish-Fisher expansion as a
starting approximation. The definition of the expansion is incorrect. However,
since this approximation just gives an
38 matches
Mail list logo
