[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