-
71. Data: 2012-11-06 14:47:26
Temat: Re: B dny epsilon - this is not a bug, this is ?
Od: Michoo <m...@v...pl>
On 06.11.2012 13:32, Roman W wrote:
>> boost::Interval Arithmetic Library - wychodzi ~2x wolniej, ale pozwala
>>
>> całkiem nieźle oszacować, czy uzyskany wynik jest czymś więcej niż
>>
>> nagromadzeniem błędów obliczeniowych.
>
> Da sie to "wrzucic" do starego kodu bez zmudnego przepisywania kazdej linijki?
>
Musiałbyś zrobić wrapper i poczarować preprocesorem, ale jest spora
szansa, ze by się dało w miarę "gładko". Problemem mogą być zewnętrzne
biblioteki/funkcje, które wymagają zwykłego double a nie przedziału -
można dodać operator konwersji + #warning.
I z tego co widzę w starym kodzie trzeba napisać samemu funkcje do
potęgowania i pierwiastkowania dwoma przedziałami.
--
Pozdrawiam
Michoo
-
72. Data: 2012-11-06 14:55:59
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: "AK" <n...@n...com>
Użytkownik "Roman W" <r...@g...com> napisał:
> Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli mam kod:
> if (a >= 0) {
> b = sqrt(a);
> } else {
> // zglos blad ze a ujemne
> }
> to zastepowanie "a >= 0" przez "a >= EPS" nie ma sensu.
Nie a >= EPS ale: a >= -EPS
Ma sens.
PS: Nigdy nie dostales z banku ponaglenia, ze masz natychmiast doplacic -0.00 zl ?
PS1: tak sie zdarzylo przed wielu wielu laty, ze uparte uzywanie przeze mie gdzie sie
da w/w
konstrukcji skutkowalo tym, ze takie ponaglenia w systemie "defBank"
pojawialy sie rzadko...
AK
-
73. Data: 2012-11-06 15:02:10
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: "AK" <n...@n...com>
Użytkownik "Michoo" <m...@v...pl> napisał:
>> if (a>= 0) {
>
> Ale to jest porównanie ze stałą a nie porównanie dwóch liczb.
Nie ma znaczenia.
'a' nie jest stala.
_Zawsze_ (no... z naprawde minimalnymi wyjatkami potwierdzajacymi regule:) trzeba tak
uzywac fp.
PS: K..de, ten temat chyba nigdy zniknie ;)
Pisze o tym "problemie": na wszelkich usenetach od 30 lat :)))
PS1: nawet dwie stale trzeba tak porownywac :)
Dlaczego ? A bo:
3.14159256dalej_nie_pamietam0000000000033333 ==
3.14159256dalej_nie_pamietam0000000000077777
da true
AK
-
74. Data: 2012-11-06 15:35:49
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: "AK" <n...@n...com>
Użytkownik "AK" <n...@n...com> napisał:
> Ma sens.
Gwoli wyjasnienia:
Wez(cie) pod uwage, ze oczywiscie pisze dosc prowokacyjnie i dlatego "zaostrzam"
stanowisko niczym f.Diraca.
W "zyciu" problemy z uzywaniem fp sa bardziej "gaussowskie" czyli mozna niekiedy
(a zcasami nawet czesto) uzywac zwyklych porownan, ale trzeba to czynic z glowa
swiadoma jak "smakuja" fp i zawsze sie zastanowic czym moze skutkowac
_w konkretnym przypadku_ takie "ostre" porownanie.
Na luzie:
Przyklad trywalny: Jesli taka czaskowa x = -0.00000000001 ma trafic jako
suma_wydatkow += x to jak najbardziej _nie wolno_ tegox traktowac jak 0.0,
ale jesli ta wynikowa suma_wydatkow == -0.00003 ma skutkowac blokada konta
i wpisaniem w rejest dlugow to.. powinno sie takiego programiste zamknac w celi
lacznie
z "dluznikiem" :) Wyrok wykona sie sam..
AK
-
75. Data: 2012-11-06 15:54:28
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: bartekltg <b...@g...com>
W dniu 2012-11-06 14:55, AK pisze:
> Użytkownik "Roman W" <r...@g...com> napisał:
>
>> Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli
>> mam kod:
>
>> if (a >= 0) {
>> b = sqrt(a);
>> } else {
>> // zglos blad ze a ujemne
>> }
>
>> to zastepowanie "a >= 0" przez "a >= EPS" nie ma sensu.
>
> Nie a >= EPS ale: a >= -EPS
> Ma sens.
>
> PS: Nigdy nie dostales z banku ponaglenia, ze masz natychmiast doplacic
> -0.00 zl ?
Ale ujemne zero ani ujemna liczba float nie spełnia x>0!
Może problem był w tym, że ten warunek sprawdzano zbyt
wcześnie, potem robiąc obliczenia, które gubiły dokładność.
Ale ja nie o tym chciałem...
> a == b fabs(a - b) <= EPS
> a != b fabs(a - b) > EPS
To trochę bez sensu.
Raz a i b są rządu 10^50, za drugim razem
rzędu 10^-30.
I obie różnice mam badać tym samym epsylonem?
Ale dla pierwszej pary powinien być w okolicy
10^36, a w drugiej 10^-44 :)
Chyba miałeś na myśli coś w rodzaju
a == b fabs(a - b) <= EPS * (a+b)
a != b fabs(a - b) > EPS * (a+b)
pzdr
bartekltg
-
76. Data: 2012-11-06 15:57:03
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: Roman W <r...@g...com>
W dniu wtorek, 6 listopada 2012 13:37:09 UTC użytkownik Michoo napisał:
> On 06.11.2012 13:31, Roman W wrote:
>
> >
>
> > Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli mam kod:
>
> >
>
> > if (a>= 0) {
>
>
>
> Ale to jest por�wnanie ze sta�� a nie por�wnanie dw�ch liczb.
Porownanie "a >= b" jest rownowazne porownaniu "a - b >= 0".
RW
-
77. Data: 2012-11-06 16:03:15
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: Roman W <r...@g...com>
W dniu wtorek, 6 listopada 2012 13:56:14 UTC użytkownik AK napisał:
> U�ytkownik "Roman W" <> napisa�:
>
>
>
> > Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli mam kod:
>
>
>
> > if (a >= 0) {
>
> > b = sqrt(a);
>
> > } else {
>
> > // zglos blad ze a ujemne
>
> > }
>
>
>
> > to zastepowanie "a >= 0" przez "a >= EPS" nie ma sensu.
>
>
>
> Nie a >= EPS ale: a >= -EPS
>
> Ma sens.
Nie ma, bo dla a == -1E-18 wyprodukuje NaN.
>
>
>
> PS: Nigdy nie dostales z banku ponaglenia, ze masz natychmiast doplacic -0.00 zl ?
A co to ma do rzeczy? Swiat sie nie konczy na sofcie do obrabiania cyferek
na kontach.
RW
-
78. Data: 2012-11-06 16:20:26
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: Michoo <m...@v...pl>
On 06.11.2012 15:57, Roman W wrote:
> W dniu wtorek, 6 listopada 2012 13:37:09 UTC użytkownik Michoo napisał:
>> On 06.11.2012 13:31, Roman W wrote:
>>
>>>
>>
>>> Nie jestem przekonany do tego, ze tak sie powinno robic ZAWSZE. Jezeli mam kod:
>>
>>>
>>
>>> if (a>= 0) {
>>
>>
>>
>> Ale to jest por�wnanie ze sta�� a nie por�wnanie dw�ch liczb.
>
> Porownanie "a>= b" jest rownowazne porownaniu "a - b>= 0".
Na komputerze nie ;)
unsigned int a=1,b=2;
Zero jest przecież dość szczególną wartością i jeżeli a jest mniejsze od
0 o epislon to czasami traktujemy je jako 0 dopiero po przemnożeniu *-1,
albo przypisaniu "wprost" zera.
--
Pozdrawiam
Michoo
-
79. Data: 2012-11-06 16:48:28
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: "AK" <n...@n...com>
Użytkownik "bartekltg" <b...@g...com> napisał:
> Ale ujemne zero ani ujemna liczba float nie spełnia x>0!
Wiem, widzialem to. Secjalnie zostawilem.
Po prostu trzeba zrobic sqrt(max(0.0, a))
Czyli ? Jak zwykle: Myslec i "byc swiadom".
Nie ma idealnego "schematu dzialania" dla fp.
> Może problem był w tym, że ten warunek sprawdzano zbyt
> wcześnie, potem robiąc obliczenia, które gubiły dokładność.
>
>
> Ale ja nie o tym chciałem...
>
>
> > a == b fabs(a - b) <= EPS
> > a != b fabs(a - b) > EPS
>
> To trochę bez sensu.
>
> Raz a i b są rządu 10^50, za drugim razem
> rzędu 10^-30.
> I obie różnice mam badać tym samym epsylonem?
> Ale dla pierwszej pary powinien być w okolicy
> 10^36, a w drugiej 10^-44 :)
Pisalem jzu tez ze bardzo czesto w numeryce uzywa sie EPS wzglednego.
Jak juz chyba kiedys tu pisalem "prawdziwa sztuka" to niekiedy wlasnie
dobor EPS.
Czasami sam dobor kroku w metodach optymalizacyjnuych
to prawdziwa sztuka i czesto nietrywailnuy algorytm..
Zalezy on a jakze on zmian wynikow czaskowych czyli posrednio od EPS.
W primitywnych obliczeniach jednak jak najbardziej EPS moze byc staly.
Zalezny po prostu od dlugosci mantysy.
> Chyba miałeś na myśli coś w rodzaju
>
> a == b fabs(a - b) <= EPS * (a+b)
> a != b fabs(a - b) > EPS * (a+b)
Rowniez. Pisalem o wzglednosci EPSa ale przeciez chodzi o zasade
wiec nie chce zaciemniac niekiedy naprawde nietrywialna "praktyka".
Szczegolnie np. w optymalizacji "plaskich funkcji" pojawia sie
problem "kiedy przestac" i/lub kiedy wydluzyc krok.
To neikiedy wrecz decydujaco wplywa na sprawnosc, dokladnosc
czy pewnosc algorytmu.
Tu sam EPS nie wystarczy
Tu np. trzeba wpierw zrobic jakis skalowanie "teoretyczne"
we wzorze funkcji, aby otrzymywane wyniki (wartosci) nie maily
zakresu 0.00000...0001 ale przyslowiowy 1.000
Nie wystarczu skalowanie "mechaniczne" (pomozenie wyniku)
bo juz jest po stracie cyfr znaczacych mantysy.
Itp itd i tak dalej. cala poddziedzina numeryki.
PS: jeszcze pamietam, ze np w metodach optymaliacji gradientowych
(np po lbie mi chodza do dzis nazwy metod Powella, Fletchera,
Wollfa-Broydena-Davidona itd itp) poprawa kiedunku gradientu to
nie byla tylko teoria.
Czasami sprawdzaly sie malo deterministyczne dzialania zawezajace stozek
dopusczalny gradientu, czasami byly to jakies heurystyki a niekeidy pomocne
byly nawet tak z pozoru oblesne "techniki" jak kilka rzutow kostka w
MonreCarlo w poblizu "miejsca chwilowego postoju".
(ze o rownanich rozniczkowych juz nie wspomne, tam EPS i krook to wprost sedno
choc tu sie "nie znam" :)
Czy to sie wiaze z EPS ? Posrednio jak najbardziej.
Ciagle sie sprawdzalo jakis roznice, kroki itp (sorry malo co pamietam
bylo to 30 lat temy tak tak, jeszcze na Odrze :)
Zreszta Wy "numerycy" sami to wiecie :)
Pisze raczej do mniej swiadomych.
AK
-
80. Data: 2012-11-06 16:56:27
Temat: Re: Błędny epsilon - this is not a bug, this is ?
Od: "AK" <n...@n...com>
Użytkownik "Roman W" <r...@g...com> napisał:
> PS: Nigdy nie dostales z banku ponaglenia, ze masz natychmiast doplacic -0.00 zl ?
> A co to ma do rzeczy? Swiat sie nie konczy na sofcie do obrabiania cyferek na
kontach.
Ano nie konczy.
Dajmy na to jest sobie obrabiarka numeryczna i program robiacy korekte noza
double y = obliczenia_geometrii()
ny = skoryguj_polozenie noza(ny, y)
No i teraz sobie wyobraz ze dzialasz "ostro" a nie z EPS.
Niezle wygladala by powierzchnia tak obrobionego przedmiotu (jak pomarancza :)
a chyba glowica by sie rozleciala z ciglych drgan.
Gdy zadzialamy z EPS (a rzadko kiedy obrabia sie zdokladnosci wieksza od EPS=0.01 mm
to wszysko sie uskopoi.
PS: Tak tak. W mechanice i CAD/CAM/CAE tez dlugo "siedzialem".
AK