[control-oo] unuseful files copied from legacy control package?

[Luca Favatella]

Hi, Lukas.


I noted you copied some files from the legacy control package into
your rewrite [0][1].

Are they needed for the rewrite? Did you change them?
If not, I think it is a good idea to remove them from the rewrite (at
the moment)
* not to have duplicated files here and there
* to semplify tracking dependencies between scripts (using grep...)


Cheers,
Luca Favatella



[0] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/inst/control/
[1] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/inst/ocst/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[paramaniac]

Hi Luca

Legacy files in [0] are the ported (*) ones, e.g. the lqr command. I  
modified lqr such that it accepts lqe designs, i. e. L = lqr (A', C'  
B*B', q)' In general, these function are intended for the user.  
Therefore, they're listed in the INDEX file.

(*) ported means that they accept the new system format and use only  
"official" functions from LTI Syncope internally.

Legacy files in [1] are not intended for the user (therefore the  
underscores in the function names), they are just for internal use in  
*one* specific function. I need __tzero__ and __zg* to calculate the  
zeros of a state-space model ([z, k] = zero (sys)). I reused the  
algorithm because I think it's better than what I would have written  
(the author, Prof. Hodel from Auburn University, published a paper  
about it :-). I made only some minor changes, e.g. sorting the results  
differently.

BTW: When coding new/porting old functions, please don't use functions  
from [1] internally. Use the "official" zero instead of __tzero__.  
This allows me to exchange algorithms quickly if needed, and all  
existing functions take benefit from it without any changes.

Maybe I should add a tag to each legacy file to simplify identification:
## Adapted-By: Lukas Reichlin
## Created: October 2009
## Version: 0.1

Please let me know if you have any further questions or suggestions.

Regards,
Lukas

> Hi, Lukas.
>
>
> I noted you copied some files from the legacy control package into
> your rewrite [0][1].
>
> Are they needed for the rewrite? Did you change them?
> If not, I think it is a good idea to remove them from the rewrite (at
> the moment)
> * not to have duplicated files here and there
> * to semplify tracking dependencies between scripts (using grep...)
>
>
> Cheers,
> Luca Favatella
>
>
>
> [0] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/inst/control/
> [1] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/inst/ocst/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Luca Favatella]

On 22/10/2009, Lukas Reichlin <lukas.reichlin@...> wrote:
[...]
> Legacy files in [0] are the ported (*) ones, e.g. the lqr command. I
[...]
> (*) ported means that they accept the new system format and use only
> "official" functions from LTI Syncope internally.

Great, you already ported some functions!

[...]
> Maybe I should add a tag to each legacy file to simplify identification:
> ## Adapted-By: Lukas Reichlin
> ## Created: October 2009
> ## Version: 0.1
>
> Please let me know if you have any further questions or suggestions.

Let's consider lyap.m [0]: it does not depend on the system format.
But you copied it [1] from the legacy package [2], adding
* 2 white spaces
* tag "Adapted-By" (even if it didn't need adaptation...)

This is what I'd like to avoid: having the same script copied in 2
places even if not needed.

I think functions not needing porting should stay only in the legacy
package and be improved there if needed, until the rewritten package
becomes the official package.
Keeping in the rewritten package a text file with the list of these
functions could also be useful.


Cheers,
Luca Favatella




[0] BTW, lyap is Scilab-compatible but not Matlab-compatible. I didn't
change it one year ago for backard compatibility concerns.

[1] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/inst/control/lyap.m?revision=6355

[2] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/control/inst/lyap.m?revision=6355

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[paramaniac]

On 22.10.2009, at 15:42, Luca Favatella wrote:

> On 22/10/2009, Lukas Reichlin <lukas.reichlin@...> wrote:
> [...]
>> Legacy files in [0] are the ported (*) ones, e.g. the lqr command. I
> [...]
>> (*) ported means that they accept the new system format and use only
>> "official" functions from LTI Syncope internally.
>
> Great, you already ported some functions!
>
> [...]
>> Maybe I should add a tag to each legacy file to simplify  
>> identification:
>> ## Adapted-By: Lukas Reichlin
>> ## Created: October 2009
>> ## Version: 0.1
>>
>> Please let me know if you have any further questions or suggestions.
>
> Let's consider lyap.m [0]: it does not depend on the system format.
> But you copied it [1] from the legacy package [2], adding
> * 2 white spaces
> * tag "Adapted-By" (even if it didn't need adaptation...)

Oops, that's really a stupid mistake :-) I have to admit that I did  
some quick "batch" adding for 19 files (revision 6355) and didn't pay  
attention to whether I really changed the code ...

>
> This is what I'd like to avoid: having the same script copied in 2
> places even if not needed.

I see your point.

>
> I think functions not needing porting should stay only in the legacy
> package and be improved there if needed, until the rewritten package
> becomes the official package.
> Keeping in the rewritten package a text file with the list of these
> functions could also be useful.
>

You are right.

Regards,
Lukas

>
> Cheers,
> Luca Favatella
>
>
>
>
> [0] BTW, lyap is Scilab-compatible but not Matlab-compatible. I didn't
> change it one year ago for backard compatibility concerns.
>
> [1] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/inst/control/lyap.m?revision=6355
>
> [2] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/control/inst/lyap.m?revision=6355

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[paramaniac]

I forgot to check with grep -r lyap ./
lyap is used by gram (which I *really* :-) ported), and this must have  
been the reason I copied the file to control-oo ...

Nevertheless, you are right that we should avoid having duplicate  
scripts in control-oo if not needed otherwise.

Regards,
Lukas

>
> Let's consider lyap.m [0]: it does not depend on the system format.
> But you copied it [1] from the legacy package [2], adding
> * 2 white spaces
> * tag "Adapted-By" (even if it didn't need adaptation...)
>
> This is what I'd like to avoid: having the same script copied in 2
> places even if not needed.
>
>
> [0] BTW, lyap is Scilab-compatible but not Matlab-compatible. I didn't
> change it one year ago for backard compatibility concerns.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Luca Favatella]

On 22/10/2009, Lukas Reichlin <lukas.reichlin@...> wrote:
> I forgot to check with grep -r lyap ./
> lyap is used by gram (which I *really* :-) ported), and this must have
> been the reason I copied the file to control-oo ...

Ok, thanks for the explanation.

Cheers,
Luca Favatella

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev