Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BB-38: No domain mismatch check if argument is not used #22

Open
mcmillan03 opened this issue Sep 3, 2021 · 2 comments
Open

BB-38: No domain mismatch check if argument is not used #22

mcmillan03 opened this issue Sep 3, 2021 · 2 comments
Milestone

Comments

@mcmillan03
Copy link
Member

The FIRST and SECOND operators only rely on the pattern, not the values, of one of their inputs. So no typecasting need be done, and there need not be any check for type compatibility. This change would allow many algorithms to operate on many different kinds of matrices, with no typecasting. For example, a BFS algorithm can work on any user defined type, if it uses these operators in its semiring.

Currently the spec requires a type compatibility check, which prohibits this.

@DrTimothyAldenDavis
Copy link
Member

I also do this in my GxB_SelectOp when the builtin operator does not use certain components. The same thing can be done in the proposed GrB_IndexUnaryOps. For example, the GrB_ROWINDEX_* operator does not access the values of the input matrix at all, so no domain check should be done there. GrB_VALUELE_FP32 (etc) does need to look at the values so a domain check should be done for that operator.

@DrTimothyAldenDavis
Copy link
Member

DrTimothyAldenDavis commented Nov 13, 2021

I've added the following statement, highlighted in yellow, to my v6.0.0 user guide:

SPEC: Some functions do not make use of all of their inputs; in particular the binary operators FIRST, SECOND, and ONEB, and many of the index unary operators. The Specification requires that the inputs to these operators must be compatible with (that is, can be typecasted to) the inputs to the operators, even if those inputs are not used and no typecasting would ever occur. As an extension to the specification, SuiteSparse:GraphBLAS does not perform this error check on unused inputs of built-in operators. For example, the GrB_FIRST_INT64 operator can be used in GrB_eWiseAdd(C,..,A,B,...) on a matrix B of any type, including user-defined types. For this case, the matrix A must be compatible with GrB_INT64.

@jim22k jim22k added this to the v2.1 milestone Mar 29, 2023
@jim22k jim22k added the maybe This issue may be considered for the given milestone label Mar 29, 2023
@jim22k jim22k modified the milestones: v2.1, v3.0 Jun 28, 2023
@jim22k jim22k removed the maybe This issue may be considered for the given milestone label Jun 28, 2023
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

No branches or pull requests

3 participants