bugGNU Octave - Bugs: bug #60375, [octave forge] (signal) New...

 
 

bug #60375: [octave forge] (signal) New implementation of bilinear

Submitted by:  Tony Richardson <amrichardson>
Submitted on:  Sun 11 Apr 2021 07:26:29 PM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  None Assigned to:  None
Originator Name:  Tony Richardson Open/Closed:  Open
Release:  6.2.0 Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 12 Apr 2021 06:26:47 PM UTC, comment #1: 

Fixed a silly bug for the degenerate (but not uncommon) case where the numerator coefficient vector is of length one.

(file #51252)

Tony Richardson <amrichardson>
Sun 11 Apr 2021 07:26:29 PM UTC, original submission:  

I implemented the bilinear function by operating directly on the coefficients in the transfer function representation (num/den) instead of operating on the poles and zeros like the current bilinear function.  I called this implementation bilinear2 because it is not compatible with the current Octave bilinear function.

However, bilinear2 is compatible with the MATLAB bilinear function in terms of calling syntax.  All MATLAB options (prewarping/no prewarping) and call variations (transfer function, pole-zero, and state-space) are supported.  It also uses the sampling frequency as an input argument (like MATLAB) instead of the sampling time (current Octave bilinear) function.  The MATLAB implementation does appear to do the transformation in the pole-zero domain (like Octave bilinear) instead of directly on the coefficients.

Two demos are included ("demo bilinear2").  The demos are examples from the public MATLAB documentation for the MATLAB bilinear function and appear to match the MATLAB results very closely.

I'd have to do a lot more testing to determine whether doing the transform in the coefficient domain is more or less accurate than doing it in the zero-pole domain.  My guess is that it depends on what you start with.  If you are transforming a coefficient representation bilinear2 is more accurate, but if you are starting with a zero-pole representation bilinear would be.

Tony Richardson <amrichardson>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51252:  bilinear2.m added by amrichardson (6KiB - text/plain)
file #51246:  bilinear2.m added by amrichardson (6KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by amrichardson (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-04-12 amrichardson Attached File- => Added bilinear2.m, #51252
    2021-04-12 mmuetzel Carbon-CopyRemoved 102357 => -
    2021-04-12 mmuetzel SummaryNew implementation of bilinear for signal package => [octave forge] (signal) New implementation of bilinear
    2021-04-11 amrichardson Attached File- => Added bilinear2.m, #51246

    Back to the top


    Powered by Savane 3.6