On Sat, 11 Sep 2004, SP9LWH wrote:
[...]
>+ Jednak dla nieskończonej (ogromnej) ilości przypadkowych danych to się
>+ wyrówna.

No, kiedy ja wzorem RoMana powiadam że się NIE wyrówna :)
Dane "dokładne" powinny np. obejmować wartości X,XXYYY
zaś "prezentowane" są X,XX (dwie cyfry "urzędowe").
Na początek przyjmijmy, iz obliczenia pośrednie robimy "tak
jak na fakturze" - czyli operujemy tylko na kwotach pośrednich
które *są zaokrąglane*. Oczywiście trzeba zauważyć iż wiele
wyników pośrednich różnych obliczeń (np. płacowych) MUSI
być tak liczonych (to dla zastrzeżenia dalej).

Przyjmując iż w tym zakresie rozkład jest statystycznie równomierny
powinniśmy oczekiwać rozłożenia statystycznego połowy (X,XX45000
do X,XX5000) do "prawidłowego zaokrąglania w dół", zaś drugiej
części (X,XX5000 do X,XX55000) do "prawidłowego zaokrąglania
w górę". Ponieważ "widać" wyniki obliczeń tylko w zakresie dwu
cyfr - to WSZYSTKIE wyniki zakresu są zaokrąglane do X,XX+0,01 !
Licząc sumy ilosczynów - otrzymamy "dryft" w wysokości bezwzględnej
ok. 10%*0,01*ilość_obliczeń.
Czyli dla kwot w okolicy 1000 zł i 1000 obliczeń (znaczy: kilkadziesiąt
pracowników po kilkanaście/kilkadziesiąt składników płacowych) wyjdzie
skromne 10^-4*10^3 - 10 groszy, czyli 0,01 procenta. Jak ilość
obliczeń będzie rosła - to i błąd będzie dalej dryfował !
Oczywiście dla innych obliczeń może być korzystniej - błąd licznika
przy ilorazie nie rośnie "tak dobrze" jak przy sumie :)

I oczywiście ów błąd można zmmniejszyć - zwiększając dokładność
obliczeń *tam gdzie przepisy to dopuszczają*: liczenie "na jedną
setną grosza" zmniejszy ów błąd stukrotnie...
Na nasze szczęscie (? :)) - nie wszędzie wolno (!) liczyć "dokładnie"...

>+ Być może umiesz sprawdzić w swoich dokumentach czy co roku niezgodność ma
>+ ten sam znak - czy w niektórych latach jest dodatnia a w innych ujemna ?

Też jestem ciekaw,
IMO może wystąpić pewien efekt kompensujący: ponieważ dla składników
ujemnych zaokrąglenia jak rozumiem robione są wobec wartości
*bezwzględnej* (dobrze mi się wydaje ? -1,025 zaokrągla się do
minus 1,03 ?) - te wartości w których element jest ujemny lub
"wartość obcinana" występuje w mianowniku bedą "tłumiły" efekt
kumulacji błędu. Również "liczenie dokładne" (w tych miejscach
gdzie przepisy *pozwalają*) znacząco zmniejszy błąd.
Ale ponieważ np. dla danych płacowych ilość operacji na "typowych
danych pracowników" jest większa dla liczb dodatnich oraz większa
dla wartości zmiennych w liczniku niż mianowniku - to IMO należy
oczekiwać mierzalnego dryftu.

>+ Metod numerycznych poprawiających uproszczenia w rachunkach na liczbach
>+ zmiennoprzecinkowych o ograniczonej ilości cyfr znaczących jest wiele, jak
>+ to zauważyłeś

Ależ nie ma mowy o "liczbach zmiennoprzecinkowych" !
Już ja cię widzę jak np. tłumaczysz USowi albo ZUSowi
że wyszły ci dwa grosze mniej "bo e to dokładniej jest
2,71... a mój kalkulator przez potęgowanie mnoży dwanaście
cyfr znaczących" :)

>+ Przemienne (połowa zaokrągleń w górę/połowa w dół) traktowanie "5" może
>+ w szczególnych przypadkach generować mniejszy błąd.

Śmiem stwierdzić że my o TAKICH właśnie ("szczególnych przypadkach")
rozmawiamy. I że mniejszy statystycznie błąd wychodziłby na statystycznych
fakturach VAT - bo tylko "korekty na minus" generowałyby efekt
tłumiący a życie pokazuje iż jest ich względnie mało !
Oczywiście NIE sugeruję iż minister powinien usiłować liczyć
"dokładnie"... w końcu po coś na deklaracji obcina się *wszystkie*
grosze !

>+ I być może z takim zestawem danych masz do czynienia w swoich rozliczeniach,
>+ stąd wniosek iż ta metoda jest lepsza.
>+ Na pewno byłaby lepsza od standardowej, gdy "piątki" występują zbyt często.

Odzipnij....
Właśnie stwierdziłeś że "lepszość" jest mierzalna ilością "piątek" !
Po prostu - jak masz tylko 10 liczb do dodania to "szum z zaokrągleń"
jest na tyle wielki że dryftu nie widzisz !
Ale statystycznie on jest ZAWSZE.
Przynajmniej WSZĘDZIE tam, gdzie PRZEPISY narzucają ci obliczenia
stałoprzenikowe on jest MIERZALNY !

>+ Jednak problem tego wątku dotyczy zasady zaokrągleń na fakturach i tu innej
>+ metody niż standardowa się nie stosuje.

Nie stosuje się.
To Marcin zaczynając wątek pytał czy tak się stosuje - i otrzymał
prawidłową odpowiedź.
Nasza dyskusja rozwinęła się z okazji zarzutu Atomka i SP9LWH
o to że metoda byłaby "nieprawidłowa". I coś o "rzucaniu kamieniami
na szkołę" było.

A to NIEPRAWDA.

Akurat na f-rze VAT (kiedy obowiązuje "prezentacja wyników
pośrednich", czyli przynajmniej dla wersji liczenia "tabelki
stawek" wg sumy pozycji oraz wersji "od brutta") byłaby
to metoda DOKŁADNIEJSZA. NIEISITOTNIE dokładniejsza, ale
JEDNAK dokładniejsza :) Mało - powiadam że statystycznie
MIERZALNIE dokładniejsza :) Dla milionów transakcji 0,01%
to już spore odchylenie - *jak na pomiar* :)

>+ W skali całego państwa nie generuje
>+ to dodatkowych wpływów ani strat budżetu

Sprzeciw.
Nie generuje ISTOTNYCH wpływów ani strat :)
Oczywiście jest PROŚCIEJ przyjąć metodę zaokrąglania która jest "bardzo
dobra" przy konwersji z liczb zmiennoprzecinkowych - i powszechnie
dlatego stosowana w komputerologii - niż "wydziwiać" z powodu
błędu o istotności 0,00001 ! (celowo 0,01% tak zapisałem coby
zera lepiej widać było :)).
Natomiast jakby to miało iść do pojedynczej indywidualnej kieszeni...
to może ja zareflektuję ? ;) Na spółę z RoManem ? :)

>+ Straty najpewniej dałoby się zmniejszyć uproszczeniem systemu podatkowego
>+ i eliminacją zbędnych wtedy stanowisk pracy.

Ależ OCZYWIŚCIE :)

>+ Koszmarkiem matematycznym jest wyliczanie formularzy podatkowych z
>+ zaokrąglaniem do pełnych złotych, z obcinaniem groszy, z zaokrąglaniem do 10
>+ groszy.

W pełni się zgadzam. Tak samo jak z tym, ze JEŚLI już ktoś nie może
żyć bez skali progresywnej (IMHO same wady...) to powinien sobie
wziąć prosty wzór w stylu (fixed font):

D - dochód do opodatkowania w złotych

0,4*D*D
podatek= --------
(D+40000)

...żadnych warunków w programie...
Efektywnie 30% dla 120 kzł dochodu (można ustalić czy 40 kzł to
właściwa wartość "przegięcia" krzywej), nie chce mi się liczyć
dla ilu jest w tej chwili EFEKTYWNIE (a nie próg!) 30%.

>+ Ten co to nakazał musiał się bardzo nudzić i koniecznie chciał
>+ wymyślić coś nowego.

Jemu się pewnie wydaje ze za pomocą kalkulatora bardzo łatwo jest
policzyć wynik z krzywej łamanej :)

>+ Problem zaokrągleń widać najlepiej na każdej długiej fakturze VAT
>+ Z powodu 22% suma pozycji brutto zwykle nie zgadza się z sumą netto *1,22

Owszem :)
Na szczęscie (?) jest możliwość wyboru która suma jest "urzędowa" :)

[...]
>+ Czy lobbujesz za zmianą metodologii zaokrąglania piątek na symetryczną (dla
>+ połowy przypadków w górę/ dla połowy w dół) ??

Absolutnie nie.
Mi wystarczy stwierdzenie że generuje ona określony błąd statystyczny
oraz jaka taka znajomość błędu - że nie będzie mnie to kosztowało
istotnej ilości masełka na chlebku. 0,01% średnio przeżyję :)

--
pozdrowienia, Gotfryd
(KPiR, VAT, ZUS)