Re: [ePiX-devel] Current status of ePiX-1 and 2

[Andrew D. Hwang]

On Mon, 8 Jan 2007, address@hidden wrote:

Hi all,

First, off, the list should no longer strip off the sender's name. Sorry 
for the unintentionally anonymous messages.

Here are a few quick replies to Marcus's ideas. A (long) status report 
will follow.

> Not sure if I understand the versioning scheme but wouldn't it be more 
> transparent to call is 1.1 as it seems there are some large changes 
> being made rather than small incremental changes?
It seems many GPL projects increment the version number when a major 
redesign occurs. Most users consequently tend to avoid upgrading until a 
decent number of sub-versions have appeared (e.g., gcc-4.1 :). While I'm 
not opposed to this scheme, I've been trying to increment the version 
numbers "traditionally", when the code reaches a new plateau of features 
or stability. Version k.m.(n+1) was meant for "ordinary users", though 
implemented only a smallish number of new features and usually wasn't an 
"essential upgrade" from k.m.n. Under this scheme, Version 1.1 would be 
a final release that's stable and well-tested.

On the downside, my current "system" (such as it is) sometimes fails to 
reflect changes users might want to know of. Version 1.0.7 was a big jump 
from 1.0.6 (because of Julian Gilbey's nearly heroic work with autotools), 
1.0.23 is (or will be) a huge jump from 1.0.22.

In any case, the current scheme lacks a certain utility, but has worked 
because I've been the only developer. For the future, maybe a linux-like 
system would be good, particularly if changes may not be incremental: The 
k.(2m+1) line is for development of k.(2m+2) and not for ordinary users.
k.(2m).n would be incremental improvements for general use.

With version numbers as they are, 1.0.23 could become 1.1 as Marcus 
suggests, with the understanding that it's not for ordinary use. Once 
testing and debugging are complete, it would become 1.2.0. Does this 
(or something similar) seem sensible?

Separately, I hadn't planned (until the 5th of this month :) to invest 
more time in the 1.x code. However, when the current round of re-coding is 
complete, the internals will be much better organized, and should be 
suitable as a foundation for further development.

> > 2. For the benefit of pdflatex users, I'd like to keep the output free
> >    of PSTricks macros unless the user explicitly asks.  My current idea
> >    for color filling is to modify Svend D. Pedersen's polygon hatching
> >    code. With luck, this will permit simulated transparency for filled
> >    polygons.
>
> Does this still give colour output? I am unfamiliar with the polygon 
> hatching code.
Yes. :) Here's a simple "smoke test":

---(snip)---
/* -*-ePiX-*- */
#include "epix.h"
#include "epix_ext.h"
using namespace ePiX;
using namespace ePiX_contrib;

P poly1[] = {P(-1,-1), P(1,-1), P(1,1), P(-1,1)};
P poly2[] = {P(-2,-0.5), P(2,-0.5), P(2,2), P(-2,2)};

int main()
{
  bounding_box(P(-2,-2),P(2,2));
  unitlength("1in");
  picture(4,4);

  begin();

  bold();
  red();
  hatch_polygon(45, 0.02, 4, poly1);

  blue();
  hatch_polygon(-45, 0.02, 4, poly2);

  end();
}
---(snip)---

The eepic file contains no specials.

> One other thing I thought of was that all graphs should refuse to plot 
> points outside of their bounds be default - it seems very unusual to see 
> points outside the graph bounds being plotted but that change should not 
> be difficult to add.
For immediate use, putting a crop() command just after begin() should do.

Orignally the goal was to plot functions specified by formulas (rather 
than data), and to draw Exactly What the User Requested. My philosophy is 
admittedly a response to the commercial M--- programs, at least one of 
which chooses plot attributes (aspect ratio, clipping, graph color, etc.) 
cleverly and automatically, making the user fight to get a plot that's 
mathematically correct. This, in my opinionated view, is a Small Crime. :)

For 2-d plotting, cropping by default seems safe fairly. For other types 
of drawing (especially in 3-d, where page locations are not so easily 
predicted), default cropping might be an annoyance. However, it would be 
easy (as you say) to make plot functions (just data plotting functions?) 
crop their output by default. If that's the expected behavior, I'm happy 
to consider it.

Best,
Andy

Andrew D. Hwang                 address@hidden
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)