Re: modified residues() for matlab compatibility

[Ben Abbott]

On Tuesday, October 02, 2007, at 07:46AM, "Ben Abbott" <address@hidden> wrote:
>
>On Oct 1, 2007, at 4:21 PM, Ben Abbott wrote:
>>
>> On Monday, October 01, 2007, at 03:37PM, "David Bateman"  
>> <address@hidden> wrote:
>>> Ben Abbott wrote:
>>>> On Monday, October 01, 2007, at 10:42AM, "David Bateman"  
>>>> <address@hidden> wrote:
>>>>> Ben Abbott wrote:
>>>>>> I plan to run more test, and see if I can improve the agreement
>>>>>> (differs in the 9th decimal place). However, I thought it a  
>>>>>> good time
>>>>>> to solicit feedback, and participation in testing.
>>>>>>
>>>>>> If anyone has an application that puts residue.m through its  
>>>>>> paces,
>>>>>> I'd appreciate you taking a look.
>>>>>>
>>>>>> Also if anyone is up to checking the scripts for adherence to the
>>>>>> common coding practices of the Octave contributers, I'd  
>>>>>> appreciate any
>>>>>> feedback.
>>>>>>
>>>>> I haven't followed this conversation, but the code needs a  
>>>>> copyright and
>>>>> you have to apply that.. Also it needs a help string though I  
>>>>> imagine
>>>>> that can be taken from the existing residue.m. Could you resend  
>>>>> it with
>>>>> a GPL copyright to be absolutely clear that the code is under a GPL
>>>>>
>>>>> D.
>>>>
>>>> David, your comment confused me ... until I noticed I'd uploaded  
>>>> the *wrong* file :-(
>>>
>>> Ok.
>>>
>>>>
>>>> The correct residue.m is attached. In addition, I've attached a  
>>>> modified version of mpoles.m which uses the sortcom.m available  
>>>> from Octave-Forge.
>>>
>>> sortcom is a function in Octave in control/util. If its used by
>>> residue.m it should probably be moved to somewhere more generic.
>>>
>>>> I've done my best to put the texinfo stuff in. Its a bit painful  
>>>> for me since I haven't figured out a convenient method to debug  
>>>> it when there's a problem.
>>>
>>> Easy, start octave at type "help residue". If it doesn't give and  
>>> error
>>> the texinfo syntax is right. Also change the layout if needed
>>>
>>>>
>>>> I did not modify the copyright from the original residue file and  
>>>> just copied the same to mpoles. If I should modify the copyright  
>>>> to indicate my name, please let me know (not sure what the  
>>>> protocol is respecting that).
>>>
>>> What percentage of the residue.m to you estimate is yours? If its a
>>> significant majority of the code then its probably justified to  
>>> change
>>> the name to yours. If there is any code left from the previous  
>>> version,
>>> then you should remove the previous authors name though.
>>>
>>> D.
>>>
>>
>> For the most part, I just modified the texinfo part from the  
>> original. Maybe half of that is my contribution.
>>
>> Regarding the m-code, I kept, or modified slightly, about 20-30% of  
>> the original code for residue. For mpoles I tried to adapt some of  
>> the coding habits I observed in residue, but basically wrote that  
>> one myself.
>
>I've removed the call to 'sortcom'  from 'mpoles' and replaced it  
>with 'sort' which I just noticed handles complex numbers. I've also  
>modfied the copyright. The file is attached, and for comparison to  
>the prior upload the diff is below.
>
>1c1
>< # Copyright (C) 2007 Ben Abbott
>---
> > # Copyright (C) 1996, 1997 John W. Eaton
>27c27
>< ## This is a support function for 'residue'.
>---
> > ## This is a support function for 'residues'.
>46c46
>< ##   @result{} n' = [2,  5, 1, 4, 3]
>---
> > ##   @result{} n' = [2, 1, 5, 3, 4]
>101c101
><     [p,ordr] = sort(p);
>---
> >     [p,ordr] = sortcom(p,'mag');
>
>For 'residue', I've added a qualification that the routine has been  
>significantly modified.
>

opps :-(

I let an error get past me in residue.  It  wasn't in the prior version I 
posted ... it was the result of my tinkering in the hope of improving speed.

256c256
<   [multp, indx] = mpoles (p, toler, 1);
---
>   [multp, indx] = mpoles (p, toler, 0);

I've attached (what I hope) is a working version.

residue.m
Description: Binary data