To roundup, rounddown number

[asdf]

In calculator (1000000-1)  / 1826 = 547.64
In MS Excel  round((1000000-1) / 1826 , 4) = 547.6446
                  round((1000000-1) / 1826 , 2) = 547.64
But my code StringGrid1.Cells[x,x]:=CurrToStrF(.....,ffnumber,4) = 547.6446
                  StringGrid1.Cells[x,x]:=CurrToStrF(.....,ffnumber,2) = 547.65

What should I use more to get along with the calculator or MSExcel ?

[Blaazen]

I have Openoffice and it gives me the same results like freepascal. Maybe it is configurable in MS Office.

For me, round 547.6446 to 547.65 is good.

Anyway you can use this:

currtostrF(0.01*Int(100*(1000000-1)  / 1826 ), ffFixed, 2);

but it only cut on two places, it does not round!

[asdf]

Dear Blaazen,

StringGrid1.Cells[x,x]:=CurrToStrF(.....,ffnumber,2)

How can I bring Currency back from StringGrid1.Cells[x,x] later ?

I need to use it to calculate something for some more purposes.
(It has comma in that cell.)

[Blaazen]

Of course, there is a oposite StrToCurr function.

It is not good way to round number, store it in StringGrid (in text format) and then turn it back to number for further calculations. It is slow and bad for precision.

If you have TStringGrid for working with more values you would better make some
myArray: array [] of Currency;

You will have your numbers stored in memory with full precision, you can calculate with full precision and you can display them with currtostrF only when needed.

 

[asdf]

My project is about the accounting.
The users have to use a lot of tables(StringGrid) to view,
and the data in some cells will be used for calculating when they click on it.
If I can't avoid,
is it OK to replace ',' with '' before using StrToCurr function ?

[Blaazen]

is it OK to replace ',' with '' before using StrToCurr function ?

  ???

Did you mean replace ',' with '.' ?

Then there is:

Code: [Select]

DecimalSeparator:=',';or

Code: [Select]

DecimalSeparator:='.';

[asdf]

For example, if the figure in a cell is 1,234.56 and I need to erase comma in order to use strtocurr with 1234.56 again for strtocurr function refuses comma.

Are there any short tricks to do instead of ....
strtocurr(stringreplace(StringGrid1.Cells[x,x],',','',[rfReplaceAll, rfIgnoreCase]));    ?

[eny]

                  StringGrid1.Cells[x,x]:=CurrToStrF(.....,ffnumber,2) = 547.65

This looks pretty bad!

[Blaazen]

Add unit strutils to your uses

and

Code: [Select]

strtocurr(delchars(StringGrid1.Cells[x, y], ','));

[asdf]

                 StringGrid1.Cells[x,x]:=CurrToStrF(.....,ffnumber,2) = 547.65

This looks pretty bad!

I've got to prepare the explanation for the users who will come to see me with their calculators in their hands (as well as in my hand)    .

Helpppppppppp

[Phil]

I've got to prepare the explanation for the users who will come to see me with their calculators in their hands (as well as in my hand)    .

Helpppppppppp

It looks to me like you've stumbled onto a Free Pascal bug. Delphi gives 547.64. Also, FPC's FloatToStrF gives 547.64. As would common sense rounding.

Try this code:

program test1;

uses
  SysUtils;
 
begin

  WriteLn(CurrToStrF((1000000-1)  / 1826, ffnumber, 4));  //547.6446

  WriteLn(CurrToStrF((1000000-1)  / 1826, ffnumber, 2));  //547.65 on FPC, 547.64 on Delphi

  WriteLn(FloatToStrF((1000000-1)  / 1826, ffnumber, 10, 4));  //547.6446

  WriteLn(FloatToStrF((1000000-1)  / 1826, ffnumber, 10, 2));  //547.64

end.

FPC's rtf.pdf says this about CurrToStrF: "Calling CurrToStr is equivalent to calling FloatToStrF", but that's not what we're seeing here. Please file a bug report on Mantis. Click FPC, not Lazarus at the top of Mantis.

Since Currency is a different type than Double, I would guess that maybe some place there's a conversion issue going on.

In the meantime, you can use FloatToStrF instead of CurrToStrF.

Thanks.

-Phil

[asdf]

Thank you Phil  ,

I will report right now.

[Zoran]

CurrToStrF really does nothing else, but call FloatToStrF. Let's test the FloatToStrF behaviour with currency and double parameter:

Code: [Select]

program FloatToStrFTest;

uses
  sysutils;

var
  C: Currency;
  D: Double;
  S: String;
begin
  C := 1.45;
  D := 1.45;

  S := FloatToStrF(C, ffNumber, 19, 0);
  WriteLn(S, ' - Currency');

  S := FloatToStrF(D, ffNumber, 19, 0);
  WriteLn(S, ' - Double');

  Readln;
end.

We get this output:

Code: [Select]

2 - Currency
1 - Double

So, FloatToStrF obviously works differently on currency and double parameter.

Looking into rtl sources, FloatToStrF eventually calls Str procedure. So, now we are testing the Str procedure, with double and currency parameters:

Code: [Select]

program StrTest;
var
  C: Currency;
  D: Double;
  S: String;
begin
  C := 1.45;
  D := 1.45;

  Str(C:19:0, S);
  WriteLn(S, ' - Currency');

  Str(D:19:0, S);
  WriteLn(S, ' - Double');

  Readln;
end.

Now, we get:

Code: [Select]

                  2 - Currency
                  1 - Double

So, the diferent rounding of Currency and Double types is obviously in Str procedure.
It's not easy to examine the implementation of Str procedure, as this procedure is part of compiler itself.

[Zoran]

Furthermore, using WriteLn directly:

Code: [Select]

program Test;
var
  C: Currency;
  D: Double;
begin
  C := 1.45;
  D := 1.45;

  WriteLn(C:19:0, ' - Currency');
  WriteLn(D:19:0, ' - Double');

  Readln;
end.

also gives different results:

Code: [Select]

                  2 - Currency
                  1 - Double