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.

  • 4600 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'

( 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 ]