Hi all,
One of the needs for a few of my DSP routines is support for functions
over polynomials. The attached file is what I threw together.
Since this definetly has a broader scope than just me, I wanted to get
some opionions on it.
1. The module is pretty type-free right now. I wanted to get some
opionions on the best type for polynomials and names for the type and
constructor(s).
The big question here (in my mind) is how to represent polynomials. The
most obvious way is as a list of the coefficients. They can also be
represented as a list of the roots. Should there be a single type with
two constructors or two types each with one constructor.
2. Are there any functions that are missing? I have a root finder in a
different module (the one from Numeric Quest; Laguerre's method), but I
am going to rewrite it in terms of the module that I attached.
Functions for inflation and deflation by a single root will need to be
added.
3. Should I add infix operators? I'm not sure what to do about this
because of namespace clutter.
Any other thoughts?
Once again, thanks.
--
Matthew Donadio
On Wednesday 07 May 2003 18:34, Matthew Donadio wrote:
Any other thoughts?
Name redundancy: Poly.Poly, Poly.polysubst Is this redundancy essential? You
are assuming the user will include the module's scope, right?
Polynomial functions: the scientific computing community has a great variety
of algorithms for solution of numerical problems you might find many things
of use in their writings. Just an off-the-top-of my head remark.
There is surely a lot to be done in mathematical libraries. I had looked for a
clean, small DCT routine and I had to write it myself when I implemented a
sound synthesizer. (I just wrote the formula as it is so it wasn't efficient
:) )
Regards,
--
Eray Ozkural (exa)
On Wed, May 07, 2003 at 11:34:28AM -0400, Matthew Donadio wrote:
Hi all,
One of the needs for a few of my DSP routines is support for functions over polynomials. The attached file is what I threw together.
Since this definetly has a broader scope than just me, I wanted to get some opionions on it.
1. The module is pretty type-free right now. I wanted to get some opionions on the best type for polynomials and names for the type and constructor(s).
The big question here (in my mind) is how to represent polynomials. The most obvious way is as a list of the coefficients. They can also be represented as a list of the roots. Should there be a single type with two constructors or two types each with one constructor.
You can only represent a polynomial as a list of roots if the roots are complex, and it looks like you don't require a to be complex, so I think you are limited to representing them as a list of coefficients (which seems best to me anyways). I would use a single constructor and just provide a function to create a polynomial from a list of roots. Of course, you can also define a polynomial by a list of (x,y) pairs, which would be convenient for interpolation (with the list of roots being a special case).
2. Are there any functions that are missing? I have a root finder in a different module (the one from Numeric Quest; Laguerre's method), but I am going to rewrite it in terms of the module that I attached. Functions for inflation and deflation by a single root will need to be added.
I'm not sure what it would be called, but it would be nice to be able to rescale x: P'(x) = P(s*x)
3. Should I add infix operators? I'm not sure what to do about this because of namespace clutter.
Is there any reason polynomials can't be of Class Num? I can't think of any, and that would seem like an ideal solution to the issue of namespace clutter. (and yes, infix operators are cool)
Any other thoughts?
How about defining a few common functions as polynomials? I'm not sure what this would be used for, but it sounds fun, and might be useful for something. e.g. something like polyexp = map inverse factorials polycos = skipaltsign True $ map inverse factorials where skipaltsign True (x:_:xs) = x : skipaltsign False xs skipaltsign False (x:_:xs) = -x : skipaltsign True xs -- David Roundy http://civet.berkeley.edu/droundy/
G'day. On Wed, May 07, 2003 at 11:34:28AM -0400, Matthew Donadio wrote:
One of the needs for a few of my DSP routines is support for functions over polynomials. The attached file is what I threw together.
Since this definetly has a broader scope than just me, I wanted to get some opionions on it.
Are you trying to write a general polynomial library, or just one which suits your purpose? Or, to put it another way, how many programs can you think of which would need both DSP code and non-DSP-related polynomial crunching? I would take the XP approach: Make a polynomial library which is powerful enough to do what you want with it and put it in your own namespace. If someone comes out with a more general polynomial library later which is suitable for your purpose, refactor your code then.
The big question here (in my mind) is how to represent polynomials. The most obvious way is as a list of the coefficients. They can also be represented as a list of the roots.
You can also represent them as sparse coefficients and as some combination of basis polynomials other than the "power polynomials". Then, of course, there's multivariate polynomials.
2. Are there any functions that are missing?
Yes, lots. Cheers, Andrew Bromage
participants (4)
-
Andrew J Bromage -
David Roundy -
Eray Ozkural -
Matthew Donadio