Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hp-pcd!hpfcso!hplvec!bayes
From: bayes@hplvec.LVLD.HP.COM (Scott Bayes)
Newsgroups: comp.sys.hp
Subject: Re: BASIC bug? (was Re: BASIC/HFS/long file name systems)
Message-ID: <560009@hplvec.LVLD.HP.COM>
Date: 25 Apr 91 15:07:18 GMT
References: <40235@fmsrl7.UUCP>
Organization: Hewlett-Packard Co., Loveland, CO
Lines: 32

Far as I can see, this is an outcome of how BASIC gets as much speed as
it can for graphics.  BASIC "dives into" fixed-point math as soon as it
can in most graphics commands.  By this, I mean it takes your input
arguments and scales them to machine units (pixels or plotter coords)
immediately.  At that point, they become 32-bit fixed point numbers,
with a limited dynamic range.  The upside of this tradeoff is speed.
Fixed-point is much faster computationally than is floating point.
Clipping, etc, happen AFTER this conversion.  Clipping is very
computation intensive, so benefits much in speed.

This is documented in BASIC/WS 6.0 Programming Techniques, Vol.  1:
General Topics and Graphics, p8-19 "Special Considerations About
Scaling", and also in BASIC/UX 5.2 Graphics Techniques, Section 2,
"Using Graphics Effectively", p 2-5 "Special Considerations About
Scaling".  The subhead "Why Does This Math Overflow Error Occur?"  lies
a bit:  The graphics system does NOT do most of its math with real
numbers.  It goes to fixed point computation early.  Also, much of the
math is done in 32 bits, which is still very fast, converting to BASIC's
16-bit integers late in the game, or sometimes not even getting there,
if it's not required.

But the synopsis is still correct:  When working with large values,
overflows can occur.

Hi, Wayne!

Scott Bayes
Measurement Systems Operation
Hewlett-Packard Company

The above opinions are my own, and do not necessarily represent those of
Hewlett-Packard Company.