samuel fleischer

PROGRAM Multiply;
VAR FactorA,FactorB:WORD;
Product:Longint;
BEGIN
FactorA:=9999;
FactorB:=9998;
Product:=FactorA*FactorB;
WriteLn(FactorA*FactorB);
WriteLn(Product);
END.

Hello !

The above code should just somehow compute the product of the two
numbers 9999 and 9998 (decimal). When compiling/running with Borland
Pascal 7.0, the result is 27602, which obviously is wrong! It should
be 99970002.
The Range of FactorA and FactorB is 0-65535 (WORD) which can capture
FactorA as well as FactorB but not the result.

But the result actually is not captured in WORD, but in LONGINT
(Range: 0-2147483647) which should be sufficient.
WriteLn(FactorA*FactorB) does not even specify how the result should be
stored - nonetheless the result also is not correct.

When switching the range of FactorA and FactorB to the range of the
Product , everything works fine.

For me that means that ultiplying values in BP only works correct as long as all
factors are assigned to variable-types which have the (often larger) range of the
result.

Are there reliable Pascal-Compilers which do not have this limitation/where
multiplication works correct even if factors are of smaller-ranged variable-types
than the result-type?

Sincerely

Sam

jochen

Hello Samuel,

Samuel Fleischer typed:

[...]

try: product := longint(factorA) * factorB;

hth
jochen

--
http://radio789.net.ms - 789 Radio - Radio 789 - We play it ALL
Radiostream: http://66.111.33.50:25223/listen.pls

jud mccranie

Right, typecast it to longint before you multiply.

---
Replace you know what by j to email

scott moore

For comparision, standard ISO 7185 Pascal rules are that all arithmetic
operations are carried out in the range of integer, which is
-maxint..maxint. In Borland Pascal integer is a 16 bit word, so maxint
is equal to 32767. longint (a non standard extention) is a 32 bit
quantity, which is why starting with a longint as a base gets your
job done.

integer being 16 bit is done for Borland for historical reasons. Integer
used to be 16 bit a long time ago, so it was kept at that size to
allow programs to remain "compatible".

The standard ISO 7185 idea of integer is for it to be the natural size
of numbers on a machine. While technically, that would allow integer
to be 0..10, the idea is that integer is the maximum size supported by
the machine efficiently, which would be 32 bits on a 80386 and beyond.
The idea that a program would become "incompatible" because the size
of integer was expanded, say from 16 to 32 bit, isn't supposed to
occur because programs either declare the range of numbers they use
specifically, or use integer and use the value of maxint to adjust
any program code to live with the larger (or smaller) range of integer.

So the short answer is that an ISO 7185 compatible compiler would not
typically have the problem you are describing. It is mainly due to
non-standard Pascal implementations.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performace, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

jason burgon

[integer -> Longint overflow problem]


I would suggest that a 16-bit ISO 7185 compatible compiler would not even
be able to attempt it because it would have no Longint or equivalent, and if
Samuel used an Integer for the result variable, then exactly the same 'bug'
(with range-checking off) would occur.

--
Jay

Jason Burgon. Author of Graphic Vision
Version 2.21 available from:
http://homepage.ntlworld.com/gvision

dr john stockton

JRS: In article <cb10sh$g50$1@newsserv.zdv.uni-tuebingen.de>, seen in
news:comp.lang.pascal.misc, Samuel Fleischer <Live****s@hotmail.com>
posted at Sat, 19 Jun 2004 11:08:02 :


The result is what it should be according to the specification and
do***entation of Borland Pascal. It is the programmer's responsibility
to control the types participating in an expression as necessary; what
may later happen to the result - in this case assignment to longint - is
irrelevant.

Sufficient but irrelevant. And the range is -2147483648 to +2147483647.
Note that even longint does not suffice for all word products;
50000*60000 is too large.


No; it is only necessary that one of the factors is sufficient.


Coders should understand the rules of their language.


Evidently you are compiling with the run-time overflow checking turned
off. That is unwise, except for an omniscient and infallible
programmer. The right result, for you, is "Runtime error 215 at
####:####", which shows your error clearly enough.

TURN ON ALL POSSIBLE RUN-TIME CHECKS AT ALL POSSIBLE TIMES.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

cbfalconer

The proper standard way to have those quantities would be:

CONST
intmax = 32767;
intmin = -intmax;

TYPE
int = intmin .. intmax;
....

which should let everything work if the system is capable, and may
reduce the storage space for ints (depending on the
implementation).

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

scott moore

Implying that either the poster had a 16 bit, 286 or earlier computer, or was
running a 16 bit compiler on a 32 bit machine. Is that common nowdays ?

Unfortunately, Borlands compilers, which certainly started out as 16 bit,
maintained the 16 bit limitation even though they moved on to 32 bits years
ago. As modern a compiler as Delphi still has this limitation. It is yet
another example of how, having ignored or misunderstood the original Pascal
standard, the result is portability problems going into the future.

This error is being repeated yet again. The 64 bit version of GPC, the GNU
Pascal compiler, will have a 32 bit integer type, even though that is
not the natural size of the integer for that machine.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performace, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

marco van de voort

Be careful here. 32-bit is the natural size for the PM mode on a 386+ proc.

The natural size for the 80386 in real mode was 16-bit, which is why TP used
it, since it was a 16-bit realmode and 16-bit PM (286 compat) compiler.

Of course backwards compability was important for TP (and their highly
optimized codebase probably didn't allow a swift move to 32-bit too),


Yes, but that has the fundamental problem that sizes bigger than the natural
size are not possible easily, without arithmetic emulating code.

IOW, you can't do compute even something HD related on a standards compliant
system, because:

So for 16-bit systems: file+hd size + memsize no larger than 64k.
for 32-bits systems: hd size < 4 GB.

Of course this is not an option.

While elegant on paper, this is the main reason why the ISO 7185 method is
braindead. It is too limiting, since the magnitude just above the natural
size is typically still needed in everyday life.

The standard thus provokes extensions to be made (and this isn't just on
Borland compilers. See e.g. GPC too), because the base principle neuters
the language too much.

Above 64-bit this slowly becomes less important, but a lot of water traveled
to the sea between the standards proposal and 64-bit systems on everybodies
desktop.

marco van de voort

Are you sure? Did you print sizeof(integer) on Delphi?


It might be wise to to revalidate your negative view on Borland from time
to time.

Integer has been 32-bit on Delphi for ages, except the very first one (a 16-bit windows 3.x version!)


That is totally unrelated to this discussion. This is simply a choice if you
match the choices of integer, pointer etc with the OS, or try to make an
own implementation that is radically different.

One (of these) solutions it is not worse than the other. The first is more
suitable for a compiler that interfaces a lot with the OS, the second is
more suitable for purity compilers and compilers targeted at doing their
own thing, and hardly touch the OS (or if the OS is thin).

Also note that 64-bit on an e.g. an AMD64 is slower than 32-bit, simply
because the cache utilisation goes down because the working set increases
significantly due to the fact that integer becomes 64-bit.

And nowadays, cache memory is relatively the most expensive resource to
increase in an avg computer. (either when upgrading or bought new), since
when increasing cache significantly one changes class from desktop computers
to "server" class machine.