Hi Iñaki and David, I fully see the need in a standardized unit package, and I understand the need for propagation of errors (though I'm in the opposite camp to David where I usually need unit tracking and conversion and rarely need error propagation-- though that's because my error propagation is often nonlinear and sometimes not normally distributed, so I have to do it myself).
I agree with David in that: error propagation and unit tracking and conversion are different with partially-overlapping audiences. But, I agree with Iñaki that there is a need for a consistent framework that can handle both. The reason for the need of a consistent framework is that if we have two separate packages that handle both they generally will be unaware of each other and may not play nicely together (ref the recent discussion on tibbles not always playing nicely with code expecting data.frames). I think that three packages should generally be the goal: 1) One that handles units 2) One that handles error propagation 3) One that uses the other two to handle both units and error propagation The components that I didn't see in your discussion of your proposal is extension of both libraries. For units, it should be possible to connect any set of units to any other set of units with a new conversion (e.g. mass and molar units could be connected with a molecular weight). And, it should be possible to have multiple unit systems that can manage separate sets of rules (often an extension of a basic set of rules), and these should be possible to connect together. The example for me again is with molecular weights, I may have molecule 1 that has a molecular weight of 100 g/mole and molecule 2 with a molecular weight of 200 g/mole; I would need to be able to store those at the same time without the system confusing the two. And, I would slow need to store the rule that 2 count of molecule 1 make 1 count of molecule 2. (FYI, parts of this are in https://github.com/pacificclimate/Rudunits2/pull/9 ) For both units and error propagation, these will need to work with general functions in packages that do not explicitly support the new packages. As an example, the lm, glm, gls, etc. (along with thousands of other) functions are unlikely to be modified for support of the packages). There should be some mechanism to make a simple wrapper function that looks at the input and understands how to map the output. Such as: lm_quantities <- function(...) { # look at the LHS of the formula argument, and apply any maths required to determine the units of the LHS. # call lm normally # assign units and/or error propagation to the result of the lm call } That would have to be repeated for any other function of interest. Straight-forward examples that are part of the recommended libraries would hopefully be covered, and other library authors should have a simple way of assessing what the right units and error measures are to add it to their own libraries (optionally). Thanks, Bill > On Oct 6, 2017, at 13:13, David Hugh-Jones <davidhughjo...@gmail.com> wrote: > > One question that comes to mind: what's the synergy? I e why are units and > errors best handled together? I use standard errors a lot, but never > units... I would like a standard way to represent uncertainty but don't > think I need the other stuff. > Cheers, > D > >> On Fri, 6 Oct 2017 at 17:25, Iñaki Úcar <i.uca...@gmail.com> wrote: >> >> Dear all, >> >> Edzer Pebesma and I are combining forces into a new GitHub >> organisation called "r-quantities", to which we have moved the CRAN >> packages 'units', 'errors' and 'constants'. The idea is to write a new >> package called 'quantities' to integrate 'units' and 'errors' into a >> comprehensive solution for dealing with quantity values + uncertainty >> calculus. >> >> Given that a significant fraction of R users, both practitioners and >> researchers, use R to analyse measurements, we believe that the R >> community would benefit from such a project. Moreover, to the best of >> our knowledge, there exists no such an integrated and automated >> framework outside the R language. >> >> We would like to share a proposal [1] to be submitted to the R >> Consortium before October 15. Until then, we kindly invite the R >> package developers to review it. Any feedback or contribution would be >> very helpful. >> >> [1] https://github.com/r-quantities/proposal >> >> Regards, >> Iñaki >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > -- > Sent from Gmail Mobile > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
