Testing permissible range when in theory when there is no upper limit?

[helske]

This is more of a question, what would be the correct way to document a positive integer argument that can in theory get arbitrarily large values, but that will also increase computation time and memory requirements so that in practice there is some upper limit which depends, not only on the computational resources but on other parameters? For example in my case the number of particles in the particle filter, where the upper limit depends on how big your model is, how much memory you have and long you are willing to wait.

[mpadge]

The quick answer: I was avoiding having to think about this. One possible route would be to have some phrase like "should generally be less than X", which autotest should pick up and not test beyond. You'd then be free to note the additional considerations like you describe there without having to actually implement a hard limit yourself.

Note, however, that current implementation of autotest does not pick that up, so I'll modify asap to ensure it does so. Would that seem acceptable to you?

[helske]

Yes, something like that could work at least for the time being. The problem I see in this solution is that X can still depend on lots of things so it is actually difficult to define even general X. For example, in particle-MCMC, the total number of stored samples depends on multiple arguments and the model size, which then affect the realistic upper bound for the number of iterations. But yeah, I can see myself writing something along the lines "This parameter affects the run time and should be generally less than 1e6 (depending on the model and other sampling parameters) at least for initial testing".

I'll think about this as well, one solution could be some kind of tag dontautotest in the docs, which would skip the parameter, but that doesn't sound optimal either because then other suitable tests are skipped as well.

[mpadge]

@helske The above commit sets up the greping for patterns like that, via these two lines:

autotest/R/input-int.R

Lines 150 to 151 in 2b2c824

	ptn_lower <- "(more|greater|larger)\\sthan|lower\\slimit\\sof|above"
	ptn_upper <- "(less|lower|smaller)\\sthan|upper\\slimit\\sof|below"

That should cover most cases (although it does require limits to be given as integers and not words). Next few commits will actually implement it.

[mpadge]

@helske That should now catch your case, but I'll re-open in order to:

1. Ensure that this is appropriately documented somewhere; and
2. Improve the main single_int_range() function which still contains now mostly redundant code from prior form which used to first test then grep; new form greps first then tests, so lots of code can be tidied and removed.