datatype forvirring

Jeg vil gætte på den laver om til hex også tilbage til decimal. Men kan du ikke bare konfigurere den til kun at vise 1 cifer efter kommma?

jo... men det gør det jo ikke rigtigt... Det kan da ikke passe at man skal smide alt væk efter kommaet... "tænkt situation" hvis så nogle gerne vil gemme 134,4525626 som så sikker bliver til 124,4525626003543 Hvad gør man så...

Jeg vil gerne ha en løsning på hvordan man hiver tekst ud, konverterer til decimal tal i koden, og gemmer som samme tal.

Og det kan godt lade sig gøre... Ellers havde de ikke turde udgive c#... ;-)

float har kun 6-7 cifres præcision.

Altså er svaret sådan set rigtigt.

Og det er noget som alle sprog har fordi det er sådan floating
point tal fungerer.

Derfor:
  - prøv double fordi ganske vist har den præcis samme problem men den
    har dobbelt så mange cifres præcision
  - når du udskriver så udskriv formateret med nogle færre cifre
  - hvis det er beløb vi snakker om så glem alt om float & double

Jeg har vel heller ikke bruget mere end et par cifres præcision ved at skrive 15,6... eller har jeg misforstået noget helt.. :-)

Jeg kan sagtens nøjes med at "klippe" resten af... Men det irriterer mig at den ikke kan gemme det ordentligt, og at jeg ikke ved hvorfor..
Men det kan sagtens ha noget med præcisionen af db'ens float og c#'s float - Er ikke sikkert de er helt ens (og .net's Single for den sags skyld)

Det må jeg lige undersøge en anden dag... Har lidt travlt idag...

-> Arne : Hvad mener du med glem float og double ved beløb... Hvad skal jeg så gøre? Kræve to decimaler og gemme som int? og så bare sætte komma selv eller hvad?

6 cifres præcision betyder at 15,6 gemmes som et tal mellem
15,5999 og 15,6001 - og det du har er jo i det interval.

Både databasen og C#/.NET bruger uden tvivl også IEEE single precision FP
(som er det der er implementeret af Intel i processoren).

Ja. Integer med embedded decimal point (svarer til at regne i ører).
C#/.net har en data type for det, hvis jeg husker rigtigt.

Er databasens datatype også en float?

Decimal mener jeg den hedder.

Kært barn har jo mange navne.

Ja - den hedder vist også System.Decimal

Det vigtige er at det er en fixed point og ikke en floating point.

Der er både en der hedder float og en der hedder decimal. Begge steder.
Men det vil sige at min eneste option er at afrunde når jeg skal vise det.

Men jeg forstår ikke helt logikken i det med præcisionen lige nu... Hvis jeg gemmer et tal som 15,6 (et helt godt eksempel ik.. hehe), så er der da ingen grund til at begynde at afrunde og gøre det lidt skævt..

Men det er nok noget jeg skal læse om en anden gang.. .

Du skriver at det er en fixed point... Når jeg nu bruger float datatypen begge steder.. Lyder det da ikke som fixed.. men mere som float.. ;-)

Men det kan selvfølgelig være min Convert.ToSingle("15,6") der er fixed point.. Det må jeg lige tjekke..

Indtil videre tak for hjælpen og opklaringen..

Ja 15.6 er float og det er problemet.

Husk computeren kører binært. Ikke i 10 tals systemet men i 2 tals
systemet.

15,6 er ikke 1*10+5*1+6*0.1 men 1*8+1*4+1*2+1*1+1*0.5+....

Decinal er fixed point og vil ikke have det problem.

Inde i mit hoved har jeg svært ved at forestille mig at der overhovedet skulle være en forskel, hvor man bruger den samme datatype både i databasen OG i applikationen.
Hvis du kan se en forskel på 0,0000003814697, så er det du gemmer vel heller ikke en float i databasen?

Problemet er at visse tal (faktisk flertallet af tal) ikke kan
repræsenteres eksakt som floating point.

Så 15,6000003814697 er formentlig den tætteste repræsentation af 15,6
(20,5 kan repræsenteres eksakt da det er 16+4+1/2).

Det er helt naturligt.

Hvis der er en fejl, så er det den udskrivning der forsøger at udskrive en
float med så mange cifre - det giver ingen mening.

Ahaa... Nu forstår jeg lidt bedre...

Det giver faktisk god mening.. Du er god til at forklare.. :-)

Jeg takker for hjælpen... Smid et svar arne.. Så får du lidt p til kontoen... ;-)

Det er i det mindste ikke den metode hvor præcisionen falder eksponentielt med afstanden fra 0, som OpenGL verdenen må finde sig i :-)

svar

Den relative præcision er konstant ved floatinpoint men den absolutte
præcsion vokser jo længer eman kommer fra nul.

cool... Jeg lever med det... ;-) Og rykker alt efter 2. decimal af... måske 1.. hehe