Re: Wavelet Denoising toolbox.

[Juan Pablo Carbajal]

On Wed, May 29, 2013 at 5:28 PM, "Peter L. Søndergaard"
<address@hidden> wrote:
> On 29-05-2013 15:59, Juan Pablo Carbajal wrote:
>>
>> On Wed, May 29, 2013 at 3:38 PM, Peter L. Soendergaard
>> <address@hidden> wrote:
>>>
>>> On 05/29/2013 03:17 PM, Juan Pablo Carbajal wrote:
>>>>
>>>> On Wed, May 29, 2013 at 9:14 AM, Peter L. Soendergaard
>>>> <address@hidden> wrote:
>>>>>
>>>>> Perhaps we can somehow coordinate so we avoid a duplication of efforts
>>>>
>>>> That sounds good, I hope you can do that.
>>>>
>>>> btw, it would be better if you provided a proper Octave package of
>>>> your toolbox. What are the chances of doing that?
>>>
>>> That depends on how much needs to be done. Some issues:
>>>
>>> 1) The main thing is the documentation, I cannot convert that to Octaves
>>> format, too much work has gone into structuring that nicely in another
>>> format (reStructuredText), and I would like to keep it in that format.
>>> Currently LTFAT comes in at around 300 functions, with a 180 page manual,
>>> http://ltfat.sourceforge.net/doc/ltfat.pdf
>>>
>>> 2) LTFAT is itself structured into directories, so it is already a
>>> collection of small "packages".
>>>
>>> 3) LTFAT is hosted on Sourceforge it a Git repository, and I would like
>>> it
>>> to stay there, as I can easily control who has write access, for instance
>>> if
>>> a ph.d. student needs to submit or cleanup a few files.
>>>
>>> If we can just create a package specification file that installs the
>>> whole
>>> toolbox, it would probably be doable, but I don't know if that is
>>> acceptable
>>> for Octave forge, or if LTFAT becomes to "alien" compared to the rest of
>>> the
>>> website.
>>>
>>> I might be able to create a script that converts reStructuredText to
>>> texinfo. Does texinfo supports Latex formulas, images and citations? If
>>> so,
>>> I can convert the TeX output. If not, I can convert the text output.
>>>
>>> btw.: We will be at the OctConf (just not registered yet).
>>>
>>> Cheers,
>>> Peter.
>>>
>>>
>>>
>>>
>>>
>>>
>> Great, we can discuss more details in the Conference then.
>> I would worry the least about the documentation. Of course that could
>> be a long term issue but I see no point, given that there is a manual,
>> on investing time on just changing the its format.
>>
>> What would be really cool is to give the package the PKG_* scripts,
>> NEWS and DESCRIPTION files needed by pkg to install the package
>> directly form the Octave prompt. This will also open the door of
>> Debian to LTFAT. We should try to see how much work does this imply.
>> The only issue I can foresee is the heavy mex dependence (Do you know
>> this could be interfaced naturally with Octave, without the need to go
>> through mex?).
>> The rest seems like the work of an afternoon, but I tend to be over
>> optimistic on these matters.
>
> We already have .oct interfaces for everything, so there is no mex issue.
> Internally, the LTFAT C code use the same convention for complex numbers ,
> so the Octave interfaces are cleaner and more efficient than the Matlab
> interfaces.
>
> We have a simple build system just using several different makefiles, have a
> look here:
>
> http://sourceforge.net/p/ltfat/code/ci/master/tree/
>
> The Octave interfaces are in /oct
> The Makefile for the C backend is src/Makefile_unix
> The Makefile for the oct interfaces is oct/Makefile_unix
>
> There are also mingw makefiles for Windows 64 bit and mac makefiles for max
> 64 bit.
>
> Cheers,
> Peter.
>
>
>

Ok, looks pretty easy then. I will add this to my TODO least, please
do remind me in OctConf if I froget about this. We could produce a pkg
compatible package in no time in one of the code sprints.