search

DrTimothyAldenDavis / GraphBLAS

SuiteSparse:GraphBLAS: graph algorithms in the language of linear algebra. For production: (default) STABLE branch. Code development: ask me for the right branch before submitting a PR. video intro: https://youtu.be/Tj5y6d7FegI .
http://faculty.cse.tamu.edu/davis/GraphBLAS.html
Other
345 stars 61 forks source link

Proposal: GxB_CASTOP #252

Closed rayegun closed 7 months ago

rayegun commented 7 months ago

Using a UDT in combination with any other type is quite a fraught process. The lack of casting or promotion affects at least:

  1. ewise_add
  2. heterogeneous accumulation
  3. valued masking

Now that we have the ability to JIT register code, it would be nice to also support (optionally) JITable cast operators. These would be standard UnaryOps but could be registered with a type (GrB_Type_set(MyInt128, GxB_CASTOP, myop) perhaps).

DrTimothyAldenDavis commented 7 months ago

That would be really difficult. Each UDT could have an arbitrary list of possible typecasting, each with its own function pointer. The effort to implement this would far outweigh the benefits.

Kernel fusion would eventually help with this.

rayegun commented 7 months ago

Would it be possible to somehow provide 2 operators to the accum then? Even with kernel fusion a heterogeneous accum will still have to cast T into C if T[i,j] exists and C[i,j] does not (in C = accum(C, T))

Ah I suppose ewise_union fused with the original would be the answer.

DrTimothyAldenDavis commented 7 months ago

Typecasting as it stands now, between built in types, is a real mess to implement and the source of many of my bugs in the past. It's also undefined in certain cases because the C language itself leaves some cases undefined.

Ewise add is weird. In my opinion, ewise add in the spec is odd because entries typecast and bypass the op. They don't do that in my GxB ewise union. But accum is essentially an ewise add not like my ewise union. It would be far too difficult to revise how the accum works