Modifying the value of a float-like object

[Steven D'Aprano]

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.


> on the other hand, the floatref class can
> keep track of the values that were constructed, 

What advantage does that give you? I can think of big disadvantages: it 
is complicated and inefficient and will lead to bugs in your code.


[...]
> To Steven: Thank you for your suggestion about checking
> UserString.MutableString.
> I do understand that mutable objects can be surprising, but, again,
> Python programmers constantly use such objects (lists, dicts,....): I
> don't think that manipulating a mutable float is more of a problem than
> using a list, for a Python programmer.

Lists and floats tend to be used in completely different ways.

I don't have (much) problem with the idea of having mutable floats per 
se, although I think they are unnecessary. But even given mutable floats, 
the use you seem to want to put them will lead you into trouble.


> As for your idea of
> "straight-forward interval arithmetic", it's a good one, but I'd have to
> redefine lots of functions from the math module, to use them explicitly
> in my code, etc.:

But you need to do that anyway, because the math module doesn't calculate 
the error estimates that you need. Given some FloatWithError x, if you 
call math.sin(x) the math.sin() function makes no effort to calculate an 
error term.


> this is heavy; I was looking for a light-weight
> alternative, where all calculations are expressed in Python as if all
> numbers were regular floats, and where you don't have to redefine any
> mathematical operation.  In other words, I'm looking for a robust way of
> implementing the derive() function of Peter without knowing anything
> about which function uses which "numbers with an uncertainty": the
> equivalent of Peter's derive () would simply successively change all
> "numbers with uncertainty" defined so far and see how the result of a
> given calculation varies-- the variables that are not used in the
> calculated expression don't change the result, for instance.  I
> understand that this is computationally inefficient (too many variables
> might be changed), but I don't need speed, only robustness in the
> propagation of errors, and a simple and very legible calculation code,
> and ideally with only a few lines of Python.

Nothing you have described gives me any confidence in the robustness of 
your solution. In fact the opposite: given the description of what you 
are planning, I'd have ZERO confidence in ANY calculation you did, 
because I'd wonder how all the other calculations being performed were 
effecting the calculations you've already done.

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