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

Reply via email to