Zásadní omyl operátoru ==

19.12.2005 22:45 | Přečteno: 1636× | Plané filozofování | poslední úprava: 19.12.2005 22:55

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í.

Ternární řešení

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.

       

Komentáře

[herhor]

Rika se ternarni, ale to je detail, protoze cele to je blabol. Mam dojem, zes zrovna prisel z nejake prednasky, kde zasvetili do taju reprezentace cisel v pocitaci, tak ses prisel hned ukazat..

[paskma]

Za ternární dík. Blábol? Tak ho vyvrať nějakým věcným argumentem.

[herhor]

Jako formalne je to trebas vsechno spravne, nelibi se mi ten styl - nejdriv "zasadni nedostatek beznych programovacich jazyku a jeho drze reseni" - zadny zasadni nedostatek to samozrejme neni, dobry programovaci jazyk neni jako php - nema tam byt operator na vsechno (ani deset druhu porovnani), zadne drze reseni to taky neni, protoze to tak dela kazdy, poznamka o tom, ze "nastesti se to na skolach uci" zni jako ""prosel jsem spoustu skol a vetsinou se to tam ucilo a kde ne tak jsem je na to upozornil"". Dalsi perly "Operátor == nemá být binární, nýbrž ternární." a "Tento program je správně." netreba komentovat.

[paskma]

Pořád čekám na ten věcný argument

[herhor]

OK, nikde nedefinuješ k čemu vztahuješ "správnost" programu. Dovedu si predstavit rozumny a naprosto korektni program, ktery bude vyuzivat toho ze treba (double)(3.0/7) != (float)(3.0/7).

[paskma]

Já tedy ani moc ne. Přijde mi to jako hack. Do řídícího softu k jaderce by ti to QA oddělení nevzalo.

Nicméně souhlasim, že by bylo potřeba míte nějaký operátor, který porovnává binární obrazy. Ale trvám na tom, že je to potřeba jen v naprosto vyjímečných případech.

Třeba v Adě95 je problém dostat se na jednotlivé bitíky i u celých čísel. Mj proto, že celé číslo si tam nadefinuješ jak chceš

type Jablka is range 1..200;

A houby víš, jestli bude podkladový typ fyzicky char, short, int nebo long. Pro práci s bity jsou tam pak nějaké funkce.

Uznávám, že mnou navrhovaná fíčura by se hodila spíš do té Ady, než do low-level C.

[Miloslav Ponkrác]

No jo, podobně se dají definovat celá čísla třeba v Pascalu.

Já bych hlavně řekl, že operátory se nemají zmnožovat, pokud k tomu není vážný důvod. Pokud sám velký paskma (to oslovení myslím samozřejmě v dobrém) má tendenci definovat další a další operátory, vřele mu doporučuji se začít věnovat jazyku APL a zasvětit mu celý svůj život. Tento jazyk jej zejména množstvím operátorů a jeho možnostmi ve výpočtech zajisté zaujme natolik, že v ničem jiném už nebude chtít napsat ani řádku howgh

[paskma]

Že to slyším zrovna od takového fanouška přetěžování operátorů

[Miloslav Ponkrác]

Jsem fanoušek přetěžování operátorů, ale tam, kde to přispívá k přehlednosti a efektivitě.

Řeknu to tak. Mám rád sex, ale kdyby ho po mě někdo chtěl tisickrát denně, tak asi začnu odmítat Stejné je to i s operátory. Mám prostě pocit, že pan paskma začíná nahrazovat kvalitu operátorů kvantitou

[JiK]

Tento program je správně.

Me prijde jakoby to psal nekdo stejne genialni jako samotny pan dokonaly, nedostizny a skvely RNDr. Mgr. Radek Ulhan, CSc.

[paskma]

Hehe. Skoro začínám chápat jeho vášeň pro cenzurování komentářů .

Ten program _je_ správně.

[llook]

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é!");

[Jan Kundrát (jkt)]

Jak bys s tim ternarnim operatorem porovnaval ostatni typy?

[paskma]

Nijak. Je definovaný jen pro reálná čísla.

[herhor]

Ted jsem na neco narazil. Vis o tom, ze zadny bezny programovaci jazyk nema porovnavani pro octoniony?

[paskma]

Většina nemá ani typ pro komplexní čísla. Leda Fortran.

[Miloslav Ponkrác]

Většina rozumných programovacích jazyků náhodou komplexní čísla má, dokonce i C, neřku-li C++. A třeba v C++ funguje operátor == i na komplexní čísla. Já, když si probírám programovací jazyky, se kterýma jsem se setkal, tak naopak musím říct, že komplexní čísla chybí jen u menšíny jazyků.

[Sinuhet]

Az na to, ze kdyz se podivate na tu sablonu, tak se to rozpada na x.real == y.real && x.img == y.img. Takze sme tam kde sme byli.

[Miloslav Ponkrác]

Ne ne, vážený pane! Je to ještě složitější! Třída complex může obsahovat jako svoji reálnou a imaginární složky libovolné typy! Takže třeba tady je to v pořádku:

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.

[Sinuhet]

Ale no samozrejme. Ja chtel jen upozornit, ze u komplexnich cisel ma operator porovnani stejny problem, jako u realnych (pokud to tedy nekdo povazuje za problem).

[ZAH]

Upozorním na chápání operátoru == v javě u všech objektů. Tedy i u komplexních čísel. Operátor testuje shodnost objektů(interně ukazatel na objekt). Nikoliv shodnost hodnot. Něco takovéhoto pro porovnání řetězců je úplně špatně

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);
}

[paskma]

No vidíš. Ale v C# == porovnává u řetězců _hodnoty_. Sranda, ne?

[Martin Beránek]

no super - nejaka vyhoda?

[Miloslav Ponkrác]

To náhodou beru jako výhodu. Operátor == má porovnávat hodnoty, to je jeho funkce.

[Tomáš Bláha]

No ale v Cčku přece porovnává hodnoty -- ukazatelů na pole znaků.

[kar]

Operátor == nakonec vždy porovnává nějaké hodnoty. U jazyků, kde se běžně míchá práce s hodnotami přímo a přes reference, to samozřejmě vede k chaosu. Ve skutečnosti používáš pro každý objekt dva typy porovnání

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?).

[Miloslav Ponkrác]

Ano, je-li výraz typu ukazatel, pak v C se samozřejmě porovnávají hodnoty a je to tak v pořádku. Protože u ukazatelů je jeho hodnotou adresa, kterou obsahuje.

Podle jsou vůbec zvláštní případ v C. C má datový typ pole, ale nelze tam vytvořit proměnnou, nebo výraz typu pole. Jediná možnost je v C používat pro práci s poli ukazatele. Toto je doplněno až v C++, kde existuje šablona vector, která se chová jako regulérní pole a lze jí použít i v proměnných a výrazech. A dokonce disponuje případně i kontrolou mezí pole.

Takže C/C++ je konzistentní. Operátor == vždy porovnává hodnoty výrazů a nikdy jinak. Je-li potřeba porovnávat adresy, pak si o to musíte říci operátorem &.

Z tohoto hlediska si nemůžu zvyknout na Javu, protože tam operátor == dělá jednou porovnávání hodnoty, jindy zase porovnání reference. Bohužel stejnou ptákovinu zavedlo i C#, ale tam je to trochu konzistentnější, protože dost tříd si zavádí vlastní operátor ==, který porovnává hodnoty.

Zato blahořečím z tohoto hlediska C/C++, stejně tak jako PHP, Pythonu a dalším jazykům, které se této chaotické pasti vyhnuly a operátor == tam vždycky porovnává hodnoty. A tak to má být.

[barney]

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 ...

[paskma]

Strojové epsilon (eps_mach) samotné situaci neřeši. Tato konstanta je definována jako nejmenší číslo takové, že:

1 + eps_mach > 1

Tedy eps_mach je obvykle 10^-k, kde k je počet desítkových cifer mantisy. No ale tato konstanta ztrácí smysl, pokud počítáme s čísly třeba 10^10.

[Miloslav Ponkrác]

Nechápu, co tímto autor sleduje. Porovnávání reálných čísel je vždycky ošemetné a to se obecně ví. Nechápu, na co si autor stěžuje.

Stejně tak by mohl autor namítat, že porovnávání funguje špatně pro řetězce, protože je závislé na jazyku a tudíž nefunguje správně.

Na druhé straně není žádný problém napsat si funkci podobného stylu:

template<typename FloatType>
bool compare_with_epsilon
(FloatType number1, FloatType number2, FloatType epsilon = 1e-7)
{
  return fabs(number1 - number2) < epsilon);
}

[paskma]

Autorovi jde jen a pouze o to, že sémantika tohoto operátoru je pro většinu případů neužitečná. Porovnávání binární obrazů reálných čísel na rovnost (právě tak to ieee754 definuje) je prostě na nic. Tak proč to neudělat tak, aby to k něčemu bylo?

[Miloslav Ponkrác]

Nikoli, sémantika operátoru == je pro většinu případů užitečná. Operátor == je definován jako binární logický operátor, do kterého vstupují dvě hodnoty a vystupuje prostě false/true podle toho, jestli jsou hodnoty stejné. Funguje to univerzálně pro jakékoli typy hodnot.

Autor pouze určil, že pro malou podmnožinu typů (limitně se blížící k nule při zvětšujícím se počtu typů v programu ) 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 ==

[llook]

Protože to je operátor na rovnost. Ten "ternární operátor" mi připadá jen jako zvláštním způsobem zapsaná funkce. Takhle by se dali přidat další a další operátory a byl by z toho rozsypaný čaj++.

[petr_p]

Kazdy operator ja funkce a naopak. Rozdil je jen v notaci (infixova vs. prefixova). Kdybyste chtel jit jeste dal, podivejte se na (un)curryfikaci.

[llook]

Každý ne. Při volání funkce se vždy nejdřív vyhodnotí všechny argumenty, zatímco u operátorů se nemusí vždy vyhodnotit všechny operandy.

Vemme si za příklad ternární operátor:

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().

[Michal Kubeček]

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á…

[#Tom]

Operátor == 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ášť.

[Sinuhet]

Nevim jak je to jinde, ale v c++ operatory pro vestavene typy (tedy i float a double) nejde menit.

[#Tom]

To je pravda, ale stačí si nadefinovat typ nový. (Navíc to může být šablona a může tak obsloužit všechny tři typy reálných čísel.)

[Sinuhet]

Panenkomarja - a proc by nekdo delal takovou prasarnu?

[Miloslav Ponkrác]

V Javě je podobná prasárna zakomponována už do jazyka. Sice ne kvůli operátoru ==, ale kvůli jiným věcem. Takže máte základní typy a pak objektové zabalené základní typy přímo ve standardní knihovně

[Miloslav Ponkrác]

Když už jsem v tom, tak bych chtěl upozornit na to, že autor také nedomyslel určité nedostatky jeho "ternáního porovnávání". Jeho operátor by měl problémy v případě, že by se do hry začaly vtahovat takové věci, jako je NaN, Inf a další věci.

[paskma]

No, ten operátor je nadefinovaný přesně tak, jak by to udělal každý programátor porovnávající dvě REÁLNÁ čísla.

abs(x-y) < eps

Takže se dostanu do úplně stejných problémů. Zvlášť NaN dělají bordel. Protože NaN == NaN dá v Javě false.

[Miloslav Ponkrác]

To není věc Javy, ale matematické operace pro reálná čísla jsou naprosto přesně definována.

Tedy platí:

NaN == NaN dává false NaN != NaN dává také false NaN < NaN dává také false NaN <= NaN dává také false NaN > NaN dává také false NaN >= NaN dává také false

Stejně tak operace (X je označeno jako normální číslo, tedy ne NaN, Inf a podobné):

NaN == X dává false NaN != X dává true NaN < X dává false NaN <= X dává false NaN > X dává false NaN >= X dává false

Pokud bych porovnával váš výraz abs(x-y) < epsilon, pak za předpokladu, že by alespoň jedno z čísel x, nebo y, případně obojí bylo NaN, pak by výraz dával hodnotu false.

Takže z hlediska chování v případě NaN by se Váš výraz choval korektně, tedy stejně, jako normální operátor porovnávání.

[paskma]

Vždyť já vím.

Jenže NaN a INF _nejsou_ reálná čísla. To jsou symboly. Nechápu, v čem je problém. Operátor je to stejné jako ta funkce (rozdíl je jen v notaci, jak tu někdo psal). A tu funkci líp nenapíšeš.

[Miloslav Ponkrác]

Dobře, buďme tedy přesní, když pan paskma si to přeje. To, co se používá v typech float, double, apod.. nejsou skutečná reálná čísla. Je to pouze počítačová napodobenina reálných čísel, a této napodobenině chybí některé vlastnosti skutečných reálných čísel. Tedy reálná čísla ála ieee754 nejsou skutečná reálná čísla, když budeme přesní. Do reálných napodobenin čísel ve formátu ieee754 patří i hodnoty typu NaN, Inf apod..

Zbytek Tvé reakce absolutně nechápu. Například jsem nikde netvrdil, že operátory nejsou funkce, apod.. To jako začínáš trpět samomluvou, když reaguješ na něco, co nebylo vůbec řečeno?

[paskma]

Jenže INF (v obyčejné matematice ležatá osmička) taky není reálné číslo. NaN (v obyčejné matematice třeba 0/0) už vůbec ne. Abychom byli přesní

[#Tom]

Mnohdy se zavádí rozřířené množiny R* s +- nekonečnem a C* s nekonečnem, když je potřeba taková množina reálných/komplexních čísel, kde jsou nekonečna žádoucí.

[Michal Kubeček]

No a o to právě jde. Že se tu nebavíme o reálných číslech, ale o hodnotách typu 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.

[Michal Kubeček]

Nemluvě o tom, že relace '|x-y| < ε' není tranzitivní, což je vlastnost, kterou by člověk od operátoru == 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é…

[podlesh]

Nemluvě o tom, že relace '|x-y| < ε' není tranzitivní, což je vlastnost, kterou by člověk od operátoru == 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é…

Dobrá připomínka! Dokonce nejen intuitivně: matematicky je ekvivalence relací reflexivní, transitivní a symetrickou.

[Petr Zelenka]

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?

[paskma]

Rozdíl je jen a pouze v tom, že takhle by to bylo zadrátované do jazyka s vizí, že by to zabránilo jedné programátorské chybě. Jinak máš samozřejmě pravdu.

A taky opakuji, že tohle se asi opravdu nehodí třeba do céčka, ale do něčeho komplexnějšího a na vyšší úrovni. Třeba do Ady.

[Miloslav Ponkrác]

Ano, v Adě si docela dobře dokážu představit reálný typ s přetížený operátorem porovnání, který by bral v úvahu epsilon.

Stejně tak si dokážu představit v C++ třídu, která by obalovala reálný typ a přetěžovala by operátor == způsobem, který by též bral v úvahu epsilon.

Dokážu si představit podobné řešení třeba v Ruby, kde jde ale o globálnější zásah do systému.

Otázkou pouze je, zda by programátor používající takové typy s upraveným operátorem nebyl překvapen a neudělal jiné programátorské chyby vyplývající z toho, že by prostě takové chování operátoru porovnávání nečekal.

[Lukáš Zapletal]

Zcela s tímto návrhem nesouhlasím. Správný kompilátor/IDE na porovnávání dvou floatů/dablů upozorní (alespoň v Javě tomu tak je). Například z nápovědy jednoho integrovaného prostředí:

This inspection reports any instances of floating-point values being compared with == or !=. Floating point values are inherently inaccurate, and comparing them for exact equality is almost never the desired semantics.

Mimochodem - operátor funguje bezvadně v jednom případě, a to triviálním případě, kdy je alespoň jeden z operandu nula. Tento případ pokrývá asi 99 % použití tohoto operátoru, to jedno procento jsou ti, kteří neví, jak je reálné číslo v daném jazyku reprezentováno. A ať se na mě nikdo nezlobí, dávat do jazyka jakousi berličku pro pár rádoby "programátorů" je holý nesmysl.

[paskma]

Jo, takže 1-cos(0) == 0 je podle tebe v pořádku? Podle mě tedy v žádném případě.

Nula je číslo jaké kterékoliv jiné. Tedy nemá nekonečný desetinný rozvoj, to jo.

[Lukáš Zapletal]

Aha, špatně jsem se vyjádřil. Myslel jsem x == 0 případně x != 0. Pochopitelně jakékoliv jiné porovnání už se musí dělat pomocí abs().

[Lukáš Zapletal]

Já to snad ze sebe nedostanu 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.

[kar]

Nebezpečného je na tom co?

Mám operaci, která je dobře definována pro všechna čísla v nějakém okolí nuly, ale pro přesnou nulu se musí počítat zvlášť. Např. x/x, chceš-li něco triviálního (v tomto případě samozřejmě podmínkou s epsilon nic nezkazím, protože výsledek je vždy jedna, ale chci vidět tu nebezpečnost podmínky x == 0.0).

[elviin]

Pekny rozbor od Bruce Dawsona.

[kar]

No tak já mám třeba program, kde se používá porovnávání doublů == zcela smysluplně a správně: čte totiž několik sad čísel v plovoucí řádové čárce, přičemž některé jsou redundantní, tj. některé sady byly zapsány několikrát a je zapotřebí je najít. K porovnání mohu použít == (mohl bych použít i memcmp()), protože dělá přesně to, co má (nejsou tam Infy a NaNy).