# A community convention for target function return values

**URL:** https://discourse.julialang.org/t/a-community-convention-for-target-function-return-values/42248
**Category:** General Usage
**Tags:** statistics, optimization, machine-learning
**Created:** [June 29, 2020, 1:03pm UTC](https://discourse.julialang.org/t/a-community-convention-for-target-function-return-values/42248 "2020-06-29T13:03:24Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)
#### Post date: [June 29, 2020, 3:01pm UTC](https://discourse.julialang.org/t/a-community-convention-for-target-function-return-values/42248/6 "2020-06-29T15:01:00Z")

</div>

> [@Tamas\_Papp](#):
>
> For my own packages, related discussion was in

I saw that you have a proposal for `get_logdensity` , `get_gradient` and `get_payload` functions in there, so that would go in the direction that @ChrisRackauckas proposed.

But I think it would be important to have this in a very lightweight central package that does nothing else (LogDensityProblems, for example, while I like it, does have it’s own opinions on how to run AD frameworks and has a load time of 7.5s - not a dependency someone will want to take on just to define a likelihood).

Would there be interest in creating such a standard package that just defines a pure API of functions to access target-function result values?

---

_[View the full topic](https://discourse.julialang.org/t/a-community-convention-for-target-function-return-values/42248)._