Re: ePiX comments (what else?)

[Jay Belanger <belanger@truman.edu>]

Andrew Hwang <ahwang@radius.holycross.edu> writes:

> Regarding an "actual_size" function, is there a particular syntax that
> seems natural to you, e.g., actual_size("4.5x3in")?

That seems as natural as anything, I suppose.

Since I usually want the x- and y-scales to match, my local solution
is to define a function mycoordinates(Q,R) which will set 
bounding_box(Q,R);
picture(P(R.x1-Q.x1,R.x2-Q.x2));
and then the unitlength is the actual length of the coordinates.  (I
suppose I could do something similar if I wanted different scalings
for x and y.)
Which brings up another question.  Putting myheaders.h in the same
directory as my epix file seems to work (I don't know where epix will
search for the headers, but that seems safe) (also, it seems that
functions as well as defines can be put in the headers file), but is
it reasonable for there to be something like an epix init file, such
as ~/.epix, in which local customizations can be put?
(For that matter, can epix assume the #include "epix.h"?)

> > There seem to be a few constructs that I would think would be pretty
> > basic, but don't seem to be built in.  (One such thing is a curve
> > which goes through a specified sequence of points.)
> >
> Do you have a specific curve in mind (e.g., a Lagrange polynomial, a
> connect-the-dots path, a spline...)?

I didn't have anything in mind; sometimes when I need to draw an
example, it's easier to say that I want a curve through these points
than to come up with a specific function with the right properties.

> > 1) Is there a way of turning an integer to a string?  I want to take,
> >    say, 3, and get back (not print) "3".
> Kernighan and Ritchie (2nd ed) have this as an example, pp. 62--64. They
> implement the conversion as two short functions; code is copied below.
> (On a tangent, there are library functions for performing the reverse
> conversion, should you ever need to.)

I'm surprised that there isn't a library function for this direction.
By the way, for the reverse function, I get an error

jay> epix jay.cc
epix: Compiling...jay.cc: In function `void reverse(char*)':
jay.cc:18: parse error before `int'
jay.cc:18: `j' undeclared (first use this function)
jay.cc:18: (Each undeclared identifier is reported only once for each function 
   it appears in.)

epix: Compilation failed...exiting

I'm working on null, the RedHat beta, with gcc 3.2.  Since I'm using
beta software, there is no reason to assume that this is an epix
problem. 


> ... Finally, there's a limit on the number of points a plot can
> contain; TeX often runs out of memory around 300 points, and I've
> had xdvi refuse to display figures with more than about 700 points.
> That may be why you're getting no output when the number of points
> is large. 

Is the number of points a per page or a per document limitation?
Could two small pictures cause TeX to run out of memory when one of
them alone would be okay?
If that's the case, then using something like eepic2eps (from pyepix)
could be useful; turn each picture into a postscript file to be
included with graphicx.  Perhaps something like that should be part of
the main distribution.

[Regarding plotting y=sin(1/x)]
> Please post if you can't get an acceptable picture...

I can get something somewhat reasonable by using your suggestions; if
I take the time to break up the subintervals over which the function
is plotting by using the max and min as endpoints would help.
For a graph that ugly, I probably can't expect to get a nice picture
with no work.

Jay