A few things: 1) This definitely should be separable from units. And although we have a units package, I still find it easier to simply use variables as units. 2) Scientific data typically is available as numbers 3.56 +/- 0.02 where the 0.02 is either the standard deviation or more often the 95% confidence limit (2-sigma deviation). 3) For the purpose of estimating how errors propagate through calculations scientists typically propagate the gaussian error in the following way. Given a function F(x,y,z...) with errors in the inputs e(x), e(y), e(z)
e(F) = sqrt((dF/dx)^2*e(x)^2 + (dF/dy)^2*e(y)^2 + (dF/dz)^2*e(z)^2 + ...) so we only use the first term in the expansion of the error contribution. This is really very simple. I'm not sure I care if there is a special ring that does this kind of arithmetic. What is important is that the physical constants come with uncertainties and that it be very clear whether they are 1-sigma or 2-sigma errors (NIST quotes the more standard 2-sigma, I believe). 4) The other issue is that there are physical situations where Poisson distributions are observed instead. Thus it may be better to leave the handling of the error propagation up to the individual. 5) Many times I'm interested in the actual expression for e(F), since we are using errors to estimate the sensitivity of our signal-to-noise ratio to improvements in the measurements. Sometimes one particular quantity is the only one we need to improve to get much better final results. 6) The listed package advertises that it does standard error propagation, but I haven't looked at the code to determine if it is what I am talking about. Again, I'm not sure how useful it is as the calculation is so simple. I would look at how the package wraps up the values and uncertainties as they claim that it works with standard python expressions. Jonathan On Saturday, March 17, 2012 3:55:57 PM UTC-5, Eviatar wrote: > > @Jonathan > Thank you for the ideas. I had previously just implemented it by copying > the current NIST values (the same way SciPy does it), but an automatic > update would be good. > > What would be a good way to store a cache? Maybe in a separate text file > as a Python dictionary? This would save the trouble of parsing it at every > runtime, and I think a database would be too much for something like this. > > @Volker Braun > I agree with Robert; there doesn't need to be unit checks, since units are > already implemented and can be multiplied to any ring. > > I'm not really sure about how error propagation with Gaussian > distributions works; does this look right? > http://pypi.python.org/pypi/uncertainties/ > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
