[Octave-bug-tracker] [bug #31474] autocor.m & autocov.m are wrong

[Reginald Beardsley]

Follow-up Comment #6, bug #31474 (project octave):

John,

Not meant as an insult.  Curt yes.  I'd wasted much of a day already.  Please
remember, I didn't just complain.  I fixed it and provided a reference and a
test case.  I would have provided the test case at the start, but I thought
the issue was obvious.

I did not say it was a failure to understand basic math.  I said it was a
failure to understand "the math". It's a basic operation in signal processing
and the analysis of random data, but I would not describe it as "basic math". 
It may have arisen from excessive enthusiasm for programming or from problems
translating English language terminology into German.  The author's English is
certainly better than my German.  However, nothing changes the fact that the
functions were seriously wrong and that a quick inquiry w/ google found it had
been accurately reported long ago and another comparison showed it had not
been corrected in the most recent version of source I had.

For condescension, I plead guilty.  I got subjected to a "you must answer
this question even if the answer you give is wrong" interface.  Obviously the
person who coded that didn't consider that there are more operating systems
than are on the list.  I've worked w/ over a dozen flavors of Unix and another
dozen or so non-Unix operating systems.  I suggest adding "other" to the list
if you control it.  Even MVS is Posix compliant and should run Octave.  In any
case, combining pedanticism and ignorance will pretty much guarantee the same
response from me every time.

I'm actually much more concerned about the general direction that Octave has
taken over the last 5-10 years.  I don't particularly care about matching
Matlab syntax & semantics.  It's a nice convenience, but hardly of any real
consequence from my perspective.  I use Octave as a prototyping tool to verify
I understand the math before I implement a major code.  For me reliability is
paramount. A tool that forces me to devise test cases to verify the functions
I use is of no help.  That's the main reason not to code it myself.  The test
cases take considerable time.

I've still not been able to compile anything later than 2.1.73 w/ more than
partial success despite spending most of a day on the task on more than one
occasion.  I plan to try again soon while I still remember the issues I
encountered. The chain of dependencies on non-standard conforming language
features and other packages becomes very arduous, especially when autoconf
gets it wrong or the dependencies make different choices (e.g. 32 vs 64 bit). 
I could avoid the problem by firing up a Gnu/Linux machine, but I don't
particularly like Gnu/Linux.  There are too many gratuitous changes to old
programs that break things.  So I'd pretty much be trading one set of problems
for another.

I'm willing to endure some pretty arduous requirements to compile Octave if
it's reliable.  However, there's a lot of arcane math in it and that becomes a
concern if there is not a regression test suite to verify that they are
correct.  I could write tests for a significant portion, but nowhere near all
and it is a Herculean task as a whole.  Many years ago writing a test suite
for Octave was a major task.   Now it's mind boggling.  The only solution I
know of is to write a test case every time a new function is added.  I'm
facing the same issues w/ several other large, complex packages.  I don't have
a good answer.  It's a hard problem.  If you've got ideas, I'd like to discuss
them.

Have Fun!
Reg


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31474>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/