Machine Learning datatyper.

Kollar man specarna för prestanda hos moderna GPU:er så står det att de skall prestera rätt kasst vid FP64, vilket en modern CPU gör bättre. Däremot så mycket som 40 ggr mer prestanda vid FP32 och FP16. Om man läser det finstilta så skall det vara flera tusen gånger snabbare vid INT8.

Men vilka är egentligen minimum och maximum värden för dessa datatyper?

8 bit –128 till 127

16 bit –32768 till 32767

32 bit –2147483648 till 2147483647

Eller vart det integers för hela slanten?

Ja, det blev int av det där. Floats är kodade på helt annat sätt.
Se tex https://en.wikipedia.org/wiki/Minifloat och https://en.wikipedia.org/wiki/Double...g-point_format

Vad har detta med machine learning att göra??

Datatyper gäller generellt för programmering och har ju ingen direkt koppling till machine learning.

Mycket data -> Många operationer -> TS tänker att 16-bitars flyttalsprecision kommer öka prestandan? Är det verkligen så långsökt (även om trådtiteln kanske inte var så bra formulerad)?

Ja, det kan vara värt att undersöka: https://keras.io/api/mixed_precision/

Men det är inte det första man trixar med precis. Det är nog i ganska få fall en vanlig människa kommer få ut något betydande av att laborera med det där. Försök få till så att beräkningarna sker på GPU:n, då kan du träna stora modeller förvånansvärt snabbt.

Jag anser inte att prestanda nödvändigtvis är det man ska fokusera på när det gäller träning av ml modeller. Då anser jag det viktigare att normalisera data och välja den datatyp som passar bäst med tanke på detta.

Vet ej om det här svaret ger något som TS eftersträvar, men här kommer
några funderingar:
Tycker nog att TS har missuppfattat vad man kan göra med 16-bits floats.
Svaret är helt enkelt: - Inte mycket faktiskt...
Det är en ganska värdelös datatyp, för att inte säga helt värdelös datatyp som man knappt kan använda till något, annat än
enklaste möjliga grafik, typ.
Och då helst bara en operation på varje.
Så fort man använder floatoperations med fler än 3 operatorer så är felet redan så stort att
datatypen inte blir så användbar.
Däremot så i den utmärkta Wikipedia-artikeln ovan så förklaras datatypen utförligt och
den tjänar ju som studieexempel på
en datatyp som följer IEEE 754-standarden.

Och där ligger också dess värde för att förstå IEEE 754 bättre.
Inte ens 32-bits floats har någon större användning, bland annat på grund av att räknefelet pga avrundning mm snabbt blir för stort.

Det fanns någon kalkylatorprogramvara har jag ett svagt minne av som kunde
visa dels decimaltalen i basen 10 med exponent och tecken men sedan
samtidigt också kunde visa deras bitmönster enligt IEEE 754.
Fast då bara för 64 bits floats förstås.
Lärorikt om man satte sig in i det.

Undvik att använda helt oanvändbara datatyper, felen växer snabbt exponentiellt, liksom huvudvärken,
när man ser hur fort räknefelen börjar att hopa sig

Vet ej om detta svar är vad TS önskade sig ?
Och vad slags machine learning TS vill genomföra ?
Kollar man på tex den här länken:
https://en.wikipedia.org/wiki/Machine_learning
Så är computational statistics en metod, men då är 16-bits floats i extrem underkant
för att ens bli användbar

Om det skulle gälla mönsterigenkänning så är det bitmönstret man vill sortera på,
och inte flyttal.

Vid träning av neurala nätverk är 16-bitars flyttal användbara. Finns ju en anledning till att det arbeta på att få in stöd för flera olika nya flyttalstyper i C++. Detta för att underlätta integrationen med t.ex Cuda och OpenCL.

Ja du har klart en poäng med detta, att visst kan de vara användbara för vissa speciella ändamål.
Men om de skulle behövas definieras en egen datatyp det vet jag inte. Tex typen float är ju inte tvunget 32-bit per default. Kör du ngn programvara i C på något gammalt Unix-system så expanderas troligen float till samma som double.

Påminner om införandet av bool.

Många kompilatorer gör detsamma att så snart operatorerna + - / eller * används så expanderas resultatet internt till double eller som i fall Windows att den är 80-bit internt eller hur det nu ligger till.

Självklart har det mesta intresset i frågan handlat om utökad precision för särskilda ändamål,
Särskilt när det gäller till exempel simuleringar med miljontals operationer att man måste hålla nere tex avrundningsfelen mm, som växer fort om precisionen är otillräcklig.
Man har inte sett så mycket vinning med "gles precision" precis:
https://en.wikipedia.org/wiki/Extended_precision

Cuda och OpenCL får samma problem i och med att de flesta kompilatorer antar att det är float eller double som gäller i alla operationer.

Bakåtkompatibiliteten mot C har ju förhindrat C++ för att utöka antalet (elementära, intrinsics) datatyper. Den sista var ju bool, som många kompilatorer tydligen ändå expanderar till en 64-bit unsigned int, om exen kompileras som 64-bit OBJ, EXE, LIB, eller DLL . Men visst finns det en bra poäng ändå, framförallt snabbheten. C och C++ ursprungliga designfilosofi specificerade inte antalet bittar en viss datatyp måste ha. C och C++ porterades både till 16-bit, 32-bit och 64-bit system med gott resultat.

Rent datorfilosofiskt brukar man skilja mellan uppräkningsbara datatyper och icke uppräkningsbara datatyper. Dvs 'A' < 'B' är ett villkor som returnerar en bool som är true.
Alltså så är char en uppräkningsbar datatyp, där villkoren < > kan ge ett resultaten true or false.
Medans en tänkt datatyp som till exempel färg, color, där till exempel 'red' < 'green' inte har någon mening.

Gissar ändå att man blir tvungen att skriva speciell programvara för att använda CUDA och OpenCL (Antar att du även menar OpenGL) fullt ut.
Och därför blir det mycket att lära ut för de studenter och ingenjörer som ska skriva dessa program.
Det är många hänsyn som måste tas om man skulle införa särskilda datatyper, och ger kanske oväntade sidoeffekter som man inte räknat med.

Datatypen float som i dess 32-bits form är ganska oanvändbar just för dess snabba felpropagering efter ett fåtal numeriska operationer pga tex avrundningsfel mm är ju liksom helt obsolet (föråldrad) idag. Den kanske dög för numeriska studentexempel, men knappast för tekniska/vetenskapliga ändamål idag.

Om man tittar bakåt i historien så fanns det säkert kod i gammal C där en char var 6 bitar.
6 bitar kan bara ge upphov till 64 olika tecken, om man väljer att koda tecken med bara 6 bitar.
Ovanligt, men det förekom. Men tecknet var ändå en char, enligt Cs sätt att se
Sedan kom 7-bitars ASCII, som blev basen för nästan alla ordbehandlare på den tiden.
Som sedan kom att överträffas av 8-bit ASCII, den dominerade teckenuppsättningen överallt för webbservrar mm.

Men vill man ha en 16 bit float så måste man vara medveten om att den datatypen är så pass begränsad att det är frågan om den egentligen är så användbar. Flera av värdena i den utgörs av NaN, alltså inte så praktiskt.
Man bör tänka sig noga för, att skapa egna datatyper för speciella ändamål brukar inte vara så lyckat.
Ja man gör det i tex Rymden där man måste spara på varje bit, förstås.
Men för de som skriver de programmen så vet de ju alla begränsningar i ryggmärgen från början.

Risken med en Minifloat är att man skapar stora problem för de programmerare som sedan ska använda den och kompilera skiten.
Vad händer tex vid underflow, overflow, teckenbyte, division med noll mm.
Skall man dessutom samtidigt hålla reda på felet vid varje operation ja då är man snabbt ute
på mycket hal is, och programmet blir extremt arbetsamt att skriva.
Att hålla reda på alla ifs och else och elseifs och varje grens feluppskattning det blir snabbt mycket jobbigt.
Och hu många bittar behövs till exponenten egentligen ?
Ett väl optimerat sådant här system för tex neurala nätverk och AI måste vara riktigt genomtänkt från början.
Så klart att om man bara använder operatorerna >, < , == eller =! så funkar de ju hyfsat

Annars så när ni har lanserat den supersnabba programvaran med den supersmarta FBF FlashBackFloat med 13 vassa bitar, eller bfloat16 så får ni snabbt en massa arga telefonsamtal från utvecklare som har råkat gå bet på denna rejäl mina,
Att deras omsorgsfullt skrivna färdiga programvara bara matar ut "garbage" hela tiden, typ ;(
Tycker knappt dessa speciella datatyper har någon användning än när det verkligen krisar.
Du kan ju knappt använda debuggern för att använda inspect, eftersom den förutsätter att värdet är 32 eller 64 bits idag.

Så var försiktig med vad ni önskar i detta delikata problem.

Ni kanske också måste skriva om varje operatorfunktion för sig för dess udda datatyper,
plus fprintf-directiven, dvs %-expansionen till text.

Finns massvis av gamla projekt där man laborerade med sådant här, och det blev till många dryga arbetstimmar, kanske i onödan, tyvärr...

Lite nostalgi om 16bits float här:
https://en.wikipedia.org/wiki/Bfloat...g-point_format
Ännu mera härlig nostalgi med 6-bits characters:
https://en.wikipedia.org/wiki/Six-bit_character_code

En av de äldsta sätten för teckenkodning är tex Morse-koden.
Morse-koden består av pulskoder, korta och långa om vart annat. Den står sig än idag.
För att tex hoppa långt tillbaka i tiden så, och riktig nostalgi från år 1870-frös-ihjäl:
- Här finns en 5-bits teckenkodning, Baudot code, som användes flitigt hos
telegrafstationer, att skicka telegram med:
https://en.wikipedia.org/wiki/Baudot_code
Den medgav alltså bara 2^5 = 32 tecken.
I ett telegram så skrevs punkten inte ut, utan ordet STOP skrevs istället.
Baudot code, ITA1, uppfanns av Émile Baudot i Frankrike.

Baudot fick ge namnet till enheten Baud, bits per sekund.

Minifloats kan visst vara användbara, men man inför samtidigt så
mycket begränsningar att det blir trubbel på andra plan.

Till exempel finns det programvara idag som körs med long double, dvs 128 bits precision,
det ger helt andra möjligheter att köra längre beräkningsserier och ändå
hålla nere avrundningsproblemen/trunkeringsproblemen.

Även om du skriver operatorkoden för alla de vanliga operatorerna för Minifloats,
så i varje sådan operation expanderas den normalt till 64bit, i en 64-bit EXE, OBJ, LIB elr DLL, och sedan trunkeras tillbaka till Minifloats. I regel så fungerar sådan överlagring alltid så på det viset.
Men trunkeringen kan ge oväntade sidoeffekter sedan.
Att precisionsförlusten blir för stor, och resultatet blir oanvändbart.