Modifying the value of a float-like object

[Eric.Le.Bigot at spectro.jussieu.fr]

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... at 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