Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Newsgroups: comp.lang.pascal
Subject: Re: Is this a bug in TurboPascal
Message-ID: <1991May1.134303.7289@maytag.waterloo.edu>
Date: 1 May 91 13:43:03 GMT
References: <1991May1.021059.2129@ux1.cso.uiuc.edu> <1991May1.060345.26511@newsserver.sfu.ca>
Sender: news@maytag.waterloo.edu (News Owner)
Organization: University of Waterloo
Lines: 38

In article <1991May1.060345.26511@newsserver.sfu.ca> shephard@newsserver.sfu.ca (Gordon Shephard) writes:
> 
> The easiest way around all of this is to add .0 to at least one number
> in an equation which could cause trouble.  This forces TP to perform
> Real Arithmetic on the numbers involved
>

You have to be careful which number gets the decimal point.  TP (like most
languages) evaluates expressions a pair of operands at a time; it's the
types of the pair that determine the result, not the types of other parts
of the expression.  For example,
 
var
  int1,int2 : integer;
  real1,result : real;
begin
  int1 := 256;
  int2 := 256;
  real1 := 1.0;
  result := real1 + int1*int2;
  writeln('result = ',result);
end.

will give a result of 1.0; the multiplication is performed in the integer
types, and overflows.  Expressions like

  real1 * int1 * int2
and
  int1 * int2 * real1

are especially dangerous, because you don't know in advance how TP will pair
the operands, and it makes a difference when overflows can occur.  (In TP
6.0, with the values above, the results of those two expressions are
65536.0 and 0.0 respectively, because on Wednesdays it operates from left
to right.  I haven't tried the program on other days of the week, so I'm
not sure what happens then.)

Duncan Murdoch