Kerekítés

Algoritmusok

Sziasztok.

Adott néhány ezer tizedes tört. Kerekíteni szeretném őket oly módon, hogy ez legyen a követendő példa az 5-re végződőeknél:

0.5 --> 0
1.5 --> 2
2.5 --> 2
3.5 --> 4
4.5 --> 4
5.5 --> 6

és ne ez:

0.5 --> 1
1.5 --> 2
2.5 --> 3
3.5 --> 4
4.5 --> 5
5.5 --> 6

Kérésem az, hogy míg utóbbinál, a felfelé kerekítés elve megy, az első verziónál valóban egyenlő valószínűséggel tudom felfelé és lefelé kerekíteni a számokat? Cél az, hogy a kerekített számok összegzésekor minél közelebbi érték legyen az eredetihez.

Másképp megfogalmazva:

a számhalmazból random módon kiválasztok 5000-et, majd kerekítés nélkül összeadom, ez legyen A.

Ezután a kerekített értékeket is összeadom, ez legyen B.

A és B különbségének abszolút értéke legyen minél közelebb a nullához, ez lenne a cél. Kérdés: Melyik kerekítés a hatásosabb, a felfelé kerekítés, vagy a másik?

Megjegyzés:
A nem 5-re végződő számok esetében a felfelé- és lefelé kerekítés hagyományos módszerei volnának.

  • 4595 megtekintés

( kisbetu v | 2016. 04. 16., szo – 14:29 )

"egyenlő valószínűséggel tudom felfelé és lefelé kerekíteni a számokat"
A kérdést sem értem.

Pontosbítsunk:
0 -> nem kell kerekíteni
1,2,3,4 -> lefelé kerekítünk, mert az van közelebb
5 -> gondolkodóba esünk, mert pont középen van
6,7,8,9 -> felfelé kerekítünk, mert az van közelebb

az 5 dilemmájára valóban az a szokásos eljárás, hogy párosra kerekítünk: [5.5,6.5]->6, (6.5,7.5)->7
(a szögletes zárójel zárt, a kerek nyílt intervallumot jelent)

Szerk: óvatosságból a 'szokásos eljárás' kifejezést cseréljük le arra, hogy 'egyik elterjedt eljárás' vagy arra, hogy 'ésszerűnek tűnő eljárás'

Nem látszik bonyolultnak... Nyilván csak az .5 re végződő számok az érdekesek, azokból is egy elég szűk intervallum elég lehet, pl -2.5,-1.5,..,+2.5,+3.5 


Kerekítetlen összeg:               3.5
"Mindig le" kerekítés után összeg: 0
"Mindig fel":                      7
"Párosra" kerekítés után összeg:   5
"Páratlanra":                      2

A hibát oszthatjuk a darabszámmal, a lényegen nem változtat: a "párosra" és a "páratlanra" algoritmus pontosabb eredményt ad, mint a "mindig le" és a "mindig fel".

( imp | 2016. 04. 16., szo – 18:51 )

Ha a normal kerekitest hasznalod, akkor a kerekitett elemek osszegenek varhato erteke megegyezik a nem kerekitett elemek osszegevel.
A masodik kerekitesnel:
tegyuk fel, hogy egy elem p esellyel vegzodik 5-re. Ezeket fele-fele aranyban jol, illetve lefele kerekited, tehat az osszeg varhato erteke 0.5 * p * x -el kevesebb lesz, ahol x az elemek szama. Ha a szamok eloszlasa uniform, es csak egy tizedesjegyed van, akkor p = 0.1, ket tizedesjegynel p = 0.01, stb.

Tehat ha |A-B| minimalizalasa a cel, akkor az eredeti kerekitest hasznald.

Szerk: a varhato ertek egy kicsit nagyobb az eredeti kerekitessel, ezt ellensulyozza a masodik kerekites.

A szisztematikus hibát valóban csökkenti imp javaslata. De a véletlenből adódó elmozdulását az átlagnak nem.

Ha olyan szabály szerint kerekítesz, ami nem veszi figyelembe a többi számot, akkor mindenképpen lesz egy véletlenszerű faktorod, ami egy véletlenszerű bolyongást fog jelenteni az összegben. Tehát az eredeti összegtől egyre nagyobb szórással kerülsz egyre messzebb.

Egy megoldás lehet, ha a kerekítések során számolod, hogy eddig mennyit "csalt el" a kerekítés, és annak megfelelően korrigálod a kerekítés szabályait. Vagy akár csak mindig hozzáadod a hibát a következő számhoz.
Ha pontosan számolod, akkor pontosan ugyanaz marad az összeg.

Egy kicsit "igazságosabb" megoldás, ha úgy lövöd be a kerekítés határát, hogy pont ugyanaz legyen az összeg. Ennek viszont "kicsit" költségesebb az algoritmusa.

( rpsoft v | 2016. 04. 17., v – 00:43 )

C-ben a rint(), lrint(), nearbyint() nem ezt csinálja megfelelő fesetround() beállítás esetén?

( falu v | 2016. 04. 17., v – 07:34 )

Páros felé kerekítesz. Csak nem földmérő vagy? (A két távcsőállásban mért szögek középértékét a páros szám felé kerekítettük, mert állítólag könnyebb volt vele számolni a függvénytáblázat meg tekerős számológép idejében)

[ Falu.me ]