octave-dev — GNU Octave developers' list

Re: [OctDev] Generating documentation

[Jordi G. H. <jo...@oc...>]

On 12 October 2012 09:23, JuanPi <aj...@gm...> wrote:
> Of course I can imagine it is a dauting task to integrate it as an
> optional toolkit/backend in octave. Who did fltk integration, how hard
> was it?

Bateman, jwe, Søren, and Shai were the major players in the fltk
integration, iirc. It was a lot of work. But this includes the OpenGL
backend. The fltk part is only a minor thing that just draws the
window decorations (buttons, borders, etc). The Qt backend (currently,
QtHandles) reuses the OpenGL plotting and uses Qt widgets instead.

- Jordi G. H.

Re: [OctDev] Generating documentation

[Søren H. <so...@ha...>]

On Oct 12, 2012, at 3:23 PM, JuanPi wrote:
> Oh, no! I've been there. I was thinking in something lower-level.
> Matplotlib uses Agg for many backends
> http://www.antigrain.com/

Ahh, okay.

> Of course I can imagine it is a dauting task to integrate it as an
> optional toolkit/backend in octave. Who did fltk integration, how hard
> was it?

Well it wasn't me, so I'm not an expert. I think the main task was writing the OpenGL renderer, which can be used with different backends. Basically, fltk only handles the actual windows, so changing the toolkit should be manageable (though still some work), but if you want to drop the OpenGL renderer you should expect to do quite some work.

Søren

Re: [OctDev] Generating documentation

[JuanPi <aj...@gm...>]

On Fri, Oct 12, 2012 at 3:20 PM, Søren Hauberg <so...@ha...> wrote:
>
> On Oct 12, 2012, at 3:12 PM, JuanPi wrote:
>
>> On Fri, Oct 12, 2012 at 1:18 PM, Søren Hauberg <so...@ha...> wrote:
>>>
>>> On Oct 12, 2012, at 4:22 AM, JuanPi wrote:
>>>> I noticed, while generating the documentation for Octave Forge, that
>>>> if graphics_toolkit == "fltk" no images are generated and the html is
>>>> broken.
>>>>
>>>> Does anybody knows a solution to this?
>>>
>>> I assume you are working with the 'generate_html' package. In principle this should work independently of which plotting system is being used, but I do remember having tons of stability problems with fltk backend some years back. The basic issue was that windows were opened and closed too fast, such that GLPS didn't have time to produce the output files. I am unsure if this problem was ever solved as I don't think anybody managed to figure out exactly what was happening.
>>>
>>> Søren
>>
>> Thank you Søren,
>>
>> Besides gnuplot and fltk, what other toolkit can be used?
>
> I don't think any other toolkits are possible at the moment. People are working towards using the Qt toolkit, but I don't think this is stable enough to be useful.
>
>> Is there a way (hypothetically) of integrating the one being used by
>> matplotlib?
>
> Yeah, sure you can write such code. I figure you can write a python server that calls matplotlib and talk to that server from Octave. But that would give you a solution similar to using gnuplot, so that might be a troublesome approach. But I'm not sure, I've been thinking about this approach myself…
>
> Søren
>

Søren
Oh, no! I've been there. I was thinking in something lower-level.
Matplotlib uses Agg for many backends
http://www.antigrain.com/

Of course I can imagine it is a dauting task to integrate it as an
optional toolkit/backend in octave. Who did fltk integration, how hard
was it?

-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Generating documentation

[Søren H. <so...@ha...>]

On Oct 12, 2012, at 3:12 PM, JuanPi wrote:

> On Fri, Oct 12, 2012 at 1:18 PM, Søren Hauberg <so...@ha...> wrote:
>> 
>> On Oct 12, 2012, at 4:22 AM, JuanPi wrote:
>>> I noticed, while generating the documentation for Octave Forge, that
>>> if graphics_toolkit == "fltk" no images are generated and the html is
>>> broken.
>>> 
>>> Does anybody knows a solution to this?
>> 
>> I assume you are working with the 'generate_html' package. In principle this should work independently of which plotting system is being used, but I do remember having tons of stability problems with fltk backend some years back. The basic issue was that windows were opened and closed too fast, such that GLPS didn't have time to produce the output files. I am unsure if this problem was ever solved as I don't think anybody managed to figure out exactly what was happening.
>> 
>> Søren
> 
> Thank you Søren,
> 
> Besides gnuplot and fltk, what other toolkit can be used?

I don't think any other toolkits are possible at the moment. People are working towards using the Qt toolkit, but I don't think this is stable enough to be useful.

> Is there a way (hypothetically) of integrating the one being used by
> matplotlib?

Yeah, sure you can write such code. I figure you can write a python server that calls matplotlib and talk to that server from Octave. But that would give you a solution similar to using gnuplot, so that might be a troublesome approach. But I'm not sure, I've been thinking about this approach myself…

Søren

Re: [OctDev] Generating documentation

[JuanPi <aj...@gm...>]

On Fri, Oct 12, 2012 at 3:12 PM, JuanPi <aj...@gm...> wrote:
> On Fri, Oct 12, 2012 at 1:18 PM, Søren Hauberg <so...@ha...> wrote:
>>
>> On Oct 12, 2012, at 4:22 AM, JuanPi wrote:
>>> I noticed, while generating the documentation for Octave Forge, that
>>> if graphics_toolkit == "fltk" no images are generated and the html is
>>> broken.
>>>
>>> Does anybody knows a solution to this?
>>
>> I assume you are working with the 'generate_html' package. In principle this should work independently of which plotting system is being used, but I do remember having tons of stability problems with fltk backend some years back. The basic issue was that windows were opened and closed too fast, such that GLPS didn't have time to produce the output files. I am unsure if this problem was ever solved as I don't think anybody managed to figure out exactly what was happening.
>>
>> Søren
>
> Thank you Søren,
>
> Besides gnuplot and fltk, what other toolkit can be used?
>
> Is there a way (hypothetically) of integrating the one being used by
> matplotlib?
>
> --
> JuanPi Carbajal
> -----
> "It is one thing not to be able to perform a certain feat, but quite
> another to prove that it cannot be done." - Henry Ernest Dudeney
> -----
> http://ailab.ifi.uzh.ch/carbajal/

btw, the table of backends is here
http://matplotlib.org/faq/usage_faq.html

-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Generating documentation

[JuanPi <aj...@gm...>]

On Fri, Oct 12, 2012 at 1:18 PM, Søren Hauberg <so...@ha...> wrote:
>
> On Oct 12, 2012, at 4:22 AM, JuanPi wrote:
>> I noticed, while generating the documentation for Octave Forge, that
>> if graphics_toolkit == "fltk" no images are generated and the html is
>> broken.
>>
>> Does anybody knows a solution to this?
>
> I assume you are working with the 'generate_html' package. In principle this should work independently of which plotting system is being used, but I do remember having tons of stability problems with fltk backend some years back. The basic issue was that windows were opened and closed too fast, such that GLPS didn't have time to produce the output files. I am unsure if this problem was ever solved as I don't think anybody managed to figure out exactly what was happening.
>
> Søren

Thank you Søren,

Besides gnuplot and fltk, what other toolkit can be used?

Is there a way (hypothetically) of integrating the one being used by
matplotlib?

-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] geometry 1.6.0 released

[JuanPi <aj...@gm...>]

On Fri, Oct 12, 2012 at 9:40 AM, c. <kin...@ti...> wrote:
>
> On 12 Oct 2012, at 09:17, c. wrote:
>
>> Hi,
>>
>> On 12 Oct 2012, at 05:02, JuanPi wrote:
>>
>>> Hi,
>>>
>>> I have uploaded geometry 1.6.0 to the server
>>> https://sourceforge.net/p/octave/package-releases/6/
>>> https://sourceforge.net/p/octave/package-releases/5/
>>>
>>> NEWS
>>> https://sourceforge.net/p/octave/code/11242/tree/trunk/octave-forge/main/geometry/NEWS
>>>
>>> If everything is OK please upload.
>>>
>> I just checked in this small fix for a bug I had caused myself:
>>
>> Index: distancePointPolyline.m
>> ===================================================================
>> --- distancePointPolyline.m   (revision 11242)
>> +++ distancePointPolyline.m   (working copy)
>> @@ -48,6 +48,8 @@
>>   # allocate memory for result
>>   minDist = inf * ones(Np, 1);
>>
>> +  ## construct the set of edges
>> +  edges = [poly(1:end-1, :) poly(2:end, :)];
>>
>>   ## compute distance between current each point and all edges
>>   dist = distancePointEdge(point, edges);
>>
>> Is it too late to include this in the release?
>>
>>> BTW, several figures are missing in the documentation because they
>>> can't be created with gnuplot. Currently only fltk plots them, but the
>>> output of ftlk is not added to the generated html.
>
>
> I tried generating the html files with Octave 3.6 and it seems to work, so the problem is caused by something in the development versio.
> For your convenience I attach release files I re-created including fix to the "SVN" link in navigation bar and the bugfix mentioned above.
>
>>> --
>>> JuanPi Carbajal
>>> -----
> c.

Thank you Carlo!

I was using 3.6.3 the latest release, not devel. I will check if the
stable branch also doesn't print the fltk figures.

@Carnë: How shall I proceed? Shall I put this files in the sf server?


-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Function shaperead for octave

[Juan P. C. <car...@if...>]

On Fri, Oct 12, 2012 at 10:58 AM, Alain Foehn <ala...@gm...> wrote:
> Hey !
> Sorry for the delay of my answer.
> I will study a bit more the package I found and then contact the owner to
> see if we can integrate it under GPL compatible licence to future Octave
> versions.
> I'll keep you informed when there is something new.
> Thanks for your support !
> Alain
>
>
> Le 04.10.2012 22:35, Juan Pablo Carbajal a écrit :
>
>> On Thu, Oct 4, 2012 at 10:28 PM, Juan Pablo Carbajal
>> <car...@if...> wrote:
>>>
>>> On Thu, Oct 4, 2012 at 9:29 PM, Alain Foehn <ala...@gm...>
>>> wrote:
>>>>
>>>> Hey all,
>>>> Thanks for your support and your quick answers this afternoon.
>>>> With further investigations, I found a package of functions for Matlab
>>>> working also under Octave having a function m_shaperead that does almost
>>>> what I am looking for. Just outputs are slightly different, but this
>>>> function is of great help. The package is available on
>>>>
>>>> http://www2.ocgy.ubc.ca/~rich/map.html
>>>>
>>>> I think it would be a good thing to have such a function available in a
>>>> "official" package for octave. I don't know the procedure for such an
>>>> addition, mostly with a function written by someone else. I think some
>>>> other
>>>> functions could also be added to the mapping package of octave and would
>>>> reinforce Octave strength in GIS field (I am a new engineer in a Alpine
>>>> environment research centre and trying to show how Octave could be a
>>>> good
>>>> replacement to Matlab, so such arguments are welcome...).
>>>> I will probably work on it next week a bit. Would you be interested by
>>>> the
>>>> modified version (I had some warnings of "matlab-looking syntax" or
>>>> something like when I did tests today).
>>>> Thanks a lot again and greetings,
>>>> Alain
>>>
>>> Hi Alain,
>>>
>>> Great job! Sadly the code is proprietary and cannot be distributed
>>> with GNU Octave unless we get the owner to release under a GPL
>>> compatible license.
>>>
>>> The procedure is as follows. Just write an e-mail to the owner of the
>>> package explaining our needs. Read these examples that I have send in
>>> the past:
>>>
>>> http://wiki.octave.org/Asking_for_package_to_be_release_under_GPL:_exmaples
>>>
>>> Use them as templates if you want. I particularly like the ones I sent
>>> to the Non-negative matrix factorization people. Do not forget to add
>>> the OctaveForge mailing list (oct...@li...) in the
>>> CC.
>>>
>>> Once we have the package under GPL we can start the port.
>>>
>>> Thank you!
>>>
>>> --
>>> M. Sc. Juan Pablo Carbajal
>>> -----
>>> PhD Student
>>> University of Zürich
>>> http://ailab.ifi.uzh.ch/carbajal/
>>
>> I am adding José to the list of e-mails. He is our mapping expert ;)
>>
>> @José: What do you think of this package?
>> http://www2.ocgy.ubc.ca/~rich/map.html Does it complement octPROJ
>> nicely?
>>
>>
>

Alain,

Excellent news!

Please do hesitate to ask for questions/help (well... asking for it
wont hurt anybody ;) )

Please, send future e-mails on this subject to oct...@li...


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Broken link on OF website

[Juan P. C. <car...@if...>]

On Fri, Oct 12, 2012 at 9:02 AM, c. <car...@gm...> wrote:
> The "SVN" link in the navigation bar on all Octave-forge points to:
>
> http://sourceforge.net/svn/?group_id=2888
>
> the correct link has now changed to
>
> https://sourceforge.net/p/octave/code
>
> The patch below (which I just checked in) will fix the link in the next package releases, if
>
> - a new release of generate_html is made
>
> - all packages a released anew
>
> - html files are generated for each package with
>   the latest version of generate_html
>
> This sounds like a task for a code-sprint, should we add it to the pkg.m code-sprint?
>
> c.
>
>
>
> Index: get_html_options.m
> ===================================================================
> --- get_html_options.m  (revision 11242)
> +++ get_html_options.m  (working copy)
> @@ -92,7 +92,7 @@
>   <a href=\"%rootbugs.html\" class=\"menu\">Bugs</a> &middot;\n\
>   <a href=\"%rootarchive.html\" class=\"menu\">Mailing Lists</a> &middot;\n\
>   <a href=\"%rootlinks.html\" class=\"menu\">Links</a> &middot;\n\
> - <a href=\"http://sourceforge.net/svn/?group_id=2888\" class=\"menu\">SVN</a>\n\
> + <a href=\"https://sourceforge.net/p/octave/code\" class=\"menu\">SVN</a>\n\
>  \n\
>          </td>\n\
>        </tr>\n\
>

Definitely!


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Generating documentation

[Søren H. <so...@ha...>]

On Oct 12, 2012, at 4:22 AM, JuanPi wrote:
> I noticed, while generating the documentation for Octave Forge, that
> if graphics_toolkit == "fltk" no images are generated and the html is
> broken.
> 
> Does anybody knows a solution to this?

I assume you are working with the 'generate_html' package. In principle this should work independently of which plotting system is being used, but I do remember having tons of stability problems with fltk backend some years back. The basic issue was that windows were opened and closed too fast, such that GLPS didn't have time to produce the output files. I am unsure if this problem was ever solved as I don't think anybody managed to figure out exactly what was happening.

Søren

Re: [OctDev] finishing up new release of image package

[Kris T. <kri...@gm...>]

> On 6 October 2012 20:17, Carnë Draug <car...@gm...>
> wrote:
> > On 1 October 2012 17:34, Kris Thielemans <kri...@gm...>
> wrote:
> >> From: Jordi Gutiérrez Hermoso
> >>> Sent: 01 October 2012 15:27
> >>>
> >>> On 1 October 2012 10:18, Kris Thielemans < > wrote:
> >>> > Why not use fall back to boost unordered_map for (old) clang? At
least
> the
> >>> user can then install boost.
> >>>
> >>> Sure, this is fine too. I suppose I'll have to write an autoconf
> >>> script now... Or would you do it?
> >>
> >>
> >> You got me there :-;
> >>
> >> Unfortunately, my knowledge of autoconf is close to zero. I did find
> >>
> http://code.google.com/p/carve/source/browse/configure.ac?name=rev-
> 1.6
> >> which is from a GPL project. Maybe somebody can use this as starting
> point...
> >
> > Hi Kris
> >
> > I also don't know autoconf to fix this. Are you able to submit a patch
> > to fix this? Or able to convince someone to fix it for you?
> >
> > About all the other warnings they are all in Octave core and have
> > already been fixed in dev. There's nothing I can do about them.
> >
> > Carnë
> 
> Hi Kris
> 
> are you planning on fixing this? I'll be releasing the new version
> this weekend if not.
> 
> Carnë

Hi Carnë

Apologies but I don't have the time for this at least until December,
especially as it'd take me a lot of effort to learn enough about autoconf to
get it to work. 

All the best 
Kris

Re: [OctDev] geometry 1.6.0 released

[c. <kin...@ti...>]

On 12 Oct 2012, at 09:17, c. wrote:

> Hi,
> 
> On 12 Oct 2012, at 05:02, JuanPi wrote:
> 
>> Hi,
>> 
>> I have uploaded geometry 1.6.0 to the server
>> https://sourceforge.net/p/octave/package-releases/6/
>> https://sourceforge.net/p/octave/package-releases/5/
>> 
>> NEWS
>> https://sourceforge.net/p/octave/code/11242/tree/trunk/octave-forge/main/geometry/NEWS
>> 
>> If everything is OK please upload.
>> 
> I just checked in this small fix for a bug I had caused myself:
> 
> Index: distancePointPolyline.m
> ===================================================================
> --- distancePointPolyline.m	(revision 11242)
> +++ distancePointPolyline.m	(working copy)
> @@ -48,6 +48,8 @@
>   # allocate memory for result
>   minDist = inf * ones(Np, 1);
> 
> +  ## construct the set of edges
> +  edges = [poly(1:end-1, :) poly(2:end, :)];
> 
>   ## compute distance between current each point and all edges
>   dist = distancePointEdge(point, edges);
> 
> Is it too late to include this in the release?
> 
>> BTW, several figures are missing in the documentation because they
>> can't be created with gnuplot. Currently only fltk plots them, but the
>> output of ftlk is not added to the generated html.


I tried generating the html files with Octave 3.6 and it seems to work, so the problem is caused by something in the development versio.
For your convenience I attach release files I re-created including fix to the "SVN" link in navigation bar and the bugfix mentioned above.

>> -- 
>> JuanPi Carbajal
>> -----
c.

Re: [OctDev] geometry 1.6.0 released

[c. <car...@gm...>]

Hi,

On 12 Oct 2012, at 05:02, JuanPi wrote:

> Hi,
> 
> I have uploaded geometry 1.6.0 to the server
> https://sourceforge.net/p/octave/package-releases/6/
> https://sourceforge.net/p/octave/package-releases/5/
> 
> NEWS
> https://sourceforge.net/p/octave/code/11242/tree/trunk/octave-forge/main/geometry/NEWS
> 
> If everything is OK please upload.
> 
I just checked in this small fix for a bug I had caused myself:

Index: distancePointPolyline.m
===================================================================
--- distancePointPolyline.m	(revision 11242)
+++ distancePointPolyline.m	(working copy)
@@ -48,6 +48,8 @@
   # allocate memory for result
   minDist = inf * ones(Np, 1);
 
+  ## construct the set of edges
+  edges = [poly(1:end-1, :) poly(2:end, :)];
 
   ## compute distance between current each point and all edges
   dist = distancePointEdge(point, edges);

Is it too late to include this in the release?

> BTW, several figures are missing in the documentation because they
> can't be created with gnuplot. Currently only fltk plots them, but the
> output of ftlk is not added to the generated html.
> 
> -- 
> JuanPi Carbajal
> -----
c.

[OctDev] Broken link on OF website

[c. <car...@gm...>]

The "SVN" link in the navigation bar on all Octave-forge points to:

http://sourceforge.net/svn/?group_id=2888

the correct link has now changed to

https://sourceforge.net/p/octave/code

The patch below (which I just checked in) will fix the link in the next package releases, if 

- a new release of generate_html is made

- all packages a released anew

- html files are generated for each package with 
  the latest version of generate_html
	
This sounds like a task for a code-sprint, should we add it to the pkg.m code-sprint?

c.



Index: get_html_options.m
===================================================================
--- get_html_options.m	(revision 11242)
+++ get_html_options.m	(working copy)
@@ -92,7 +92,7 @@
  <a href=\"%rootbugs.html\" class=\"menu\">Bugs</a> &middot;\n\
  <a href=\"%rootarchive.html\" class=\"menu\">Mailing Lists</a> &middot;\n\
  <a href=\"%rootlinks.html\" class=\"menu\">Links</a> &middot;\n\
- <a href=\"http://sourceforge.net/svn/?group_id=2888\" class=\"menu\">SVN</a>\n\
+ <a href=\"https://sourceforge.net/p/octave/code\" class=\"menu\">SVN</a>\n\
 \n\
         </td>\n\
       </tr>\n\

[OctDev] [bug #37508] fminsearch misses in deconvolving 2 gaussian peaks

[Rik <INV...@gn...>]

Update of bug #37508 (project octave):

                  Status:                    None => Octave Forge           


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37508>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[OctDev] geometry 1.6.0 released

[JuanPi <aj...@gm...>]

Hi,

I have uploaded geometry 1.6.0 to the server
https://sourceforge.net/p/octave/package-releases/6/
https://sourceforge.net/p/octave/package-releases/5/

NEWS
https://sourceforge.net/p/octave/code/11242/tree/trunk/octave-forge/main/geometry/NEWS

If everything is OK please upload.

BTW, several figures are missing in the documentation because they
can't be created with gnuplot. Currently only fltk plots them, but the
output of ftlk is not added to the generated html.

-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] Generating documentation

[JuanPi <aj...@gm...>]

Hi all,

I noticed, while generating the documentation for Octave Forge, that
if graphics_toolkit == "fltk" no images are generated and the html is
broken.

Does anybody knows a solution to this?

Thanks

-- 
JuanPi Carbajal
-----
"It is one thing not to be able to perform a certain feat, but quite
another to prove that it cannot be done." - Henry Ernest Dudeney
-----
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] finishing up new release of image package

[Carnë D. <car...@gm...>]

On 6 October 2012 20:17, Carnë Draug <car...@gm...> wrote:
> On 1 October 2012 17:34, Kris Thielemans <kri...@gm...> wrote:
>> From: Jordi Gutiérrez Hermoso
>>> Sent: 01 October 2012 15:27
>>>
>>> On 1 October 2012 10:18, Kris Thielemans < > wrote:
>>> > Why not use fall back to boost unordered_map for (old) clang? At least the
>>> user can then install boost.
>>>
>>> Sure, this is fine too. I suppose I'll have to write an autoconf
>>> script now... Or would you do it?
>>
>>
>> You got me there :-;
>>
>> Unfortunately, my knowledge of autoconf is close to zero. I did find
>> http://code.google.com/p/carve/source/browse/configure.ac?name=rev-1.6
>> which is from a GPL project. Maybe somebody can use this as starting point...
>
> Hi Kris
>
> I also don't know autoconf to fix this. Are you able to submit a patch
> to fix this? Or able to convince someone to fix it for you?
>
> About all the other warnings they are all in Octave core and have
> already been fixed in dev. There's nothing I can do about them.
>
> Carnë

Hi Kris

are you planning on fixing this? I'll be releasing the new version
this weekend if not.

Carnë

Re: [OctDev] [Dr Oliver Woodford MA MEng DPhil] Your m-Files packages (real2rgb, etc)

[Juan P. C. <car...@if...>]

Dear Oliver,

Thank you very much!

I will start the port asap. Please check the Image package[1], If you
think your functions on image processing fit there, we will very happy
to add them.

Thanks again!

Regards,

Juan Pablo

[1] http://octave.sourceforge.net/image/overview.html

On Thu, Oct 11, 2012 at 10:53 PM, Oliver Woodford
<o.j...@ca...> wrote:
> Dear Juan Pablo
>
> I am very happy to contribute my code to your project under a GPLv3
> license. Please find the real2rgb code attached. Please let me know if
> you want to include any other packages of mine.
>
> Kind regards,
> Oliver
>
> On 11 October 2012 07:38,  <car...@if...> wrote:
>> Juan Pablo Carbajal  sent a message using the contact form at
>> http://www.wolfson.cam.ac.uk/.
>>
>> Dear Oliver Woodford,
>>
>> My name is Juan Pablo Carbajal, I am developer at Octave-Forge[1] a
>> sibling project of GNU/Octave. I have downloaded your package real2rgb from
>> the Matlab file exchange and I find it
>> very useful.
>> Would you like to contribute it to Octave-Forge? I know licensing issues are
>> difficult topics and therefore I approach you with utter respect.
>>
>> If you accept this invitation to contribute code to Octave-Forge, I can
>> offer
>> you the following
>> - You will be properly credited and your papers will be linked as well.
>> - Maintenance of your function, test and demos will be taken over by the
>> Octave and Octave-forge community. Of course you can continue contributing,
>> and we will very happy to have you among us. I will also
>> let you know of any bug report we get from the users.
>> - I will take care of porting (code formatting, demos and test).
>> - You function will be directly downloaded and installed from an
>> Octave prompt (assuming it is packed inside real2rgb package):
>>  >pkg -forge install real2rgb
>>
>> The only thing that you need to do is to release your code under GPLv3 (we
>> like this one :D ) or any license compatible with them, e.g. FreeBSD. I
>> cannot use the downloaded the packages from the Matlab file exchange because
>> it will be a violation of their "Terms of Use" (that code can be used only
>> in
>> Mathworks products). You need only to let me know that you allow me to
>> redistribute your code under your free license of choice, I will
>> take care of adding the header to each file of your package.
>>
>> In case you are interested, I can tell you about successful experiences of
>> other researches contributing their work. For example the matGeom
>> community[2] released under GPLv3 so that Octave-forge can mirror they
>> package[3], since the package have enjoyed several new contributions and
>> code
>> optimization. A group form the technical
>> university of Denmark[4] working on nonnegative matrix factorization also
>> allowed us to redistribute their package under GPLv3. Biomechanics &
>> Neurosciences researchers[5] have also changed their license to GPLv3 to
>> allow us to produce packages out of their excellent algorithms.
>>
>> We have no other objective but to offer a truly free platform for the
>> exchange of our research. I hope you join us!
>>
>> If you have any question or comments, please let me know without hesitation.
>>
>> Thank you very much for your excellent code!
>>
>> Regards,
>>
>> Juan Pablo Carbajal
>>
>> [1] http://octave.sourceforge.net/
>> [2] http://sourceforge.net/apps/mediawiki/matgeom/index.php?title=Main_Page
>> [3] http://www.octave.org/wiki/index.php?title=Geometry_package
>> [4] http://cogsys.imm.dtu.dk/toolbox/nmf/index.html
>> [5]
>> http://sites.google.com/site/systemsneurosciencegroup/people/stewart-heitmann
>>



-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] is octave good for video processing?

[NAMITHA M. <nam...@gm...>]

sir,
i m new in using LINUX platform.
i m using UBUNTU 12.04 version.
i want to do real time object tracking using kalman filter in linux. Is
octave good for video processing.?
i can use the recorded video too,,,
I installed GNU octave via ubuntu sotware centre. what is the next step to
do for compiling video in octave..
i tried scilab software... bt it is not installing propperly...???

Re: [OctDev] Test failures due to tolerance in fftfilt.m

[Ed M. <ee...@gm...>]

On Wed, Oct 10, 2012 at 1:11 AM, c. <car...@gm...> wrote:

>
> On 10 Oct 2012, at 09:16, Daniel J Sebald wrote:
>
> >> I propose fixing this test by replacing the tolerance eps with something
> >> like 2*eps*norm(z)
>
> FYI this could be expressed as
>
> 2 * eps (z)
>
> from the help text for eps () :
>
> "Given a single argument X, return the distance between X and the next
> largest value"
>
> c.


Thanks, Carlos, I wasn't aware of this capability.  I thought it was just
what I needed until I
tried it on a vector, expecting something like eps(z) = eps*norm(z) but
what I get is eps(z(1)).
Is that the intended behavior?

-- 
Ed Meyer

Re: [OctDev] Test failures due to tolerance in fftfilt.m

[c. <car...@gm...>]

On 10 Oct 2012, at 09:16, Daniel J Sebald wrote:

>> I propose fixing this test by replacing the tolerance eps with something
>> like 2*eps*norm(z)

FYI this could be expressed as 

2 * eps (z)

from the help text for eps () :

"Given a single argument X, return the distance between X and the next largest value"

c.

Re: [OctDev] Test failures due to tolerance in fftfilt.m

[Daniel J S. <dan...@ie...>]

On 10/09/2012 07:49 PM, Ed Meyer wrote:
>
>
> On Fri, Sep 7, 2012 at 2:12 PM, Daniel J Sebald <dan...@ie...
> <mailto:dan...@ie...>> wrote:
>
>     On 09/06/2012 02:59 PM, Daniel J Sebald wrote:
>
>         I'll toss this one to Ed and Rik, since we were just talking about
>         precision issues for svds test failures...
>
>         I checked the current state of tests and found this failure:
>
>                             processing
>                             /usr/local/src/octave/octave/__octave/scripts/signal/fftfilt.__m
>
>         ***** test
>
>
>     There is a bit more to this, and I've put a patch on Savannah:
>
>     https://savannah.gnu.org/bugs/__index.php?37297
>     <https://savannah.gnu.org/bugs/index.php?37297>
>
>     The routine will round the output if the inputs are integers and
>     will truncate the imaginary component if both inputs are real.  That
>     seems fair, I suppose.  (I do wonder though if there should be an
>     option to remove this behavior because some might not want such a
>     thing.  Any thoughts maintainers or OctDev?)  I've extended that
>     concept to account for the other cases of real*imaginary,
>     imaginary*real, and imaginary*imaginary.  I don't see why only the
>     real*real case should be done...all or nothing, as I see it.  These
>     conditions now have tests, and there are a couple more tests for
>     tolerance on the imaginary/imaginary scenario, as well as the
>     complex/complex scenario.
>
>     By making the integerization (rounding) test more stringent, I
>     uncovered a bug whereby only the first element of the output single
>     row vector was rounded.
>
>     Dan
>
>
> I just ran into the fftfilt test failure again (bugs 37297 & 35959)
> and I narrowed it down to differences between FFTPACK and fftw3.
> octave with FFTPACK gets the test error:
>
> !!!!! test failed
> assert (fftfilt (b, r * x),r * r * [1, 1, 0, 0, 0, 0, 0, 0, 0, 0],eps)
> expected
>   Columns 1 through 3:
>       ...
>   maximum absolute error 2.22478e-16 exceeds tolerance 2.22045e-16
>
> rebuilding with fftw3 makes the error go away. Then I looked
> at the errors with fftpack and fftw3, ie the difference between
> the fftfilt output (a 10-element complex vector) and the expected vector:
>
>                  fftpack
> fftw3
>                  -------
> -----
>     3.4694469519536142e-18 + 2.2204460492503131e-16i
> 0.0000000000000000e+00 - 0.0000000000000000e+00i
>     1.3877787807814457e-17 + 2.2204460492503131e-16i
> 0.0000000000000000e+00 - 2.2204460492503131e-16i
>     3.1892503067014210e-17 + 2.0395767215548695e-17i
> 0.0000000000000000e+00 - 0.0000000000000000e+00i
>    -1.5476803848138888e-17 - 1.1721501528016046e-17i
> 0.0000000000000000e+00 - 0.0000000000000000e+00i
>    -5.5511151231257827e-17 - 5.2041704279304213e-17i
> 0.0000000000000000e+00 + 2.7755575615628914e-17i
>     0.0000000000000000e+00 - 6.9388939039072284e-17i
> 0.0000000000000000e+00 + 2.7755575615628914e-17i
>    -3.1892503067014198e-17 - 3.5115384015709088e-17i
> 0.0000000000000000e+00 - 0.0000000000000000e+00i
>     1.0999025841583994e-18 + 1.0166004376210030e-17i
> 0.0000000000000000e+00 + 5.5511151231257827e-17i
>    -3.4694469519536142e-18 - 0.0000000000000000e+00i
> 0.0000000000000000e+00 - 0.0000000000000000e+00i
>    -1.3877787807814457e-17 - 0.0000000000000000e+00i
> 0.0000000000000000e+00 - 5.5511151231257827e-17i
>
> some things to notice about these:
>
> 1) the largest error in both is in the imag part of the 2nd element
>     and is exactly eps, i.e. one ulp; no big surprise
>
> 2) the fftpack result has more "garbage" numbers but roughly the
>     same size as the garbage from fftw3 and all smaller than eps.
>
> 3) the reason the test fails with fftpack is that it was unlucky enough
>     to have put a bit of garbage in the real part of the second element
>     which made the abs of the element slightly larger than eps. Otherwise
>     the two results should be considered equivalent.

Keep in mind that you may have found the first instance of the tolerance 
limit being exceeded.  If the example were run for more trials worse 
excursions might result.

I think this was the test where I checked for large numbers of trials 
just to get an estimate of the probability of exceeding the limit.  It 
was surprising at first how large the error could be, but thinking about 
it, FFT has rather extensive computational "mixing", for lack of better 
phrase.


> 4) the fftw3 result passes the test because assert() uses the infinity
>     norm; had it used, e.g. the 2-norm the test would have failed.
>     These tests should not depend on which norm is used.

I'm curious if you ran the test with inf-norm for high numbers of trials.


> I propose fixing this test by replacing the tolerance eps with something
> like 2*eps*norm(z) where z = r*r*[1 1 0 0 0 0 0 0 0 0]. Just multiplying
> eps by 2 would fix this problem but tests like these should always account
> for the size of the things being tested.

I'm fine with that.  Especially in this case, as the FFT has a lot of 
computations in it.  However, there were one or two tests using 
degenerate inputs where the result should come out exact.


> I put a modified version of Dan's patch for bug #37297 on the tracker.
> In it I added norms to the test tolerances, so for example instead of
>
> assert (y0, y, 55*eps);
>
> I substituted
>
> assert (y0, y, 4*eps*norm(y));
>
> and it passes 10000 passes with both fftpack and fftw3.

In this case, 4*norm(y) is approximately 49.  I had come up with 55 by 
trial and error for large numbers of trials.  A scale factor of 50 was 
probably still causing tolerance failures if I chose 55, but I suspect 
the occurrence is still rare enough that the number who run the test 
will ever find a failure.  In other words, 49 is in the ballpark from 
the tests I did.

Dan

Re: [OctDev] Test failures due to tolerance in fftfilt.m

[Ed M. <ee...@gm...>]

On Fri, Sep 7, 2012 at 2:12 PM, Daniel J Sebald <dan...@ie...>wrote:

> On 09/06/2012 02:59 PM, Daniel J Sebald wrote:
>
>> I'll toss this one to Ed and Rik, since we were just talking about
>> precision issues for svds test failures...
>>
>> I checked the current state of tests and found this failure:
>>
>>  processing
>>>>>>> /usr/local/src/octave/octave/**octave/scripts/signal/fftfilt.**m
>>>>>>>
>>>>>> ***** test
>>
>
> There is a bit more to this, and I've put a patch on Savannah:
>
> https://savannah.gnu.org/bugs/**index.php?37297<https://savannah.gnu.org/bugs/index.php?37297>
>
> The routine will round the output if the inputs are integers and will
> truncate the imaginary component if both inputs are real.  That seems fair,
> I suppose.  (I do wonder though if there should be an option to remove this
> behavior because some might not want such a thing.  Any thoughts
> maintainers or OctDev?)  I've extended that concept to account for the
> other cases of real*imaginary, imaginary*real, and imaginary*imaginary.  I
> don't see why only the real*real case should be done...all or nothing, as I
> see it.  These conditions now have tests, and there are a couple more tests
> for tolerance on the imaginary/imaginary scenario, as well as the
> complex/complex scenario.
>
> By making the integerization (rounding) test more stringent, I uncovered a
> bug whereby only the first element of the output single row vector was
> rounded.
>
> Dan
>

I just ran into the fftfilt test failure again (bugs 37297 & 35959)
and I narrowed it down to differences between FFTPACK and fftw3.
octave with FFTPACK gets the test error:

!!!!! test failed
assert (fftfilt (b, r * x),r * r * [1, 1, 0, 0, 0, 0, 0, 0, 0, 0],eps)
expected
 Columns 1 through 3:
     ...
 maximum absolute error 2.22478e-16 exceeds tolerance 2.22045e-16

rebuilding with fftw3 makes the error go away. Then I looked
at the errors with fftpack and fftw3, ie the difference between
the fftfilt output (a 10-element complex vector) and the expected vector:

                fftpack                                                fftw3
                -------                                                -----
   3.4694469519536142e-18 + 2.2204460492503131e-16i
0.0000000000000000e+00 - 0.0000000000000000e+00i
   1.3877787807814457e-17 + 2.2204460492503131e-16i
0.0000000000000000e+00 - 2.2204460492503131e-16i
   3.1892503067014210e-17 + 2.0395767215548695e-17i
0.0000000000000000e+00 - 0.0000000000000000e+00i
  -1.5476803848138888e-17 - 1.1721501528016046e-17i
0.0000000000000000e+00 - 0.0000000000000000e+00i
  -5.5511151231257827e-17 - 5.2041704279304213e-17i
0.0000000000000000e+00 + 2.7755575615628914e-17i
   0.0000000000000000e+00 - 6.9388939039072284e-17i
0.0000000000000000e+00 + 2.7755575615628914e-17i
  -3.1892503067014198e-17 - 3.5115384015709088e-17i
0.0000000000000000e+00 - 0.0000000000000000e+00i
   1.0999025841583994e-18 + 1.0166004376210030e-17i
0.0000000000000000e+00 + 5.5511151231257827e-17i
  -3.4694469519536142e-18 - 0.0000000000000000e+00i
0.0000000000000000e+00 - 0.0000000000000000e+00i
  -1.3877787807814457e-17 - 0.0000000000000000e+00i
0.0000000000000000e+00 - 5.5511151231257827e-17i

some things to notice about these:

1) the largest error in both is in the imag part of the 2nd element
   and is exactly eps, i.e. one ulp; no big surprise

2) the fftpack result has more "garbage" numbers but roughly the
   same size as the garbage from fftw3 and all smaller than eps.

3) the reason the test fails with fftpack is that it was unlucky enough
   to have put a bit of garbage in the real part of the second element
   which made the abs of the element slightly larger than eps. Otherwise
   the two results should be considered equivalent.

4) the fftw3 result passes the test because assert() uses the infinity
   norm; had it used, e.g. the 2-norm the test would have failed.
   These tests should not depend on which norm is used.

I propose fixing this test by replacing the tolerance eps with something
like 2*eps*norm(z) where z = r*r*[1 1 0 0 0 0 0 0 0 0]. Just multiplying
eps by 2 would fix this problem but tests like these should always account
for the size of the things being tested.

I put a modified version of Dan's patch for bug #37297 on the tracker.
In it I added norms to the test tolerances, so for example instead of

assert (y0, y, 55*eps);

I substituted

assert (y0, y, 4*eps*norm(y));

and it passes 10000 passes with both fftpack and fftw3.

-- 
Ed Meyer

Re: [OctDev] DPCM

[Carnë D. <car...@gm...>]

Always make reply all and include the mailing list. Also, avoid top
posting, we use bottom posting on the mailing list. See

http://www.catb.org/jargon/html/B/bottom-post.html
http://www.idallen.com/topposting.html

On 9 October 2012 17:49, LEo <le...@gm...> wrote:
> On Fri, Oct 5, 2012 at 7:40 PM, Carnë Draug <car...@gm...> wrote:
>> On 5 October 2012 20:03, LEo <le...@gm...> wrote:
>>> Hello Carnë,
>>>
>>> A friend sugested me to add some checking for for input variables to
>>> give an appropriate error message when some crazy dude try to stick a
>>> string when it was expected a vector, and things like that.
>>> What do you think? Is it necessary? If so, let me know and I will do it.
>>> Another suggestion was to add References. Should I? How?
>>>
>>> Was the example/demo okay?
>>>
>>> Regards,
>>> LEo
>>
>> Hi Leonardo
>>
>> could you please upload them to
>> https://sourceforge.net/p/octave/feature-requests/40/ and follow this
>> there? This things get lost very easily on mailing lists.
>>
>> But one problem is that demos should be made into demo blocks, not a
>> separate demo script. Are you familiar with them?
>>
>> Carnë
>
> Unfortunately I am not familiar with demo blocks.
> Could you point me where can I find further information?

The best should be the manul though I think it could be improved

http://www.gnu.org/software/octave/doc/interpreter/Demonstration-Functions.html#Demonstration-Functions

See other code for examples (by convention, demos are placed at the
end of the function file):

http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/plot/plot.m
http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/general/interp2.m
http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/strings/strtok.m

This functins will have a micture of both demo and test blocks. Test
blocks are also very important as it allows you to find problems
during development much faster.

Carnë