search

mrossini-ethz / physical-quantities

A common lisp library that provides a numeric type with optional unit and/or uncertainty for computations with automatic error propagation.
32 stars 3 forks source link

Engineering tolerances #2

Open lukego opened 3 years ago

lukego commented 3 years ago

Hi Marco,

Thank you for your great work on PHYSICAL-QUANTITIES! I've been using this for some experiments in electronics CAD and it's been wonderful being able to preserve units and uncertainties from day one.

I have a challenge though: the +/- uncertainties in my application are engineering tolerances that need to be interpreted as upper/lower bounds rather than confidence intervals over a normal distribution. They are not so much natural phenomena as quality assurance process parameters ("we promise that we threw away all the units that were more than 10% out of spec (and we may have skimmed off the very best ones to sell in a more expensive pool.)")

So in my application 1±10% would refer to the set [0.9,1.1] and 1±10%² would be the set [0.9²,1.1²].

Have you any thoughts on how to address this issue as a PHYSICAL-QUANTITIES user? My first thought is that PHYSICAL-QUANTITIES is still a good match but I need to write a new suite of arithmetic functions, either shadowing the existing ones or with new names, but I wanted to fish for a better idea first.

mrossini-ethz commented 3 years ago

Hi Luke

That is an interesting idea! It would mean to change the underlaying mechanism that calculates the uncertainty/tolerances. I never was especially happy about the assumption of a gaussian distribution (but hey - statistics is hard). It would be nice if this could be modularized such that the user can a) choose from different methods and b) plug in their own method. Of course you could also define your own m+ functions etc., but that is not ideal in my opinion. On the other hand, you may have to implement some code for each operation anyway.

I will think about it.

Marco

lukego commented 3 years ago

Thanks!

Just one further thought is that each kind of uncertainty should probably be tracked separately, and arithmetic operations to only be defined on the kinds that they understand, to avoid "Ariane 5" bugs where one accidentally does arithmetic on a combination of engineering tolerance intervals and gaussian probability distributions and gets non-obviously garbage results.