[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #51310] [octave forge] (signal) firls.m modifi

From: Vlad
Subject: [Octave-bug-tracker] [bug #51310] [octave forge] (signal) firls.m modification to include all 4 FIR types, Hilbert transformer, and differentiator
Date: Thu, 7 Mar 2019 11:08:00 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0

Follow-up Comment #15, bug #51310 (project octave):

It's not the categorization, it's the "wish" part, when I repeatedly said the
script behaves, by default, like Matlab, that is, that flag that bothers you,
is "yes", by default, unless explicitely added as "n" or "no"; it can be
completely ignored. It's in the description, too.

And I never said "I must have it", even if I did press it as a matter of
educational value, because if it really is not wanted, all you have to do is
say "We don't want that flag". I will remove it. I'll wonder why you bothered
saying that it's fine to add extra features, as long as the intended behaviour
is not affected, but I'll remove it. I currently wonder what is it about that
flag that hurts you, it's not like it breaks the Matlab compatibility, it
simply adds a new feature, which can be ignored, and is ignored by default.

I only made the GitHub address because it was suggested, in the mails, that it
may be easier to work with, but I never did work with it and it's quite
foreign to me.

The errors? Last time it was that it's a perfect match except the 1/f^2
weighting, which I showed it to be a wrong answer from Matlab. It was also
left, at your discretion, whether you want to emulate that mistake or you want
to provide the correct answer. I don't know how Matlab does it, I only suspect
(as mentioned), but if I have to make something willingly wrong, on the sole
reason that the numbers don't coincide, I refuse. My motor functions will not
let me. If they let you and you are fine with copying something wrong, go

As for the doc string, error reporting, unit test failures, no idea what you
mean but the only errors I see in "test firls" are where the errors range
between 1e-16..2e-13. I am willing to bet it's the expint() function. I could
lessen the tolerances, if that's not frowned upon.

Finish the bug "hopefully" with my help? The reasons that this has been going
on for two years are because you insisted I make a pristine script edition
when many others don't even come close (but I did it, anyway, and never
complained), and because last time (right before you released the last
version) you didn't pick the latest upload. I'll upload the latest version
here, with relaxed tolerances for the test suite, GitHub apparently won't let
me. But, please, let's not point fingers. I've made mistakes, you've made
mistakes, the purpose is to see this done.

(file #46454)

Additional Item Attachment:

File name: firls.m                        Size:40 KB


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]