Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!masscomp!peora!tarpit!bilver!alex
From: alex@bilver.uucp (Alex Matulich)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Contour plotting
Message-ID: <1991Mar3.232107.1675@bilver.uucp>
Date: 3 Mar 91 23:21:07 GMT
References: <1991Feb27.194218.12227@csun.edu> <1991Feb28.173901.27728@bilver.uucp> <1991Mar1.213257.6960@csun.edu>
Organization: W. J. Vermillion - Winter Park, FL
Lines: 64

In article <1991Mar1.213257.6960@csun.edu> bcphyagi@csunb.csun.edu (Stephen Walton) writes:
>>Comparing two machines according to completely different contour algorithms
>>tells nobody anything.
>
>It does if the two algorithms purport to accomplish the same thing--it
>tells you how long it will take each machine to perform the task I
>require. 

I apologize for misunderstanding the way PPLOT worked.  However, I still think
your statement above is incorrect.  Two dissimilar algorithms that have the
same end result cannot be used to make a valid comparison between two
dissimilar architectures as well.  At best you are just comparing the
algorithms, but a hardware comparison was implied in your original article.
I didn't know that the Amiga graphics package was device-independent.  In
that case, I am impressed!  It's contouring algorithm must be extremely
well-designed and optimized compared to the IBM GRAFTOOLS package.

>You also missed the point that this two-hour+ operation to generate the
>contours in GRAFTOOL is *required before* you can get the pen plot.
>PLPLOT will generate the pen plot directly. 

I didn't know that.  Yecch!

>>For the pen-plotter algorithm, you have to design the routine to minimize
>>the number of pen lifts and pen color changes.
>
>PLPLOT uses an algorithm like this.  If you watch it run on the Amiga
>screen, it does in fact produce one contour interval at a time, making
>a complete pass through the data for each contour level.  I admit that
>I've never tried the pen plot part, but I bet it takes much less than
>the time GRAFTOOL takes to just do the screen version. 

Here the plotter speed and the size of it's data buffer is the primary
factor in the speed of the output.  With no buffer (like an HP 7475 plotter)
the plotter might well take two hours with _either_ algorithm, depending
on the complexity of your data.  I learned this from painful experience!

>Please tell me how to run the following loop under MSDOS:
>
>        float **z;
>
>	z = (float **) malloc(512 * sizeof(float *));
>	for (i = 0; i < 512; i++)
>		z[i] = (float *) malloc(512 * sizeof(float));

Easy.  The pointers must be declared as far or huge, and malloc() should
be substituted with _fmalloc() or whatever equivalent your MSDOS compiler
has.  I like programming on the Amiga because I don't have to worry about
memory-model issues, but I have to do MSDOS programming too, and the available
C compilers provide reasonable work-arounds given the constraints of
the architecture.
 
I have noticed one case in my own projects where a 25 MHz 80386 runs a
program slower than a 14-Mhz 68000 Amiga.  It was a sort routine.  The
MSDOS cpu can only use two registers for user programs, whereas the
68000 can use many more.  For tight multi-nested loops, this is an important
factor in speed.  Maybe it's also a factor in your observed differences
between the speed of contour plots.

-- 
 _ |__  Alex Matulich   (alex@bilver.UUCP)
 /(+__>  Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817
//| \     UUCP:  ...uunet!tarpit!bilver!alex
///__)     bitnet:  IN%"bilver!alex@uunet.uu.net"