oivindt@ulrik.uio.no (Oivind Toien) (02/18/90)
I have a problem that may interest TurboHALO users as well as those
only using Turbo Pascal: I have written a plotting routine that is
plotting lines or points at very short intervals using
world-coordinates. It is used in a data acquisition routine to display
the input on the A/D converter variable plotted against time. After
some samples, however, the x-coordinate is at certain intervals not
plotted correctly, but is plotted with a x-value 1-3 pixels lower than
it is supposed to. When input to the routine is obtained from a
sine-wave equation, it results in a jagged appearance. The effect is
especially present when the distance between data-points is very short
on the X-axis. However, the numbers passed to TurboHALO are correct!
It is the address of the variables that is passed from Turbo Pascal to
the TurboHALO routines. The error occurs when using the procedures:
LnAbs, MoveAbs+PtAbs and PolyLnAbs. The problems are present with all
versions of Turbo Pascal >= 3.0.
Finally I detected a way to make the error appear and disappear:
X : real; { x-coordinate}
XInterval : real; { interval between points on x-axis}
n : Integer; {counter variable}
1)It is present in the test routine if the X-value is calculated the
following way:
X:=X+Xinterval;
2)It is not present if the X-value is calculated this way:
n:=n+1;
X:=n*Xinterval;
But I have still not been able to eliminate it in the routine used in
the program, in spite of avoiding the no.1) approach. Something is
still screwing up the system. (The source is to long to post).
Has anyone out there had similar problems? I can E-mail source of
test-routine if interest, I am especially interested if the problems
exists with **HALO 88** which is an updated version of the same
graphics kernel.
I will be very pleased for any response. If you E-mail I will summarize.
--
Oivind Toien <oivindt@ulrik.uio.no>
Div. of General Physiology, Dept. of Biology, Univ. of Oslo
P.O. Box 1051, N-0316 Oslo 3, NORWAY
Phone+47-2-454732 Fax+47-2-454726
milne@ics.uci.edu (Alastair Milne) (02/20/90)
oivindt@ulrik.uio.no (Oivind Toien) writes: >Finally I detected a way to make the error appear and disappear: > X : real; { x-coordinate} > XInterval : real; { interval between points on x-axis} > n : Integer; {counter variable} >1)It is present in the test routine if the X-value is calculated the >following way: > X:=X+Xinterval; Not at all surprising. >2)It is not present if the X-value is calculated this way: > > n:=n+1; > X:=n*Xinterval; No, it won't be. You are encountering the numeric analyst's favourite problem, the accumulated representation error in floating point numbers. Since decimal reals seldom if ever have exact binary representations, you have to put up with a bit of inexactitude in the least significant bits. While normally you don't worry about that, certain operations can cause it to magnify most unpleasantly. Adding inaccurate numbers to themselves is one way to do so. I leave the consequences of multiplication to your imagination. Correct means of dealing with this are best obtained from a numeric analyst, or failing that, a numeric analaysis text. About all I can remember at the moment is to avoid adding very similar numbers of opposite sign, since that will abruptly turn most of your significant bits to 0, and leave you with a value that's principally lower-end noise. >But I have still not been able to eliminate it in the routine used in >the program, in spite of avoiding the no.1) approach. Something is >still screwing up the system. (The source is to long to post). Perhaps high integer factors are magnifying the low-bit noise when N gets very high. But that's just a guess. I would have said that eliminating all the reals you can from your operations was the right thing to do. >Has anyone out there had similar problems? I can E-mail source of >test-routine if interest, I am especially interested if the problems >exists with **HALO 88** which is an updated version of the same >graphics kernel. I have never touched Halo, so I certainly won't swear it's not suffering from internal floating-point numeric problems. >I will be very pleased for any response. If you E-mail I will summarize. I probably should have done, but e-mailing to members on this net always seems to fail. Alastair Milne, U. Calif. Irvine