The newest version of my #R#package TidyDensity really took off for me. Now wait until the next release which introduces 39 new functions. #R#RStats#RProgramming
The white background logo is the current hex sticker for my TidyDensity #R#package the others were generated from DALL-E #dalle3#gpt#chatgpt pretty cool
Want a simple form of #MCMC analysis in #R well, I got you covered.
My #R#Package TidyDensity has a function called tidy_mcmc_sampling() that is pretty straight forward. It takes a raw vector and performs the calculation you give it over a default of 2k samples.
@nanorepublica I think there's room for this. While applications shouldn't have this (it assumes some level of lack of data integrity), it's probably in most systems > 5 years old. I look at this as a data driven version of https://deadmanssnitch.com/
Been compulsively checking package for days...found this morning that it was in Melbourne. Came home...autocomplete URL for the tracking page. Oh look! it's been delivered! Look outside...no package.
Went down to the post office. Then home and back again to get ID. They tell me it's been signed. Go home and ask around to see if this is true. Nope. Back to the post office... Then I realise that the autocompleted URL was for a previous package that arrived 11 days ago. Didn't tell the person at the desk...
New paper with David Rey-Blanco, @pelayoarbues, and Fernando Lopez presents an open data product with real estate values for three major Spanish markets in 2018: Madrid (n = 94,815), Barcelona (n = 61,486), and Valencia (n = 33,622).
For the importance of open data products that are analysis-ready in GIS and the spatial sciences, see this essential paper by Arribas-Bel et al. (2021)
A little #Emacs#package I made to easily see what #semver constraints translate to in the echo area. For example to ensure that ~1.1.0 actually does translate to >=1.1.0 <1.2.0 and avoid mistakes!
@etenil Few people talk about a major disadvantage of Semver, often in a business context. But even FOSS suffered from it, e.g. Linus' Linux-Kernel.
The issue is the psychological distance in PMs, Marketing, etc to large Numbers. They don't like e.g. "foobar 3.325". And force an arbitrary rename. To "foobar 4.0" if you're lucky. Iignoring that nothing would mandate a Semver-conforming major number change). Or to, worse, "foobar 2025".
And they dislike a "foobar 420.1.0" even more.
So, technical Semver might be nice, but it ignores a human psychological aspect.
Personally I've had suits never mess with a versioning scheme. of YYYY-MM.n, where n is going from 1 up (not a day). That allows two releases in one day ("face palm release"). And it also removes the often not so easy decision of major number change. What e.g. is the API of a GUI program? And when is a change incompatible?
To suits, YYYY-MM isn't too large. And it transports some sense of "newness" (since they usually only have to do with the newest version). That makes this scheme suit-resistant.
And to document API changes ... use the changelog. You have docs, do you?