Lazarus cannot handle simple calculations?

[Waco]

I've got an odd problem and it had taken me quite a while till I sorted it out. I didn't want to believe my eyes, so I made several screenshots. I really doubt that I have something wrong there.
(http://img194.imageshack.us/img194/9339/scr1t.th.jpg)
(http://img194.imageshack.us/img194/8454/scr2p.th.jpg)
(http://img405.imageshack.us/img405/6329/scr3.th.jpg)
(http://img151.imageshack.us/img151/3222/scr4c.th.jpg)

[theo]

Gosh, do we really have to look at 4 screenshots for this little problem?

var n1,m1,m2:integer;
e:double;
begin
{$Q+}
n1:=78;
m1:=295;
m2:=162;
e:=8*n1*n1*m1*m2;
end;

Arithmetic Overflow, the double "e" can't hold the resulting value.
using {$Q+} you get an error message.

[Vincent Snijders]

If you cannot believe it, compile with overflow and range checking.

The value is too big to fit in an integer, either use int64 or convert to floating point (double) before calculation.

[Waco]

Alright, it seems that yet again, I've made a mistake... But I don't get it, double is supposed to have range up to 1.79 x 10^308, so why should 'e' overflow? I deliberately used double to avoid any overflows. Vincent, so how do I convert to floating point?

[theo]

I think the problem is not with the resulting "double" but it's an integer overflow.

Try this  (should work):

Code: [Select]

var n1,m1,m2:cardinal; //instead of integer, double might work too.
e:double;
begin
{$Q+}
n1:=78;
m1:=295;
m2:=162;
e:=8*n1*n1*m1*m2;
caption:=floatToStr(e);
end;
Ask the compiler developers for details:
http://www.freepascal.org/maillist.var see fpc-pascal

[Vincent Snijders]

using cardinal instead of integer only doubles the range.

try:

Code: [Select]

e := 8*(n1*(n1*(m1*int64(m2)));then the multiplication is evaluated using 64 bit integers.

[skalogryz]

how about?

e:=8*double(n1)*double(n1)*double(m1)*double(m2);

[Vincent Snijders]

That is the conversion to double alternative, I mentioned.

[Waco]

I see... Thanks for clearing things out, but wouldn't it be logical, if the multiplication is evaluated using the type of variable, which is being calculated?

[Vincent Snijders]

wouldn't it be logical, if the multiplication is evaluated using the type of variable, which is being calculated?

Maybe more logical for you, but that is not how it is done in Pascal. The value of an expression is determined by the expression and is not influenced by what you do with the expression.

[Waco]

Well, I think it would be more logical generally, but whatever. Anyway, thanks for your assistance, I "somehow" get it know.

[sasa]

In addition to other posts. In FPC, resulting mid-calculation variable do not relyes on resulting variable type as in Delphi. Type of variable is upgrading during calculation process, depending on each operand type. When calculation is finished, result is converted to resulting variable type. This way is probably done to speedup the whole calculation process.

At end, to ensure non-overflowing in this case:

e:=double(1.0)*...

[Vincent Snijders]

At end, to ensure non-overflowing in this case:

e:=double(1.0)*...

This is not safe, because then you are relying on the order in which the expression is evaluated. If it is evaluated from right to left (which the compiler is allowed to do, and this is even documented), you end up with the same overflow.

That is the reason I added so many braces in the int64 example.

[sasa]

This is not safe, because then you are relying on the order in which the expression is evaluated.

You have a point, hopefully compiler currently work left to right way regarding each sub-expression.

Anyway, your code will overflow as well when exceed int64 range.

Worst, for my own expression evaluator project I made clearing brackets after parsing if operation priority is the same, to speedup calculation (users 3D functions drawing), so in the future compiler releases may fail that as well...

As I wrote explanation, currently, in this case:
e:=8*n1*n1*m1*m2;

it is enough:
e:=double(1.0)*8*n1*n1*m1*m2;

If there is many sub-expressions (operation priority change), each will start regarding its own operand type and thus will lead to overflow.

I.e, this will overflow as well:
e:=double(1.0)*8*n1*n1*m1*m2+
8*n1*n1*m1*m2;

This will pass:
e:=double(1.0)*8*n1*n1*m1*m2+
double(1.0)*8*n1*n1*m1*m2;

After I looked at pictures provided by OP, I would suggest to change all function parameter types as well as in function variables to resulting one, regarding calculation complexity ...

I'm not sure there is a compiler directive about this (to get a resulting variable type for each subcalculation instead), but behavior with Delphi mode switch gives the same result as in FPC mode. This is definitely problematic, even if intention to speedup the calculation may have been the goal.

[Vincent Snijders]

I think the fpc docs are clear: read the remark on http://www.freepascal.org/docs-html/ref/refch9.html