You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I find it super-annoying that we're unable to use our operators to operate on scalars. Should we support ewise_add, ewise_mult, ewise_union, and apply on scalars? Also, support normal infix rules, such as s + 1. But, should these return expressions? Do we even dare to consider masking?
We can do this. We can use s._as_vector() to efficiently do this on GrB Scalars in SuiteSparse:GraphBLAS (other scalars would incur a copy into a new size 1 Vector).
This is important to support for operating on Python scalars
and as methods e.g. s.ewise_mult(t, "+")
I don't think masks make sense (for now). We may be able to support s.select where the first index is always 0 (mathematically, it's probably more correct to have no indices at all).
Activity
eriknw commentedon May 19, 2022
I think a big selling point for doing this is to allow users to more easily see what operators do. For example,
unary.exp(1)orbinary.plus(1, 2).jim22k commentedon May 21, 2022
Yes, let's do this.
eriknw commentedon Nov 24, 2022
Given scalars
sandt, I think we can support multiple syntaxes:binary.plus(s | t)binary.plus(s | t, left_default=10, right_default=10)binary.plus(s & t)binary.plus(s, t) # same as binary.plus(s & t)s.ewise_mult(t, "+")I don't think masks make sense (for now). We may be able to support
s.selectwhere the first index is always0(mathematically, it's probably more correct to have no indices at all).