Count digits after point

[WojTec]

I need to know how many digits has float number after point.

Delphi-Quellcode:

function CountDigitsAfterPoint(AValue: Extended): Byte;
begin
  Result := 0;

  while (Frac(AValue) <> 0) do
  begin
    Inc(Result);
    AValue := AValue * 10;
  end;
end;

Working good in most cases, but not for all :o

Incorect results for sample data:
2.048 --> 19
8.448 --> 19
565.148 --> 17
32.064 --> 18
274.176 --> 17
97.728 --> 17
155.52 --> 17
622.08 --> 17

:shock:

Please help :(

[Aphton]

That is because there are some inaccuracy regarding non-integer numbers.
0.99999999999999999999.... is equal to 1!
(or your example: 2.048 could internally be 2.04799999999999999...)
Therefore your method needs to take that into account.
But sadly I have no idea since my knowledge about precision is not good. Someone else might be of help!

Edit: Another problem that came to mind is irrational numbers. I thought Id mention it but it shouldnt be too problematic since the data-type cuts off after a certain degree of precision..

[DelphiProgrammer]

Hi,
maybe that'll help:

Code:

decimalplaces := (length(floattostr(number)) - pos(',',floattostr(number))-1);

[Aphton]

@DelphiProgrammer:
Nope!

Delphi-Quellcode:

var
  x: Single;

begin
  x := 2.048;
  writeln(x);
  writeln((length(floattostr(x)) - pos('.',floattostr(x))-1));
  readln;
end.

Output

Code:

 2.04800009727478E+0000
15

[WojTec]

I thought about strings too, but (1) it's lame and (2) see @Aphton's post.

There is no math solution? :(

[Aphton]

This might be a problem that can be solved in another way.
You want to find out the number of fraction-digits.
Why?
Maybe the root problem you are trying to solve can be solved in another way! Maybe you dont even need to find out the digitcount!

[mkinzler]

Why you need the number of digits? perhaps there is a better way to achieve your aim.

[Aphton]

@mkinzler: xDD

[WojTec]

So, reason is not important. Important is problem.
But if you want to know: (1) result is required for further computation purposes and (2) for formating. :)

[mkinzler]

For (1) because the system iminent computation error the consumption more digits are better doesn't seem right to me.
For (2) I'd prefer to restrict the digits to dispay to a fixed count