Skip to content

GrB_Vector_select (or GrB_Matric_select) accepts a mask M, but GB_selector essentially ignores it #444

@stevenzengg

Description

@stevenzengg

Users of the above operations will notice that the entire input A is scanned unconditionally, and the mask is applied only after the fact in GB_accum_mask. This is acknowledged in Source/select/GB_selector.c, but makes the mask on select essentially decorative. In practice, assign, apply, mxv, mxm, and eWise*` all exploit the mask to prune work, but select does not.

For our service, the tradeoff is thus this:

  1. GrB_assign + GrB_select to achieve O(M) runtime via using O(M) memory, or
  2. prevent memory spikes but accept O(A) runtime via GrB_select with a mask M

Compare with GrB_assign, which applies an operation over A restricted by mask M via iterating over mask entries and binary-searches into A. Fundamentally, I think select can do the same, something along the lines of:

  1. pass M into GB_selector
  2. iterate over entries of M
  3. probe A for each masked index
  4. apply predicate to matched entries
  5. skip GB_accum_mask since the mask is already applied during selection

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions