Floating point calculation problem

[Schizoid Man]

> Highly unlikely. I'd say impossible, unless you type a different value for 
> x
> of course. By the time the input() function returns, the result is already
> a float. Wrapping it in float() again cannot possibly change the value. If
> you have found a value that does change, please tell us what it is.
>
> The only examples I can think of that will behave that way involve NANs 
> and
> INFs. If you don't know what they are, don't worry about it, and forget I
> mentioned them. For regular floating point values, I can't think of any
> possible way that float(input(x)) and input(x) could give different
> results.
>

No, the calculation returns in neither NaN or Inf at any point.

> float(x) converts x into a float.
>
> - if x is already a float, it leaves it unchanged;
>
> - if x is a string, it converts it to the nearest possible float;
>
> - if x is some other numeric value (e.g. int, Decimal or Fraction,
>  but not complex) it converts it to the nearest possible float.
>
>
> float(input()) is a waste of time. The dangerous part happens in the call 
> to
> input(): a malicious user could type a Python command, and run arbitrary
> code; or they could type something like "10**100**100" and lock up your
> computer. Calling float *after* the call to input doesn't do anything.
>
> In Python 3.x, raw_input is gone, but float(input()) is safe -- it is
> exactly equivalent to float(raw_input()) in Python 2.x.
>
> One other difference between Python 2.7 and 3.3 is that they sometimes
> display floats slightly differently. Sometimes 3.3 will show more decimal
> places:

Thanks for that, I'll post the problematic code here shortly.