Re: odepkg: odeset profile tests

[Carlo De Falco]

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 <address@hidden> 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