Hi!

With `reduce_sum`

(and `map_rect`

) we can now parallelise Stan programs nicely. However, this comes at the price of being forced to use the standardised densities.

So while one can write this in the model block:

```
counts ~ poisson_log(mu);
```

which avoids calculating log-gamma functions needed for normalisation. Now, when you use the new parallelsiation facilities, then the log-lik must be written in a user defined function, but then users must use

```
log_lik_term += poisson_log(counts | mu);
```

… and this is wasting a lot of computational resources since the normalisation constant is being computed which is often not needed.

So can we solve this?

How about we let users define `mydensity_ lpdf`

where they can simply use the usual `~`

notation. The function would not declare a returned value which would be auto-generated from the stan parser; like:

```
real mydensity_lpdf(int[] counts, vector mu) {
counts ~ poisson_log(mu);
}
```

This would only be compatible with the current language when we *disallow* a return value whenever the `~`

notation is used.

Alternatively, one could turn calls to `poisson_log(counts | mu)`

in users functions into versions which do not estimate the normalisation constant whenever the user density is used with the `~`

notation.

I don’t really mind how we turn these normalisations off, but it’s a bit sad to force everyone to pay some performance penalty when you go parallel merely for the normalisation which is often not used. The alternative for users is write their pdf’s tailored for their case if that is possible (based on using `sum`

or whatever).

Tagging some compiler experts @Bob_Carpenter, @rok_cesnovar, @nhuurre, @rybern … apologies whomever I missed and wanted a heads-up here.

Sebastian