Closed jcrist closed 10 years ago
I like option 1, since it seems more easily composable (e.g. the user doesn't have to know about a special way to print it)
To keep the math simple, I would simply make it an error to combine two polynomials in different variables. I think making this option valid quickly starts to turn this library into a badly implemented CAS instead of a simple polynomial library (which was originally started to support a controls tf implementation, which I just never got around to working on, and thus only needs the simple operators)
Excellent. I'll work up an implementation and submit a pull request in the next day or so.
fixed by #20
I'm working on Control.jl, a package for control system synthesis and analysis. A basic type for controls is a transfer function, which in essence is a fraction of two polynomials. By standard convention, the polynomial has 's' as its variable.
Currently I'm using an alternative implementation of Polynomial.jl to accomplish all polynomial routines, but it would be nice if the necessary functionality could be added into this package. The main issue I have is with the printing mechanism, and the lack of variable configuration. Here's my thoughts on a fix:
While option 1 is more clean (keeps the variable associated with the polynomial), the issues in defining math for different variables make me lean towards option 2. Thoughts?