[comp.sys.hp] BASIC bug?

wehr@fmsrl7.UUCP (Bruce Wehr ) (04/15/91)

Speaking of BASIC (yeah ... it looks like it'll be tough completely
ousting good ol' RMB for HP-UX in these labs :-)

We don't have BASIC 6.0 ... we're using 5.13. I have come across a bug
(WHAT!! ... in RMB?! Well, ... maybe).

I've put together some general purpose plotting software to look at
data acquired from the lab (an automotive test lab). Given some data,
the X and Y limits can be set by the user, or "autoscaled".

A particular test produces numbers in the 1E-3 range across numerous
samples. But this test can be pretty harsh, and occasionally sensors
fail.  Failed sensors produce numbers in the 1E+14 range. When the plot
for such a sensor is "autoscaled", it is scaled to show all the data -
but the scale is too large to see the detailed data that was acquired
before the failure. When the plot has the limits manually set to more
appropriate values, an "ERROR 19 - Improper value or out of range"
error is generated by the PLOT statement.

I've read the documentation on the PLOT statement. It says that its
arguments can be any real value (+-E308). I'm using BASICs own WINDOW
statement for mapping (it's much more efficient). It claims that any
value plotted outside the window will be ignored.  That's all it says -
implying again that any real value can be specified. However, it seems
that this error occurs when the an argument to the PLOT statement
exceeds about 5E+5 times the range of the window.

For now, I'm working around this by having the plot loop check the
value of the data before it plots it. If I understand the manuals
correctly, it shouldn't have to do this. Is this a bug, or am I missing
something? If it is a bug, has BASIC 6.0 addressed it?

Thanks for any enlightenment.

-- 
               Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com)
                (..!uunet!srlvx0.srl.ford.com!wehr%dptc.decnet)
              Ford Motor Company - Engineering Technology Services
     P.O. Box 2053, Room 1153, Dearborn, Michigan 48121-2053 (313)337-5304

wayne@dsndata.uucp (Wayne Schlitt) (04/17/91)

In article <40235@fmsrl7.UUCP> wehr@fmsrl7.UUCP (Bruce Wehr ) writes:
> 
> [ basically, bruce says that when you are using RMB, if you plot
> data that is too far out of your window, you get an error 19]
> 
> For now, I'm working around this by having the plot loop check the
> value of the data before it plots it. If I understand the manuals
> correctly, it shouldn't have to do this. Is this a bug, or am I missing
> something? If it is a bug, has BASIC 6.0 addressed it?
> 

i cant think of any place that i have seen that says that you could or
should get an error 19.  i also havent seen any place that says this
is a bug.  it has, however, been this way since at least basic 2.0,
and to the best of my knowledge, it continues to be this way in basic
6.0.  (i havent really check 6.0 'cause all our software already
handles it...)

this can be a real pain to work around, especially when you need to
draw a "very long" line, and one end of the line is way of the edge of
the screen.  the only way to draw it is to carefully calculate where
the line crosses the edge of the screen and do your own clipping.
*gack*.  this problem also occurs when you are doing things like SET
ECHO, AREA FILL, and LABEL.  these commands are much harder to work
around. 



-wayne

bayes@hplvec.LVLD.HP.COM (Scott Bayes) (04/25/91)

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.