> R is not the cup of tea of everybody R was offered up-thread as the answer for why SQLite needs statistics functions. My response was that no programming language needs SQLite to have them *less* than R. Now we get this opposite argument. If it it's the non-R users who need these functions, then which programming language are we talking about? Every common programming language you can name either has such things built in as well, or it has a code repository where you can add it; either way, you can then export them as [application-defined functions][0]. Uncommon languages where such things haven't been written yet are hardly a good argument for adding this to SQLite, but even then, you could write the implementations in that language yourself and export them to SQLite. If someone wants to wrap such statistics functions up into [an *extension*][1] for use by others, great! I just don't think such a thing can be justified as a built-in for a "lite" library designed for storing and retrieving data, particularly given that SQLite's original purpose — and still most common use case — is to be linked into a larger program written in a language which either *does* have statistics functions built-in or which offers some mechanism for adding them from a third-party library repository. Have I overlooked a common programming language for which that is not the case, which thus needs the functions to be part of SQLite, there being no other way to get them? The only possible argument I can see for doing this is for the convenience of those using the `sqlite3` shell, who also cannot use SQLite extensions for some reason. That just brings us back to the "lite" argument. Have I overlooked some common use case that doesn't fall under one of the objections above? [0]: https://www.sqlite.org/appfunc.html [1]: https://www.sqlite.org/loadext.html