Excel ja desimaalit

Aivan, niin käsitinkin.

Lisätäänpä vielä:

"Mistä excel saa nuo loppuosan desimaalit."

Silloin kun ruksi on laitettu, ja normaalista laskentatarkkuudesta on luovuttu, tapahtuu kahden desimaalin luvulle sellaista, että tämän kahden desimaalin jälkeen tulevat numerot muutetaan nolliksi. Eli ei exceli saa niitä desimaaleja mistään, vaan ne on aina mukana, vaikka laskisit kahdendesimaalin tarkkuudella.

Anonyymi kirjoitti:

Lisätäänpä vielä:

"Mistä excel saa nuo loppuosan desimaalit."

Silloin kun ruksi on laitettu, ja normaalista laskentatarkkuudesta on luovuttu, tapahtuu kahden desimaalin luvulle sellaista, että tämän kahden desimaalin jälkeen tulevat numerot muutetaan nolliksi. Eli ei exceli saa niitä desimaaleja mistään, vaan ne on aina mukana, vaikka laskisit kahdendesimaalin tarkkuudella.

Lue lisää

Lisätäänpä vielä:

Tämä vaihe jossa siirrytään muunneltuun laskentatarkkuuteen, vaihtelee eri taulukkolaskentaohjelmien välillä. Exceli lisää nollat, toisilla tapahtuu luvun pyöristämisiä.

Anonyymi kirjoitti:

Lisätäänpä vielä:

Tämä vaihe jossa siirrytään muunneltuun laskentatarkkuuteen, vaihtelee eri taulukkolaskentaohjelmien välillä. Exceli lisää nollat, toisilla tapahtuu luvun pyöristämisiä.

Lue lisää

Lisätäänpä vielä:

Korjaus, laskentatarkkuus oli 15 numeroa, eikä 16 kuten yllä tulin maininneeksi.

Anonyymi kirjoitti:

Lisätäänpä vielä:

Korjaus, laskentatarkkuus oli 15 numeroa, eikä 16 kuten yllä tulin maininneeksi.

Kiitos vastauksista. En kuitenkaan ihan ymmärrä miksi kahden luvun, jotka on tallennettu kahdella desimaalilla, vähentäminen keskenään aiheuttaa tulokseen outoja loppudesimaaleja,
Yritin myös etsiä asiasta aikaisempaa keskustelua, en löytänyt sitäkään, minulla taitaa siis olla ymmärryksessä ja osaamisessa puutteita.

Anonyymi kirjoitti:

Kiitos vastauksista. En kuitenkaan ihan ymmärrä miksi kahden luvun, jotka on tallennettu kahdella desimaalilla, vähentäminen keskenään aiheuttaa tulokseen outoja loppudesimaaleja,
Yritin myös etsiä asiasta aikaisempaa keskustelua, en löytänyt sitäkään, minulla taitaa siis olla ymmärryksessä ja osaamisessa puutteita.

Lue lisää

Oletusarvoisesti, solun sisältämä luku tallennetaan AINA 15 numeron tarkkuudella. Samalla tallennetaan myös tieto kuinka olet halunnut solussa olevan tiedon näytettävän.

Jos laskentatarkkuutta ei ole muutettu:
A1 => 1 => 1.000 000 000 000 00
B1 => 3 => 3.000 000 000 000 00
C1 => A1 / B1 => 0,333 333 333 333 33
Mutta se näytetään sinulle 0,33

Laskennassa kuitenkin käytetään lukua 0,333 333 333 333 33

Anonyymi kirjoitti:

Oletusarvoisesti, solun sisältämä luku tallennetaan AINA 15 numeron tarkkuudella. Samalla tallennetaan myös tieto kuinka olet halunnut solussa olevan tiedon näytettävän.

Jos laskentatarkkuutta ei ole muutettu:
A1 => 1 => 1.000 000 000 000 00
B1 => 3 => 3.000 000 000 000 00
C1 => A1 / B1 => 0,333 333 333 333 33
Mutta se näytetään sinulle 0,33

Laskennassa kuitenkin käytetään lukua 0,333 333 333 333 33

Lue lisää

Lisätäänpä vielä:

Jos nyt laitat D1 => 3,33 tallentuu soluun luku:

0,330 000 000 000 00

tätä D1 ja edellisen C1 vertailtaessa, IF() funktiolla, on tulos epätosi.

C1 => 0,333 333 333 333 33
D1 => 0,330 000 000 000 00

Vaikka sinulle näytetään kahdendesimaalin tarkkuudella molemmissa soluissa olevan saman luvun:

0,33

Anonyymi kirjoitti:

Oletusarvoisesti, solun sisältämä luku tallennetaan AINA 15 numeron tarkkuudella. Samalla tallennetaan myös tieto kuinka olet halunnut solussa olevan tiedon näytettävän.

Jos laskentatarkkuutta ei ole muutettu:
A1 => 1 => 1.000 000 000 000 00
B1 => 3 => 3.000 000 000 000 00
C1 => A1 / B1 => 0,333 333 333 333 33
Mutta se näytetään sinulle 0,33

Laskennassa kuitenkin käytetään lukua 0,333 333 333 333 33

Lue lisää

"Oletusarvoisesti, solun sisältämä luku tallennetaan AINA 15 numeron tarkkuudella."

Ei todellakaan tallenneta"oletusarvoisesti" eikä "AINA" 15 numeron tarkkuudella. Todellisuudessa ei koskaan, ei ikinä.

Anonyymi kirjoitti:

"Oletusarvoisesti, solun sisältämä luku tallennetaan AINA 15 numeron tarkkuudella."

Ei todellakaan tallenneta"oletusarvoisesti" eikä "AINA" 15 numeron tarkkuudella. Todellisuudessa ei koskaan, ei ikinä.

Lue lisää

TROLLI, olisit jättänyt sotkematta asiallista ketjua.

Anonyymi kirjoitti:

"Oletusarvoisesti, solun sisältämä luku tallennetaan AINA 15 numeron tarkkuudella."

Ei todellakaan tallenneta"oletusarvoisesti" eikä "AINA" 15 numeron tarkkuudella. Todellisuudessa ei koskaan, ei ikinä.

Lue lisää

Excel käyttää liukulukujen tallentamisessa IEEE 754 -standardin kuvaamaa "decimal64" tallennusmuotoa, liukuluku koodataan 64 kpl binääriseen bittiin siten että matissassa on 16 kpl kymmenjärjestelmän digittejä ja exponentin desimaalinen lukuarvo voi olla korkeintaan 384.

Anonyymi kirjoitti:

Excel käyttää liukulukujen tallentamisessa IEEE 754 -standardin kuvaamaa "decimal64" tallennusmuotoa, liukuluku koodataan 64 kpl binääriseen bittiin siten että matissassa on 16 kpl kymmenjärjestelmän digittejä ja exponentin desimaalinen lukuarvo voi olla korkeintaan 384.

Lue lisää

"siten että matissassa on 16 kpl"

Nykäsen Matistako sinä puhut?

Mitä nuo "digittejä" sitten, Brikettejä myydään, 10 kg erissä.

Anonyymi kirjoitti:

Excel käyttää liukulukujen tallentamisessa IEEE 754 -standardin kuvaamaa "decimal64" tallennusmuotoa, liukuluku koodataan 64 kpl binääriseen bittiin siten että matissassa on 16 kpl kymmenjärjestelmän digittejä ja exponentin desimaalinen lukuarvo voi olla korkeintaan 384.

Lue lisää

"desimaalinen lukuarvo voi olla korkeintaan 384"

Mitäs se tuo olevinaan tarkoittaa, olisko ollut tarkoitus kirjoittaa "desimaalinen likiarvo voi olla korkeintaan 384"

Muutenkin nuo juttusi on kuin M-Karin sössötystä aikoinaan.

Anonyymi kirjoitti:

"siten että matissassa on 16 kpl"

Nykäsen Matistako sinä puhut?

Mitä nuo "digittejä" sitten, Brikettejä myydään, 10 kg erissä.

Excel tallentaa liukuluvut niin että mantissassa on 16 kpl kymmenjärjestelmän digittiä ja exponentti koodataan niin että sen kymmenjärjestelmän mukainen arvo voi olla enintään 384. Excel käyttää tähän koodaukseen 64 bittiä, IEEE 754 -standardin "decimal64" koodauksen mukaisesti.

Tuo tallennuskoodaus aiheuttaa osan "virheistä", koska mm päättymättömiä desimaaleja ei ole mahdollista tallentaa tarkasti käyttäen likulukukoodausta.

Enemmän "virheitä" aiheutuu siitä että laskentaa varten nuo tallennetut liukuluvut muutetaan binäärijärjestelmään, koska nykytietokoneet eivät suorita laskutoimituksia kymmenjärjestelmässä.

Tallennetun liukuluvun muunnos binääriksi yleensä aiheuttaa sen että näppäimistöltä syötetty arvo ja sellaisen formulan tulos jonka pitäisi olla yhtä suuri kuin em näppäimistöltä syötetty arvo ovatkin vertailtaessa erisuuria. Esimerkiksi liukuluku 0,1 on binäärimuodosssa päättymätön jono ykkösiä ja nollia.

Kyseessä ei ole Excelin virhe, eikä virhe lainkaan, vaan ominaisuus. Liukulukujen kanssa ei ole mahdollista, ainakaan toistaiseksi, laskea tietokoneella eksaktisti.

Jokin ohjelmat käyttävät enemmmän muistia liukulukujen tallentamiseen, esim saman IEEE 754 -standardin "decimal 128" koodausta, jossa mantissassa on 34 kpl kymmenjärjestelmän digittiä ja exponentti koodataan niin että sen kymmenjärjestelmän mukainen arvo voi olla enintään 6144. Tämä koodaus siis kuluttaa kaksinkertaisen bittimäärän verrattuna "decimal64" koodaukseen, ja tietenkin aiheuttaa laskennan hidastumista.

Anonyymi kirjoitti:

Excel tallentaa liukuluvut niin että mantissassa on 16 kpl kymmenjärjestelmän digittiä ja exponentti koodataan niin että sen kymmenjärjestelmän mukainen arvo voi olla enintään 384. Excel käyttää tähän koodaukseen 64 bittiä, IEEE 754 -standardin "decimal64" koodauksen mukaisesti.

Tuo tallennuskoodaus aiheuttaa osan "virheistä", koska mm päättymättömiä desimaaleja ei ole mahdollista tallentaa tarkasti käyttäen likulukukoodausta.

Enemmän "virheitä" aiheutuu siitä että laskentaa varten nuo tallennetut liukuluvut muutetaan binäärijärjestelmään, koska nykytietokoneet eivät suorita laskutoimituksia kymmenjärjestelmässä.

Tallennetun liukuluvun muunnos binääriksi yleensä aiheuttaa sen että näppäimistöltä syötetty arvo ja sellaisen formulan tulos jonka pitäisi olla yhtä suuri kuin em näppäimistöltä syötetty arvo ovatkin vertailtaessa erisuuria. Esimerkiksi liukuluku 0,1 on binäärimuodosssa päättymätön jono ykkösiä ja nollia.

Kyseessä ei ole Excelin virhe, eikä virhe lainkaan, vaan ominaisuus. Liukulukujen kanssa ei ole mahdollista, ainakaan toistaiseksi, laskea tietokoneella eksaktisti.

Jokin ohjelmat käyttävät enemmmän muistia liukulukujen tallentamiseen, esim saman IEEE 754 -standardin "decimal 128" koodausta, jossa mantissassa on 34 kpl kymmenjärjestelmän digittiä ja exponentti koodataan niin että sen kymmenjärjestelmän mukainen arvo voi olla enintään 6144. Tämä koodaus siis kuluttaa kaksinkertaisen bittimäärän verrattuna "decimal64" koodaukseen, ja tietenkin aiheuttaa laskennan hidastumista.

Lue lisää

Unohdin mainita että riippumatta siitä mitä tahansa koodausta liukululujen tallentamiseen mikäkin ohjelma käyttääkin, niin näiltä "virheitä" ei voi välttyä kun lasketaan binäärisillä tietokoneilla.

Mitä suurempi muistimäärä (bittimäärä, tavumäärä) käytetään liukuluvun tallennukseen/koodaukseen niin sitä pienempiä "virheiden" absoluttiset lukuarvot ovat, mutta eivät koskaan mene nollaksi. "Virheiden" ilmaantuvuus tosin myös hieman vähenee, mutta ei sekään koskaan mene nollaksi.

Esimerkiksi MatLab tallentaa liukulukuja kymmenjärjestelmän 16 digitin tarkkuudella. Ja sen huomaa varsin kivuliaasti kun malli on vähänkään vaativampi kuin yksinkertaista nelilaskentaa. MatLab:iin on saatavissa lisuke jonka avulla voi käyttää paljonkin rajumpia laskentatarkkuuksia, silloin varsin kepeähkön mallin laskenta kestää päiviä tai viikkoja, masiinan tuuulettimien käydessä kokoajan täysillä. Vastaavahko, mutta paljon rajoittuneempi ja tyrmäävästi hitaampi lisuke oli aikoinaan saatavilla myös Excelille, ensin DLL, sitten VBA, nimeltään xnumbers, en nyt löytänyt sitä.

Anonyymi kirjoitti:

Unohdin mainita että riippumatta siitä mitä tahansa koodausta liukululujen tallentamiseen mikäkin ohjelma käyttääkin, niin näiltä "virheitä" ei voi välttyä kun lasketaan binäärisillä tietokoneilla.

Mitä suurempi muistimäärä (bittimäärä, tavumäärä) käytetään liukuluvun tallennukseen/koodaukseen niin sitä pienempiä "virheiden" absoluttiset lukuarvot ovat, mutta eivät koskaan mene nollaksi. "Virheiden" ilmaantuvuus tosin myös hieman vähenee, mutta ei sekään koskaan mene nollaksi.

Esimerkiksi MatLab tallentaa liukulukuja kymmenjärjestelmän 16 digitin tarkkuudella. Ja sen huomaa varsin kivuliaasti kun malli on vähänkään vaativampi kuin yksinkertaista nelilaskentaa. MatLab:iin on saatavissa lisuke jonka avulla voi käyttää paljonkin rajumpia laskentatarkkuuksia, silloin varsin kepeähkön mallin laskenta kestää päiviä tai viikkoja, masiinan tuuulettimien käydessä kokoajan täysillä. Vastaavahko, mutta paljon rajoittuneempi ja tyrmäävästi hitaampi lisuke oli aikoinaan saatavilla myös Excelille, ensin DLL, sitten VBA, nimeltään xnumbers, en nyt löytänyt sitä.

Lue lisää

LOPETA TUO SÖNKKÄÄMINEN
Et edes käytä oikeita termejä tuossa tarinassasi jota et muutenkaan ymmärrä.

Esimerkkinä vaikka tuo "digittiä" jota käytetään digitaalisten mittarien tarkkuusominaisuuksista puhuttaessa, koska digitaalisen mittarin näyttö ei aina sisällä numeroita ilmaisemaan mitattua suuretta.

Mutta takaisin siihen Excelin laskentatarkkuuteen.
Excelissä laskentatarkkuus tarkoittaa sitä, että mikä tahansa luku, jossa on enemmän kuin 15 numeroa, tallennetaan ja näytetään vain 15 numeron tarkkuudella. Kyseiset numerot voivat olla desimaalipilkun kummalla puolella tahansa. 15:nnen numeron oikealla puolella olevat numerot ovat nollia. Esimerkiksi luvussa 1234567,890123456 on 16 numeroa (7 numeroa ennen desimaalipilkkua ja 9 sen jälkeen). Excelissä se tallentuu ja näkyy muodossa 1234567,89012345 (tämä näkyy kaavarivillä ja solussa). Jos määrität solun lukumuotoilun siten, että kaikki numerot näkyvät (sen sijaan että käyttäisit tieteellistä muotoa kuten 1,23457E 06), huomaat, että luku näkyy muodossa 1234567,890123450. Lopussa oleva 6 (16:s numero) poistetaan ja korvataan 0:lla. Laskentatarkkuus loppuu 15 numeron kohdalla, joten kaikki seuraavat numerot ovat nollia.

Asia on juuri niin kuin minä jo aiemmin kerroin.

Anonyymi kirjoitti:

LOPETA TUO SÖNKKÄÄMINEN
Et edes käytä oikeita termejä tuossa tarinassasi jota et muutenkaan ymmärrä.

Esimerkkinä vaikka tuo "digittiä" jota käytetään digitaalisten mittarien tarkkuusominaisuuksista puhuttaessa, koska digitaalisen mittarin näyttö ei aina sisällä numeroita ilmaisemaan mitattua suuretta.

Mutta takaisin siihen Excelin laskentatarkkuuteen.
Excelissä laskentatarkkuus tarkoittaa sitä, että mikä tahansa luku, jossa on enemmän kuin 15 numeroa, tallennetaan ja näytetään vain 15 numeron tarkkuudella. Kyseiset numerot voivat olla desimaalipilkun kummalla puolella tahansa. 15:nnen numeron oikealla puolella olevat numerot ovat nollia. Esimerkiksi luvussa 1234567,890123456 on 16 numeroa (7 numeroa ennen desimaalipilkkua ja 9 sen jälkeen). Excelissä se tallentuu ja näkyy muodossa 1234567,89012345 (tämä näkyy kaavarivillä ja solussa). Jos määrität solun lukumuotoilun siten, että kaikki numerot näkyvät (sen sijaan että käyttäisit tieteellistä muotoa kuten 1,23457E 06), huomaat, että luku näkyy muodossa 1234567,890123450. Lopussa oleva 6 (16:s numero) poistetaan ja korvataan 0:lla. Laskentatarkkuus loppuu 15 numeron kohdalla, joten kaikki seuraavat numerot ovat nollia.

Asia on juuri niin kuin minä jo aiemmin kerroin.

Lue lisää

Lisätäänpä vielä:

Tuo edellinen oli suora lainaus Microsoftin omasta "Lisätietoja Excelin laskentatarkkuudesta" dokumentista.

Ja noiden digitaalisen mittareiden "digitti" käsitteeseen, voit syventyä vaikka tuolla:
https://www.fluke.com/fi-fi/lue-lisaa/blogi/digitaaliset-yleismittarit/tarkkuus-tasmallisyys

"Numero" ei ole sama kuin "digitti", älä sotke asioita.

Anonyymi kirjoitti:

Lisätäänpä vielä:

Tuo edellinen oli suora lainaus Microsoftin omasta "Lisätietoja Excelin laskentatarkkuudesta" dokumentista.

Ja noiden digitaalisen mittareiden "digitti" käsitteeseen, voit syventyä vaikka tuolla:
https://www.fluke.com/fi-fi/lue-lisaa/blogi/digitaaliset-yleismittarit/tarkkuus-tasmallisyys

"Numero" ei ole sama kuin "digitti", älä sotke asioita.

Lue lisää

Excel tallentaa liukuluvut (tiettyjä erikoistapauksia lukuunottamatta IEEE 754 -standardissa kuvatun (ns double-precision) "decimal64" koodauksen mukaisesti, jossa mantissassa on 16 kpl kymmenjärjestelmän digittiä ja exponentti koodataan niin että sen kymmenjärjestelmän mukainen arvo voi olla enintään 384. Excel käyttää tähän koodaukseen 64 bittiä,

Excel esittää vain 15 kymmenjärjestelmän digittiä koska se 16. digitti on erittäin ussein virheellinen.

https://docs.microsoft.com/en-us/office/troubleshoot/excel/floating-point-arithmetic-inaccurate-result

Anonyymi kirjoitti:

Excel tallentaa liukuluvut (tiettyjä erikoistapauksia lukuunottamatta IEEE 754 -standardissa kuvatun (ns double-precision) "decimal64" koodauksen mukaisesti, jossa mantissassa on 16 kpl kymmenjärjestelmän digittiä ja exponentti koodataan niin että sen kymmenjärjestelmän mukainen arvo voi olla enintään 384. Excel käyttää tähän koodaukseen 64 bittiä,

Excel esittää vain 15 kymmenjärjestelmän digittiä koska se 16. digitti on erittäin ussein virheellinen.

https://docs.microsoft.com/en-us/office/troubleshoot/excel/floating-point-arithmetic-inaccurate-result

Lue lisää

TROLLI

Tilanteissa joissa hakukohde tai hakuperuste on laskennan tulos täytyy käyttää pyöristystä, riippumatta ohjelmasta ja riippumatta raudasta. Excelissä käsitääkseni pyöristäminen 12 desimaaliin riittää siivoamaan nuo liukulukulaskennasta väistämättömästi syntyvät poikkeavuudet.

Etenkään kellonaikaa tai ajankohtaa ei kannata pyöristää niin karheaksi kuin kahteen desimaaliin, koska Excelissä yksi vuorokausi on desimaalisena lukuarvo 1. Josta seuraa että desimaalinen lukuarvo 0,01 vastaa 14,4 minuuttia ̶ joka on pienin aikaväli (gap) jonka kahteen desimaaliin pyöristetyillä kellonajoilla tai ajankohdilla voi esittää.

Toisinaan näitä poikkeavuuksilta voi välttyä Exelissä laskemalla tarkasti sekalumuodossa, mutta ollenkaan aina laskennan tulos ei mahdu Excelin tukemiin sekalukumuotoihin jolloin Excel kääntää tuloksen liukuluvuksi. Yksinkertainen esimerkki:

Excelissä soluun näppäimistöltä kirjoitetttu (tai alta kopioitu ja pastettu) sekalukuja käyttävä yhtälö:

=1/3 1/3 1/3-1

tuottaa aina tuloksen == 0.

Mutta soluun näppäimistöltä kirjoitetttu (tai alta kopioitu) liukulukuja käyttävä vastaava kaava:

=0.333333333333333 0.333333333333333 0.333333333333333-1

tuottaa nollasta eroavan tuloksen jonka pitäisi päässälaskun perustella olla -1,000000000000000E-15 mutta ei aivan tarkasti ole (arvo hieman riippuu Excelin versioista ja CPU/ALU valmistajasta ja versiosta).

Anonyymi kirjoitti:

Tilanteissa joissa hakukohde tai hakuperuste on laskennan tulos täytyy käyttää pyöristystä, riippumatta ohjelmasta ja riippumatta raudasta. Excelissä käsitääkseni pyöristäminen 12 desimaaliin riittää siivoamaan nuo liukulukulaskennasta väistämättömästi syntyvät poikkeavuudet.

Etenkään kellonaikaa tai ajankohtaa ei kannata pyöristää niin karheaksi kuin kahteen desimaaliin, koska Excelissä yksi vuorokausi on desimaalisena lukuarvo 1. Josta seuraa että desimaalinen lukuarvo 0,01 vastaa 14,4 minuuttia ̶ joka on pienin aikaväli (gap) jonka kahteen desimaaliin pyöristetyillä kellonajoilla tai ajankohdilla voi esittää.

Toisinaan näitä poikkeavuuksilta voi välttyä Exelissä laskemalla tarkasti sekalumuodossa, mutta ollenkaan aina laskennan tulos ei mahdu Excelin tukemiin sekalukumuotoihin jolloin Excel kääntää tuloksen liukuluvuksi. Yksinkertainen esimerkki:

Excelissä soluun näppäimistöltä kirjoitetttu (tai alta kopioitu ja pastettu) sekalukuja käyttävä yhtälö:

=1/3 1/3 1/3-1

tuottaa aina tuloksen == 0.

Mutta soluun näppäimistöltä kirjoitetttu (tai alta kopioitu) liukulukuja käyttävä vastaava kaava:

=0.333333333333333 0.333333333333333 0.333333333333333-1

tuottaa nollasta eroavan tuloksen jonka pitäisi päässälaskun perustella olla -1,000000000000000E-15 mutta ei aivan tarkasti ole (arvo hieman riippuu Excelin versioista ja CPU/ALU valmistajasta ja versiosta).

Lue lisää

(arvo hieman riippuu Excelin versioista ja CPU/ALU valmistajasta ja versiosta)

Jaksollinen desimaaliluku on desimaaliluku, jonka desimaaleissa toistuu jokin numero tai numerosarja äärettömän monta kertaa peräkkäin.

Excelin versio tai CPU/ALU ei näihin vaikuta mitenkään, vain laskennan tuloksen desimaaleja on vähemmän kun laskentatarkkuutta vähennetään.

1/3 = tulos on päättymätön.

Anonyymi kirjoitti:

(arvo hieman riippuu Excelin versioista ja CPU/ALU valmistajasta ja versiosta)

Jaksollinen desimaaliluku on desimaaliluku, jonka desimaaleissa toistuu jokin numero tai numerosarja äärettömän monta kertaa peräkkäin.

Excelin versio tai CPU/ALU ei näihin vaikuta mitenkään, vain laskennan tuloksen desimaaleja on vähemmän kun laskentatarkkuutta vähennetään.

1/3 = tulos on päättymätön.

Lue lisää

"Jaksollinen desimaaliluku on desimaaliluku, jonka desimaaleissa toistuu jokin numero tai numerosarja äärettömän monta kertaa peräkkäin."

Suurkiitos, tuo oli minulla täysin uusi tieto.

"Excelin versio tai CPU/ALU ei näihin vaikuta mitenkään, vain laskennan tuloksen desimaaleja on vähemmän kun laskentatarkkuutta vähennetään"

Kummatikin vaikuttavat. ALU:issa aina toisiaan parannetaan sitä miten ne optimoivat laskennan. Niissä on myös toisiaan bugeja, ainakin yksi bugi on ihan julkisesti tiedossa (se "korjattiin" softakilkkellä). Myös Excelissä on versioiden saatossa paranneltu laskenta-algoritmeja, ne eivät käsittele kaavaa aina siinä järjestyksessä kuin se soluun on kirjoitettu vaan pyrkivät supistamaan kaavan siten että nämä kyseessä olevat poikkeamat pienenevät ja tai vähenevät.

"1/3 = tulos on päättymätön."

Suurkiitos, tuo oli minulla täysin uusi tieto.