Can we get rid of some of those "Info: ..." messages

Interfaces RStan
1

With rstan 2.18, users of brms are flooded with informational messages of the form

Info: left-hand side variable (name=p) occurs on right-hand side 
of assignment, causing inefficient deep copy to avoid aliasing.

that I can’t get rid of without also suppressing other relevant parser information such as failings to parse a Stan model. These info messages mostly look like false positives to me. Is there any way to selectively suppress them or even get rid of them entirely?

2 Likes
2

It is going to be all or nothing. Since you should be confident the autogenerated Stan code will parse, you could suppressMessages all of them. But basically the autogenerated Stan code needs to use more += and / or temporary variables to avoid having the same vector or matrix on both sides of the assignment.

3

I am confident my Stan code parses, but it will fail if the user specifies a syntactially invalid prior. I will see how much of these messages I can avoid with additional += statements.

4

stan 2.17 only generated warnings for cases where there was a definite problem, stan 2.18 generates a lot of spurious warnings…

5

You could try(suppressMessages(stanc(...))) and if that fails stanc(...).

1 Like
6

That does the trick, thanks! Still, are we really loosing efficiency by writing x = x + y instead of x += y as suggested by the informational message?

7

If it is making a copy of a large x, then yes.

8

Not yet. But the plan going forward is to put everything in a logger level so that you can select the levels, information, warning, error, etc.

But for now, no easy way to do that as far as I know. @mitzimorris should know what happened between 2.17 and 2.18 in the parser.

9

@paul.buerkner could you please send or post examples of these programs and I’ll try and track down what’s causing this.

10

@mitzimorris Deep copy warning -- efficient coding?

11

thanks for the example - confirmed bad behavoir.

1 Like
12

Thanks for looking into this Mitzi!

13

good news, bad news:

  • good news, just submitted PR w/ bugfix.

  • bad news: generated code is indeed using stan::model::deep_copy instead of regular assigment and this is less efficient, so there might be a performance slowdown in current 2.18.

14

Thanks Mitzi! Under which conditions are we using stan::model::deep_copy that is what shell we avoid?

And is the bugfix avoiding the call of stan::model::deep_copy?

15

Yeah, thanks Mitzi, but could you clarify if a) something changed in 2.18 that made deep copies occur more regularly and hence generate warnings, or b) these deep copies were already occurring but the warnings just started appearing?
edit: should have read the github issues again first – sounds like the deep copies were introduced in 2.18…

16

in the current version, whenever there’s a simple assignment statement which is somehow updating the value of a variable using its current value, the generated code will call stan::model::deep_copy, e.g.

vector[5] x;
real y;
y = y + 1;  // line 3: spurious deep_copy
x[1] = x[1] + 1;  //line 4: spurious deep_copy
x[2:3] = x[3:4] + 1  // line 5: legit deep_copy

rewriting lines 3 and 4 using compound assignment will avoid the bug, given the logic in the compiler and generator.

17

Sounds like we’re going to need to do another Stan and RStan release with a bunch of patches in it. We should talk about how soon we need to do that and what all needs to be fixed.

18

We need to do another RStan ASAP because prophet got broken. But might as well have the parser fixes and the exception handling fix and whatever else.

19

better news - fix has been merged into develop.

further investigation revealed that deep copy isn’t needed anywhere. a new issue has been filed to remove this altogether from the compiler.

1 Like