# 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:** 10

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 30, 2020, 11:44am UTC](https://discourse.julialang.org/t/a-community-convention-for-target-function-return-values/42248/10 "2020-06-30T11:44:12Z")

</div>

> [@oschulz](#):
>
> Exactly - I think the approach about having lightweight common “almost-API-only” packages has been extremely successful in the Julia community/ecosystem. We have plotting recipes, we have ZygoteRules and ChainRulesCore, we have NLSolversBase and MathOptInterface, and so on.
> 
> So why wouldn’t we profit from having a common API for target functions like densities and loss functions, so that these can be coded up in a way that’s compatible with a variety of algorithm implementations?

Some packages have a common interface, some don’t. Eg from the examples you have mentioned, NLSolversBase is perhaps the one that is used most widely… with [13 direct dependents](https://juliahub.com/ui/Packages/NLSolversBase/NEDD6/7.6.1?t=2), while there are many more package doing optimization.

Personally I find the interface a bit too convoluted (with modifying and non-modifying variants etc), but I respect that some people find it useful. Making a common API for objective functions would require that we find some common ground though; at this stage of the ecosystem’s development I am not entirely sure this is a reasonable goal.

> [@oschulz](#):
>
> And if we could get packages like (e.g.) `DynamicHMC` , `AdvancedHMC` , `Optim` , etc. to support that interface - maybe in addition to their own style

This is a nice example because it actually exposes a difference in design. My understanding (and I would appreciate being corrected if I am wrong) is that the authors of Turing.jl wrote AdvancedHMC.jl as a _backend_ for use in Turing.jl, while DynamicHMC.jl wants users to code their own log posteriors. I am not sure if the intersection is very useful and someone would switch between these two — after all, they do pretty much the same thing.

Again, what I am not convinced about is the use case of switching between MCMC, optimization, and other approaches which need a \mathbb{R}^n \to \mathbb{R} function (w/ derivatives). While seemingly similar, these usually require a different function.

I recognize that _optimization_ could benefit from a common interface, the and AFAIK NLSolversBase.jl aims to do just that. Maybe refining the API for objective functions would be a reasonable interim goal to start with.

---

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