Om man läser om vad som skrivs om ämnet så har nog TS missuppfattat vad dessa forskare skriver.
I själva verket handlar det om att ibland undvika floats helt och hållet, således så skrivs en hel del problem om så att man bara använder integers eftersom integer-aritmetik är mycket snabbare än motsvarande floats.
Eller så kan man använda speciella datatyper med fixerad decimalpunkt.
Eller till exempel BCD, Binary Coded Decimal, som tar 4 bitar för varje siffra 0-9, en omsorgsfullt designad sådan kod kan räkna exakt rätt i större delen av fallen, och i en mindre del ge rätt så små räknefel.
Tror faktiskt att Excel använer den datatypen.
Ett annat angreppssätt är att räkna om datasettet till att bli ett linjärt problem istället. Alla flyttal logaritmerades istället, och då blir det huvudsakligen addition och subtraktion som blir de flesta numeriska operationerna. Alltså mycket snabbare.
Fast då fick man hitta på något sätt att beteckna noll, 0, eftersom logaritmen för noll är -oändlighten.
Redan hos 1950-talets tidiga datapionjärer så sysslade man med detta för att förenkla beräkningarna.
Mycket riktigt så hittar man flera ställen där de refererar till att den förlust av precision som sker med att bara deklarera 16-bits floats att den kan komma att bita dig rejält i röven i slutändan ändå.
Ytterligare ett annat angreppssätt är att utöka precisionen till 128-bit, dvs long double, och räkna om allting och jämföra med resultatet vid 64-bit, och man kan där uppskatta hur stort beräkningsfelet blir.
Området är mycket bredare än att bara handla om 16-bits Minifloats.
En annan möjlighet är att använda i princip oändlig precision och det finns en hel del C++ libs som förmår räkna numeriska tal med en hög förinställd precision
Men tex i grafikberäkningar där man ska vrida perspektivet eller objekt i det tänkta 3D-rummet genom att göra koordinattransformeringar med tex matrisoperationer så räcker det inte alltid
ens med 32-bit floats.
Sedan så finns det sådana problem där man kan använda bitoperationerna & | osv för att göra jämförelser, dessa är förstås snabba som blixten.
Artiklarna som tar upp problemet förbiser problemen med många operationer efter varandra.
Det är viktigt att läsa vad de påstår, de påstår inte att 16-bits floats skulle vara användbara överallt.
Snarare tvärtom.
Dessa problem förstås bättre av dem som sysslat med till exempel numerisk analys och linjära/icke-linjära ekvationssystem som löses på dator.
Och inte sådana som enbart har IT-utbildning.
C++ har en klass BIGNUM som kan räkna med godtycklig precision och kan dessutom räkna rätt, och med korrekt avrundning.
Det finns andra rätt så udda knep, till exempel om man har talbasen 36, där tecknena 0-9, A-Z representeras talen 0-36, och man kunnat ur dessa konstruera andra slags floats som inte representeras av IEEE 754.
Sedan kan man rentav designa datatyper som kan representera bråktal exakt.
Alltså rationella tal
I själva verket handlar det om att ibland undvika floats helt och hållet, således så skrivs en hel del problem om så att man bara använder integers eftersom integer-aritmetik är mycket snabbare än motsvarande floats.
Eller så kan man använda speciella datatyper med fixerad decimalpunkt.
Eller till exempel BCD, Binary Coded Decimal, som tar 4 bitar för varje siffra 0-9, en omsorgsfullt designad sådan kod kan räkna exakt rätt i större delen av fallen, och i en mindre del ge rätt så små räknefel.
Tror faktiskt att Excel använer den datatypen.
Ett annat angreppssätt är att räkna om datasettet till att bli ett linjärt problem istället. Alla flyttal logaritmerades istället, och då blir det huvudsakligen addition och subtraktion som blir de flesta numeriska operationerna. Alltså mycket snabbare.
Fast då fick man hitta på något sätt att beteckna noll, 0, eftersom logaritmen för noll är -oändlighten.
Redan hos 1950-talets tidiga datapionjärer så sysslade man med detta för att förenkla beräkningarna.
Mycket riktigt så hittar man flera ställen där de refererar till att den förlust av precision som sker med att bara deklarera 16-bits floats att den kan komma att bita dig rejält i röven i slutändan ändå.
Ytterligare ett annat angreppssätt är att utöka precisionen till 128-bit, dvs long double, och räkna om allting och jämföra med resultatet vid 64-bit, och man kan där uppskatta hur stort beräkningsfelet blir.
Området är mycket bredare än att bara handla om 16-bits Minifloats.
En annan möjlighet är att använda i princip oändlig precision och det finns en hel del C++ libs som förmår räkna numeriska tal med en hög förinställd precision
Men tex i grafikberäkningar där man ska vrida perspektivet eller objekt i det tänkta 3D-rummet genom att göra koordinattransformeringar med tex matrisoperationer så räcker det inte alltid
ens med 32-bit floats.
Sedan så finns det sådana problem där man kan använda bitoperationerna & | osv för att göra jämförelser, dessa är förstås snabba som blixten.
Artiklarna som tar upp problemet förbiser problemen med många operationer efter varandra.
Det är viktigt att läsa vad de påstår, de påstår inte att 16-bits floats skulle vara användbara överallt.
Snarare tvärtom.
Dessa problem förstås bättre av dem som sysslat med till exempel numerisk analys och linjära/icke-linjära ekvationssystem som löses på dator.
Och inte sådana som enbart har IT-utbildning.
C++ har en klass BIGNUM som kan räkna med godtycklig precision och kan dessutom räkna rätt, och med korrekt avrundning.
Det finns andra rätt så udda knep, till exempel om man har talbasen 36, där tecknena 0-9, A-Z representeras talen 0-36, och man kunnat ur dessa konstruera andra slags floats som inte representeras av IEEE 754.
Sedan kan man rentav designa datatyper som kan representera bråktal exakt.
Alltså rationella tal