octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #52758] [octave forge] (signal-1.3.2) fracshif


From: Klaus Braun
Subject: [Octave-bug-tracker] [bug #52758] [octave forge] (signal-1.3.2) fracshift(x, d) don't shift, if d is an integer
Date: Sun, 21 Jan 2018 12:36:46 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0

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

Sorry, but I think your last fix makes no sense.
It is absolutely useless to check if d is integer and then do exactly the same
costly calculation, which result is not used. Moreover a complicated h is
returned but was not used for the shift. h includes many values about 3e-17
which was not used for the returned y and therfore are inconsistent result.

The sense of the distinction whether d is integer is to have a short and quick
return in case of a simple (integer) input.

In case of d = integer you should bypass the complete filter generation and
filter calculation, e.g. in the manner I suggested.

In this case, when no filter was applied, I tink it could be ok to return []
as filter.
I have not much set me apart with the theory of fractional shifting and it
depends on what you want to do with the returned filter but maybe it could
make sense to return 1 as filter in case of integer shift.
To realize this, simply set h = 1 in the if branch of the integer case.
But I am doubtful in the case when d is integer and the caller provides h.
Should we return the 'provided' h or schould we return the 'used' 1 - or sould
we 'use' the provided h regardless if d is integer and do not the shortcut in
this case. I think the last case is the best and provides consistent results.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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