Additional headers and other options

[Andrew Hwang <ahwang@radius.holycross.edu>]

On 3 Sep 2002, Jay Belanger wrote:

> 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.
>
Another idea is to have bounding_box() set the picture() parameters by
default as you suggest. However, users must then put the call to picture()
after the call to bounding_box().

On a tangent, do you do a lot of "actual size" plotting/pictures?

> 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"?)
>
At Andrew Sterian's suggestion, epix accepts command-line options that
tell it where to look for additional headers and libraries. epix always
searches the current directory, but you can do something like

  epix -I~/myheaders/myheader.h file.cc

(no space between the "-I" and the path to the header) to include a header
that is not in a standard place. Other flags are -L (for lib directories)
and -l (small ell, for libraries).

Using a config file is a possibility; the easiest syntax to implement is
to have lines like -I~/myheaders/myheader.h. I'll look at Andrew's email
(he had comments about config files) and get back to you. :)

> 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.
>
If you need simple curves through a small number of points, splines are
probably the easiest thing to use (for now). Implementing splines with an
arbitrary number of points is in the TODO list.

> [regarding compile bug]
I probably left out a variable declaration when transcribing. Will
check...

> 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?
My understanding is that LaTeX reads in a paragraph (or the set of data
points in an eepic \path) before typesetting anything; splitting a single
path of 500 points into two paths of 250 points circumvents this
limitation. However, I've had unpredictable previewer problems that seem
to be related to the number of points on a page.

eepic2eps is "elaps" in epix. Only my laziness prevented the script from
getting the sensible name eepic2eps initially. (elaps is easier for me to
type...) Perhaps I'll adjust the Makefile to create hard links
laps -> latex2ps and elaps -> eepic2eps at installation.

> [regarding graphing y=sin(1/x)]
I'll try a few things...

--Andy

Andrew D. Hwang			ahwang@mathcs.holycross.edu
Department of Math and CS	http://mathcs.holycross.edu/~ahwang
College of the Holy Cross	(508) 793-2458 (Office: 320 Swords)
Worcester, MA, 01610-2395	(508) 793-3530 (fax)