Stan fails to report when assigning RHS value larger than LHS

General
1

cmdstan v2.36.0

In my generated quantites section I have the below code. Notice that the three first vectors are of n_trials size. Now, I incorrectly assigned n_patients zeros to these vectors. The number of patients is much larger than the number of trials here.

  vector[n_trials] trial_K_obs_condition_number = zeros_vector(n_patients);
  vector[n_trials] trial_K_obs_min_eigenvalue = zeros_vector(n_patients);
  vector[n_trials] trial_K_obs_max_eigenvalue = zeros_vector(n_patients);
  
  vector[n_patients] patient_K_obs_condition_number = zeros_vector(n_patients);
  vector[n_patients] patient_K_obs_min_eigenvalue = zeros_vector(n_patients);
  vector[n_patients] patient_K_obs_max_eigenvalue = zeros_vector(n_patients);

Stan compiles this and does not report any errors (I guess at compile time it doesn’t know what is in those size variables). At runtime, I get the below inexplicable error:

Storage capacity [37401] exceeded while writing value of size [211] from position [37395]. This is an internal error, if you see it please report it as an issue on the Stan github repository. (in '/tmp/Rtmptz2aEN/model-70e1a0dcb08.stan', line 136, column 10 to column 38)

What I would expect is that at runtime an error would be reported right at when the initialization of incorrect size is happening.

2

Hi, @karimn and thanks for reporting.

Me, too. That was my original intent with the language design. If we had a do-over, that’s what we’d do. The problem we have is that many Stan programs now depend on this bug and fixing it would break a lot of programs. So we’ve decided not to fix it. Sorry if it’s making it harder to debug.

3

Thanks for your response @Bob_Carpenter. So how is this bug used? Just asking to see if I can also take advantage of it! :-) Does it by any chance allow things like

array[] int a = get_some_array_of_ints();
4

I think that we previously viewed this as a bug and tried to fix it: Assign size-checking not occurring for arrays of vectors · Issue #3150 · stan-dev/stan · GitHub

So it might still be something to look at fixing up

5

Using your code as a generated quantities block and creating arbitrary values for the number of patients and trials did yield an exception (e.g. NOT an internal error):

Exception: vector assign rows: assigning variable trial_K_obs_condition_number (37401) and right hand side rows (67401) must match in size (in '../../ml/stanc3/foo.stan', line 6, column 2 to column 75)

If this wasn’t occurring for you, it’s worth trying to understand why

6

No. You always need to declare with a size. What it does allow is that size to be anything and then you can reassign.

It’s being used to dynamically resize vectors at runtime and to create ragged arrays at runtime.

Looking at @WardBrian and @andrjohns comments, it looks like this got fixed at some point (see the link from @andrjohns).

I’m guessing you may be using an older version of Stan, because it looks like this was fixed on Aug 2023.

7

I am using cmdstan v2.36.0 though, which I believe is the latest.

8

Are you using STANCFLAGS=--O1 by any chance? Removing some bounds checks is a known limitation of that setting that we haven’t had developer cycles to address properly yet.

(This is part of why it is generally a good idea to do model development without --O1, and turn it on after you’ve done at least a small run of the unoptimized model)

9

As a matter of fact, yes, I do have stanc_options = list("O1")!

A follow-up question, I love the idea of being able to have ragged arrays/vectors. Do this “bug” allow us to have for example array[n] vector[m] x; and then set arbitrarily sized values for x[1] = zeros_vector(m + 1); x[2] = zeros_vector(m - 1);? When would I get the storage internal error then? Is there a risk of overwriting other variables? Does it re-allocate memory dynamically when I change the size?

10

When the sizes don’t match, Stan ends up inheriting “whatever C++ does”, which in this case isn’t even defined in the C++ spec. If the sizes are “close enough” you might observe the behavior you desire, or you might get crashes, or you might get demons flying out of your nose, or…

2 Likes
11

Ok, in the interest of preserving my nasal cavities, I’ll stay clear.

2 Likes