stan-dev / stan-dev/posterior

Distinguishing between scalar rvars and arrays-of-size-1

Open
#187 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

feature
Dominant language
R
Stars
171
Forks
26
Avg merge
2d 18h
Merged PRs (30d)
3

Description

Copying @martinmodrak's post from discourse here since it should probably be resolved in some way:

Hi,
it appears that the rvar interface in posterior cannot distinguish between a scalar and array of size 1, i.e.

scalar <- draws_matrix("y" = 1:10)
array1 <-  draws_matrix("y[1]" = 1:10)
all.equal(scalar, array1) # Correctly unequal
# [1] "Attributes: < Component “dimnames”: Component “variable”: 1 string mismatch >"
all.equal(as_draws_rvars(scalar), as_draws_rvars(array1)) # Incorrectly equal
# [1] TRUE
all.equal(as_draws_matrix(as_draws_rvars(array1)), array1) # Incorrectly unequal
# [1] "Attributes: < Component “dimnames”: Component “variable”: 1 string mismatch >"

Is this the desired/expected behaviour? Or is this a bug?

Also copying my thoughts from later in the thread:

Hmm. One behavior that base R vectors do that I did not mimic in rvars because it creates many corner cases in code is that vectors do not require a dim attribute (i.e. dim(x) can be NULL), whereas rvars will always return a numeric vector for dim (sometimes it's just the length of the vector). I did this because otherwise a bunch of code has to check for NULL dims and use length instead, which at the time did not seem useful.

That said, one way to distinguish between a "scalar" in base R and an array of size 1 is if dim(x) == NULL or dim(x) == 1. So one option would be to have the conversion functions recognize this convention. It will be slightly annoying to fix since we'd have to check all uses of dim() on rvars in the code that assume dim() is guaranteed non-null, and other functions that assume the internal array always has at least two dimensions (since currently this is also guaranteed). This would also mean the value of draws_of() returned to a user would not be guaranteed to have at least two dimensions. I'm also not sure if this would make some other operations on rvars kind of annoying to use if they are returning values that the user would expect to be treated as scalar when converted to other formats but which are actually 1-element arrays.

The other option would be a more focused solution that just uses an attribute, as you suggest. It might be an attribute for array-ness rather than scalar-ness; then 1-element arrays that get converted to rvars from another format could retain their array-ness through this attribute. Would be curious what folks think. (I'm not sure either solution sounds great to me at the moment, at least from the perspective of implementing it :) )

Another idea that occurred to me if we don't want to change how rvars treat scalars versus arrays-of-1 would be to instead expose the helper functions for flattening/unflattening array indices, since it sounds (maybe) like that's what you were intending to use the rvar stuff for @martinmodrak?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the rvar conversion functions, the handling of dim() and draws_of(), and the flattening/unflattening array-index helpers described in the issue. First establish whether scalar-versus-size-one-array identity should be preserved; done means the chosen behavior is documented and conversion round trips consistently distinguish or intentionally unify these cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
r
Domain
data
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.