Alv:it integereinä

[SHT]

https://yle.fi/a/74-20084164

[MooM]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

[ID10T]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Onhan esim. tuloverokin ilmoitettu desimaalilukuna iät ja ajat. Tuossa alvissa voi toki olla takana ajatus järjestelmän suorituskyvyn optimoinnista. Ehkä lähimaksutapahtumassa kokonaisluku siirtyy bittiavaruudessa liukulukua nopeammin?

[MooM]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Onhan esim. tuloverokin ilmoitettu desimaalilukuna iät ja ajat. Tuossa alvissa voi toki olla takana ajatus järjestelmän suorituskyvyn optimoinnista. Ehkä lähimaksutapahtumassa kokonaisluku siirtyy bittiavaruudessa liukulukua nopeammin?

Itse ajattelin ensin, että kyse on ikivanhoista systeemeistä ja muuttujan viemän muistin optimoinnista. Mutta tuossa jutussa puhutaan vain siitä, että liukulukuihin liittyvien pyöristysepätarkkuuksien vuoksi integerejä on suosittu rahaan liittyvissä softissa

[SHT]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Luultavasti integeriä käytetään siksi, että tuoteita voidaan tuoda ja viedä exceliin. Excel saattaa muuttaa desimaaliluvun 25.5 päivämääräksi 25 Toukokuuta (tässä on nyt senverran aikaa siitä, kun olen ohjelmoinut, jotta en muista milloin tämä tapahtuu)
https://o-e-tuki.paytrail.com/hc/fi/art ... cel-tuonti
Lisäksi desimaalilukujen käytössä on ongelmia siinä, onko desimaalierotin piste vai pilkku.

[ID10T]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Onhan esim. tuloverokin ilmoitettu desimaalilukuna iät ja ajat. Tuossa alvissa voi toki olla takana ajatus järjestelmän suorituskyvyn optimoinnista. Ehkä lähimaksutapahtumassa kokonaisluku siirtyy bittiavaruudessa liukulukua nopeammin?

Itse ajattelin ensin, että kyse on ikivanhoista systeemeistä ja muuttujan viemän muistin optimoinnista. Mutta tuossa jutussa puhutaan vain siitä, että liukulukuihin liittyvien pyöristysepätarkkuuksien vuoksi integerejä on suosittu rahaan liittyvissä softissa

Verohallintoa tuo pyöristysepätarkkuus ei kuitenkaan haittaa tuloveron osalta?

[Lyde19]

Ohjelmoija on mokannut jos on vallinnut kokonaisluvun prosentin esittämiseen. Mutta ei kuulosta isolta ongelmalta.

[MooM]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Luultavasti integeriä käytetään siksi, että tuoteita voidaan tuoda ja viedä exceliin. Excel saattaa muuttaa desimaaliluvun 25.5 päivämääräksi 25 Toukokuuta (tässä on nyt senverran aikaa siitä, kun olen ohjelmoinut, jotta en muista milloin tämä tapahtuu)
https://o-e-tuki.paytrail.com/hc/fi/art ... cel-tuonti
Lisäksi desimaalilukujen käytössä on ongelmia siinä, onko desimaalierotin piste vai pilkku.

Jos puhutaan kaupallisista tuotteista, mitään copypastausta exceliin ei pitäisi olla mukana. Exceliä voi kyllä lukea ja kirjoittaa ihan alemmallakin tasolla ja määritellä itse, mitä tyyppiä soluihin kirjoitetaan.

[MooM]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Onhan esim. tuloverokin ilmoitettu desimaalilukuna iät ja ajat. Tuossa alvissa voi toki olla takana ajatus järjestelmän suorituskyvyn optimoinnista. Ehkä lähimaksutapahtumassa kokonaisluku siirtyy bittiavaruudessa liukulukua nopeammin?

Itse ajattelin ensin, että kyse on ikivanhoista systeemeistä ja muuttujan viemän muistin optimoinnista. Mutta tuossa jutussa puhutaan vain siitä, että liukulukuihin liittyvien pyöristysepätarkkuuksien vuoksi integerejä on suosittu rahaan liittyvissä softissa

Verohallintoa tuo pyöristysepätarkkuus ei kuitenkaan haittaa tuloveron osalta?

No eipä sille vaihtoehtojakaan ole. Käytännössä nuo ovat merkityksettömiä.

[KultaKikkare]

Fixed point on hyvä valuuttalaskuissa. Eli käytännössä säilötään Alv vaikka promillen kymmenesosina ja rahasummat sentteinä, lasketaan ja siirretään pilkkua oikeaan paikkaan.

[SHT]

Vaikka kuinka liukuluvut olisivat epätarkempia, lukutyypin valinta on käsittämätön tuollaiselle parametrille, joka aivan hyvin voi olla muutakin kuin integer.

Onhan esim. tuloverokin ilmoitettu desimaalilukuna iät ja ajat. Tuossa alvissa voi toki olla takana ajatus järjestelmän suorituskyvyn optimoinnista. Ehkä lähimaksutapahtumassa kokonaisluku siirtyy bittiavaruudessa liukulukua nopeammin?

Minä muistan ajan, jolloin tulot piti pyöristää kokonaisluvuksi paperisessa veroilmoituksessa.

[SHT]

Fixed point on hyvä valuuttalaskuissa. Eli käytännössä säilötään Alv vaikka promillen kymmenesosina ja rahasummat sentteinä, lasketaan ja siirretään pilkkua oikeaan paikkaan.

Siinä voi tulla ongelmia, jos MaxInt ylitetään.

[KultaKikkare]

Fixed point on hyvä valuuttalaskuissa. Eli käytännössä säilötään Alv vaikka promillen kymmenesosina ja rahasummat sentteinä, lasketaan ja siirretään pilkkua oikeaan paikkaan.

Siinä voi tulla ongelmia, jos MaxInt ylitetään.

Se on totta, jos ei 64bittiä riitä niin sit 128bittinen BigInt. Jos sekään ei riitä niin sit kaksi sellasta ja vähän lisäkoodia väliin.

Mut moderneissa kielissä on sopivat tietotyypit valmiina, c# decimal, Java BigDecimal, jne... Ja kaikille yleisille kielille löytyy sopivia kirjastoja valmiina.

[Kohina]

Tosimiehet koodaa assemblyllä

[KultaKikkare]

Tosimiehet koodaa assemblyllä

Sit kannattaa varata tietty määrä bittejä desimaaleille niin voi bit shiftillä konvertoida fixed point aritmetiikasta esitettäviksi desimaaliluvuiksi.

Tolleen tehtiin kaikki matikka silloin kun kaikissa prosareissa ei vielä ollu hw tukea flotari laskuille. 386:ssa oli vielä erillinen matikkaprosessori.