The patch tracker still looks to be down Sun Feb 7 @ 07:30 EST
Patch tracker was up again this evening. Savannah sometimes has its quirks (but not very often)
How important is it for Octave Code to follow multiple
versions of MATLAB?
I’d say just the latest releases, seems most practical to me. However I think the package maintainer’s opinion weighs in more than mine Probably best discussed in the patch tracker.
It is important to support the oldest Octave version the signal processing package supports.
<snip> … reproduces it inside its main function instead of
calling the package function. Are there style recommendations
for this technique?
Hmm, remarkable. But maybe it was done for performance, to circumvent overhead in the external hanning function? I have no idea.
In general I’m all in favor of eliminating duplicate code, even if (in this case) e.g. the existing hanning function would need to be adapted to mimic what the subfunction in pwelch does; if at all needed.
But again, in this case, I just don’t know.
What is the guidance for Octave function strict compatibility
with MATLAB? Is it an option to make an “improved” Octave function with
a different name then have the MATLAB compatible function call the
No need for other function names or wrapper functions. Octave should be able to run existing Matlab code, but not necessarily the other way round.
As to the coding process, it’s best to start with something simple but reliable and then gradually improve / extend the code step by step. Full Matlab compatibility in the sense of complete functionality in one fell swoop is often too ambitious.
spectrogram looks like a complex beast so this advice applies especially here I think
… collaborate with others … can someone else help with argument handling code …
Sure, TTBOMK that’s the way it usually works here, more or less.
Again, we are all volunteers each with different interests and skills (and available time), so it’ll depend on collaborators at hand. Please don’t be alarmed if the project stalls a bit now and then.
Are these sorts of questions best kept to the patch tracker?
This general discussion looks to be “at home” here, yes.
I’d say come up with a basic but functional skeleton function in the patch tracker that at least does one or two things properly and from there “we” can help you develop & finish it.
Hint: glance through some patch tracker reports to get a taste of what the process looks like (no two patch process submissions are the same)