Float - Hur många decimaler ska jag använda? 6, 7, 8 eller 9?

Jag tror inte ANSI C specificerar något särskilt format för flyttal, men i praktiken är det nog IEEE 754-formatet som används. Med det antagandet så blir det en jäkla massa decimaler då en single precision floating point kan representera talet 2^(-126) genom att sätta samtliga bitar i exponenten till 0 och sedan sätta mantissan till 1. Det exakta talet är 1.1754944e-38, så 45 decimaler bara där. Om jag inte räknat fel. Jag kan mycket väl ha räknat fel, det gjorde jag nämligen på försök nummer 1

Med det sagt, vad är det du försöker göra? Varför behöver du veta antalet decimaler för att skriva ett flyttal till fil?

Floating point betyder just att det inte finns ett fixt antal decimaler, utan det varierar med storleken på talet som ska representeras

Om det blir tokigt eller inte beror ju helt på vad för data du ska spara....
Min favoritfråga, vilket problem försöker du lösa?
Och nej, problemet är inte "spara float värden i en fil"

Tror du frågar: hur många signifikanta siffror kan C float/double representera.

Svaret är lite lurigt,

32-bit float kan minst hålla 6 signifikanta siffror men det är nästan alltid minst 7 och kan vara upp till 9 för specifika tal.
64-bit float kan minst hålla 15 signifikanta siffror men det är nästan alltid minst 16 och kan vara upp till 21 för specifika tal.

Verkar handlar om 32-bit float här, så 6, 7 eller 9 beroende på vad du vill uppnå

Det är inte antalet decimaler som spelar roll, utan antal signifikanta siffror.
Som ett experiment, testkör följande lilla program, och fundera över hur relevant antalet decimaler är.

#include <stdio.h>

int main(void)
{
	float x = 0.000000123;

	printf("%.7f\n", x);
	printf("%.7e\n", x);

}

Nu beskrev du ju fortfarande inte problemet. Det är en ganska stor skillnad på om din data är temperatur ( då har du antagligen tillräckligt stor precision) eller om du ska spara värde av dina bitcoin i hela bitcoin (då kanske du vill ha ännu högre precision)
Återigen, beskriv ditt problem inte din lösning!

du frågar efter enkel svar på något som kan vara väldigt komplext...

Det bero på vad du skall göra och det fins många fällor här som vid iterativa processer (som ränta på ränta och annuitetslån) där bristvärdiga antal värdesiffror kan göra att resultatet kan bli från flertal procent fel i slutändan till helt absurda värden - eller ännu värre i andra sammanhang i formelkedja som ger kaotisk beteende i iterativa dynamiska system (tänk fraktaler, mandebrot-figurer, fjärils-effekten där en fjärilsvingslag i Asien kan starta en tornado i USA några veckor senare då det var inom meteorologin man börja hitta dessa egenheter) där även en ändrad värde även 100 decimaler bort kan ge helt annan slutresultat.

också att tänka på om det är beräkningar som i sig har värden 1.0000023 som multipliceras upprepande någonstans i räkningskedjan.

Det fins anledning varför HP 12C är en standardräknare inom finansvärldens utbildningskurser då den tar hänsyn till sådant i sina beräkningsalgoritmer för tex. annuitetslån då de vidmakthåller antalet värdesiffror i sina beräkningar med olika trix - medans tar man formella formlerna för dessa operationer rakt av och stoppar in dessa som en programsnurra i en programmerbar miniräknare för tex. annuitetslån på många år så kan det bli många % fel i slutet just för att man tappar värdesiffror i beräkningssnurran och som de publika formlerna för operationerna inte tar hänsyn till och förutsätter att det är oändlig antal värdesiffror (eller hanterar som exakta kvoter) i beräkningarna. Att komma runt sådana saker kan vara rätt trixigt...

Du får kanske titta i någon lärobok om just numeriska beräkningar då mycket av hanteringen består av att förstå var felen kan uppträda och begränsa verkan av tex. avrundningsfel och helst gör att de tar ut varandra varannan gång i iterativa förlopp eller hantera värden väldigt nära 1 och att det inte ger exponentiell tillväxt av fel i någon riktning efter ett antal iterationer när man har värden med begränsad antal värdesiffror.

Dessutom ger räkning med basen 10 (BCD-räkning ala miniräknare och tidiga stordatorer) och beräkning baserat på basen 2 olika fel i olika scenarion - tex. kan inte 0.1 representeras exakt vid beräkning med basen 2 men kan hanteras exakt när det beräknas med basen 10 och motsvarande fall finns med exakta värden på basen 2 inte kan beskrivas exakt med basen 10 när man har begränsad antal värdesiffror, och värden av tex. 1/3 kan inte beskrivas exakt av någondera mer än att de uttrycks som en kvot - dvs. 1/3 i hela beräkningsskedjan utan att 'översättas' till någon annan talbas under beräkningen.

tex miniräknaren HP42S har decimal talbas i sina beräkningar - och dess motsvarighet för mobiler och laptop i form av free42 så kan man välja om den skall ha BCD (talbas 10) som beräkningsmaskin eller att det baseras standardlibbar i CPU som arbetar med basen 2.