[comp.lang.pascal] Bug in TurboHALO Graphics Kernel? -Summary and comment.

oivindt@ulrik.uio.no (Oivind Toien) (02/28/90)

In previous posting I wrote (extract):
> I have a problem that may interest TurboHALO users as well as those
..........
> 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!
....
>I will be very pleased for any response. If you E-mail I will summarize.


I only got two responses to the message, the first one by mail from :

      Alpo Varri  ( varri@tut.fi)

> I am using HALO-88 and I'm still experiencing something similar. For
> example, when I plot a high frequency sinusoidial to the screen, it
> should appear as a solid horisontal bar, but in practise there are
> some vertical blank lines in the bar. 
> 
> We use the HALO-88 to plot physiological signals, too, EEG, EOG, EMG
> etc. We have found some bugs in some printer drivers, too. I can't
> remember exactly, but I believe that Epson GQ-3500 driver did not seem
> to work. We are hoping that there would be a new version of HALO
> coming to market soon, but I've no idea, when it will happen.
> 
> 	Alpo Varri
> 	Tampere University of Technology
> 	Signal Processing Laboratory
> 	Tampere, Finland

The other one was posted by 
   milne@ics.uci.edu (Alastair Milne)
who points out that numerical processing may cause the problems (extract):

> >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.
> ....
>    Alastair Milne,
>    U. Calif. Irvine


What by my opinion strongly suggests that the problems is not caused by
numerical processing in turbo-pascal is the following:
I wrote:
> .....  However, the numbers passed to TurboHALO are correct!

What this means is that when exactly the same numbers that cause the
bad plot are saved to disk, they are plotted correctly after the
program has been started up again and the data reloaded from the file.
If the data are replotted after leaving the data-acquisition
procedure, however, (but not restarting the program or reloading the
data), the plot is still messed up.

Together with Alpo Varris reply, this suggests that the problems arise
from a bug in TurboHalo/Halo88.

--
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