I just put up my own statistics routines at https://code.jsoftware.com/wiki/User:Devon_McCormick/myStats (also on github). It includes functions related to quartiles. There's one called "quartile" which returns the breakpoints for quartile x in vector y and another called "ntilebps" which is a generalized n-tile routine so, for example, x would be "4" for quartiles.
On Fri, Feb 26, 2021 at 8:08 AM chris burke <[email protected]> wrote: > > I noticed for example that the sqlite package does this. The author > forked the library, modified it so that its easier to integrate, and then > bound J to it leaving code on both sides to maintain. > > Right, though we didn't modify the sqlite code itself, just extended > it to allow J to read and write array arguments to sqlite. Without > that extension, J would have to loop, e.g. record at a time, so this > would slow things down. The only maintenance done is to recompile from > a later sqlite source. > > On Fri, Feb 26, 2021 at 12:04 AM Emir U <[email protected]> wrote: > > > > Hey Devon, I think J's stat libraries are a basic start. the other day I > wrote an interquartile range function because there wasn't one or a > quantile function. Please compare the GNU Scientific list or an ok library > like https://www.statsmodels.org/stable/api.html for gaps. PCA, PLS, KDE, > MCMC, ME est., multivariate distributions, are bread and butter for my work > but none of these things come with J. I personally think that binding a > different language (e.g. R) and then calling stats functions from it is at > best a stop gap but not a solution in itself. That's for example something > that Julia does whilst they hustle to cover all basis. I.e. worst case > scenario, call Python from Julia. What happens in practice is that you just > end up writing stuff in both languages in order to facilitate the > integration which I don't like for maintenance. I noticed for example that > the sqlite package does this. The author forked the library, modified it so > that its easier to integrate, and then bound J to it leaving code on both > sides to maintain. > > > > Hey Bill, I've also used Stan a lot in the last 1.5 years. I've used > both the R and Python packages extensively, and tbh I find the integrations > pretty clunky. I think part of the reason is that Stan has a DSL so you end > up either writing the code in a file and referencing that or having big > multi-line strings in which your model is embedded. I personally prefer > PyMC3 or Nimble type integrations. Just a thought but I think a better way > to grow would be to integrate the SGLD and NUTS routines from Tensorflow > probability, and then specify likelihoods directly in J if that's possible. > However, it means having much better support for commonplace uni/multi > variate distributions at the least. > > > > Emir > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA Quantitative Consultant ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
