odepkg: odeset profile tests

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

odepkg: odeset profile tests

Jacopo Corno
Dear Carlo, dear Roberto,

here are the results of the execution time of tests I run after the c
implementation of the levenshtein comparison introduced by Roberto.

TEST ODESET WITH LEVENSHTEIN STRING COMPARISON

TEST 1: set many options with exact naming
TEST 2: set only one option with exact naming
TEST 3: set many options with many typos
TEST 4: set only one option with small typo

-------------------------------------------------------------------------------------------
|  TEST  |   levenshtein.m    |   levenshtein.cc   |   odeset old
version   |
-------------------------------------------------------------------------------------------
|    1      |      0.819225         |      0.066781       |
0.004404            |
|    2      |      0.030761         |      0.015593       | 0.006332    
        |
|    3      |      0.876063         |      0.062384       | (error)    
           |
|    4      |      0.037888         |      0.017068       | (error)      
          |
-------------------------------------------------------------------------------------------


Best regards,
Jacopo


On 28/11/2014 09:56, Carlo De Falco wrote:

> On 27 Nov 2014, at 16:40, Jacopo Corno <[hidden email]> wrote:
>
>> the performance of ode45 on it's own should not change with or without levenshtein. Only odeset calls it when setting the options before launching the solver.
>>
>> J
> OK, so rather than different simulations, on each row use a different set of options:
>
> test 1: set many options with exact naming
> test 2: set only one option with exact naming
> test 3: set many options with many typos
> test 4: set only one option with completely wrong name
> test 5: set only one option with small typo
>
> c.

--

Jacopo Corno M.Sc.
Technische Universität Darmstadt
Graduate School of Computational Engineering
Dolivostraße 15
64293 Darmstadt / Germany

Office: S4|10-232
Phone: +49 6151 16 - 76877
Email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Carlo de Falco-2
Hi Jacopo,

Please don't top post [1] when sending messages to the list,
here we prefer either interleaved [2] or bottom posting [3] here.

On 2 Dec 2014, at 11:14, Jacopo Corno <[hidden email]> wrote:

> Dear Carlo, dear Roberto,
>
> here are the results of the execution time of tests I run after the c implementation of the levenshtein comparison introduced by Roberto.
>
> TEST ODESET WITH LEVENSHTEIN STRING COMPARISON
>
> TEST 1: set many options with exact naming
> TEST 2: set only one option with exact naming
> TEST 3: set many options with many typos
> TEST 4: set only one option with small typo
>
> -------------------------------------------------------------------------------------------
> |  TEST  |   levenshtein.m    |   levenshtein.cc   |   odeset old version   |
> -------------------------------------------------------------------------------------------
> |    1      |      0.819225         |      0.066781       | 0.004404            |
> |    2      |      0.030761         |      0.015593       | 0.006332            |
> |    3      |      0.876063         |      0.062384       | (error)               |
> |    4      |      0.037888         |      0.017068       | (error)               |
> -------------------------------------------------------------------------------------------

The timing seems quite OK now, so I think it is reasonable to leave the leveneshtein distance computation in odeset.

Now the question is what to do with the levenshtein.cc function:

The final goal is to move odeset to core so no doubt this should go in core too.

I wonder whether this function is useful for odeset only (in which case it should be renamed by
adding a double underscore before/after the name to mark as internal function) or whether it
may be useful by itself...

Maybe it would be better if you could write a few lines to the list about what the levenshtein function does
and add a link to the code so that some core developer may help us decide whether it makes sense to have it in
core and where to put it.

In any case to go into core the function needs to adhere better to the coding standards, do I have
write access to your bitbucket repo to apply the changes? otherwise I'll just send you a diff.

You should also add a few tests and/or demos in the function source.

Finally, the current trend is to try to avoid DLD functions in core so you should probably consider
building this as a builtin function (udes DEFUN instead of DEFUN_DLD).


> Best regards,
> Jacopo

c.


[1] http://en.wikipedia.org/wiki/Posting_style#Top-posting
[2] http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
[3] http://en.wikipedia.org/wiki/Posting_style#Bottom-posting


Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Carlo de Falco-2
Hi,

On 2 Dec 2014, at 15:49, Carlo de Falco <[hidden email]> wrote:

> In any case to go into core the function needs to adhere better to the coding standards, do I have
> write access to your bitbucket repo to apply the changes? otherwise I'll just send you a diff.

Attached is my modified version of levenshtein.cc,
apart from some formatting the main changes are:

- add a copyright notice suitable for including in Octave core
- better check for consistency of input
- use "octave_idx_type" instead of "unsigned int" (less efficient but more portable)
- faster access to array elements
- add texinfo docstring

with this changes the function seems to run a bit faster on my system:

%% with levenshtein.cc
>> tic, opts = odeset ('AbsTol', 1e-5, ...
              'NormControl', 'on', ...
              'MaxNewtonIterations', 1e4, ...
              'MaxOrder', 4, ...
              'NewtonTol', 1e-2', ...
              'NonNegative', [1 3 5], ...
              'RelTol', 1e-5, ...
              'InitialStep', .1, ...
              'Refine', 1, ...
              'Vectorized', 'on'); toc
Elapsed time is 0.241296 seconds.

%% with levenshtein_new.cc
>> tic, opts = odeset ('AbsTol', 1e-5, ...
              'NormControl', 'on', ...
              'MaxNewtonIterations', 1e4, ...
              'MaxOrder', 4, ...
              'NewtonTol', 1e-2', ...
              'NonNegative', [1 3 5], ...
              'RelTol', 1e-5, ...
              'InitialStep', .1, ...
              'Refine', 1, ...
              'Vectorized', 'on'); toc
Elapsed time is 0.0917881 seconds.

I'm not sure these numbers are reliable though
as the test is quite fast anyway.

As I wrote off-list optimization of levenstein.cc
does not make much sense as the main bottleneck is
elsewhere, probably in this loop in fuzzy_logic.m :

 %# loop on every field of the list
  for i=1:1:fields_nb
    %# if the list is a cell_array of strings
    if(iscellstr(string_set))
      string2 = deblank(string_set{i}); % removing spaces at the end
    else
      %# if the list is a vector of strings
      string2 = deblank(string_set(i,:));  % removing spaces at the end
    end
    %# determining the distance by a call to levenshtein function
    values(i) = levenshtein_new (lower(string1),lower(string2),minimus); % not case sensitive
    minimus = min(minimus,values(i)); % updating the upper_bound to speedup the computation
  end

modifying levenshtein.cc to work with cell arrays of strings would probably
improve this.

I would suggest to re-run the comparison with my version of levenshtein.cc
to see if any further speedup is actually needed before spending any effort there
though.

Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
it is absolutely not acceptable, formatting, documentation and comments
(too many useless and annoyingly verbose comments don't make the code more readable)
all need a lot of improvement.

c.


levenshtein_new.cc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Carlo de Falco-2

On 2 Dec 2014, at 18:29, Carlo De Falco <[hidden email]> wrote:

> Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
> it is absolutely not acceptable, formatting, documentation and comments
> (too many useless and annoyingly verbose comments don't make the code more readable)
> all need a lot of improvement.

looking at other functions that should maybe go into core, there still lots
of style fixes to be done, for example:

- '%#' as comment should be '##' for indented comments at beginning of line,
  '#' for inline comments

- remove reduntant and annoyingle verbose comments.
 
  for example in <https://bitbucket.org/robs88/octave-odepkg/src/df11f2a32e4bc192ca6f2a3d22bead4085cbbfc7/inst/ode23.m?at=default#cl-330> :
 
   if (vmassdependence) %# constant mass matrices have already
     ...
   else                 %# if (vmassdependence == false)
     ...
   endif

  the comments beside 'if' and 'else' are not really required nor helpful.

  If the code is not clear enough, either make the code clearer or add the required
  info in the documentation.

  Only use inline comments when you are doing something very nonstandard or to point
  out something that should be fixed later.
 
- single- and double-quoted strings have different meaning in Octave, unless you really
  want to use single-quoted for a specific reason, prefer using double-quoted.

- use "!" instead of "~" for negation, leave a space between the negation operator and
  the negated quantity.

- break long lines

- leave a space before and after arithmetic operators

- leave a space after a ',' in argument lists.

HTH,
c.






Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Doug Stewart-4


On Wed, Dec 3, 2014 at 5:29 AM, Carlo De Falco <[hidden email]> wrote:

On 2 Dec 2014, at 18:29, Carlo De Falco <[hidden email]> wrote:

> Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
> it is absolutely not acceptable, formatting, documentation and comments
> (too many useless and annoyingly verbose comments don't make the code more readable)
> all need a lot of improvement.

looking at other functions that should maybe go into core, there still lots
of style fixes to be done, for example:

- '%#' as comment should be '##' for indented comments at beginning of line,
  '#' for inline comments

- remove reduntant and annoyingle verbose comments.

  for example in <https://bitbucket.org/robs88/octave-odepkg/src/df11f2a32e4bc192ca6f2a3d22bead4085cbbfc7/inst/ode23.m?at=default#cl-330> :

   if (vmassdependence) %# constant mass matrices have already
     ...
   else                 %# if (vmassdependence == false)
     ...
   endif

  the comments beside 'if' and 'else' are not really required nor helpful.

  If the code is not clear enough, either make the code clearer or add the required
  info in the documentation.

  Only use inline comments when you are doing something very nonstandard or to point
  out something that should be fixed later.

- single- and double-quoted strings have different meaning in Octave, unless you really
  want to use single-quoted for a specific reason, prefer using double-quoted.

- use "!" instead of "~" for negation, leave a space between the negation operator and
  the negated quantity.

- break long lines

- leave a space before and after arithmetic operators

- leave a space after a ',' in argument lists.

HTH,
c.







This is a job that I can do.
I am working on ode23.m unless someone else has started already.
Doug Dtewart 

--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Doug Stewart-4


On Wed, Dec 3, 2014 at 8:22 AM, Doug Stewart <[hidden email]> wrote:


On Wed, Dec 3, 2014 at 5:29 AM, Carlo De Falco <[hidden email]> wrote:

On 2 Dec 2014, at 18:29, Carlo De Falco <[hidden email]> wrote:

> Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
> it is absolutely not acceptable, formatting, documentation and comments
> (too many useless and annoyingly verbose comments don't make the code more readable)
> all need a lot of improvement.

looking at other functions that should maybe go into core, there still lots
of style fixes to be done, for example:

- '%#' as comment should be '##' for indented comments at beginning of line,
  '#' for inline comments

- remove reduntant and annoyingle verbose comments.

  for example in <https://bitbucket.org/robs88/octave-odepkg/src/df11f2a32e4bc192ca6f2a3d22bead4085cbbfc7/inst/ode23.m?at=default#cl-330> :

   if (vmassdependence) %# constant mass matrices have already
     ...
   else                 %# if (vmassdependence == false)
     ...
   endif

  the comments beside 'if' and 'else' are not really required nor helpful.

  If the code is not clear enough, either make the code clearer or add the required
  info in the documentation.

  Only use inline comments when you are doing something very nonstandard or to point
  out something that should be fixed later.

- single- and double-quoted strings have different meaning in Octave, unless you really
  want to use single-quoted for a specific reason, prefer using double-quoted.

- use "!" instead of "~" for negation, leave a space between the negation operator and
  the negated quantity.

- break long lines

- leave a space before and after arithmetic operators

- leave a space after a ',' in argument lists.

HTH,
c.







This is a job that I can do.
I am working on ode23.m unless someone else has started already.
Doug Dtewart 

-

1)  There are hundreds of changes to this file. do you want it as a big hg changset???  
2)  3 dots (...)  are used for line continuation, is this still the way we do it?
Doug
Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Carlo de Falco-2
Doug,

Thank you very much for this!

On 3 Dec 2014, at 15:24, Doug Stewart <[hidden email]> wrote:

> 1)  There are hundreds of changes to this file. do you want it as a big hg changset???  
that would be great, if it is too complicated just sending the modified file would also do.
Jacopo will then take care of merging that in the repo.

> 2)  3 dots (...)  are used for line continuation, is this still the way we do it?
yes, we used to have backslash too, but that is deprecated.

when the line is broken between parentheses no continuation is needed,
unless the parentheses indicate a vector, in which case a new line is equivalent
to a semicolon (end of row), so to break a line whithout ending the row one needs to
use '...'

> Doug
c.



Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Doug Stewart-4


On Wed, Dec 3, 2014 at 9:41 AM, Carlo De Falco <[hidden email]> wrote:
Doug,

Thank you very much for this!

On 3 Dec 2014, at 15:24, Doug Stewart <[hidden email]> wrote:

> 1)  There are hundreds of changes to this file. do you want it as a big hg changset???
that would be great, if it is too complicated just sending the modified file would also do.
Jacopo will then take care of merging that in the repo.

> 2)  3 dots (...)  are used for line continuation, is this still the way we do it?
yes, we used to have backslash too, but that is deprecated.

when the line is broken between parentheses no continuation is needed,
unless the parentheses indicate a vector, in which case a new line is equivalent
to a semicolon (end of row), so to break a line whithout ending the row one needs to
use '...'

> Doug
c.



Here is a patch that fixes the style but I haven't removed any comments yet.

It will take a while to read each comment and see if it is good or bad.
I like lots of comments so I might not be the best person to do this. I understand
 that some of the comments are redundant and should be removed. But I also find 
that when trying to help debugging some reported bugs, I find the lack of comments 
are big hindrance to my progress.

ode23.m still passes all tests for me.


363.patch (86K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Jacopo Corno

On 03/12/2014 16:45, Doug Stewart wrote:


On Wed, Dec 3, 2014 at 9:41 AM, Carlo De Falco <[hidden email]> wrote:
Doug,

Thank you very much for this!

On 3 Dec 2014, at 15:24, Doug Stewart <[hidden email]> wrote:

> 1)  There are hundreds of changes to this file. do you want it as a big hg changset???
that would be great, if it is too complicated just sending the modified file would also do.
Jacopo will then take care of merging that in the repo.

> 2)  3 dots (...)  are used for line continuation, is this still the way we do it?
yes, we used to have backslash too, but that is deprecated.

when the line is broken between parentheses no continuation is needed,
unless the parentheses indicate a vector, in which case a new line is equivalent
to a semicolon (end of row), so to break a line whithout ending the row one needs to
use '...'

> Doug
c.



Here is a patch that fixes the style but I haven't removed any comments yet.

It will take a while to read each comment and see if it is good or bad.
I like lots of comments so I might not be the best person to do this. I understand
 that some of the comments are redundant and should be removed. But I also find 
that when trying to help debugging some reported bugs, I find the lack of comments 
are big hindrance to my progress.

ode23.m still passes all tests for me.

Dear Doug,

unfortunately the ode23 file you modified is the old version present in odepkg (version 0.8.4 I believe) and not the current version modified by Roberto last year that is present on his repository [1].

Nevertheless a lot of you changes are still valid and I will apply them to the current version of the solver. So thanks for your help.

[1] https://bitbucket.org/robs88/octave-odepkg

Best regards,
Jacopo
-- 

Jacopo Corno M.Sc.
Technische Universität Darmstadt
Graduate School of Computational Engineering
Dolivostraße 15
64293 Darmstadt / Germany

Office: S4|10-232
Phone: +49 6151 16 - 76877
Email: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Jacopo Corno
In reply to this post by Carlo de Falco-2

On 02/12/2014 18:29, Carlo De Falco wrote:

> Hi,
>
> On 2 Dec 2014, at 15:49, Carlo de Falco <[hidden email]> wrote:
>
>> In any case to go into core the function needs to adhere better to the coding standards, do I have
>> write access to your bitbucket repo to apply the changes? otherwise I'll just send you a diff.
> Attached is my modified version of levenshtein.cc,
> apart from some formatting the main changes are:
>
> - add a copyright notice suitable for including in Octave core
> - better check for consistency of input
> - use "octave_idx_type" instead of "unsigned int" (less efficient but more portable)
> - faster access to array elements
> - add texinfo docstring
>
> with this changes the function seems to run a bit faster on my system:
>
> %% with levenshtein.cc
>>> tic, opts = odeset ('AbsTol', 1e-5, ...
>                'NormControl', 'on', ...
>                'MaxNewtonIterations', 1e4, ...
>                'MaxOrder', 4, ...
>                'NewtonTol', 1e-2', ...
>                'NonNegative', [1 3 5], ...
>                'RelTol', 1e-5, ...
>                'InitialStep', .1, ...
>                'Refine', 1, ...
>                'Vectorized', 'on'); toc
> Elapsed time is 0.241296 seconds.
>
> %% with levenshtein_new.cc
>>> tic, opts = odeset ('AbsTol', 1e-5, ...
>                'NormControl', 'on', ...
>                'MaxNewtonIterations', 1e4, ...
>                'MaxOrder', 4, ...
>                'NewtonTol', 1e-2', ...
>                'NonNegative', [1 3 5], ...
>                'RelTol', 1e-5, ...
>                'InitialStep', .1, ...
>                'Refine', 1, ...
>                'Vectorized', 'on'); toc
> Elapsed time is 0.0917881 seconds.
>
> I'm not sure these numbers are reliable though
> as the test is quite fast anyway.
>
> As I wrote off-list optimization of levenstein.cc
> does not make much sense as the main bottleneck is
> elsewhere, probably in this loop in fuzzy_logic.m :
>
>   %# loop on every field of the list
>    for i=1:1:fields_nb
>      %# if the list is a cell_array of strings
>      if(iscellstr(string_set))
>        string2 = deblank(string_set{i}); % removing spaces at the end
>      else
>        %# if the list is a vector of strings
>        string2 = deblank(string_set(i,:));  % removing spaces at the end
>      end
>      %# determining the distance by a call to levenshtein function
>      values(i) = levenshtein_new (lower(string1),lower(string2),minimus); % not case sensitive
>      minimus = min(minimus,values(i)); % updating the upper_bound to speedup the computation
>    end
>
> modifying levenshtein.cc to work with cell arrays of strings would probably
> improve this.
>
> I would suggest to re-run the comparison with my version of levenshtein.cc
> to see if any further speedup is actually needed before spending any effort there
> though.

these are the test run with your modifications.

TEST 1: set many options with exact naming
time : 0.058801
    #               Function Attr     Time (s)   Time (%) Calls
---------------------------------------------------------------------
   24          fuzzy_compare             0.019      35.73 10
    7                deblank             0.019      35.34 447
    3                 odeset             0.007      13.11 1
   38 ode_struct_value_check             0.001       2.11 1
   15                    max             0.001       2.03 447
   13                   find             0.001       1.48 457
   34            levenshtein             0.001       1.26 370


TEST 2: set only one option with exact naming
time : 0.015748
    #               Function Attr     Time (s)   Time (%) Calls
---------------------------------------------------------------------
    2                 odeset             0.006      41.00 1
    6                deblank             0.003      25.61 78
   23          fuzzy_compare             0.002      17.28 1
   37 ode_struct_value_check             0.001       6.46 1
   14                    max             0.000       1.54 78
   12                   find             0.000       1.03 79
   20         __fieldnames__             0.000       1.01 2



TEST 3: set many options with many typos
time : 0.063206
    #               Function Attr     Time (s)   Time (%) Calls
---------------------------------------------------------------------
   24          fuzzy_compare             0.021      36.66 10
    7                deblank             0.020      34.15 457
    3                 odeset             0.007      12.75 1
   42 ode_struct_value_check             0.001       1.96 1
   15                    max             0.001       1.94 457
   13                   find             0.001       1.50 467
   40                warning             0.001       1.18 10


TEST 4: set only one option with small typo
time : 0.017849
    #               Function Attr     Time (s)   Time (%) Calls
---------------------------------------------------------------------
    2                 odeset             0.007      42.70 1
    6                deblank             0.004      23.83 79
   23          fuzzy_compare             0.003      16.55 1
   41 ode_struct_value_check             0.001       6.00 1
   14                    max             0.000       1.62 79
   20         __fieldnames__             0.000       1.58 2
   12                   find             0.000       1.06 80


>
> Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
> it is absolutely not acceptable, formatting, documentation and comments
> (too many useless and annoyingly verbose comments don't make the code more readable)
> all need a lot of improvement.

I will take care of that.
>
> c.
>
Jacopo

--

Jacopo Corno M.Sc.
Technische Universität Darmstadt
Graduate School of Computational Engineering
Dolivostraße 15
64293 Darmstadt / Germany

Office: S4|10-232
Phone: +49 6151 16 - 76877
Email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Carlo de Falco-2

On 4 Dec 2014, at 10:07, Jacopo Corno <[hidden email]> wrote:

>>
>>
>> Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
>> it is absolutely not acceptable, formatting, documentation and comments
>> (too many useless and annoyingly verbose comments don't make the code more readable)
>> all need a lot of improvement.
>
> I will take care of that.
>>
>> c.
>>
> Jacopo
Hi,

I had a look at your changes to fuzzy_compare, it is getting better
but still not there.

I made changes in a clone of your repo but creating a pull request
does not seem to work. I contacted bitbucket support about it.
In the meantime, I attach the changesets below.

Main changes:
 
 - The copyright notice must be changed if you want this to go
   into core.

 - Long lines should be truncate in comments as well.

 - Comments should be written in imperative mood:
   
  - ## initializing the vector that will contain the distances
  - values = inf .* ones (fields_nb, 1);
  + ## initialize the vector that will contain the distances
  + values = inf .* ones (fields_nb, 1);

I did not remove comments, but I still think that some of them like
the one above are absolutely useless and redundant.

you can apply this changes to your repo with the command

 hg import <filename>

c.



open_2Xcmfjz5.txt (2K) Download Attachment
open_cEnA5pIH.txt (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: odepkg: odeset profile tests

Carlo de Falco-2

On 4 Dec 2014, at 11:55, Carlo De Falco <[hidden email]> wrote:

> On 4 Dec 2014, at 10:07, Jacopo Corno <[hidden email]> wrote:
>>>
>>>
>>> Furthermore, it seems fuzzy_compare would need to go into Octave core as well, but as it is now
>>> it is absolutely not acceptable, formatting, documentation and comments
>>> (too many useless and annoyingly verbose comments don't make the code more readable)
>>> all need a lot of improvement.
>>
>> I will take care of that.
>>>
>>> c.
>>>
>> Jacopo
>
> Hi,
>
> I had a look at your changes to fuzzy_compare, it is getting better
> but still not there.
>
> I made changes in a clone of your repo but creating a pull request
> does not seem to work. I contacted bitbucket support about it.
> In the meantime, I attach the changesets below.
>
> Main changes:
>
> - The copyright notice must be changed if you want this to go
>   into core.
>
> - Long lines should be truncate in comments as well.
>
> - Comments should be written in imperative mood:
>
>  - ## initializing the vector that will contain the distances
>  - values = inf .* ones (fields_nb, 1);
>  + ## initialize the vector that will contain the distances
>  + values = inf .* ones (fields_nb, 1);
>
> I did not remove comments, but I still think that some of them like
> the one above are absolutely useless and redundant.
>
> you can apply this changes to your repo with the command
>
> hg import <filename>
>
> c.


Hi,

Looking at your latest commits, there is one more thing to take care of.

You should not reference "odepkg" in the "seealso" part of the docstring
of a function that goes into core Octave because some users may not have the
odepkg package installed, so for them "help odepkg" will not work.

c.