Steven, I'd appreciate if you could refrain from criticizing so bluntly so many points. I'd be great if you trusted me more for knowing what I'm talking about; I've been a programmer for 25 years, now, and I pretty well know what my own code looks like! I appreciate your input, but please soften your style!
For instance, for your information, to respond only to your first point (below), I'd like to be more precise: I don't want a function that calculates a result (such as f() in Peter's code above) to explicitly contain code for handling uncertainties. This is what I had in mind when I said, perhaps inadequately, that "the place in the code where (foo, baz) is calculated has no idea (...) of where they were defined, etc.". Thus, either f() manipulates numbers without knowing that it is actually performing error calculations when doing x*y, or some code calls f() and does the job of calculating the uncertainty. The first method does not work, for many reasons: (1) correlated errors are really hard to take into account, (2) the 2 modules you list are interesting, but none of them gives the standard deviation of an arbitrary mathematical expression. Steven, there is obviously a strong misunderstanding problem here. For instance, I do not "conflate four different issues as if they were one". There are, however, various issues raised in this stimulating thread, and many paths are worth exploring. It looks to me like Dan has paved the way to a good solution to the initial problem: calculate the uncertainty on any calculation that was written for code that works with floats, without modifying this code; the method consists essentially in performing Peter's calc() calculation, but changing the values of the quantities used through references (as Ben described). But, again, I don't yet see how to unambiguously keep track of the uncertainty associated to a numerical value. I'll try this, to see if the devil does lie in the details, here. :) The other, approximate solution, would be to coerce with float() any parameter that can carry an uncertainty, in calculations (numbers with uncertainty would have a __float__() method that returns a result that can be changed after instantiation); but this would modify (and make less legible) existing code. On Apr 15, 10:59 am, Steven D'Aprano <ste...@remove.this.cybersource.com.au> wrote: > On Wed, 15 Apr 2009 01:05:33 -0700, Eric.Le.Bigot wrote: > > Ben F., you're right on the money! You expressed exactly what I'm > > looking for. Why should I want this? because the place in the code > > where (foo, baz) is calculated has _no idea_ of what foo and baz are, of > > where they were defined, etc.; > > This makes no sense. The piece of code which calculates (foo, baz) knows > EXACTLY what foo and baz are, because it has just calculated them. It has > them *right there*. If it wants to know what they are, it can just look > at them: > > def calculate(): > # lots of calculations > result = (foo, baz) > # what is foo? > foo > # what is baz? > baz > # what are their types? > type(foo) > type(baz) > > As for where they were defined... why do you care where they were > defined? What's important is *what they are*, and you know what they are, > because you have them, right there. > As far as I can tell, you are conflating four different issues as if they > were one: > > (1) how to calculate and propagate errors and do interval arithmetic; > > (2) how to use the functions in the math module with arguments which > aren't floats; > > (3) how to make a mutable float type; > > (4) how to have the result of a calculation magically change when you > change the arguments, without re-doing the calculation (at least not > explicitly re-doing the calculation). > > (1) - (3) are reasonable; (3) is I think pointless but not actively > harmful; but (4) is just creating a world of pain and almost-impossible > to track down bugs. > > > Anyway, Steven gave me hope that some kind of mutable float is possible > > in Python, and Ben perfectly expressed my need. Again, alternatively, > > any module that handles in a convenient manner calculations with error > > propagation would be great, but I have not found any single such module! > > http://pyinterval.googlecode.com/svn/trunk/html/index.html > > http://docs.sympy.org/modules/mpmath/intervals.html > > You should also read > this:http://conference.scipy.org/proceedings/SciPy2008/paper_3/ > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
