W dniu 2011-06-18 22:30, Radoslaw Jocz pisze:
>
> spojrzcie na ten kod nie rozumiem zbytno po co ktos
> robil takie sztuczki z przesunieciami bitowymi << 14 >> 14

Chyba chodzi o niekiedy używaną w informatyce realizację liczb
ułamkowych STAŁOPRZECINKOWYCH jako całkowite ze skalowaniem (dziesiętnym
lub bitowym)

"Chyba" tzn nie wczytuję się w ten kod w szczególach

do góry

Użytkownik "Jacek Czerwinski" napisał w wiadomości grup
dyskusyjnych:itivfv$qsr$...@n...onet.pl...

>Jeśli bazą do pytania są szersze przemyślenia, to zagadnienia rachunku
>błędów są od 100-200 lat podstawą kształcenia inzynieryjsko-technicznego.
>Kiedy błąd bezwzględny, kiedy względny, jak

Sorry Winetou, ale komplemutnie pomyliłeś dwie, zupełnie różne, rzeczy:

1. Błąd pomiarowy (czy jak to teraz modnie określać "niepewność"), co
ewentualnie da się powiązać z tolerancją;

2. Dokładność obliczeń, która jest jak każdy koń widzi taka jaka jest jest z
przyczyny używania "liczb" float-point.

Dlaczego cudzysłów? Bo liczby to mamy naturalne, całkowite, rzeczywiste,
zespolone, parzyste, niewymierne itd. Czegoś takiego jak "liczby
float-point" po prostu nie ma (między innymi dlatego, że nie tworzą nawet
grupy, a co dopiero ciała).

Problem jest wielki i ogromny. W praktyce pomaga: a. instynkt
samozachowawczy (stosowanie dobrze uwarunkowanych numerycznie algorytmów);
b. podwójna precyzja, poczwórna precyzja, jeszcze większa precyzja; c.
obliczanie jednej rzeczy różnymi metodami (w nadziei, że jeżeli się nam coś
rozłazi, to wszak w każdej metodzie w inną stronę); d. obliczanie dla
rozmaitych warunków, kroków (patrz punkt c.); e. rachunek interwałowy i
obliczenia po prostu dokładne.

Co do rachunku interwałowego - zamiast x masz przedział (x1,x2), taki że na
pewno x1 < x < x2 . Oczywiście - trzeba rozwinąć to dla działań
arytmetycznych, a także (jeżeli akurat potrzebujesz) np. dla transformacji
całkowych. To można np. zaimplementować jako obiekt C++.

Co do obliczeń dokładnych - cierpliwie pisać (sqrt(2)+sqrt(3))**2 jako
2*sqrt(6)+5 . Może być trochę wątpliwości, które pierwiastki - bo są po dwa.
Ale takie rzeczy to albo "kartka i ołówek" (może być LaTeX jak kto ma
zacięcie), albo dobry program do algebry symbolicznej.

slawek


--- Posted via news://freenews.netfront.net/ - Complaints to n...@n...net ---

do góry

W dniu 2011-06-18 22:40, slawek pisze:
> Użytkownik "Jacek Czerwinski" napisał w wiadomości grup
> dyskusyjnych:itivfv$qsr$...@n...onet.pl...
>
>> Jeśli bazą do pytania są szersze przemyślenia, to zagadnienia rachunku
>> błędów są od 100-200 lat podstawą kształcenia
>> inzynieryjsko-technicznego. Kiedy błąd bezwzględny, kiedy względny, jak
>
> Sorry Winetou, ale komplemutnie pomyliłeś dwie, zupełnie różne, rzeczy:
>
> 1. Błąd pomiarowy (czy jak to teraz modnie określać "niepewność"), co
> ewentualnie da się powiązać z "tolerancją"
jedno słowo na rodowód nauk poznawczych (fizyki) drugie kierunku
praktycznego (techniki).

>
> 2. Dokładność obliczeń, która jest jak każdy koń widzi taka jaka jest
> jest z przyczyny używania "liczb" float-point.

Są to oddzielne byty, masz rację, natomiast ich dalsze skutki już nie
różnią się zbytnio. Nie ma dużego znaczenia czy pomiar ma dokładność
'x', czy jest 'nieskończenie dokładny' ale wprowadzimy i będzie
przetwarzać w systemie o skończonej dokładności. Dalsze zagadnienia
kumulacji błędów nie róznią się bardzo.

do góry

W dniu 18.06.2011 21:30, Radoslaw Jocz pisze:
>
> ostatnio pracuje troche nad grafika wektorowa 2D
> i mam pytanie jak rozwiazac problemy z dokladnoscia i zaokraglaniem

Ogólnie, przeczytaj sobie wstęp do geometrii obliczeniowej w dowolnej
książce o algorytmice (np. "Wprowadzenie do algorytmów" Cormena...) lub
w dobrych źródłach w Internecie (np.
http://was.zaa.mimuw.edu.pl/?q=node/15).



--
Piotr Beling - http://qwak.w8.pl http://warcaby.w8.pl http://bcalc.w8.pl
http://kiedygdzie.co

do góry

W dniu 18.06.2011 21:30, Radoslaw Jocz pisze:
>
> ostatnio pracuje troche nad grafika wektorowa 2D
> i mam pytanie jak rozwiazac problemy z dokladnoscia i zaokraglaniem
Jak możesz użyć to polecam:
http://www.boost.org/doc/libs/1_46_1/libs/numeric/in
terval/doc/interval.htm


--
Pozdrawiam
Michoo

do góry

qwak wrote:
> W dniu 18.06.2011 21:30, Radoslaw Jocz pisze:
>>
>> ostatnio pracuje troche nad grafika wektorowa 2D
>> i mam pytanie jak rozwiazac problemy z dokladnoscia i zaokraglaniem
>
> Ogólnie, przeczytaj sobie wstęp do geometrii obliczeniowej w dowolnej
> książce o algorytmice (np. "Wprowadzenie do algorytmów" Cormena...) lub
> w dobrych źródłach w Internecie (np.
> http://was.zaa.mimuw.edu.pl/?q=node/15).
>
>

spojrzelem na gugla
computational geometry filetype:pdf

754lects.pdf
introduction.pdf
compgeo.pdf

do góry

> http://was.zaa.mimuw.edu.pl/?q=node/15).
>
fajna stronka
:)

do góry

Użytkownik "Jacek Czerwinski" napisał w wiadomości grup
dyskusyjnych:itj2s7$76f$...@n...onet.pl...

>jedno słowo na rodowód nauk poznawczych (fizyki) drugie kierunku
>praktycznego (techniki).

"Błąd pomiarowy" musiał być jakoś pojmowany od czasów najdawniejszych - i to
właśnie z przyczyn "technicznych". Dojrzałą teorię zapodał niejaki Gauss, bo
chciał zmierzyć krzywiznę przestrzeni (tj. zmierzyć czy suma kątów w
trójkącie to 180 stopni) metodami ówczesnej geodezji... i wychodziło mu
jakoś "dziwnie".

>Są to oddzielne byty, masz rację, natomiast ich dalsze skutki już nie
>różnią się zbytnio. Nie ma dużego znaczenia czy pomiar ma dokładność

Różnią się drastycznie. Mniej więcej tak, jak zegarek który "się spieszy"
(tj. skok wskazówki o działkę sekundową następuje w nim co pół sekundy), a
zegarek który ma wskazówki nieprzymocowane do osi (czyli pokazują one
zupełnie dowolne rzeczy, po prostu kręcą się niezależnie od mechanizmu
zegara).

To co teraz robi się "w obliczeniach zmiennoprzecinkowych" to zakładanie, że
owszem, prawda, wskazówki są "nieco" luźno, ale być może jednak mechanizm
nimi kręci.

Drastycznie? A jak można, inaczej niż na kredyt zaufania, wierzyć że
obliczenia na float pointsach są ok, jeżeli nie ma się oszacowania
dokładności, tj. ustalenia jak wielkie są błędy zaokrągleń? Zwróć uwagę, że
żaden FPU/CPU nie ma hardware'owo wspieranego liczenia dokładności wyniku.

Wyjaśnię to na przykładzie - mnożymy 198 razy 51 "ręcznie z oceną
dokładności"

198 to niemal 200
51 to prawie 50
ich iloczyn to 10000

Do tego miejsca mamy obliczenia a'la FPU. Rzecz w tym, że powinno się
jeszcze zrobić coś takiego

zaokrąglając 198 do 200 popełnia się błąd równy 2 czyli mniejszy niż 1%
zaokrąglając 51 do 50 popełnia się błąd równy 1 czyli mniejszy niż 2%
w przypadku iloczynu dobre oszacowanie błędu daje suma "procentów"
czyli błąd wyniku oszacowujemy na 3% (względny)
to daje błąd mniejszy niż 300 (bezwzględny)

Oczywiście, w przypadku obliczeń FPU/CPU mamy teraz (przez monokulturę
Intela - AMD i inni po prostu mają "takie same", nawet jeżeli ARM itd.) w
porywach 80 bitów binarnej mantysy (liczby long double w niektórych
systemach) - chyba że liczymy na jakiś paskudkach poósmej precyzji (nie
wspieranej przez hardware). Niemniej jednak - idea jest taka sama.

Jest rzeczą zdumiewającą, że np. właśnie Intel robi najrozmaitsze bajery -
ale nie potrafi jakoś (a może po prostu nie ujawnia?) procesorów
numerycznych liczących np. z 160 bitową mantysą.

Przy obecnej jest około 16 cyfr dziesiętnych (plus trochę jeszcze jak zmusi
się FPU do poświęcenia cechy na rzecz mantysy). To oznacza, że miliard
kroków, każdy wrzucający "epsilon" przesunie nam wynik o być może 9 cyfr.
Zostanie nam 7 cyfr znaczących. Jak jeszcze zaczniemy to odejmować od
podobnie otrzymanych wyników... oj, to nic nam nie zostanie. Przy 32 cyfrach
znaczących te miliard kroków zostawi nadal ponad 20 cyfr po przecinku. To
dalej niczego nie gwarantuje. Ale jest już trochę lepiej.

Jeżeli ktoś myśli, że wystarczą jedynie dobrze uwarunkowane algorytmy, to
niech liczy na short float. Też można.

slawek


slawek


--- Posted via news://freenews.netfront.net/ - Complaints to n...@n...net ---

do góry

W dniu 2011-06-18 21:30, Radoslaw Jocz pisze:
>
> ostatnio pracuje troche nad grafika wektorowa 2D
> i mam pytanie jak rozwiazac problemy z dokladnoscia i zaokraglaniem
>
> podstawowe problemy z jakimi sie spotykam:
>
> - mamy dane 2 punkty p0(x,y), p1(x,y) powiedzmy p0 jest podany a p1
> obliczony nalezy sprawdzic czy to ten sam punkt czy dwa lezace powiedzmy
> blisko siebie, wiadomo gdy d(p0, p1) == 0 to ten sam punkt ale to tez wiem
>
> - mamy dana prosta zadana dwoma punktami p1,p2 i punkt p0
> sprawdzic czy punkt p0 lezy na prostej czy powiedzmy bardzo blisko tej
> prostej

Może to oczywiste, ale gdzie się da, należy nie dopuszczać do
rozstrzygania takich dylematów stosując się do zasad:
- punkty o matematycznie tych samych współrzędnych powinniśmy
przechowywać jako odniesienia do pojedynczego obiektu,
- po modyfikacji listy punktów, trzeba odpowiednio przetworzyć zestaw
danych (np po podziale odcinka w miejsce oryginału powstaną dwa nowe
odcinki i 3 wierzchołki).

artur

do góry

W dniu 2011-06-19 12:59, slawek pisze:
> Użytkownik "Jacek Czerwinski" napisał w wiadomości grup
> dyskusyjnych:itj2s7$76f$...@n...onet.pl...
>
>> jedno słowo na rodowód nauk poznawczych (fizyki) drugie kierunku
>> praktycznego (techniki).
>
> "Błąd pomiarowy" musiał być jakoś pojmowany od czasów najdawniejszych -
> i to właśnie z przyczyn "technicznych". Dojrzałą teorię zapodał niejaki
> Gauss, bo chciał zmierzyć krzywiznę przestrzeni (tj. zmierzyć czy suma
> kątów w trójkącie to 180 stopni) metodami ówczesnej geodezji... i
> wychodziło mu jakoś "dziwnie".
>
>> Są to oddzielne byty, masz rację, natomiast ich dalsze skutki już nie
>> różnią się zbytnio. Nie ma dużego znaczenia czy pomiar ma dokładność
>
> Różnią się drastycznie. Mniej więcej tak, jak zegarek który "się
> spieszy" (tj. skok wskazówki o działkę sekundową następuje w nim co pół
> sekundy), a zegarek który ma wskazówki nieprzymocowane do osi (czyli
> pokazują one zupełnie dowolne rzeczy, po prostu kręcą się niezależnie od
> mechanizmu zegara).

Dołożę - coś jak "błąd pomiaru" pojawia się np. w finansach, gdy jakiś
kozak próbuje zapisać 1.10 zł w double (zmienny przecinek z binarną
podstawą). M.in. do tego wymyślono "decimal floating-point". Schody
zaczynają się tak czy inaczej, gdy trzeba policzyć zysk z lokaty
z dzienną kapitalizacją, dzienne oprocentowanie 0.0139%, czas trwania:
254 dni. Ale prztnajmniej jest gwarancja, że 0.0139% jest w tych
obliczeniach dokładne (zerowy "błąd pomiaru").

> To co teraz robi się "w obliczeniach zmiennoprzecinkowych" to
> zakładanie, że owszem, prawda, wskazówki są "nieco" luźno, ale być może
> jednak mechanizm nimi kręci.
>
> Drastycznie? A jak można, inaczej niż na kredyt zaufania, wierzyć że
> obliczenia na float pointsach są ok, jeżeli nie ma się oszacowania
> dokładności, tj. ustalenia jak wielkie są błędy zaokrągleń? Zwróć uwagę,
> że żaden FPU/CPU nie ma hardware'owo wspieranego liczenia dokładności
> wyniku.
>
> Wyjaśnię to na przykładzie - mnożymy 198 razy 51 "ręcznie z oceną
> dokładności"
>
> 198 to niemal 200
> 51 to prawie 50
> ich iloczyn to 10000
>
> Do tego miejsca mamy obliczenia a'la FPU. Rzecz w tym, że powinno się
> jeszcze zrobić coś takiego
>
> zaokrąglając 198 do 200 popełnia się błąd równy 2 czyli mniejszy niż 1%
> zaokrąglając 51 do 50 popełnia się błąd równy 1 czyli mniejszy niż 2%
> w przypadku iloczynu dobre oszacowanie błędu daje suma "procentów"
> czyli błąd wyniku oszacowujemy na 3% (względny)
> to daje błąd mniejszy niż 300 (bezwzględny)

Są biblioteki, które wprawdzie nie podają błędu, ale przynajmniej
sygnalizują, że w wyniku operacji doszło do utraty precyzji. Do tego
pozwalają na sterowanie sposobem zaokrąglania, co przy finansowych
obliczeniach jest najczęściej prawnie zdefiniowane.

--
Paweł Kierski
n...@p...net

do góry