Haaste: Koodaa pyöristysalgoritmi

[Jamac]

Niin koodaappa desimaaliluvun pyöristysalgoritmi jollain "geneerisellä tavalla", eli että sen voi toteuttaa millä tahansa haluamallaan ohjelmointikielellä.

Algoritmi ottaa vastaan desimaaliluvun jossa on [0…n] -desimaalia (okei, ei tarvi hyväksyä ääretöntä määrää desimaaleja, mutta koodi ei saa jumiutua yllätyksiin) ja lopullisen halutun desimaalien määrän. Jos haluat hifistellä, niin voit koodata niin että voi pyöristää luvun myös isompaan kuin desimaaliin, eli ykkösiin, kymmeniin… satoihin… jne. (ehkä siten että haluttujen desimaaalien määrän olisi negatiivinen).

Vinkki: tietääkseni tämä ei onnistu valmiilla funktioilla.

Esimerkkiluku kahteen [2] desimaaliin: 0,344444445 => 0,35

[arisel]

Esimerkkiluku kahteen [2] desimaaliin: 0,344444445 => 0,35

Täh?

Siis tuo virhe on se ongelma, johon haet ratkaisua?

[Jamac]

Niin, siis tietokoneet vaikuttavat pyöristävän tuon aina 0,34 mikä on väärin ja se aiheuttaa esimerkiksi kirjanpidossa yhden sentin "katoamisia" kun lasketaan vaikka arvonlisäveroa.

Ei mun "otanta" tosin ole mitenkään laaja , mutta muistelen Exelin ja Open Officen laskevan tuon väärin ja ainakin PHP-scriptauskielen nettipuolella kärsivän tuosta. Itse olen sen verran kykenemätön että ratkaisin ongelman aikoinaan muuttamalla koko desimaalin merkkijonoksi ja tutkimalla "vitosen" esiintymistä desimaaliosassa. Todella kankeaa jne. mutta toimii. (Mutta kaatuu vähän isommilla luvuilla.)

Kuriositeettina muuten Applen manio laskin, nimeltä "Laskin" tai "Calculator", osaa laskea desimaalien pyöristykset oikein.

[Jamac]

Kuvailen ongelmaa vielä:

Nämä kummatkin tietokone pyöristää oikein:
0,344 = 0,34
0,345 = 0,35

Tämän taas väärin:
0,3445 = 0,35 (tietokone luulee: 0,34)

Tämän kuitenkin oikein:
0,3455 = 0,35

[arisel]

Mulle on opetettu toisenlaista matematiikkaa...

Kun desimaaliluku katkaistaan, niin viimeinen mukaan tuleva numero korotetaan yhdellä, jos ensimmäinen pois jäävä numero on 5, 6, 7, 8 tai 9.

Arvonlisäverosäännöt tietenkin vaativat oman laskentatapansa, ja taulukkolaskentaohjelmat tuntuvat olevan tällaisissa kysymyksissä kertakaikkisen avuttomia; joskus rakentelin kaavoja näihin pyöristyksiin, mutta koodata en osaa.

[arisel]

Nuo senttipyöristykset ovat kylllä hankalia, esimerkiksi verkkopankin laskelmissa korkolukemat heittelevät edestakaisin, vaikka korko ei muutukaan välillä.

[Jamac]

Ongelma siis syntyy rahoja (esim laskutus) laskettaessa siitä, että hatusta vedettynä noin 99% laskun summista pyöristyy oikein (lasku menee tyyliin 0,284€ x 12668 kpl + 24% alv), mutta se 1 % pyöristyy laskutusohjelmassa desimaalien tapauksesta riippuen väärin. Jos rakennetaan siis vaikka laskutusohjelmaa, niin syntyy satunnaisesti esiintyvä yhden sentin "pyöristysvirhe", jota selitellään sitten… "pyöristysvirheenä".

0,345 = 0,35 (oikein)
0,3445 = 0,34 (väärin)

[pallo]

Ei välituloksia ainakaan normilaskennassa pyöristellä kahteen desimaaliin, jos lopputulokselta sitä vaaditaan - tulema on juuri tuo.

0,34445 pyöristetään lopputuloksena ihan 100-varmaan 0,34.

[Jamac]

Nuo senttipyöristykset ovat kylllä hankalia, esimerkiksi verkkopankin laskelmissa korkolukemat heittelevät edestakaisin, vaikka korko ei muutukaan välillä.

Kyllä kyllä, ja se ongelma liittyy juuri siihen, että ohjelmointikielien pyöristysalgoritmit tutkivat lukua vasemmalta oikealle vain yhden desimaalin enemmän kuin mitä desimaaleja halutaan. Jotta tuota pyöristysongelmaa ei tulisi, pitäisi lukua tutkia desimaalien loppuun asti, ja aloittaa desimaalin pyöristäminen oikealta vasemmalle haluttuun desimaaliin asti. Vain näin sentit täsmäävät vaikka kirjanpidossa. Ongelmaksi tulee äkkiä esimerkiksi päättymättömät desimaalit ja niiden tutkiminen mumeerisesti. Ityse en osannut tosiaan tuota tehdä, ja muutin luvun merkkijonoksi jota tutkin muutamalla silmukalla tms.

[Jamac]

Ei välituloksia ainakaan normilaskennassa pyöristellä kahteen desimaaliin, jos lopputulokselta sitä vaaditaan - tulema on juuri tuo.

0,34445 pyöristetään lopputuloksena ihan 100-varmaan 0,34.

Kyllä, tietokoneet tekee noin ja tulos on väärä. Usko minua. Olen koodannut myyntireskontran PHP:llä ja OSISSA laskuja en saanut summia sentilleen oikein ennen kuin koodaasin oman (kömpelön) pyöristysalgoritmin.

Kun sentti uupuu, niin kokeile laskea Applen Laskimella (Calculator) sama lasku ja se laskee luvut sentilleen oikein, se osaa pyöristää luvut kuten edellä kuvailin.

[hesebe]

Ei välituloksia ainakaan normilaskennassa pyöristellä kahteen desimaaliin, jos lopputulokselta sitä vaaditaan - tulema on juuri tuo.

0,34445 pyöristetään lopputuloksena ihan 100-varmaan 0,34.

Kyllä, tietokoneet tekee noin ja tulos on väärä. Usko minua. Olen koodannut myyntireskontran PHP:llä ja OSISSA laskuja en saanut summia sentilleen oikein ennen kuin koodaasin oman (kömpelön) pyöristysalgoritmin.

Kun sentti uupuu, niin kokeile laskea Applen Laskimella (Calculator) sama lasku ja se laskee luvut sentilleen oikein, se osaa pyöristää luvut kuten edellä kuvailin.

Pyöritysvirhe:

0.3445 => 0.34, virheen itseisarvo 0.0045
0.3445 => 0.35, virheen itseisarvo 0.0055

Ylemmässä pienempi pyöristysvirhe!

[pallo]

En tiä mut mää tarkotin, et jos vaikka:

0,22222+0,22222=0,44444≈0,44

ja

0,44444+0,44444=0,88888≈0,89

niin ei voi oikeaan lopputulokseen tulla seuraavalla välituloksen "pyöristyksellä":

0,44+0,44=0,88.

Voin olla ihan pihallakin. Eli pitäis käyttää referenssinä alkuperäistä laskua/kaavaa/tms. eikä sitä pyöristettyä välitulosta.

[Jamac]

Pyöritysvirhe:

0.3445 => 0.34, virheen itseisarvo 0.0045
0.3445 => 0.35, virheen itseisarvo 0.0055

Ylemmässä pienempi pyöristysvirhe!

Okei, HYVÄ (…jos oikein ymmärsin), mutta käytäntö on toinen! Kun pyöristetään alemmalla tavalla, esimerkiksi laskutusohjelmatyyppisessä sovelluksessa, laskelmat menevät joka kerta sentilleen oikein! Ylemmässä pyöristysvirheen ollessa pienempi, aiheuttaa se kuitenkin (laskuohjelmissa) näennäisesti satunnaisilla summilla loppusummaan pyöristysvirheen joka onyksiselitteisesti väärin ilman tulkinnan mahdollisuutta.

Koodailin (olikohan jotain 2006) pitkät päivät laskutusohjelman laskurivien summausta, luulin että ongelma on siinä että pyöristää välisummia väärissä kohdissa jne. ja silloin sainkin ongelman katoamaan esimerkkilaskussa, mutta vain siihen asti kun sama pyöristysvirhe pomppasikin esiin muualla missä sitä ei aikaisemmin ollut. Olin tulla sekopääksi tuon asian kanssa ja googlailin ja testailin eri ohjlemia ja matematiikkakirjastoja mitä osaisin.

Ainut ratkaisu oli että koodasin oman luokan mikä pyöristää Elon laskuopin mukaan siten kun joskus ala-asteella on matematiikan tunnilla opetettu. Ja sen jälkeen ei ole ollut ensimmäistäkään sentin väärinpyöristymistä.

[Jamac]

En tiä mut mää tarkotin, et jos vaikka:

0,22222+0,22222=0,44444≈0,44

ja

0,44444+0,44444=0,88888≈0,89

niin ei voi oikeaan lopputulokseen tulla seuraavalla välituloksen "pyöristyksellä":

0,44+0,44=0,88.

Voin olla ihan pihallakin. Eli pitäis käyttää referenssinä alkuperäistä laskua/kaavaa/tms. eikä sitä pyöristettyä välitulosta.

Tuon tietokoneet (yleistän tietokoneet, vaikka kyse on tietysti ohjelmointikielien ongelmasta), pyöristävätkin oikein joka kerta. Vasta desimaaliosassa ensimmäinen nelonen minkä perääsä on vitonen aiheuttaa pyöristymisen katkeamisen väärin, koska se nelosen prässä oleva vitonen nostaa nelosen vitoseksi joka sitten edelleen nostaa joissain tapauksessa sitä lopullista viimeistä desimaalia. Ongelma tulee melko harvoin, mutta se tulee vääjäämättä silloin tällöin.

[Jamac]

(Itseasiassa tänään on perjantai, mulla on useampi tölkki olutta, niin voisin koodata softaani kokeeksi pikku palikan mikä laskis kaikkien tietokannassa olevien laskujen kohdalta milloin mun pyöristysalgoritmi iskee kiinni ja siitä laskea keskimäärin prosenttiluvun miten usein laskussa tuo pyöristysvirhe tulee ilman asianmukaista laskemista. Hmmm... ooolutta… 8) )

[amanita]

Kohta saatte lukea pyöristämätöntä rairairaata...luulen ma.

Joo, män ohi aiheen.

[jra72]

Eikös javan BigDecimal osaa tuon out of the box?

[thoug]

Siis wut, kuinka monta kertaa te oikein pyöristätte?
Jos luku on 0,3444445 ja se pitää pyöristää kahteen desimaaliin niin ainoastaan kolmas desimaali on merkitsevä pyöristyksessä. Eli tässä tapauksessa tuo alleviivattu. Sen ollessa 4 joka pyöristyy alaspäin jää toinen desimaali myös neloseksi = 0,34. Vain tilanteessa, jossa pyöristetään 6 desimaalin tarkkuudella, katsotaan mitä 7 desimaali on ja pyöristetään sen mukaan ylöspäin = 0,344445

[Jamac]

Siis wut, kuinka monta kertaa te oikein pyöristätte?
Jos luku on 0,3444445 ja se pitää pyöristää kahteen desimaaliin niin ainoastaan kolmas desimaali on merkitsevä pyöristyksessä.

V Ä Ä R I N

Peruste: Aiheuttaa käytännön sovelluksessa (laskutus/reskontra) näennäisen satunnaisesti yhden desimaalin pyöristysvirheen loppusummaan.

Tuolla sinun mainitsemalla tavalla loppusumma tulee miltei joka kerta oikein, mutta aina joskus näkymättömissä ohjelman muuttujissa tapahtuva yhteenlasku (tms.) aiheuttaa lopputulokseen pyöristyksen heittämisen yleensä yhdellä sadasosalla (jos nyt puhutaan tästä rahasuminen kahdesta desimaalista).

[thoug]

Siis wut, kuinka monta kertaa te oikein pyöristätte?
Jos luku on 0,3444445 ja se pitää pyöristää kahteen desimaaliin niin ainoastaan kolmas desimaali on merkitsevä pyöristyksessä.

V Ä Ä R I N

Peruste: Aiheuttaa käytännön sovelluksessa (laskutus/reskontra) näennäisen satunnaisesti yhden desimaalin pyöristysvirheen loppusummaan.

Tuolla sinun mainitsemalla tavalla loppusumma tulee miltei joka kerta oikein, mutta aina joskus näkymättömissä ohjelman muuttujissa tapahtuva yhteenlasku (tms.) aiheuttaa lopputulokseen pyöristyksen heittämisen yleensä yhdellä sadasosalla (jos nyt puhutaan tästä rahasuminen kahdesta desimaalista).

Jos oletetaan että kyse on ALVista niin toinen puoli on luultavasti jokin kokonaisluku esim 1,00 joten nettoarvoksi jäisi 0,655555
Jos tuo pyöristetään sääntöjen mukaan siitä tulee 0,66 ja täsmää siis tuon aiemman pyöristyksen mukaan. Sinun pyöristys arvon mukaan tulee se 0,01 ero.

[Jamac]

Hmm.. siis onko nyt niin että tässä mun esittämän ongelman ytimen hahmottamisessa on jokin ongelma?

Tiedän täsmälleen mistä esiintuomani väärinpyöristys johtuu – se johtuu yksiselitteisesti ohjelmointikielien virheellisestä pyöristysalgoritmista – ja olen itse jo ohjelmoinut sellaisen oikein toimivan pyöristysalgoritmin mikä pyöristää siten miten minulle on ala-asteella opetettu.

Tässä vaan ajattelin että jos jollain olisi elegantti ratkaisu tähän ongelmaan – omani kun on kaukana elegantista…

[atheos]

0,344444445 pyöristettynä kahteen desimaaliin on oikeaoppisen ala-asteen laskuopin mukaan 0,34. Jos ymmärsin oikein niin haluaisit siis rikkoa matematiikan pyöristyssääntöjä helpottaaksesi kirjanpitoasi? Sori. Kyllä niitä senttejä kaikki muutkin kirjaavat pois, olkoonkin kuinka ärsyttävää tahansa.

Ei riitä? No entäs valtion kanta asiaan? Verohallinto kertoo asian näin (kohta 6.1.10, Suoritettavan veron määrä):

Veron määrä ilmoitetaan kahden desimaalin tarkkuudella. Matemaattisen pyöristyssäännön mukaan, kun desimaaliluku katkaistaan, niin viimeinen mukaan tuleva numero korotetaan yhdellä, jos ensimmäinen pois jäävä numero on 5 tai sitä suurempi numero. Pyöristys tehdään laskun loppusumman osalta.

Esimerkkiluvussa ensimmäinen pois jäävä numero eli kolmas desimaali on arvoltaan 4. Edeltävää lukua 4 ei siis matemaattisen säännön mukaan pyöristetä ylöspäin vaan se jää arvoon 4.

[pallo]

^Thank you for ending this madness.

[Jamac]

Laskussahan ongelma esiintyy niin, että laskulle pitää kirjoittaa laskurivien yhteensä sarakkeen summa kahdella desimaalilla. Tämä on ns. veroton nettohinta. Tässä vaiheessa on siis pakko pyöristää kahteen desimaaliin

100,4445
100,0115
------------
200,46

Ylläoleva on allekkain laskettuna yksiselitteisesti oikein, eikö?

Tulostetaanpa tämä SAMA siihen oieaan laskuun tietokoneen tavalla kahdella desimaalilla

100,44
100,01
------------
200,45


Tsädäm. Meiltä katosi jonnekin sentti. Sitten "sattumasta" riippuen laskettaessa tuosta arvonlisäveroa nettosumman päälle saadaan taas jokin pitkähkö tai vähemmän pitkähkö desimaaliluku joka sekin voi pyöristyä sen sentin väärin. Ihan näennäisestä säkästä riippuen voi käydä niin, että nettosumma on alapyöristynyt ja verosumma ok – tai toisinpäin. Tai sitten kumpikin alaspyöristyy, jolloin loppusummassa on kahden sadasosan heitto. Siinä kun summia tarkistelee taskulaskimella, milloin nettosummien kautta ja milloin veron kautta, niin meinaa oikeasti pää hajota kun vaikuttaa että summat on täysin satunaisesti vero- tai nettosumman mukaan joko sentin tai kaksi pielessä, tai sitten täysin oikein sekä veto- että nettosumman puolesta.

JOS tietokoneet laskisi pyöristyksen oikein tavalla kuten olen esittänyt, niin kaikki laskut täsmäävät aina.

[Jamac]

0,344444445 pyöristettynä kahteen desimaaliin on oikeaoppisen ala-asteen laskuopin mukaan 0,34. Jos ymmärsin oikein niin haluaisit siis rikkoa matematiikan pyöristyssääntöjä helpottaaksesi kirjanpitoasi? Sori. Kyllä niitä senttejä kaikki muutkin kirjaavat pois, olkoonkin kuinka ärsyttävää tahansa.

Ei riitä? No entäs valtion kanta asiaan? Verohallinto kertoo asian näin (kohta 6.1.10, Suoritettavan veron määrä):

Veron määrä ilmoitetaan kahden desimaalin tarkkuudella. Matemaattisen pyöristyssäännön mukaan, kun desimaaliluku katkaistaan, niin viimeinen mukaan tuleva numero korotetaan yhdellä, jos ensimmäinen pois jäävä numero on 5 tai sitä suurempi numero. Pyöristys tehdään laskun loppusumman osalta.

Esimerkkiluvussa ensimmäinen pois jäävä numero eli kolmas desimaali on arvoltaan 4. Edeltävää lukua 4 ei siis matemaattisen säännön mukaan pyöristetä ylöspäin vaan se jää arvoon 4.

EI varmasti pyöristetä, ja tämä ihan aikuisten oikeasti näkyy kirjanpidoissa satunnaisesti puuttuvina sentteinä. Katso yo. lasku joka on rautalankaesimerkki ko. ongelmasta.