On Apr 15, 5:33 pm, Arnaud Delobelle <arno...@googlemail.com> wrote: > I still don't think mutable floats are necessary. Here is an approach > below - I'll let the code speak because I have to do some shopping!
Hats off to you, Arnaud! I'm very impressed by the ideas found in your code. :) Your UExpr object is almost a mutable float, though ("x=UVal(...); y=x; x.value =...; print y+0" gives a new value). What was not needed was some kind of "external" access to numbers with error, that would have allowed an external routine to modify them so as to perform calculations of Python expressions with different parameters. Your idea of building an expression (UExpr) that keeps track of the variables involved in it (basis) was great! I was somehow stuck with the idea that "float with uncertainty" objects should return a float, when involved in mathematical calculations. I adjusted your code in a few ways, and put the result at http://code.activestate.com/recipes/576721/ (with due credit): 1) There was a strange behavior, which is fixed (by performing only dynamic calculations of UExpr, with an optimization through a new "constant" class): >>> x = UVal(100., 1.) >>> y = 2*x >>> x.value = 3.14 >>> print y, "should equal", y+0 # Values not equal! 200.0 +- 2.0000000006348273 should equal 6.2800000000000002 +- 2.0000000000131024 2) More operations are supported: calculations with integers (UVal (1)), comparisons, unary operators + and - (+Uval(1.)),... 3) The code is documented, and identifiers are longer and more explicit. Voilà! Thank you all for this lively and productive thread! -- http://mail.python.org/mailman/listinfo/python-list