Re: [OctDev] request for developer
ons, 22 07 2009 kl. 23:56 -0300, skrev Esteban Cervetto: In the last two months I have been writing source code to make an actuarial package for Octave. I have been finished the m files and the help files. Only left upload it formaly and your check. Could you guide me to reach it? It is always great to see new contributors :-) The OctaveForge project is very open, but we do require seeing source code before we give access to the subversion repository. Could you please send the code you wish to share to this list? Then somebody will have a look and provide feedback. If all is good, you will be given SVN access. Søren -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Moving lauchli.m into miscellaneous package and killing special-matrix
man, 20 07 2009 kl. 16:28 -0500, skrev Carlo de Falco: On 20 Jul 2009, at 15:00, Thomas Weber wrote: The reality is that most small packages are maintained by nobody. That's the reason why they stay small. I don't object reorganizing orphaned functions in a way that is more easy to maintain, I just don't think it is a good idea to put together in one package many functions that are different in scope. Okay, I've been holding out on this discussion as I wanted people to have a chance to speak up. (I get the impression that some people consider my opinions as being the final decisions, which really isn't the case) My opinion is that it is fine to combine packages as long as the resulting package isn't too much of a mess. So, I'm just saying we should deal with such issues case-by-case. In the specific situation I think it is fine to move 'leachli' and then kill 'special-matrix'. Søren -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Moving lauchli.m into miscellaneous package and killing special-matrix
man, 20 07 2009 kl. 08:02 -0500, skrev Carlo de Falco: I also believe this approach is more consistent with the packaging system phylosophy: In the near future (I should have finished doing this long time ago, sorry for my delay Søren ;) ) we expect to move to a release system where each package maintainer can take care of his/her package independently, so forcibly grouping functions that are maintained by different people would likely mess up things quite a bit... Hey, I should have finished this work long time ago, so you _really_ don't have any reason for apologising :-) Søren -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
[OctDev] Shipping data files for testing
Hi, the statistics package contains a few data files in a test/ directory. Shouldn't these files be part of the tarball, i.e. moved into inst/ ? Without them, tests for e.g. caseread.m fail. Thomas -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Shipping data files for testing
On Thu, Jul 23, 2009 at 12:40:46PM +0200, Søren Hauberg wrote: tor, 23 07 2009 kl. 12:32 +0200, skrev Thomas Weber: the statistics package contains a few data files in a test/ directory. Shouldn't these files be part of the tarball, i.e. moved into inst/ ? Without them, tests for e.g. caseread.m fail. I think we should have some way of allowing data to be shipped along with packages. I would like to distribute a few images with the 'image' package that I could use in demos. Right now I'm using synthetic images, which is really boring. Perhaps packages should be allowed to have a 'data' directory along with 'inst' and 'doc'? I think this would be better than storing both code and data in the same directory. Keep in mind that the code must be able to find the files. So, if you want a separate directory, I'd prefer a sub-directory of inst/. Thomas -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] nelder_mead_min and the use of lists in the optimization functions
Jaroslav Hajek wrote:
On Wed, Jul 22, 2009 at 5:54 PM, Jonathan Stickeljjstic...@vcn.com wrote:
I just checked in a small bug fix to the nelder_mead_min function
regarding some trouble with parsing the list or cell arguments. Someone
more familiar with the function might want to check that I didn't
break anything. I did check that the test script test_nelder_mead_min_1
passes all tests.
I found that my fix was not quite right. I have checked in another change.
Many of the minimization functions make use of lists in their argument
passing. This results in the warning
warning: list objects are deprecated; use cell arrays instead
It would be helpful if the authors of these functions could clean the
functions up to use exclusively cell arrays.
One last note: I noticed that someone ('highegg') recently changed the
names of fminunc and fzero to fminunc_compat and fzero_compat. Why the
name change? Wouldn't Matlab compatibility be better achieved by using
exactly the same name used in Matlab? I use fminunc in some of work,
including the data smoothing functions I contributed to the data
smoothing package.
the change is due to the fact that fminunc and fzero are now in core
Octave, so to avoid a name clash.
I think Octave's fzero is more Matlab compatible than the one in
OctaveForge, but otherwise roughly equivalent in functionality, so
maybe fzero_compat can be dropped. fminunc_compat (former fminunc) is
a mere wrapper to minimize.
OK, good to know about fminunc and fzero in octave proper. I know that
the old fminunc was a wrapper for minimize, but I preferred the user
interface of fminunc. I seem to have found a bug for the new fminunc
that I will report on the bugs list.
BTW, I find it confusing that optimization functions are split between
Octave and the octave-forge package. At one point, I thought there was
a plan to keep associated functions together, either all in Octave or in
the appropriate octave-forge package. I guess the split remains more
development oriented: polished functions make it to Octave where as
rough contributions remain in octave-forge.
Regards,
Jonathan
--
___
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Fwd: Octave 3.2.0 backend on MS Vista
On 23 Jul 2009, at 11:37, Richardson, Anthony wrote: Pressing 'u' unzooms, 'p' and 'n' go to the previous and next zoom level. More importantly, pressing 'h' while the plot window is active displays all options in the gnuplot terminal window. (Pressing 'h' does not display help when gnuplot is run through Octave.) Actually it does for me: __gnuplot_version__ ans = 4.2.5 version ans = 3.2.0 both installed via the OSX binary installer from octave forge Tony Richardson c. -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Fwd: Octave 3.2.0 backend on MS Vista
--- Gio 23/7/09, bagvian bagv...@gmail.com ha scritto: Da: bagvian bagv...@gmail.com Oggetto: Re: [OctDev] Fwd: Octave 3.2.0 backend on MS Vista A: tmacch...@yahoo.co.jp Cc: octave-...@lists.sourceforge..net Data: Giovedì 23 luglio 2009, 18:07 Dear Tatsuro, Many thanks for your exhaustive explanation. From a general point of view I would perfectly be happy to use gnuplot as a backend for Octave. It is a very nice piece of software that I frequently use to display data. The problem I am facing here is that gnuplot backend in Octave cannot be better than gnuplot itself. In other words : Say that you have got x y data saved in a text file called tmp..txt. For example looking like : 1 1 2 4 3 -1 4 2 5 5 6 0 You want to display these data with gnuplot. Just launch gnuplot and type something like : set term x11 plot tmp.txt using 1:2 w linespoints On the graph you get you can zoom-in by defining an area by right-clicking as you explained in your email, but you cannot zoom-out say 1-level out for example. This is precisely the same problem I encounter when trying to display data with Octave through gnuplot backend : I can zoom-in but cannot zoom-out. have you tried to press u on the gnuplot window? Press h for more help. At least on cygwin platform it works, so I will be surprised if mingw version lack it. The only silly solution I found both for gnuplot and Octave to zoom-out is to kill the figure and draw it again. Anybody has got a better solution? When using a piece of software to display big amount of detailed data you absolutely need to be able to very rapidly zoom-in and out at different positions to focus on what you are looking for. This is what I often do and unfortunately I cannot use either of these software that I enjoy using at any other occasion. Maybe it can be done, but in that case I do not know how and I would be very glad to learn this trick. Thanks again for the answers you have sent. Regards, JB Regards Marco -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Fwd: Octave 3.2.0 backend on MS Vista
--- Gio 23/7/09, Carlo de Falco carlo.defa...@gmail.com ha scritto: Da: Carlo de Falco carlo.defa...@gmail.com Oggetto: Re: [OctDev] Fwd: Octave 3.2.0 backend on MS Vista A: Richardson, Anthony a...@evansville.edu Cc: octave-dev@lists.sourceforge.net Data: Giovedì 23 luglio 2009, 19:03 On 23 Jul 2009, at 11:37, Richardson, Anthony wrote: Pressing 'u' unzooms, 'p' and 'n' go to the previous and next zoom level. More importantly, pressing 'h' while the plot window is active displays all options in the gnuplot terminal window. (Pressing 'h' does not display help when gnuplot is run through Octave.) Actually it does for me: __gnuplot_version__ ans = 4.2.5 version ans = 3.2.0 both installed via the OSX binary installer from octave forge Tony Richardson c. It works also in cygwin __gnuplot_version__ ans = 4.2.4 Marco -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] nelder_mead_min and the use of lists in the optimization functions
On Thu, Jul 23, 2009 at 5:30 PM, Jonathan Stickeljjstic...@vcn.com wrote:
Jaroslav Hajek wrote:
On Wed, Jul 22, 2009 at 5:54 PM, Jonathan Stickeljjstic...@vcn.com
wrote:
I just checked in a small bug fix to the nelder_mead_min function
regarding some trouble with parsing the list or cell arguments. Someone
more familiar with the function might want to check that I didn't
break anything. I did check that the test script test_nelder_mead_min_1
passes all tests.
I found that my fix was not quite right. I have checked in another change.
Many of the minimization functions make use of lists in their argument
passing. This results in the warning
warning: list objects are deprecated; use cell arrays instead
It would be helpful if the authors of these functions could clean the
functions up to use exclusively cell arrays.
One last note: I noticed that someone ('highegg') recently changed the
names of fminunc and fzero to fminunc_compat and fzero_compat. Why the
name change? Wouldn't Matlab compatibility be better achieved by using
exactly the same name used in Matlab? I use fminunc in some of work,
including the data smoothing functions I contributed to the data
smoothing package.
the change is due to the fact that fminunc and fzero are now in core
Octave, so to avoid a name clash.
I think Octave's fzero is more Matlab compatible than the one in
OctaveForge, but otherwise roughly equivalent in functionality, so
maybe fzero_compat can be dropped. fminunc_compat (former fminunc) is
a mere wrapper to minimize.
OK, good to know about fminunc and fzero in octave proper. I know that the
old fminunc was a wrapper for minimize, but I preferred the user interface
of fminunc. I seem to have found a bug for the new fminunc that I will
report on the bugs list.
BTW, I find it confusing that optimization functions are split between
Octave and the octave-forge package. At one point, I thought there was a
plan to keep associated functions together, either all in Octave or in the
appropriate octave-forge package. I guess the split remains more
development oriented: polished functions make it to Octave where as rough
contributions remain in octave-forge.
Er, not really. Yes, the dev status is a factor; for instance, source
must conform to Octave guidelines.
However, it's also about what is more and what is less common. For
instance, you have linear algebra in the core, but you also have other
advanced linear algebra in packages. It's the same with optimization;
I don't see what's confusing on that.
My intent was to bring to core Octave the 1D equation solver /
optimizer (fzero / fminbnd) and the local unconstrained
solver/optimizer (fsolve / fminunc). These both use established
techniques - bracketing + inverse interpolation in 1D, and local
Newton/BFGS iterations with trust-region step limiting and factorized
updating (Broyden/BFGS). There's a lot of similarity between the
fsolve and fminunc code. Both are designed for small-to-medium-size
problems (they use full matrices), and are local iterative methods.
Starting from a sufficiently good initial guess, with a smooth,
reasonably behaved problem, these methods will probably work well.
The optim package, on the contrary, should provide a variety of other
methods, for expert usage and more difficult problems, with
bound/linear/equality/inequality constrants, noisy functions, etc. It
is believed amongst numerical analysts that there is no single best
method, so there's no problem if optim contains competing methods.
I encourage you to use the fminunc from core if local unconstrained
search is enough for your purposes. So far it didn't get much testing,
so don't be too surprised if problems arise, but I hope it will
improve over time, when real usage is seen.
regards
--
RNDr. Jaroslav Hajek
computing expert GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
--
___
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] Fwd: Octave 3.2.0 backend on MS Vista
I forgot rely to octave-dev@lists.sourceforge.net
--- Tatsuro MATSUOKA tmacch...@yahoo.co.jp wrote:
Hello
The version of gnuplot for octave/windows mingw is
__gnuplot_version__
ans = 4.3.0-2008-11-21CVS.0octave-mingw32
The terminal is winows terminal but not x11 because gnuplot bundled is
gnuplot for windows.
Please try to execute the gnuplot in the /bin folder directly by doublly
clicking the icon
of
gnuplot.exe or type
system('gnuplot')
from octave prompt to execute gnuplot.
And type
gnuplot plot sin(x)
then gnuplot graph window appeared.
Please press 'h' on the keyboard at the condition that gnuplot graph window
is active.
You will find help of the key binds at zooming mode gnuplot in the gnuplot
console but not
graphic
window.
This help will be useful for you.
For the convinience I copied and paste the help to this mail
The lines '2xB1' to Shift-B2-Motion are help for mouse operation.
B1 is the left mouse button.
B2 is the right mouse button
B3 is the mouse wheel.
The lines after 'Space raise gnuplot console window' is key bind in
the gnuplot graph
window.
**
2xB1 print coordinates to clipboard using `clipboardformat`
(see keys '3', '4')
B2 annotate the graph using `mouseformat` (see keys '1', '2')
or draw labels if `set mouse labels is on`
Ctrl-B2 remove label close to pointer if `set mouse labels` is on
B3 mark zoom region (only for 2d-plots and maps).
B1-Motionchange view (rotation). Use ctrl to rotate the axes
only.
B2-Motionchange view (scaling). Use ctrl to scale the axes only.
Shift-B2-Motion vertical motion -- change xyplane
Space raise gnuplot console window
q* close this plot window
a `builtin-autoscale` (set autoscale keepfix; replot)
b `builtin-toggle-border`
e `builtin-replot`
g `builtin-toggle-grid`
h `builtin-help`
l `builtin-toggle-log` y logscale for plots, z and cb for splots
L `builtin-nearest-log` toggle logscale of axis nearest cursor
m `builtin-toggle-mouse`
r `builtin-toggle-ruler`
1 `builtin-decrement-mousemode`
2 `builtin-increment-mousemode`
3 `builtin-decrement-clipboardmode`
4 `builtin-increment-clipboardmode`
5 `builtin-toggle-polardistance`
6 `builtin-toggle-verbose`
7 `builtin-toggle-ratio`
n `builtin-zoom-next` go to next zoom in the zoom stack
p `builtin-zoom-previous` go to previous zoom in the zoom stack
u `builtin-unzoom`
Right `builtin-rotate-right` only for splots; shift increases
amount
Up `builtin-rotate-up` only for splots; shift increases amount
Left `builtin-rotate-left` only for splots; shift increases
amount
Down `builtin-rotate-down` only for splots; shift increases
amount
Escape `builtin-cancel-zoom` cancel zoom region
* indicates this key is active from all plot windows
*
Regards
Tatsuro
--- bagvian wrote:
Dear Tatsuro,
Many thanks for your exhaustive explanation.
From a general point of view I would perfectly be happy to use gnuplot
as a backend for Octave. It is a very nice piece of software that I
frequently use to display data. The problem I am facing here is that
gnuplot backend in Octave cannot be better than gnuplot itself.
In other words :
Say that you have got x y data saved in a text file called tmp.txt.
For example looking like :
1 1
2 4
3 -1
4 2
5 5
6 0
You want to display these data with gnuplot. Just launch gnuplot and
type something like :
set term x11
plot tmp.txt using 1:2 w linespoints
On the graph you get you can zoom-in by defining an area by
right-clicking as you explained in your email, but you cannot zoom-out
say 1-level out for example.
This is precisely the same problem I encounter when trying to display
data with Octave through gnuplot backend : I can zoom-in but cannot
zoom-out.
The only silly solution I found both for gnuplot and Octave to
zoom-out is to kill the figure and draw it again.
Anybody has got a better solution?
When using a piece of software to display big amount of detailed data
you absolutely need to be able to very rapidly zoom-in and out at
different positions to focus on what you are looking for. This is what
I often do and unfortunately I cannot use either of these software
that I enjoy using at any other occasion.
Maybe it can be done, but in that case I do not know how and I would
be very glad to learn this trick.
Re: [OctDev] optimization function strategy (was: nelder_mead_min and the use of lists in the optimization functions)
On 7/23/09 Jaroslav Hajek wrote: BTW, I find it confusing that optimization functions are split between Octave and the octave-forge package. At one point, I thought there was a plan to keep associated functions together, either all in Octave or in the appropriate octave-forge package. I guess the split remains more development oriented: polished functions make it to Octave where as rough contributions remain in octave-forge. Er, not really. Yes, the dev status is a factor; for instance, source must conform to Octave guidelines. However, it's also about what is more and what is less common. For instance, you have linear algebra in the core, but you also have other advanced linear algebra in packages. It's the same with optimization; I don't see what's confusing on that. My intent was to bring to core Octave the 1D equation solver / optimizer (fzero / fminbnd) and the local unconstrained solver/optimizer (fsolve / fminunc). These both use established techniques - bracketing + inverse interpolation in 1D, and local Newton/BFGS iterations with trust-region step limiting and factorized updating (Broyden/BFGS). There's a lot of similarity between the fsolve and fminunc code. Both are designed for small-to-medium-size problems (they use full matrices), and are local iterative methods. Starting from a sufficiently good initial guess, with a smooth, reasonably behaved problem, these methods will probably work well. The optim package, on the contrary, should provide a variety of other methods, for expert usage and more difficult problems, with bound/linear/equality/inequality constrants, noisy functions, etc. It is believed amongst numerical analysts that there is no single best method, so there's no problem if optim contains competing methods. I encourage you to use the fminunc from core if local unconstrained search is enough for your purposes. So far it didn't get much testing, so don't be too surprised if problems arise, but I hope it will improve over time, when real usage is seen. OK, seems reasonable. Are you planning to move fminbnd over to Octave sometime soon? I am rather pragmatic and can work with this approach. However, let me make a couple points you might consider. Matlab provides all of its optimization functions in the optimization toolbox; none are provided in core Matlab. I am sure they do this for monetary reasons (to sell more overpriced toolboxes), but folks migrating to Octave might get a little confused. Also, some of the Matlab optimization functions, e.g. fminunc, are not algorithm specific. The algorithm used depends on a passed option and/or the nature of the problem (detected internally by the function). This was sort of the philosophy used for the old fminunc in octave-forge. If we wanted to emulate this behavior, and I personally like the idea, then all the supported algorithms would need to be co-located with the fminunc function. Anyway, that's my 2 cents. Jonathan -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
Re: [OctDev] optimization function strategy
Hi, Oh, I never realized that fminbnd is a core function of Matlab and not in the core. I guess that's because you don't have to explicitely load toolboxes. Anyways, I know, because I had plans of working on it, that the fminbnd in Octave is much slower than the fminbnd in Matlab, because the Matlab function uses quadratic interpolation. That may be something to consider when moving an Octave function to the core. The principle of least surprise should apply. Florent Jonathan Stickel wrote: On 7/23/09 Jaroslav Hajek wrote: BTW, I find it confusing that optimization functions are split between Octave and the octave-forge package. At one point, I thought there was a plan to keep associated functions together, either all in Octave or in the appropriate octave-forge package. I guess the split remains more development oriented: polished functions make it to Octave where as rough contributions remain in octave-forge. Er, not really. Yes, the dev status is a factor; for instance, source must conform to Octave guidelines. However, it's also about what is more and what is less common. For instance, you have linear algebra in the core, but you also have other advanced linear algebra in packages. It's the same with optimization; I don't see what's confusing on that. My intent was to bring to core Octave the 1D equation solver / optimizer (fzero / fminbnd) and the local unconstrained solver/optimizer (fsolve / fminunc). These both use established techniques - bracketing + inverse interpolation in 1D, and local Newton/BFGS iterations with trust-region step limiting and factorized updating (Broyden/BFGS). There's a lot of similarity between the fsolve and fminunc code. Both are designed for small-to-medium-size problems (they use full matrices), and are local iterative methods. Starting from a sufficiently good initial guess, with a smooth, reasonably behaved problem, these methods will probably work well. The optim package, on the contrary, should provide a variety of other methods, for expert usage and more difficult problems, with bound/linear/equality/inequality constrants, noisy functions, etc. It is believed amongst numerical analysts that there is no single best method, so there's no problem if optim contains competing methods. I encourage you to use the fminunc from core if local unconstrained search is enough for your purposes. So far it didn't get much testing, so don't be too surprised if problems arise, but I hope it will improve over time, when real usage is seen. OK, seems reasonable. Are you planning to move fminbnd over to Octave sometime soon? I am rather pragmatic and can work with this approach. However, let me make a couple points you might consider. Matlab provides all of its optimization functions in the optimization toolbox; none are provided in core Matlab. I am sure they do this for monetary reasons (to sell more overpriced toolboxes), but folks migrating to Octave might get a little confused. Also, some of the Matlab optimization functions, e.g. fminunc, are not algorithm specific. The algorithm used depends on a passed option and/or the nature of the problem (detected internally by the function). This was sort of the philosophy used for the old fminunc in octave-forge. If we wanted to emulate this behavior, and I personally like the idea, then all the supported algorithms would need to be co-located with the fminunc function. Anyway, that's my 2 cents. Jonathan -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev -- ___ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
