[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Angles and elaps and emacs, oh my!



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

> Expediency and my inexperience (a.k.a. "bad design"), and writing in C (no
> overloading). The idea was to minimize the amount of typing (especially to
> minimize occurrances of M_PI in source files), but to use radians as much
> as possible. Eventually the inconsistency reached the current ugly state,
> but I never had the impetus to change things. In practice, revolutions
> could be eliminated with no trouble (they're only used in specifying
> angular intervals in polar plots). Would degrees or radians be easier to
> use as a general angle unit? 

It depends on whose using it, I suppose.  I like the solution that you
mention later.

> Here's a C++-ish idea: Define two new data types in epix, degree and
> radian, and write all functions that accept angle parameters in "degree"
> and "radian" forms. This would also encourage the use of symbolic angle
> parameters, as in
> 
>   theta1 = degree(60);
>   theta2 = radian(M_PI_2);
> 
> The current functions that accept angle parameters could be retained for
> arguments of type "double". Does this seem like a good (i.e., usable, more
> consistent) scheme? (I bought Stroustrup's book on C++, and can already
> feel his influence. :)

This sounds like a very nice solution.

> > Finally, I wrote an emacs mode for epix; essentially, it is c++ mode
> > with additional commands for running epix, elaps, going to errors, and
> > viewing the eps output of elaps.  It's somewhat crude, but works for
> > me.
> >
> Cool! At the very least, please send a URL.

ftp://vh213601.truman.edu/pub/ePiX/epix.el

Jay