Skip to content

Computation between scalars #199

Closed

Description

@eriknw

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. added
    discussionDiscussing a topic with no specific actions yet
    featureSomething is missing
    on Apr 5, 2022
  2. eriknw commented on May 19, 2022

    @eriknw
    MemberAuthor

    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
    Member

    Yes, let's do this.

  4. eriknw commented on Nov 24, 2022

    @eriknw
    MemberAuthor

    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. self-assigned this
    on Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

discussionDiscussing a topic with no specific actions yetfeatureSomething is missing

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions