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

[swkevin08]

as the others have said, it has something to do with the approach.
but look at this. maybe it will help you!

ps: doenst work for all numbers! for example x,42300000000000000001

Edit: e was randomly generated

Code:

const
  e = 0.0000000001;

function CountDigitsAfterPoint(AValue: Extended): Byte;
var r: Extended;
begin
  Result := 0;
  r := Int(AValue);
  while ((Frac(AValue) <> 0) and ((AValue - r) > e)) do
  begin
    Inc(Result);
    AValue := AValue * 10;
    r := Int(AValue+e);
  end;
end;

[WojTec]

Thanks, for all values I used early, is working correctly.
BTW: why e has that value, can have other values?

[swkevin08]

e is just a small number close to zero. it doesn't matter if there's one zero more or one less.

[Sir Rufo]

Zitat:

Zitat von WojTec (Beitrag 1248005)

Thanks, for all values I used early, is working correctly.
BTW: why e has that value, can have other values?

Have a look at the documentation System.Math.SameValue and System.Math.CompareValue and read what is the meaning of Epsilon.

Another helpful article is http://en.wikipedia.org/wiki/Machine_epsilon

[Furtbichler]

Zitat:

Zitat von WojTec (Beitrag 1247995)

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. :)

The reason is always important, especially when people don't seem to exactly know what they are talking about.

Showing the number of decimals is definitely not something to please the eye. It is showing the accuracy of your value, so a value of, say, 100 (metres) measured up to a mm is correctly shown as "100,000 m" whereas the same value with an accuracy of 1m is shown as "100m".