Is there anything an UnsizedType can do that a SizedType couldn't do?

[SteveBronder]

I'm messing with the for loop stuff of #877 and right now the goal is to take

vector[N] x;
vector[N] y = // fill this
for (i in 1:N) {
  x[i] = exp(y[i]);
}

and transform it to

  x[1:N] = exp(y[1:N]);

That's fine, integer sequence subsetting and assignment in the C++ can have a trick that just looks if the sequence start and end is the same size as the input to make this pretty cheap. We could even write an index_positive_min_max for this special case to make this very trivial.

But it would be nice to be able to do

  x = exp(y);

But the problem is that functions only hold an UnsizedType as the arguments and so we lose size information for checking that the rhs is of size N so we can't do the above. I think it would be a lot of effort so not sure if worth it, but is there any reason we have an UnsizedType here instead of a SizedType? Is it just that it is much easier to not have to worry about how to represent the dims?

[seantalts]

The sizes of function arguments are not specified in the Stan language. If we knew no one outside of Stan would call these functions we could attempt to infer their sizes in certain cases, but they are also exposed externally.

…

On Thu, Apr 15, 2021 at 15:42 Steve Bronder ***@***.***> wrote: I'm messing with the for loop stuff of #877 <#877> and right now the goal is to take vector[N] x;vector[N] y = // fill thisfor (i in 1:N) { x[i] = exp(y[i]); } and transform it to x[1:N] = exp(y[1:N]); That's fine, integer sequence subsetting and assignment in the C++ can have a trick that just looks if the sequence start and end is the same size as the input to make this pretty cheap. We could even write an index_positive_min_max for this special case to make this very trivial. But it would be nice to be able to do x = exp(y); But the problem is that functions only hold an UnsizedType as the arguments and so we lose size information for checking that the rhs is of size N so we can't do the above. I think it would be a lot of effort so not sure if worth it, but is there any reason we have an UnsizedType here instead of a SizedType? Is it just that it is much easier to not have to worry about how to represent the dims? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#884>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGET3AHR6GJ2JF25AHF3ALTI46Q5ANCNFSM43AEG67A> .

[SteveBronder]

The sizes of function arguments are not specified in the Stan language.

If we knew no one outside of Stan would call these functions we could
attempt to infer their sizes in certain cases, but they are also exposed
externally.

tbc I'm not suggesting we do anything with the sizes in terms of how things in the Stan language is designed. I'm more interested in using that size information while transforming the mir. So for instance if we had a model like the below

data {
  int N;
  int M;
  int idx1_size;
  int idx2_size;
  int index1[idx1_size];
  int index2[idx2_size];
}
parameters {
  matrix[N, M] X;
}

transformed parameters {
  matrix[idx1_size, idx2_size] = X[index1, index2];
}

We can know that the indexing expresson on the rhs has a return type of a SizedType.Matrix (idx1_size, idx2_size) since those are the sizes of the multi-index

This could be weird for user defined functions though. There would be times we would only know the return type's size is some expression of the arguments of the user defined function