Re: firls.m, part 2

[je suis]

> Well, a number of people are working on a number of their own
> projects, it appears that you were point person on this one.

I'm not sure how to translate this: "you were point person on this one".

> Well, this isn't a routine that I currently have an immediate
> technical use for, so the only inputs I'd have to test are the
> examples we've already gone through. With the modified expint, do they
> reproduce well? That was an interesting find and might warrant its own
> discussion. If there actually is a deficiency in expint, and your
> version improves it I think fixing the main one would be preferable to
> just having your fix as a subfunction to firls.
>
> I notice there are still no built-in tests at the end of the current
> version.  I'd recommend adding a bunch of those for basic input/output
> form checking as well as a few (simple if possible) expected numerical
> outputs. I think one of my past emails may have included some
> examples.

You're right, I'm sorry, I completely forgot about those. I'll modify
the script(s).

> I'm thinking the best thing might now be to create two separate
> submissions to the Octave bug tracker, one for firls (if you haven't
> done this already) and one for expint at bugs.octave.org. You can link
> the github archive and mention the dependency between the two bug
> reports.

Then I disregarded the etiquette, for which I apologize.

>  I've cc'd Mike, who is maintaining the signals package.  He may have
> suggestions on what else is needed for this function prior to
> inclusion. There is no single maintainer for the specfun package,
> which contains expint, but maybe he has suggestions there.

Thank you very much for your help so far, I'll try to continue on the
right path. I don't know if you got to that part, but the expint()
implementation is adapted from Numerical Recipes, I hope that doesn't
come against any licenses.

Hope to hear good news soon,
Vlad