Skip to content

Conversation

@hcirellu
Copy link
Contributor

This pull request adds support for matrix, array and %*% for integer64. Since there are no S3 methods for matrix and array, they are added.
In matrix and array the base functions are used. In order to display convinient warnings and errors that show the call (e.g. matrix(1:10, nrow=5) instead of base::matrix(...)) I use withCallingHandlers(). If there is a generic call, this is displayed, and if not, the S3-method call is displayed.
In order to display matrices and arrays consistently to R, str.integer64 is changed accordingly.
colSums.integer64 and rowSums.integer64 are refactored to throw R consistent error messages.
as.matrix.integer64 is added to coerce accordingly.
Since aperm.integer64 isn't exported, one has to use the generic. Thus it is refactored to use NextMethod().
The matrix multiplication uses a new helper function target_class_for_Ops(), which determines the class of the result. If a matrix multiplication of integer64 and complex is performed, I expect the result in complex. It also throws R consistent error messages for Ops. This helper is also intended to be used for other Ops methods like *.integer64 in the future. The remaining method checks the matrix dimensions and performs the calculation.

Closes #45

@hcirellu hcirellu marked this pull request as ready for review November 26, 2025 17:24
R/integer64.R Outdated
Comment on lines 851 to 852
} else if (!is.null(dim(object))) {
dimO = dim(object)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
} else if (!is.null(dim(object))) {
dimO = dim(object)
} else if (!is.null(dimO <- dim(object))) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But didn't you want to use = instead of <- consistently?



# helper for determining the target class for Ops methods
target_class_for_Ops = function(e1, e2) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for this to be a chooseOpsMethod() method?

https://stat.ethz.ch/R-manual/R-devel/library/base/html/chooseOpsMethod.html

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have a look into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To my knowledge, we can use chooseOpsMethod() to achieve that Date+integer64 and integer64+Date is handled by +.integer64.
Default behaviour: Since both operands have a class attribute, the operation is performed with the warning Incompatible methods ("+.Date", "+.integer64") for "+" and we get a Date or integer64, depending on the first argument. In case of numeric+integer64 this is not necessary, because numeric has no class attribute and therefore +.integer64 is applied.
If we define chooseOpsMethod.integer64 <- function(x,y,mx,my,cl,rev) TRUE, Date+integer64 and integer64+Date are handled by +.integer64. This should also apply to all other methods of the Group "Ops", i.e. +, &, == etc, but not %*% or log.

My helper target_class_for_Ops does not address the method selection. It shall determine the desired output class of the result. In the above example it should be that Date+integer64 and integer64+Date both result in Date and not integer64, if that is added in the function. Right now only complex is assumed to be converted to. In all other cases it is converted to integer64.

hcirellu and others added 4 commits December 13, 2025 10:17
Co-authored-by: Michael Chirico <michaelchirico4@gmail.com>
Co-authored-by: Michael Chirico <michaelchirico4@gmail.com>
try fix tests for ubuntu latest
@hcirellu
Copy link
Contributor Author

Are you fixing the follwing error in the checks for ubuntu-latest (3.6)?

Error: 
  ! error in pak subprocess
  Caused by error: 
  ! Could not solve package dependencies:
  * deps::.: Can't install dependency patrick (>= 0.3.0)
  * patrick: Needs R >= 4.1.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

matrix(<integer64>) strips the attribute

2 participants