R devel - Mar 2026 - diff(<ts-matrix>), Ops.ts -- R Bugzilla PR#18972

>>>>> Martin Maechler 
>>>>>     on Wed, 4 Mar 2026 12:42:20 +0100 writes:
>>>>> Suharto Anggono Suharto Anggono 
>>>>>     on Wed, 4 Mar 2026 06:05:18 +0000 (UTC) writes:
    >> Then, please announce the change in NEWS. For example:
    >> The result of arithmetic and comparison operations of
non-overlapping "ts" objects where either is a matrix is now a matrix.

    >> It seems that the statement "diff(<ts-matrix>) remains
matrix, even when it has length zero" was meant for the change to
'Ops.ts'. But the wording is about diff(<ts-matrix>), which is
included in the previous statement.

    >> But I've just realized this :

    >> Suppose that
    >> x <- ts(0)

    >> With the change, x - lag(x, -1) and x == lag(x, -1) are NULL.
    >> In R 4.5.2, x - lag(x, -1) is integer(0) and x == lag(x, -1) is
logical(0).

    > Indeed, so we may even have to change R-devel further (for this
    > rare boundary case).

    > But the R 4.5.2   x - lag(x, -1)  giving integer(0)  is only somewhat
better than
    > giving NULL  when in principle the "truly correct" answer
should
    > be  double(0) and we'd rather get that right in R-devel.

==> So, we should probably reopen R Bugzilla item PR#18972, at
 ---> https://bugs.r-project.org/show_bug.cgi?id=18972

Martin

To have usual storage mode of the result and for error if e1 and e2 are matrices
with different number of columns, 'Ops.ts' could still use
NextMethod(.Generic)
even if e1 and e2 are not overlapping and just change e1 and e2.

 if(is.null(e12))# if e1 or e2 is matrix but e1 & e2 are not overlapping,
e12 is NULL ..
 return(if(is.matrix(e1)) e1[0, , drop=FALSE]
 else if(is.matrix(e2)) e2[0, , drop=FALSE]
 ## else NULL ( == e12 )
 )
 e1 <- if(is.matrix(e1)) e12[, 1L:nc1 , drop = FALSE] else e12[, 1]
 e2 <- if(is.matrix(e2)) e12[, nc1 + (1L:nc2), drop = FALSE] else e12[, nc1 +
1]

could become

 if(is.null(e12)) {# if e1 & e2 are not overlapping, e12 is NULL ..
 e1 <- if(is.matrix(e1)) e1[0, , drop = FALSE] else e1[0]
 e2 <- if(is.matrix(e2)) e2[0, , drop = FALSE] else e2[0]
 } else {
 e1 <- if(is.matrix(e1)) e12[, 1L:nc1 , drop = FALSE] else e12[, 1]
 e2 <- if(is.matrix(e2)) e12[, nc1 + (1L:nc2), drop = FALSE] else e12[, nc1 +
1]
 }

_______
On Wednesday, 4 March 2026 at 06:57:51 pm GMT+7, Martin Maechler <maechler at
stat.math.ethz.ch> wrote:

>>>>> Martin Maechler
>>>>>? ? on Wed, 4 Mar 2026 12:42:20 +0100 writes:
>>>>> Suharto Anggono Suharto Anggono
>>>>>? ? on Wed, 4 Mar 2026 06:05:18 +0000 (UTC) writes:
? ? >> Then, please announce the change in NEWS. For example:
? ? >> The result of arithmetic and comparison operations of
non-overlapping "ts" objects where either is a matrix is now a matrix.

? ? >> It seems that the statement "diff(<ts-matrix>) remains
matrix, even when it has length zero" was meant for the change to
'Ops.ts'. But the wording is about diff(<ts-matrix>), which is
included in the previous statement.

? ? >> But I've just realized this :

? ? >> Suppose that
? ? >> x <- ts(0)

? ? >> With the change, x - lag(x, -1) and x == lag(x, -1) are NULL.
? ? >> In R 4.5.2, x - lag(x, -1) is integer(0) and x == lag(x, -1) is
logical(0).

? ? > Indeed, so we may even have to change R-devel further (for this
? ? > rare boundary case).

? ? > But the R 4.5.2? x - lag(x, -1)? giving integer(0)? is only somewhat
better than
? ? > giving NULL? when in principle the "truly correct" answer
should
? ? > be? double(0) and we'd rather get that right in R-devel.

==> So, we should probably reopen R Bugzilla item PR#18972, at
---> https://bugs.r-project.org/show_bug.cgi?id=18972

Martin  
	[[alternative HTML version deleted]]