Re: problem with floats and calculations
Stefan Krah
> hey all,
> I got a problem with floats and calculations. I made an mini-application where
> you get random questions with some science calculations in it
> So the user can type in his result with the values given by random creation.
> And the user value is compared against the computer value... the problem is
> that the user input is only 2 numbers behind the '.' so like 1.42, 1.75
>
> here is the example:
> http://dpaste.com/hold/158698/
>
> without decimal it would be very inaccurate. decimal is very accurate when I
> have to compare d with users calculations from a,b,c,var.
> But when I ask the user what is "a" the result gets inaccurate when calculating
> with the same values given before (b,c,d,var).
>
> Maybe anyone can help me with this problem, I don't want to generate for every
> possible user input a single formula. And also it should be possible for a
> computer, my calculator at home does the same and is much smaller and slower.
d = (a * b)/ (c * var)
d = Decimal(d).quantize(Decimal('0.01'))
By quantizing d, the above equality does not hold any longer. You've got
to drop that line (your calculator doesn't quantize either).
Stefan Krah
Mark Lawrence
Karsten Goen wrote:
> also this doesn't help, there are still errors in the accuracy. Isn't
there
> a perfect way to do such calculations?
>
Please read the following and see if it helps. Also search the python
users mailing list for something like floating point accuracy, you'll
get plenty of hits.
http://docs.python.org/tutorial/floatingpoint.html
Regards.
Mark Lawrence
Stefan Krah
> also this doesn't help, there are still errors in the accuracy. Isn't there a
> perfect way to do such calculations?
The hint I gave you removes the most egregious error in your program.
You still have to quantize the result of (c*var*d) / b) if you want
it to match a. If I adapt your program, I don't find any non-matching
numbers.
for i in range(100000):
# set random numbers
a = Decimal(str(random.uniform(0.1,123))).quantize(Decimal('0.01'))
b = Decimal(str(random.uniform(20.1,3000))).quantize(Decimal('0.01'))
c = Decimal(str(random.uniform(100, 5000))).quantize(Decimal('0.01'))
var = Decimal('8.314').quantize(Decimal('0.01'))
# calc d
d = (a * b)/ (c * var)
if ((c*var*d) / b).quantize(Decimal('0.01')) != a:
print a, (c*var*d) / b
Note that for perfect accuracy you should use the fraction module.
Stefan Krah
Albert van der Horst
Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>On Sun, 14 Feb 2010 10:33:54 +0100, Karsten Goen
><karste...@googlemail.com> declaimed the following in
>gmane.comp.python.general:
>
>> Maybe anyone can help me with this problem, I don't want to generate for
>> every possible user input a single formula. And also it should be possible
>> for a computer, my calculator at home does the same and is much smaller and
>> slower.
>>
>for numeric data. That is -- two decimal digits (0-9) and a few special
>codes (mantissa sign, exponent sign, decimal point location, and
>exponent start). A lot of them (though strangely not HP) included "guard
>digits" -- they would display, say, 8 significant digits for results,
>but kept 10 digits internally, so that rounding errors wouldn't
>accumulate as rapidly. M$ Excel/Access/VisualBasic "money" data type
What is displayed has no influence on rounding errors.
Calculator vendors prevent puzzlement by non-knowledgeable users
by having guard digits. HP apparently deals with professional users,
so I think it not strange at all.
>carries four decimal places, on the assumption that only two are
>significant, and the last two are guards.
>
> Most ALL computers are using IEEE floating point (and the exceptions
>are still a binary floating point, not a decimal representation).
>
> The practice, which /used to be/ taught, is that one does not
>compare floating numbers for equality, but rather one compares the
>difference between floating numbers to be less than some epsilon value;
>epsilon chosen depending upon the significance needed.
>
> Rather than comparing
>
> a = b
>
>one uses
>
> abs(a - b) < epsilon
>
> Since Decimal() also has "infinite" series values (1.0/3.0), an
>epsilon comparison may also be called for.
Not may be.
>--
> Wulfraed Dennis Lee Bieber KD6MOG
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst