Description

eriknw

opened on Apr 5, 2022

Issue body actions

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).

Activity

1. eriknw

   added

   discussionDiscussing a topic with no specific actions yetDiscussing a topic with no specific actions yet

   featureSomething is missingSomething is missing

   on Apr 5, 2022
2. eriknw commented on May 19, 2022

   

   eriknw

   on May 19, 2022

   MemberAuthor

   More actions

   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) or binary.plus(1, 2).
3. jim22k commented on May 21, 2022

   

   jim22k

   on May 21, 2022

   Member

   More actions

   Yes, let's do this.
4. eriknw commented on Nov 24, 2022

   

   eriknw

   on Nov 24, 2022

   MemberAuthor

   More actions

   Given scalars s and t, 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)
     • 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).
5. eriknw

   self-assigned this

   on Nov 28, 2022
6. eriknw

   closed this as completedin #358on Jan 6, 2023

Issue actions