Użytkownik "M.M." <m...@g...com> napisał:

>> Kto Ci powiedzial ze fp C/C++ jest zapisane w postaci poteg dwojki ?
>> A moze sa pamietane decymalnie ? Albo siodemkowo ?
>
>Nikt mi nic takiego nie mówił, ani ja nic takiego nie mówię.
>
> Mówię tylko to, że jeśli jeden raz pow(3.0,2.0) równa się 9.0 na ostro, a
> drugi raz nie równa się, to ten pierwszy raz jest dokładniej.

Otoz nie.
Moze sie okazac, ze ten koproc/kompilator ktory akurat daje dokladnie
w tym przypadku pow(3.0,2.0), w wiekszosci innych przypadkow
sie "myli", natomiast ten gdy ten gorszy liczy "dobrze".

> Być może taka dokładność jest okupiona wolniejszym wykonaniem.

Byc moze, a byc moze nie (np inna reprezentacja wewnetrzna,
inna dlugoscia akumulatora itp).

Naprawde dyskusje o fp sa toczone na usenecie od zawsze (rowniez przeze
mnie wiec na stare lata sobie dam spokoj z nawracaniem kolejnego pokolenia
"mlodych gniewnych wiedzacych lepiej" bo mi szkoda resztek zycia.
Zalosc tylko bierze, ze na studiach tak podstawowej rzeczy nie ucza jak
traktowanie liczb fp w jezykach programowania jako ZAWSZE
obarczonych pewnym bledem.
Ta "niedokladnosc" nalezy traktowac nie jako neidoskonalosc
kompilatora/procesora ale jako NATURE tych liczb.
Owszem, ciagle w kompilatorach dazy sie do uleopszen w celu
molziwie najwiekszej dokladnosci/mozliwie najwiekszemu zneutralizowaniu
tej CECHY fp, ale absolutnie nie nalezy tego uwazac za
"zalatwienie" problemu. (Przyklad ostatnich ulepszen dla Pythona
na koncu).

Hint: szukaj chocby mych postow tyczacych fp
(Google: Adam Karpierz, liczby zmiennoprzecinkowe), a jak mi
nie wierzysz to spojrz do pierwszej ksiazki jaka przeczytalem po
postanowieniu nauczenia sie programowania:
prof Maciej Syslo "Algorytmy optymalizacji w jezyku Algol60"
a tam w pierwszym algorytmie - simplex - jak byk stoi cos w rodzaju
if abs(x - y) <= EPS then // czyli odpowiednik x == y
begin
comment Solution found;
...
end;

Pozdrawiam

AK

------------------
.
Conversions between floating-point numbers and strings are now correctly rounded on
most platforms.
These conversions occur in many different places: str() on floats and complex
numbers; the float and
complex constructors; numeric formatting; serializing and deserializing floats and
complex numbers
using the marshal, pickle and json modules; parsing of float and imaginary literals
in Python code;
and Decimal-to-float conversion.

Related to this, the repr() of a floating-point number x now returns a result based
on the shortest
decimal string that's guaranteed to round back to x under correct rounding (with
round-half-to-even
rounding mode). Previously it gave a string based on rounding x to 17 decimal digits.

The rounding library responsible for this improvement works on Windows and on Unix
platforms using
the gcc, icc, or suncc compilers. There may be a small number of platforms where
correct operation
of this code cannot be guaranteed, so the code is not used on such systems. You can
find out which
code is being used by checking sys.float_repr_style, which will be short if the new
code is in use
and legacy if it isn't.

Implemented by Eric Smith and Mark Dickinson, using David Gay's dtoa.c library; issue
7117.

.
Conversions from long integers and regular integers to floating point now round
differently,
returning the floating-point number closest to the number. This doesn't matter for
small integers
that can be converted exactly, but for large numbers that will unavoidably lose
precision, Python
2.7 now approximates more closely. For example, Python 2.6 computed the following:


>>>>>> n = 295147905179352891391
>>> float(n)
2.9514790517935283e+20
>>> n - long(float(n))
65535L

Python 2.7's floating-point result is larger, but much closer to the true value:

>>>>>> n = 295147905179352891391
>>> float(n)
2.9514790517935289e+20
>>> n - long(float(n))
-1L

(Implemented by Mark Dickinson; issue 3166.)

Integer division is also more accurate in its rounding behaviours. (Also implemented
by Mark
Dickinson; issue 1811.)