Portál AbcLinuxu, 2. května 2025 07:20
O zásadním nedostatku běžných programovacích jazyků a jeho drzém řešení.
Mějme kód v jazyce C nebo Java:
double q = 3.0 / 7.0;
if (q == 3.0 / 7.0)
print("rovnají se");
else
print("jsou rozdílné!");
Pokud takový kód přeložíte, dostanete v různých prostředích, při různých volbách překladu různé výsledky. To, zda se čísla po porovnání vyhodnotí jako stejná, může záležet třeba na tom, jestli se výpočet provede se skladováním v paměti nebo se vše zvládne v registrech koprocesoru (které jsou 80ti bitové - extended precision). Pokud by bylo q deklarované jako float, čísla se rovnat nebudou, protože 3.0 / 7.0 je double.
Testovat reálná čísla na rovnost je čiré bláznovství (a naštěstí se to učí i na školách). Operátor == je dobrý leda tak na porovnávání se speciálními hodnotami INF a NaN. Jinak tento operátor nefunguje, jak by člověk očekával. V téměř každé aplikaci je nutné porovnávat s nějakou tolerancí.
Nemůžu si pomoct, ale v jazycích jako C a Java je to špatně. Operátor == nemá být binární, nýbrž ternární. Dalším operandem má být epsilon, které určí toleranci, se kterou se prvé dva operandy můžou lišit. Tedy:
double q = 3.0 / 7.0;
double eps = 1e-6;
if (q == 3.0 / 7.0 : eps)
print("rovnají se");
else
print("jsou rozdílné!");
Tento program je správně. Operátor == je zde definován jako abs(X - Y) < EPS.
Samozřejmě by nastala diskuse, zda má být nějaké epsilon implicitní, zda má být odvozeno od řádů operandů atd.
Tiskni
Sdílej:
howgh
Stejné je to i s operátory. Mám prostě pocit, že pan paskma začíná nahrazovat kvalitu operátorů kvantitou
19.12.2005 23:27
JiK | skóre: 13
| blog: Jirkoviny
| Virginia
.
Ten program _je_ správně.
Tento názor musím podpořit, čím méně operátorů, tím lépe. A od operátoru rovnosti chci, aby porovnával rovnost.
Stokrát lepší se mi zdá následující drzé řešení:
double q = 3.0 / 7.0;
double eps = 1e-6;
if (around(q, 3.0 / 7.0, eps)
print("asi se rovnají");
else
print("jsou rozdílné!");
x.real == y.real && x.img == y.img. Takze sme tam kde sme byli.
complex<int> x,y; // ... nejaky kod if (x == y) // ...Ale jak říkám, považuji původní operátor == pro reálná čísla jako lepší. Kromě toho jde vždycky i v komplexních číslech napsat:
complex<double> x(1,2), y(1,2); if (abs(x - y) < epsilon) // ...Díky flexibilitě C++ není rozdíl v práci mezi reálnými a komplexními čísly.
public boolean textString(String a,String b){
return a==b;
}
Vrátí true pouze pro totožné objekty, Pro porovnání hodnot se musí použít
public boolean textString(String a,String b){
return a.equals(b);
}
1. identita(a) == identita(b) 2. hodnota(a) == hodnota(b)První je pravda tehdy a jen tehdy, když jsou a a b tentýž objekt. V C to typicky znamená porovnání referencí (&a == &b), v Pythonu id(a) == id(b). Identita je sice obyčejně též nějaký typ jazyka, čímž se sice porovnání 1. převádí na 2., ale nebývá předefinovatelné. Málokdy má smysl pro výrazy, lze-li ho vůbec provést. Doporučuji se ovšem zamyslet, proč se id(re.match('a', 'b')) == id(re.match('c', 'd')) v Pythonu vyhodnotí jako True. Druhé porovnání je to, které si každý typ definuje, jak se mu zlíbí. Zmatek nastává, když default pro 2. je 1., nebo je to ještě hůře jinak pro jednoduché typy a pro složené... V závislosti na duševním zdraví autora třídy nemusí být == transitivní, symetrický ani reflexivní, ale my normální tyto vlastnosti očekáváme, protože jinak to není žádná relace rovnosti. Takže na IEEE == mi spíš vadí, že není reflexivní (pro NaN), než že mu chybí nějaké argumenty (co takhle přidat == hneda dva argumenty: relativní a absolutní odchylky?).
existuje pojem ako "strojove epsilon".
jeho hodnota je nejaka konstanta v /usr/include/
(nepamatam pod akym menom)
a teraz prichadzame na to, ze navrhari javy nepochopili C++
bool operator == (double a, double b) {
return (nejaky ten zapis s abs a EPSILON);
}
a situacia je vyriesena k spokojnosti autora ...
poznamka pre javistov:
skutocne som mohol napisat:
bool operator == (double a, double b) {
return rand () > 0.5 ? false : true;
}
ale nie som predsa v sutazi o najhorsi kod ...
template<typename FloatType>
bool compare_with_epsilon
(FloatType number1, FloatType number2, FloatType epsilon = 1e-7)
{
return fabs(number1 - number2) < epsilon);
}
) týkajících se reálných čísel, a to ještě jenom některých, to jest reálných čísel v plovoucí čárce, kde je porovnávání ošemetné. POkud potřebujete přesně porovnávat reálná čísla, tak buď:
1) použijete výraz (cislo1 - cislo2) &kt; epsilon pro reálná čísla v plovoucí čárce
2) použijete jinou reprezentaci reálných čísel, třeba v pevné řádové čárce, kde se dá porovnávat přímo pomocí operatoru ==
1 ? 1 : unlink("/boot/vmlinuz");
Pokud bychom ho nahradili funkcí:
ternary(1, 1, unlink("/boot/vmlinuz"));
Už je vidět ten rozdíl? Nebo and(FALSE, fn()) versus FALSE && fn().
Autorovi jde jen a pouze o to, že sémantika tohoto operátoru je pro většinu případů neužitečná.
U jednoho typu z… kolika? Nota bene u typu, který se v mnoha programech ani nepoužije a v mnoha dalších sice použije, ale na rovnost neporovnává…
== lze stejně jako mnohé další přetížit. Porovnání pak může brát v úvahu nepřenosti, toleranci (epsilon) bude třeba nastavit zvlášť.
float a double) nejde menit.
float nebo double (pro fajnšmekry možná ještě long double). A tam nekonečna patří, stejně jako NaN. A je nutné, aby se operace chovaly korektně i pro tyto hodnoty.
== instinktivně očekával. Je to jako overloadovat operátor + tak, že nebude komutativní, nebo = tak, že nebude vracet výsledek. Oboje sice v praxi jde, ale není to moc rozumné…
Nemluvě o tom, že relace '|x-y| < ε' není tranzitivní, což je vlastnost, kterou by člověk od operátoruDobrá připomínka! Dokonce nejen intuitivně: matematicky je ekvivalence relací reflexivní, transitivní a symetrickou.==instinktivně očekával. Je to jako overloadovat operátor+tak, že nebude komutativní, nebo=tak, že nebude vracet výsledek. Oboje sice v praxi jde, ale není to moc rozumné…
Zdravím,
možná mi něco uniká, ale tohle řešení podle mě nic neřeší. Místo porovnání dvou nepřesných čísel na rovnost se porovnává rozdíl dvou nepřesných čísel na nerovnost s jiným nepřesným číslem. Kde je rozdíl?
Míním kontrolu po inicializaci. Každopádně i toto je evidentně nebezpečné (na to 1-cos jsem nemyslel), takže je lepší se tomu úplně vyhýbat.
20.12.2005 07:46
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.