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-5304wayne@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.